KI macht das Programmieren leichter. Sie stellt auch neue Anforderungen.

Was wirklich leichter geworden ist

KI-Assistenten für das Programmieren sind in bemerkenswert kurzer Zeit von der Kuriosität zum Standard geworden. In Googles DORA-Studie 2025 mit fast 5.000 Technologiefachleuten nutzen 90 % KI bei der Arbeit, im Median zwei Stunden am Tag, und mehr als 80 % sagen, dass sie dadurch produktiver geworden sind.¹ In der Stack-Overflow-Umfrage unter mehr als 49.000 Entwicklerinnen und Entwicklern nutzen 84 % KI-Werkzeuge oder planen es, und die Hälfte der professionell Entwickelnden nutzt sie täglich.^4,5

Die Gewinne sind real, wo die Arbeit klar umrissen ist: Boilerplate-Code, Tests für bestehendes Verhalten, Übertragung zwischen Sprachen und Frameworks, erste Entwürfe von Dokumentation und das Erkunden einer unbekannten Codebasis. DORA stellt außerdem fest, dass die Einführung von KI inzwischen mit einem höheren Liefer-Durchsatz einhergeht, eine Umkehr des Befunds von 2024.²

Dieselbe Studie bringt die Einführung von KI jedoch weiterhin mit geringerer Lieferstabilität in Verbindung.² Diese Kombination aus mehr Output und weniger Stabilität ist das Signal, dass sich noch etwas anderes verändert hat.

Wohin sich der Engpass verlagert hat

Code zu schreiben war nie die ganze Arbeit. Eine Änderung muss spezifiziert, geschrieben, geprüft, getestet, ausgerollt und betrieben werden. KI verkürzt einen dieser Schritte drastisch. Die anderen bleiben, und manche wachsen, weil es jetzt mehr Code zu prüfen gibt und er schneller ankommt.

Die Studienlage weist in dieselbe Richtung. Zwei Drittel der Entwicklerinnen und Entwickler sagen, ihr größtes Ärgernis seien KI-Ergebnisse, die fast richtig sind, aber nicht ganz, und 45 % sagen, das Debuggen von KI-generiertem Code koste mehr Zeit.⁴ Das Vertrauen sinkt, während die Nutzung steigt: Der Anteil derer, die der Genauigkeit von KI misstrauen, stieg innerhalb eines Jahres von 31 % auf 46 %.⁵

Auch die eigene Wahrnehmung ist ein unzuverlässiger Maßstab. In einer randomisierten Studie von METR arbeiteten 16 erfahrene Open-Source-Entwicklerinnen und -Entwickler an 246 echten Aufgaben in großen, ausgereiften Repositories. Waren KI-Werkzeuge erlaubt, dauerten die Aufgaben 19 % länger. Vor der Studie hatten sie eine Beschleunigung um 24 % erwartet; danach glaubten sie noch immer, KI habe sie um 20 % schneller gemacht.⁶ Eine größere Folgestudie mit 57 Entwicklerinnen und Entwicklern, veröffentlicht im Februar 2026, deutete auf eine moderate Beschleunigung mit großer Unsicherheit hin; METR selbst nannte das Signal unzuverlässig, unter anderem weil viele Entwicklerinnen und Entwickler nicht mehr ohne KI arbeiten wollen.⁷

Die Lehre daraus ist nicht, dass KI nicht hilft. Sondern dass der Gewinn außerhalb des Editors entschieden wird: daran, wie klar Arbeit spezifiziert wird, wie gut sie geprüft wird und wie sicher sie in die Produktion gelangt.

Sieben neue Anforderungen

Aus dem Bau und Betrieb von Software, die rund um die Uhr läuft, mit KI im täglichen Arbeitsablauf, sehe ich sieben Anforderungen, die heute wichtiger sind als früher. Keine davon ist im Grundsatz neu. Neu ist, dass es kurzfristig billiger und langfristig teurer geworden ist, sie zu ignorieren.

Die Spezifikation wird zum neuen Quellcode

Wenn eine Maschine den ersten Entwurf schreibt, entscheidet die Qualität der Anweisung über die Qualität des Entwurfs. Teams, die Absicht, Randbedingungen und Abnahmekriterien aufschreiben, bevor sie Code generieren lassen, erhalten brauchbare Ergebnisse. Teams, die das überspringen, erhalten Code, der kompiliert, einen kurzen Blick übersteht und an den Rändern versagt. In der Praxis hat sich die wertvollste Fähigkeit erfahrener Entwicklerinnen und Entwickler verschoben: vom Schreiben von Code zur präzisen Beschreibung dessen, was der Code tun muss und was er nicht tun darf.

Review ist keine Formalität mehr

Eine Nutzerstudie aus Stanford ergab, dass Teilnehmende mit einem KI-Assistenten deutlich weniger sicheren Code schrieben als jene ohne, und eher glaubten, ihr Code sei sicher.⁸ Das ist das Kernrisiko KI-gestützter Entwicklung: nicht, dass die Maschine Fehler macht, sondern dass Menschen weniger sorgfältig prüfen, weil das Ergebnis fertig aussieht. Review muss als Ingenieursarbeit mit Zeit und Verantwortung behandelt werden, nicht als Klick vor dem Merge.

Die Lieferkette ist jetzt Teil des Codes

Package Hallucination macht aus dem Fehler eines Modells eine Angriffsfläche. In einer Analyse von 576.000 generierten Codebeispielen aus 16 Modellen fanden Forschende mehr als 200.000 eindeutige Namen von Paketen, die es nicht gibt.¹¹ OWASP führt dieses Muster ausdrücklich auf und empfiehlt Gegenprüfung und menschliche Aufsicht.¹² Zugleich hebt die Regulierung die Messlatte: Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen, die in der EU verkauft werden, nach dem Cyber Resilience Act aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle innerhalb von 24 Stunden mit einer Frühwarnung melden, gefolgt von einer Meldung innerhalb von 72 Stunden; die Hauptpflichten gelten ab dem 11. Dezember 2027.¹⁴ Der Rechtsakt verlangt außerdem eine Software-Stückliste (SBOM) in der technischen Dokumentation.¹⁵ Ein Team, das nicht weiß, was in seiner Software steckt, kann diese Pflichten nicht erfüllen, egal wie der Code geschrieben wurde.

Verantwortung lässt sich nicht generieren

Rechtliche Fragen folgen derselben Logik. In den USA hat das Copyright Office erklärt, dass KI-Output nur geschützt ist, wo ein Mensch ausreichend gestaltende Elemente bestimmt hat; Prompts allein genügen nicht.¹⁶ Unabhängig von der Rechtsordnung ist die praktische Antwort dieselbe: Jemand im Team muss jede ausgelieferte Komponente verstehen, verantworten und erklären können.

Vom Werkzeug zur Teampraxis

Der nützlichste Befund von DORA ist einfach: KI ist ein Verstärker. Sie macht starke Teams effizienter und verschärft die Probleme von Teams, die ohnehin kämpfen. Lose gekoppelte Architekturen profitieren; eng gekoppelte gewinnen kaum.² DORA hat inzwischen sieben Fähigkeiten beschrieben, die aus der Einführung von KI Ergebnisse machen.³

In den Systemen, die ich baue und betreibe, wird daraus eine Regel: Jede von KI geschriebene Änderung durchläuft genau dasselbe Tor wie eine menschliche. Sie liegt auf einem eigenen Branch, wird automatisch gebaut und getestet, in eine Vorschau ausgerollt und von einer namentlich benannten Person freigegeben, bevor sie in die Produktion gelangt. Änderungen bleiben klein, damit das Review aussagekräftig bleibt. Die KI ist schnell; das Tor hält sie sicher. Das kostet bei jeder Änderung etwas Tempo und spart über die Lebensdauer eines Systems sehr viel davon.

Für Führungskräfte bedeutet das: Investitionen in KI-Werkzeuge für das Programmieren sollten mit Investitionen in die Praktiken drumherum einhergehen: eine ausdrückliche KI-Richtlinie, Kapazität für Reviews, automatisierte Tests und ein klarer Überblick über die Abhängigkeiten. Ohne diese beschleunigt das Werkzeug eher das Anhäufen von Problemen als die Lieferung von Nutzen.

Was die Studienlage noch nicht sagen kann

Die Forschung ist jung und entwickelt sich schnell. Umfragen erfassen Wahrnehmung, und die METR-Studie zeigt, dass diese stark vom gemessenen Effekt abweichen kann.⁶ Kontrollierte Studien sind klein (die Stanford-Sicherheitsstudie wertete 47 Teilnehmende aus⁸) und schwer zu wiederholen, und das jüngste METR-Update nennt sein eigenes Signal unzuverlässig.⁷ Sicherheitsstudien testen einzelne Codebeispiele, nicht vollständige Systeme mit Review und Tests. Und die Werkzeuge werden von Quartal zu Quartal besser.

Was über alle Befunde hinweg gilt, ist die Richtung: Die Kosten, Code zu erzeugen, sind gesunken, und der Wert von Urteilsvermögen, Prüfung und Verantwortung ist gestiegen. Teams, die diese Verschiebung einplanen, bekommen die Geschwindigkeit der KI, ohne später dafür zu bezahlen.

Häufige Fragen