Connect with us

Künstliche Intelligenz

KI-Code: Schneller geschrieben, langsamer getestet


Generative KI hat die Produktivität beim Programmieren deutlich erhöht. Eine Studie von GitHub Research zeigt, dass Entwickler Programmieraufgaben in kontrollierten Experimenten mit KI-Assistenz rund 55 Prozent schneller erledigen als ohne Unterstützung. Doch der Geschwindigkeitsgewinn beim Schreiben von Code mittels KI-Systemen bedeutet nicht automatisch, dass Softwareprojekte insgesamt schneller vorankommen. Eine Untersuchung des Forschungsinstituts METR (Model Evaluation and Threat Research) zeigt, dass erfahrene Entwickler bei Arbeiten in vertrauten Code-Umgebungen mit KI-Werkzeugen im Schnitt 19 Prozent länger benötigen – vor allem wegen zusätzlicher Prüf- und Korrekturschritte. Ein Grund: Sie müssen sich bei Fehlern erst in den von der KI erzeugten Code einarbeiten.

Weiterlesen nach der Anzeige

Da Testen, Debugging und Verifikation schon in der herkömmlichen Softwareentwicklung rund die Hälfte des Zeitaufwands ausmachen, schlagen Verzögerungen bei diesen Arbeiten besonders stark auf die Projektlaufzeit durch. Mit KI-Werkzeugen beim Programmieren verschiebt sich der Engpass: Das Erzeugen von Code wird einfacher und schneller – der Nachweis, dass er korrekt funktioniert und freigegeben werden kann, bleibt aufwendig. Das wiegt umso schwerer, weil die Kosten für Fehler mit jeder späteren Projektphase steigen. Eine vielzitierte Analyse des IBM Systems Sciences Institute beziffert den Unterschied: Während der Implementierung ist die Behebung eines Fehlers sechsmal teurer als in der Designphase. Beim Testen steigt der Faktor auf 15, in der Produktion auf bis zu 100. Gerade in komplexen Unternehmenssystemen wird das zum Problem. Moderne Anwendungen bestehen aus vielen Services, Programmierschnittstellen (APIs) und Datenquellen. Eine Änderung an einer Stelle kann unerwartete Nebenwirkungen an vielen anderen auslösen. Je schneller KI-Werkzeuge neuen Code produzieren, desto häufiger entstehen solche Wechselwirkungen – und damit zusätzliche Fehlerquellen.

Um diesen Engpass abzumildern, kommen zunehmend KI-Systeme auf den Markt, die neue oder geänderte Programme schneller testen sollen. Das führt jedoch zu einem grundlegenden Wandel in der Testmethodik. Klassisches Softwaretesten folgt einem deterministischen Modell: gleicher Input, gleiches Programm, identischer Output. Genau darauf beruhen Testläufe, bei denen Funktionen mit definierten Parametern aufgerufen werden und exakt die erwarteten Ergebnisse liefern müssen. Doch bei KI-Systemen gilt dieses Prinzip nur noch eingeschränkt. Große Sprachmodelle und andere generative Verfahren arbeiten auf Basis statistischer Wahrscheinlichkeiten und liefern Ergebnisse innerhalb einer Bandbreite möglicher Antworten. Die Qualität eines Systems lässt sich deshalb nicht mehr allein mit Ja-Nein-Tests überprüfen. Entscheidend ist, ob sich das Verhalten innerhalb akzeptabler Grenzen bewegt. Damit verschiebt sich auch der Fokus der Qualitätssicherung (QA). Statt vollständiger Testabdeckung rückt ein risikobasierter Ansatz in den Vordergrund: Kritische Funktionen und Schnittstellen prüfen Teams intensiver, weniger relevante Teile mit geringerer Tiefe. Ziel ist nicht mathematische Vollständigkeit, sondern eine belastbare Einschätzung des Restrisikos.

Zu den Anbietern KI-gestützter Werkzeuge gehören Keysight Eggplant, SmartBear, OpenText und Tricentis. Letzterer hat kürzlich eine „Agentic Quality Engineering Platform“ vorgestellt – eine Plattform, auf der autonom agierende KI-Agenten Qualitätssicherungsaufgaben übernehmen. Sie unterstützt unter anderem die SAP-GUI und Web-Anwendungen. Hierzu nutzt die Plattform generative KI, um Testfälle zu erzeugen, bestehende Tests zu priorisieren und Ergebnisse großer Testläufe zusammenzufassen. Technisch geht es dabei weniger um „KI testet Software“ als um die Unterstützung typischer QA-Arbeitsschritte: Änderungen im Code analysieren, relevante Tests auswählen, Fehlermeldungen gruppieren oder umfangreiche Logdateien verdichten. Der Ansatz zielt auf einen der zeitaufwendigsten Schritte im Testprozess: die Auswertung großer Mengen von Testergebnissen. In Continuous-Integration-Umgebungen laufen oft mehrere tausend Tests pro Commit, deren Resultate Entwickler anschließend interpretieren müssen. KI-Werkzeuge können helfen, Muster schneller zu erkennen und Fehlerursachen besser einzugrenzen. Der Nutzen verschiebt sich damit vom Generieren einzelner Tests hin zur Organisation und Auswertung ganzer Testlandschaften.

Trotz dieser Entwicklungen bleibt der Einsatz KI-basierter Tests begrenzt. Viele Aspekte der Softwarequalität lassen sich nicht aus Testläufen ableiten. Dazu gehören Sicherheitsprobleme, strukturelle Code-Schwächen oder die Vermeidung technischer Schulden – also aufgeschobener Wartungs- und Modernisierungsarbeiten, die langfristig den Entwicklungsaufwand erhöhen. Solche Fragen betreffen die Architektur einer Anwendung und nicht nur ihr Laufzeitverhalten. Statische Codeanalyse (Static Analysis), die den Quellcode ohne Ausführung auf Fehler und Schwachstellen untersucht, Security Audits und klassische Code Reviews bleiben daher notwendig. Generative KI kann hier allenfalls Hinweise liefern, ersetzt aber keine systematische Analyse. Besonders bei sicherheitskritischen Anwendungen ist automatisches KI-Testing kein ausreichender Qualitätsnachweis.

Weiterlesen nach der Anzeige

Diese Grenzen führen zu einem Grundprinzip moderner Entwicklungsprozesse: Der Mensch bleibt Teil der Entscheidungskette. Automatisierte Tests können Hinweise liefern und große Datenmengen auswerten, doch die Freigabe eines Releases bleibt eine Risikoabwägung. In vielen Unternehmen entscheiden deshalb weiterhin Entwickler- oder QA-Teams darüber, ob eine neue Softwareversion in Produktion gehen darf. KI kann diesen Prozess beschleunigen, indem sie Informationen verdichtet und Routineaufgaben übernimmt. Die Verantwortung für die Freigabe bleibt jedoch beim Menschen. Wie riskant eine unzureichende Kontrolle ist, zeigten jüngst durch KI-Tools verursachte Ausfälle bei Amazon, nach denen der Konzern strengere Prüfmechanismen einführte.

Generative KI beschleunigt das Schreiben von Code erheblich, erhöht aber zugleich den Aufwand für dessen Verifikation. Mehr generierter Code bedeutet mehr Varianten, mehr Integrationspunkte und damit mehr potenzielle Fehlerrisiken. KI kann beim Erzeugen von Testfällen und bei der Analyse großer Testläufe helfen, löst aber nicht alle Qualitätsprobleme. Fragen der Sicherheit, Architektur und technischer Schulden bleiben Aufgaben von Entwicklern und Review-Prozessen. Entscheidend bleibt: Ob eine Softwareversion in Produktion gehen darf, ist eine menschliche Entscheidung.

Lesen Sie auch


(fo)



Source link

Künstliche Intelligenz

Matter sei Dank: Ambilight-TVs sprechen wieder mit Hue und auch Lampen von Ikea


Die Lichterweiterung AmbiScape soll Lampen im Raum im Takt mit dem Bildinhalt an Philips Ambilight-TVs leuchten lassen. So finden sich AmbiScape ab diesem Jahr in allen Philips Fernsehern ab der 8001er-Reihe, mithin in allen OLED-Modellen aus 2026 und den neuen RGB-Mini-LED-Fernsehers der Serie 981. Als weitere Voraussetzung nennt Philips das Titan-Betriebssystem, bisherige Google-TVs werden AmbiScape demnach nicht unterstützen.

Weiterlesen nach der Anzeige

Wer Ambilight-Fernseher mit Lampen im Raum verbinden wollte, um die Lichteffekte auf diese auszuweiten, hatte mit TV-Modellen ab 2023 ein Problem: Weil den neueren Ambilight-Fernsehern die eingebaute Hue-Kompatibilität fehlt, kommunizierten sie weder mit der Hue Bridge Pro des ausgegliederten Lichtkonzerns Signify noch mit dessen Hue-Lampen.

Den Hue-Ersatz AmbiScape hatte Philips bereits Ende 2025 eher heimlich bei einigen Fernsehern mit Ambilight eingeführt. Ob auch diese in den Genuss der Lichterweiterung kommen werden, ist noch offen.

AmbiScape basiert auf dem offenen Matter-Kommunikationsprotokoll und kann darüber neben einigen Hue-Lampen auch Thread-kompatible Leuchtmittel anderer Hersteller einbinden. Aktuell unterstützt Philips neben den Philips-Leuchten Hue White und Color Ambience auch die Systeme von Ikea (Tradfri LED Bulb und Dirigera Hub), Nanoleaf (Smart Bulb), Wiz (E27 Smart Bulb) und Osram (LED Bulb). Künftig können das außer klassischen Leuchtmitteln auch LED-Streifen sein, zunächst beschränkt sich die Auswahl aber auf E27-Leuchtmittel. Auch wer noch eine Philips Hue-Bridge 2.0 besitzt, kann diese weiter nutzen. Sie hat vor einiger Zeit ein Update für Matter-Support erhalten.



In einem Auswahlmenü legt man die Position der Lampen im Raum und zum Fernseher fest und kann im Ambilight-Menü zusätzlich den gewünschten Effekt einstellen.

(Bild: Ulrike Kuhlmann / heise medien)

Die genannten Ambilight-TVs aus 2026 können mit AmbiScape nun bis zu vier smarte Lampen im Raum gleichzeitig ansteuern, um den Lichteffekt der farbigen LEDs im TV-Gehäuse auf den Raum auszuweiten. Im Unterschied zur vormaligen Hue-Lösung sind derzeit nur einfarbige Anpassungen und keine Farbverläufe wie Sonnenaufgänge möglich, da der Matter-Standard diese noch nicht unterstützt. Die per AmbiScape respektive Matter angebundenen Lampen reagieren mit einer geringen Verzögerung auf Änderungen des Bildinhalts. Philips spricht von 0,5 Sekunden, in der in Berlin gezeigten Umsetzung fiel der Delay nicht störend auf.

Um AmbiScape zu aktivieren, muss man den Fernseher zunächst über einen Matter-QR-Code einmalig mit den kompatiblen smarten Lampen verbinden. Anschließend lässt sich AmbiScape per Direktwahltaste auf der Fernbedienung oder über das Ambilight-Menü in den TV-Einstellungen starten. Man kann bis zu zehn Lampen registrieren und die vier Gewählten jeweils über ein Untermenü in einer Zone zum Fernseher platzieren. Zusätzlich lässt sich die Leuchtstärke der Lampen einstellen.

Weiterlesen nach der Anzeige

Philips bietet zudem drei Ansteuermodi an: die Synchronisation mit Ambilight im Video-Modus, außerdem eine dynamische Lichtsteuerung im Musik-Modus und für sehr ruhige Stimmungen eine feste Farbwiedergabe in einer ausgewählten Farbe.


(uk)



Source link

Weiterlesen

Künstliche Intelligenz

Schwer zu finden: Apple spielt Background-Security-Improvement-Update aus


Mini-Update mitten in der Nacht: Apple hat sein erstes sogenanntes Background Security Improvement, kurz BSI, für Nutzer von iOS, macOS und iPadOS ausgespielt. Damit wird eine Sicherheitslücke im Apple-Browser Safari (beziehungsweise dessen Browser-Engine WebKit) geschlossen. Allerdings ist die Installation keineswegs simpel, Apple hat sie sogar gut versteckt – und zwar an einer Stelle, wo viele User erst gar nicht suchen. Selbst wenn zuvor automatische Updates aktiviert wurden, spielte sich das BSI nicht ein, wie Tests in der Mac & i-Redaktion zeigten.

Weiterlesen nach der Anzeige

BSIs sollen laut Apple dazu dienen, „Updates zwischen Updates“ zu ermöglichen, damit Nutzer nicht zu lange auf Aktualisierungen warten müssen, falls zwischen größeren Update-Paketen Lücken auftauchen. Der Vorteil der BSIs ist auch, dass sie meist nur einen kurzen Reboot der Geräte erfordern – manchmal sogar keinen –, der üblicherweise schneller ist als ein normaler Neustart.

Die nun geschlossene Lücke scheint auf den ersten Blick nicht extrem kritisch zu sein: Es geht darum, böswillige Websites davon abzuhalten, die sogenannte Same Origin Policy zu umgehen. Damit könnte auf Daten in anderen Browser-Fenstern oder Browser-Tabs zugegriffen werden. Ob es bereits dazu kam, ist unklar. Apple nennt in seinen Release Notes zumindest keine „bekannten Berichte“, wie das bei schon vorhandenen Exploits der Fall ist.

Das Problem: Apple setzt auf eine andere Verteilinfrastruktur – und BSIs können sogar untergehen. Statt unter „Allgemein“ und „Softwareupdate“, wie normale Updates, findet man BSIs unter „Datenschutz & Sicherheit“. Dort muss man dann ganz nach unten scrollen zu „Im Hintergrund ausgeführte Sicherheitsverbesserungen“ (deutscher Begriff für BSIs). Hier kann man dann „Automatisch installieren“ aktivieren, wobei selbiges wie erwähnt zumindest bei unseren Versuchen nicht erfolgte – es kann dauern, da sich Apple hier einige Tage Zeit lässt.

Ansonsten taucht hier jedes neue BSI auf, das man dann anklicken muss, um es zu installieren – nach Eingabe der PIN. Die Installation selbst erfolgt wie erwähnt recht schnell. Warum Apple BSIs nicht einfach im Bereich „Softwareupdate“ aufführt, bleibt unklar.

Weiterlesen nach der Anzeige


(bsc)



Source link

Weiterlesen

Künstliche Intelligenz

Oracle: Souveränitätsversprechen zwischen Anspruch und Wirklichkeit


Auf der Oracle AI World in Frankfurt präsentierten führende Oracle-Manager ihre Pläne für eine verteilte, souveräne und KI-fähige Cloud-Infrastruktur. Im Mittelpunkt stand die Frage, wie Unternehmen angesichts wachsender Datenschutzanforderungen und einer zunehmend fragmentierten Cloud-Landschaft handlungsfähig bleiben können. Andrew Bond, CTO von Oracle EMEA, setzte den Rahmen: Oracle sei nicht einfach ein weiterer Hyperscaler, sondern unterscheide sich architektonisch deutlich von der Konkurrenz. Ob diese Behauptung trägt, muss sich in der Praxis zeigen – die Argumente waren aber durchaus substanziell.

Weiterlesen nach der Anzeige

Oracles EU Sovereign Cloud läuft nach eigenen Angaben seit knapp drei Jahren in Frankfurt und Madrid. Sie wird ausschließlich von EU-Personal betrieben und ist vom öffentlichen Oracle-Cloud-Netz physisch getrennt. Technisch basiert sie auf denselben OCI-Bausteinen wie die öffentliche Cloud, läuft aber in einem eigenen, isolierten Realm. Damit reagiert Oracle auf eine zentrale Sorge europäischer Kunden: Daten sollen die EU nicht verlassen, und die Betriebsverantwortung liegt nachweislich in der EU.

Antonio Freitas, bei Oracle EMEA für die Sovereignty-Strategie verantwortlich, erläuterte in einer Roundtable-Session die Entwicklung des Angebots: Sein Team habe intensiv mit EU-Institutionen wie der Europäischen Kommission, ENISA und nationalen Regulierungsbehörden zusammengearbeitet. Das Ziel: die Anforderungen an souveräne Cloud-Infrastruktur nicht nur zu verstehen, sondern sie frühzeitig in die Produktentwicklung einfließen zu lassen. Inwieweit Oracle damit näher an einer EUCS-Zertifizierung (EU Cloud Services Scheme) ist als etwa AWS oder Azure, blieb auf der Veranstaltung allerdings offen.

Dass das Konzept in der Praxis trägt, sollte ein Kundenbeispiel belegen: Stefan Moch, VP von Arvato Systems, berichtete über den Betrieb von Arzneimittel-Verifikationssystemen gemäß der EU-Richtlinie FMD (Falsified Medicines Directive). Das System verarbeite allein in Deutschland täglich fünf bis sechs Millionen Apothekentransaktionen und europaweit rund 35 bis 40 Millionen Packungsverifizierungen. Hochverfügbarkeit und niedrige Latenzzeiten seien ausschlaggebend gewesen. Unabhängig überprüfbar waren diese Leistungswerte auf der Veranstaltung nicht.

Ein Argument, das Bond in der Keynote mehrfach unterstrich: Oracle berechnet für Cloud-Dienste in Europa denselben Preis wie in den USA. Da der Rechenzentrumsbetrieb in Deutschland deutlich teurer sei, bedeute das für europäische Kunden einen erheblichen Kostenvorteil. Oracle beziffert die Einsparungen gegenüber Mitbewerbern auf 30 bis 50 Prozent – wohlgemerkt nach Eigenangaben, nicht unabhängig geprüft.

Tatsächlich zeigen öffentlich einsehbare Preislisten, dass AWS und Azure für die Region Frankfurt häufig höhere Listenpreise aufrufen als für US-Regionen. Ob die Oracle-Rechnung unter Berücksichtigung von Enterprise-Rabatten, Reserved Instances und Committed-Use-Modellen der Mitbewerber in dieser Höhe standhält, bleibt offen. Kunden sollten hier eigene TCO-Vergleiche anstellen.

Weiterlesen nach der Anzeige

Neben der öffentlichen Cloud und der EU Sovereign Cloud stellte Oracle seine Dedicated Region und das Alloy-Modell vor. Die Dedicated Region ermöglicht es Unternehmen, die vollständige OCI-Infrastruktur inklusive SaaS, PaaS und IaaS im eigenen Rechenzentrum zu betreiben, ab drei Racks. Vodafone hat damit nach Oracle-Angaben 40 Rechenzentrumsstandorte in sechs Dedicated Regions konsolidiert, zwei davon in Deutschland.

Das Alloy-Modell setzt anders an: Partner können eigene Cloud-Angebote auf OCI-Basis aufbauen. Als Referenzen nannte Oracle die japanische Sovereign Cloud von Fujitsu und die Thai Cloud von AIS. Konzeptionell erinnert Alloy an Angebote der Konkurrenz wie AWS Outposts, Azure Stack oder Googles Distributed Cloud. Durch die vollständige SaaS-Verfügbarkeit hebt sich Oracle aber ab. Oracle betont, dass es sich bei allen Varianten technisch um exakt dieselbe Plattform handelt.

Ein weiterer Schwerpunkt war Oracles Multi-Cloud-Strategie. Das Unternehmen hat Teile seiner OCI-Infrastruktur direkt in Rechenzentren von Microsoft Azure, Google Cloud und AWS integriert. Oracle-Datenbankservices wie die Autonomous Database lassen sich dort nativ nutzen. Wer etwa Amazon Bedrock mit einer Oracle-Datenbank kombinieren will, muss keine Daten in eine andere Umgebung migrieren.

Passend dazu kündigte Oracle die Multi-Cloud Universal Credits an: ein einheitliches Verbrauchsmodell, das Oracle-Datenbankservices flexibel zwischen OCI, AWS, Azure und Google Cloud verschiebbar machen soll – ohne jeweils neue Vertragsverhandlungen. Die Idee klingt in Zeiten schnell wechselnder KI-Strategie, die zuletzt für ein starkes Umsatzwachstum im Cloud-Geschäft sorgten plausibel, wirft aber auch Fragen auf: Wie portabel sind Workloads in der Praxis wirklich, wenn sie auf Oracle-proprietäre Features wie die Autonomous Database angewiesen sind? Echte Multi-Cloud-Portabilität bleibt auch bei Oracle an das eigene Ökosystem gebunden.

Oracle begründet seine Leistungs- und Kostenargumentation mit grundlegenden Architekturentscheidungen. Anders als AWS und Azure setzt Oracle konsequent auf Bare-Metal-Instanzen: Workloads laufen direkt auf dedizierter Hardware ohne Hypervisor-Overhead – das soll besonders datenbankintensiven Anwendungen zugutekommen. Für die Netzwerkanbindung setzt Oracle sowohl auf RoCE (RDMA over Converged Ethernet) statt auf InfiniBand und kombiniert das mit der hauseigenen Acceleron-Architektur, um Verkabelungsaufwand bei großen GPU-Clustern zu reduzieren. Beide Entscheidungen haben allerdings auch Kehrseiten: Ohne Hypervisor entfällt die flexible Ressourcenverteilung zwischen Workloads, und ob RoCE bei sehr großen Cluster-Topologien mit dem Congestion-Management von InfiniBand mithalten kann, ist in der Branche umstritten.

Den Abschluss der Veranstaltung bildete Oracles KI-Strategie. Mit der AI Data Platform will Oracle private Unternehmensdaten sicher mit generativen KI-Modellen verbinden, statt eigene Foundation Models zu entwickeln. Kernelement ist die Autonomous Database, die neben relationalen Daten auch Vektoren, JSON, Graph- und Spatial-Daten unterstützt und sich über offene Formate wie Apache Iceberg mit externen Datenspeichern verbinden lässt.

Der Ansatz, sich als Datenplattform für KI zu positionieren, statt im Wettlauf um eigene Modelle mitzumischen, ist nachvollziehbar: Die meisten Unternehmen kämpfen weniger mit der Verfügbarkeit von Modellen als mit der Integration und Governance ihrer eigenen Daten. Konkrete Referenzkunden aus dem deutschsprachigen Raum blieb Oracle allerdings schuldig.

Oracle präsentierte sich auf der AI World als relevante Alternative für Unternehmen mit hohen Anforderungen an Datensouveränität und Datenbankperformance. Die Sovereign-Cloud-Architektur, das einheitliche Pricing und die Multi-Cloud-Integration sind nachvollziehbare Unterscheidungsmerkmale gegenüber den drei großen Hyperscalern. Naturgemäß blieben die zentralen Versprechen auf einer solchen Marketingveranstaltung ungeprüft. Kunden sollten Kostenvorteile anhand eigener Workloads validieren und hinterfragen, wie portabel ihre Anwendungen tatsächlich sind, wenn sie tief in Oracle-proprietäre Features investiert haben.

Lesen Sie auch


(fo)



Source link

Weiterlesen

Beliebt