Verstehen, Gestalten, Prüfen: Wie wir mit KI-generiertem Code umgehen

Der 2026 Software Engineering Benchmarks Report (opens in new tab) von LinearB hat 8,1 Millionen Pull Requests aus 4.800 Teams ausgewertet. Mit KI erstellte Pull Requests wurden in 32,7 % der Fälle innerhalb von 30 Tagen gemergt. Pull Requests ohne KI-Unterstützung: 84,4 %.

Das heißt nicht, dass KI schlechten Code schreibt. Es heißt, dass zwei Drittel der KI-erzeugten Änderungen es binnen eines Monats nach dem Öffnen nicht in die Codebasis geschafft haben. Irgendwo zwischen Öffnen und Merge wurden diese Änderungen als nicht richtig, nicht fertig, nicht verstanden oder nicht gewollt beurteilt – oder sie bekamen nie die Aufmerksamkeit, die nötig gewesen wäre, um sie überhaupt zu beurteilen. Genau dieses Urteil ist heute die eigentliche Arbeit.

Agenten haben das Schreiben von Code billig gemacht. Sie haben nicht billig gemacht, zu wissen, was geschrieben werden soll, und auch nicht, sicher zu sein, dass es stimmt. Wenn Sie Individualsoftware einkaufen, bezahlen Sie genau für diese beiden Dinge. In diesem Beitrag geht es darum, wie wir sie angehen.

Die Arbeit ist nicht weniger geworden. Sie hat sich verlagert.

Das meistzitierte Experiment zu dieser Frage ist nach wie vor die randomisierte kontrollierte Studie von METR aus dem Jahr 2025 (opens in new tab). Sechzehn erfahrene Open-Source-Entwickler bearbeiteten 246 echte Issues in großen Repositories, die sie gut kannten. Wenn KI-Werkzeuge erlaubt waren, brauchten sie 19 % länger. Vor der Studie hatten sie mit einer Beschleunigung um 24 % gerechnet; hinterher glaubten sie immer noch, etwa 20 % schneller gewesen zu sein.

Gern wird das als „KI macht Entwickler langsamer“ herumgereicht. Das ist die falsche Lehre, und METR sagt das selbst: Die Autoren behaupten ausdrücklich nicht, dass KI die meisten Entwickler nicht beschleunigt, und ihr eigenes Follow-up vom Februar 2026 (opens in new tab) deutet bei wiederkehrenden Teilnehmenden auf eine Beschleunigung hin (geschätzt 18 %, mit einem Konfidenzintervall von 38 % schneller bis 9 % langsamer). METR bezeichnet diese neueren Daten allerdings selbst als unzuverlässig – unter anderem, weil so viele Entwickler gar nicht mehr ohne KI arbeiten wollten: Zwischen 30 und 50 % der Teilnehmenden gaben an, Aufgaben zurückgehalten zu haben, weil sie diese nicht ohne KI erledigen wollten.

Unsere Lehre daraus ist enger gefasst und nützlicher. Einer der Faktoren, die METR für die Verlangsamung 2025 anführt: KI schneidet vergleichsweise schlechter ab, wo sehr hohe Qualitätsstandards und viele implizite Anforderungen gelten – Dokumentation, Testabdeckung, Konventionen, die nie jemand aufgeschrieben hat. Das ist eine präzise Beschreibung von Unternehmenssoftware, die fünfzehn Jahre laufen muss. Der Engpass war nie das Tippen. Es war das Implizite, und Agenten kennen es nicht, solange es ihnen niemand sagt.

Die Arbeit von Entwicklern ist also nicht kleiner geworden. Sie hat sich auf drei Stellen konzentriert:

1. Verstehen – das Problem so gut durchdringen, dass das Implizite explizit wird.
2. Gestalten – die Architektur entwerfen und schriftlich festhalten, damit der Agent innerhalb vereinbarter Leitplanken arbeitet.
3. Prüfen – das Ergebnis so kritisch reviewen, dass ein Engineer für jede Zeile die Verantwortung übernehmen kann.

Bei der Code-Produktion dazwischen helfen Agenten wirklich. Der Rest dieses Beitrags geht die drei Verben der Reihe nach durch.

Verstehen: Agenten verstärken, was Sie ihnen geben

Das DORA-Team von Google hat seine Forschung 2025 zur KI-gestützten Entwicklung (opens in new tab) in einem Satz zusammengefasst: Die Hauptrolle von KI ist die eines Verstärkers, der die vorhandenen Stärken und Schwächen einer Organisation vergrößert. Den aus unserer Sicht wichtigsten Befund enthält das DORA AI Capabilities Model (opens in new tab): Ein konsequenter Fokus auf die Nutzer verstärkt den positiven Effekt von KI auf die Teamleistung – und ohne diesen Fokus kann die Einführung von KI negative Auswirkungen haben. In DORAs Worten: Teams bewegen sich dann womöglich einfach schnell in die falsche Richtung.

Das deckt sich damit, wie Agenten in der Praxis scheitern. Selten liefern sie Code, der nicht kompiliert. Sie scheitern, indem sie selbstbewussten, sauber strukturierten, gut getesteten Code liefern, der ein leicht anderes Problem löst. Laut Stack Overflow Developer Survey 2025 (opens in new tab) ist der größte Frust mit KI-Werkzeugen, genannt von 66 % der Befragten, „Lösungen, die fast richtig sind, aber eben nicht ganz“. Fast richtig ist die teuerste Art von falsch, weil sie einen flüchtigen Blick übersteht.

Stellen Sie sich einen Großhändler vor, der „automatische Zahlungserinnerungen“ haben möchte. Ein Agent, dem man genau diesen Satz gibt, liefert an einem Nachmittag einen sauberen Scheduler, eine E-Mail-Vorlage und eine Testsuite. Was er nicht weiß: dass Key Accounts mit Rahmenverträgen niemals eine automatische Erinnerung erhalten dürfen, dass Skonto das Fälligkeitsdatum verschiebt, dass Teilzahlungen an der Tagesordnung sind und dass die Mahnstufen zu dem passen müssen, was die Buchhaltung heute schon von Hand macht. Nichts davon steht im Ticket. Alles davon steckt in den Köpfen der Menschen, die diese Arbeit heute erledigen.

Ein Entwickler, der das von Hand schreibt, wäre auf halber Strecke auf diese Fragen gestoßen und hätte nachgefragt. Ein Agent füllt die Lücke mit einem plausiblen Standardwert und macht weiter. Schnelle Generierung beseitigt genau die Reibung, durch die Missverständnisse früher ans Licht kamen.

Deshalb halten wir das Verstehen des Problems heute für die Engineering-Tätigkeit mit der größten Hebelwirkung – und nicht für eine Formalie im Vertrieb. Konkret lautet eine gute Regel: Bevor irgendeine Implementierung generiert wird, sollte der Engineer die Sonderfälle, die Ausnahmen und die „das darf nie passieren“-Regeln im Vokabular des Kunden benennen können. Kann der Engineer das nicht, kann es der Agent erst recht nicht – und der zurückkommende Code schreibt eine Vermutung fest.

Gestalten: Schriftliche Entscheidungen sind die Leitplanken des Agenten

Unsere erste harte Regel: Architekturentscheidungen werden schriftlich festgehalten und mit dem Kunden abgestimmt, bevor Agenten Implementierungscode generieren. Datenmodell, Modulgrenzen, Integrationspunkte, wo Zustand liegt, wie Fehler sichtbar werden, welche Abhängigkeiten wir akzeptieren. Kurze Dokumente in verständlicher Sprache, freigegeben von den Menschen, die mit dem System leben werden.

Dafür gibt es zwei Gründe, und nur einer davon betrifft den Agenten.

Der offensichtliche Grund: Eine schriftliche Entscheidung ist Kontext, den der Agent nutzen kann. DORA zählt „AI-accessible internal data“ (für KI zugängliche interne Daten) zu seinen sieben Fähigkeiten. Ein Agent, der lesen kann „Rechnungen sind nach Ausstellung unveränderlich; Korrekturen sind neue Belege“, trifft weniger falsche Entscheidungen als einer, der das aus der Codebasis erschließen muss.

Der weniger offensichtliche Grund wiegt schwerer: Die schriftliche Entscheidung ist der Maßstab für das Review. Agenten befolgen Anweisungen nicht zuverlässig, egal wie sorgfältig sie formuliert sind. Birgitta Böckelers praktische Evaluation von Werkzeugen für Spec-Driven Development (opens in new tab) auf martinfowler.com berichtet genau das: Sie sah häufig, dass der Agent am Ende nicht alle Anweisungen befolgte – einschließlich eines Falls, in dem er Notizen zu bestehenden Klassen ignorierte und diese duplizierte. Eine Spezifikation ist also keine Garantie. Sie ist das, woran man das Ergebnis misst. Ohne schriftliche Entscheidung kann ein Reviewer nur fragen: „Sieht das vernünftig aus?“ Mit einer kann er fragen: „Tut das, was wir vereinbart haben?“ – und das ist eine weitaus schärfere Frage.

Wie viel aufschreiben?

Böckelers Beitrag benennt auch das Scheitern auf der anderen Seite: ein kleiner Bugfix, den ein Werkzeug in vier User Stories mit sechzehn Akzeptanzkriterien verwandelte – mit Kanonen auf Spatzen geschossen –, und Berge von repetitivem Markdown, die schwerer zu reviewen waren als der Code selbst. Wir stimmen ihr zu: Überspezifikation ist ein reales Problem.

Unsere Sicht: Entscheidungen sollten auf der Ebene festgehalten werden, auf der eine falsche Wahl teuer rückgängig zu machen wäre – Datenmodell, Grenzen, Integrationen, Sicherheit und Datenschutz. Wir schreiben keine Spezifikation pro Button. Böckeler unterscheidet „spec-first“ (die Spezifikation wird nach dem Feature verworfen) von „spec-anchored“ (die Spezifikation bleibt erhalten und entwickelt sich mit dem Code weiter). Für Architektur halten wir die zweite Variante für die einzig vertretbare. Ein System im Mittelstand überlebt die Engineers, die es gebaut haben, und die nächste Person muss wissen, warum die Grenzen dort verlaufen, wo sie verlaufen – nicht nur, wo sie verlaufen.

Und weil der Kunde diese Entscheidungen freigibt, ist der Kunde Teil der Leitplanke. Das ist Absicht. Schlägt ein Agent eine Änderung vor, die eine vereinbarte Grenze überschreitet, ist das kein Kommentar im Code-Review. Es ist ein Gespräch mit dem Kunden.

Prüfen: Unsere Regeln, bevor irgendetwas gemergt wird

Auf diesen Teil verweist unsere Seite So arbeiten wir, deshalb werden wir hier konkret. Unsere Kernregel ist schnell formuliert:

Ein Engineer prüft, versteht und verantwortet jede Zeile, bevor sie gemergt wird. Nicht der Agent, nicht „das Team“, kein Bot. Ein namentlich benannter Engineer, der jede Zeile der Änderung auf Nachfrage erklären kann.

Addy Osmani hat in Own the Outer Loop (opens in new tab) dasselbe Argument gemacht: Agenten können den inneren Zyklus aus Untersuchen, Implementieren und Verifizieren übernehmen, aber Menschen verantworten die Grenzen, die Quality Gates und das finale Urteil – weil jemand erklären können muss, was sich geändert hat, warum es sicher war und was passiert, wenn man sich geirrt hat. Wir stimmen dem vollständig zu. Verantwortung, die sich nicht an ein Werkzeug delegieren lässt, muss bei einem Menschen landen, und dieser Mensch muss verstehen, was er unterschreibt.

Vier Dinge sind bei jeder Änderung Standard und keine optionalen Extras:

• Tests. Generierter Code kommt ohne Vorgeschichte. Tests sind der Weg, ihm eine zu geben – und der Weg, über den der nächste Engineer herausfindet, was der Code eigentlich tun soll.
• TypeScript mit strikter Typisierung. Typen sind eine Spezifikation, die der Compiler bei jedem Build prüft. Wenn Agenten Code in großer Menge produzieren, ist eine Einschränkung, die die Maschine kostenlos durchsetzt, das günstigste Review, das wir je bekommen werden.
• Quality Gates. Typprüfung, Linting, Testsuite und ein Produktions-Build laufen bei jeder Änderung automatisch, und eine Änderung, die eines davon nicht besteht, wird nicht gemergt. Die Gates ersetzen den Reviewer nicht. Sie sorgen dafür, dass seine Aufmerksamkeit bei den Fragen landet, die keine Maschine beantworten kann.
• Dokumentation, die mit dem Code mitgeht. Ändert sich Verhalten, eine Schnittstelle, die Konfiguration oder eine Architekturentscheidung, wird die zugehörige Dokumentation in derselben Änderung aktualisiert – nicht „später“. Veraltete Dokumentation führt den nächsten Engineer in die Irre und ebenso den nächsten Agenten, denn Agenten lesen sie als Kontext.

Was wir zurückweisen – und warum

Das sind unsere festen Gründe, eine Änderung zurückzuschicken. Keiner davon hängt davon ab, ob ein Mensch oder ein Agent den Code geschrieben hat; sie gelten für beide. Agenten lösen sie nur häufiger aus.

• Code, den niemand im Team erklären kann. Kann der Reviewer ihn nicht erklären, kann ihn niemand warten. Das ist die Verantwortungsregel, wörtlich angewendet. Unser Beitrag zu Verständnisschulden erklärt, warum diese Rechnung im zweiten Jahr kommt und nicht in der ersten Woche.
• Änderungen, die von der vereinbarten Architektur abweichen. Eine neue Datenbanktabelle, über die niemand gesprochen hat, Logik in der falschen Schicht, eine Abkürzung quer durch eine Modulgrenze. Der Code mag funktionieren. Er bricht trotzdem eine Vereinbarung mit dem Kunden.
• Code ohne Tests. Keine Ausnahmen für „ist doch nur Glue Code“. Gerade im Glue Code scheitern Integrationen.
• Übergroße Diffs, die sich nicht reviewen lassen. Eine Änderung mit zweitausend Zeilen wird nicht reviewt, sondern überflogen. DORAs Capabilities Model hebt das Arbeiten in kleinen Schritten als besonders wirkungsvoll im Zusammenspiel mit KI hervor. Wir teilen große Änderungen vor dem Review auf, nicht danach.
• Duplizierte Hilfsfunktionen, statt bestehende zu erweitern. Agenten schreiben mit Vorliebe ein neues formatDate, statt das vorhandene zu finden. Jedes Duplikat ist eine künftige Inkonsistenz.
• Stillschweigend verschluckte Fehler. Ein leerer catch-Block oder ein Fallback, der einen Fehler verdeckt – so wird ein System falsch, ohne dass es jemand bemerkt. Fehler werden bewusst behandelt oder sichtbar gemacht.
• Änderungen, die die Dokumentation zurücklassen. Tut der Code etwas, das die Dokumentation nicht beschreibt, ist die Dokumentation falsch – und falsche Dokumentation ist schlimmer als keine. Die Änderung geht zurück, bis beides übereinstimmt.
• Neue Abhängigkeiten, die niemand gewählt hat. Jedes Paket ist eine Entscheidung über Lieferkette, Lizenz und Wartung. Ein Agent, der eines hinzufügt, weil es bequem war, hat keine Entscheidung getroffen.

Die Incident-Daten hinter dieser Disziplin (den Cortex-Benchmark 2026) und weitere Review-Techniken finden Sie in unserem früheren Beitrag zur Review-Disziplin.

Die ehrlichen Zielkonflikte

Diese Arbeitsweise ist pro Pull Request langsamer, als einfach zu übernehmen, was der Agent produziert. Wir werden nicht so tun, als wäre es anders.

Die Branchendaten zeigen, wo die Kosten anfallen. Im LinearB-Datensatz warteten von KI-Agenten erstellte Pull Requests im 75. Perzentil 17,6 Stunden auf ein Review, gegenüber 3,4 Stunden bei Arbeit ohne KI-Unterstützung. Das Review ist jetzt der Engpass, und wer ernsthaft reviewt, spürt diesen Engpass stärker, nicht schwächer. Der Stack Overflow Survey (opens in new tab) liefert die andere Seite: 45,2 % der Entwickler sagten, das Debugging von KI-generiertem Code sei zeitaufwendiger. Die bei der Generierung gesparte Zeit wird bei der Verifikation teilweise wieder fällig. Teams, die die Verifikation auslassen, sind nicht schneller; sie haben die Zahlung nur aufgeschoben.

Gleichzeitig hielten wir es für unehrlich, Agenten als Modeerscheinung abzutun. METRs Update von 2026 ist unübersichtlich, aber der Grund dafür ist aufschlussreich: Entwickler weigerten sich zunehmend, ohne KI zu arbeiten. Nach unserer Einschätzung helfen Agenten wirklich bei:

• Boilerplate und Scaffolding innerhalb einer bereits bestehenden Struktur,
• dem Generieren von Testfällen, besonders der mühsamen Sonderfälle, die ein Mensch auslässt,
• mechanischen Refactorings und Migrationen mit klaren Vorher-nachher-Regeln,
• dem Lesen von unbekanntem Code und dessen Zusammenfassung als Ausgangspunkt für einen Menschen,
• dem schnellen Skizzieren von zwei oder drei alternativen Ansätzen, zwischen denen der Engineer wählen kann.

Achten Sie auf das Muster. Agenten sind dort am stärksten, wo die Entscheidung bereits getroffen ist und es um die Ausführung geht. Am schwächsten sind sie genau dort, wo die drei Verben zu Hause sind.

Was das einen Kunden kostet, ist Zeit am Anfang: Workshops, um die impliziten Regeln sichtbar zu machen, Entscheidungen, die gelesen und freigegeben werden wollen, und Review-Zeit, die im Plan auftaucht. Was es einbringt, ist eine Codebasis, in der jede Zeile jemanden hat, der sie verantwortet und erklären kann, in der die Architektur dokumentiert ist, weil sie abgestimmt werden musste, deren Dokumentation noch zum Code passt und die das nächste Team – unseres oder ein anderes – übernehmen kann. Für Software, die ein Unternehmen ein Jahrzehnt lang trägt, halten wir das für den einzig vernünftigen Tausch.

Was Sie jeden Softwaredienstleister fragen sollten

Wenn Sie 2026 Individualsoftware einkaufen, gehen Sie davon aus, dass der Anbieter KI-Agenten einsetzt. Das ist nicht die Frage. Diese hier sind es:

1. Wer verantwortet jede Zeile? Fragen Sie, ob ein namentlich benannter Engineer jede Änderung vor dem Merge prüft und erklären kann. Fragen Sie, was passiert, wenn er es nicht kann.
2. Wo sind die Architekturentscheidungen festgehalten? Lassen Sie sie sich zeigen. Fragen Sie, ob Sie diese freigeben, bevor die Implementierung beginnt.
3. Wie bringen Sie die Regeln ans Licht, die nie jemand aufgeschrieben hat? Hören Sie auf Workshops, Listen mit Sonderfällen und fachliche Rückfragen – nicht nur auf „Schicken Sie uns die Anforderungen“.
4. Sind Tests, strikte Typisierung und automatische Quality Gates Standard oder Extras? Werden sie als Zusatzleistung bepreist, fallen sie unter Termindruck weg.
5. Wird die Dokumentation mit jeder Änderung aktualisiert oder einmal bei der Übergabe geschrieben? Am Ende geschriebene Dokumentation beschreibt das System so, wie sich jemand daran erinnert, nicht so, wie es ist.
6. Was weisen Sie zurück? Ein Anbieter ohne Antwort darauf hat keinen Review-Standard, sondern einen Merge-Button.
7. Wie groß ist eine typische Änderung? Kleine, reviewbare Inkremente sind ein Zeichen von Disziplin. Riesige wöchentliche Lieferungen sind ein Zeichen, dass niemand sie gelesen hat.
8. Könnte ein anderes Team diesen Code übernehmen? Die ehrliche Antwort hängt vollständig von den vorherigen sieben ab.

Keine dieser Fragen erwähnt KI. Genau darum geht es. Die Werkzeuge haben sich verändert. Was Software vertrauenswürdig macht, nicht: Jemand hat das Problem verstanden, jemand hat sie bewusst gestaltet, und jemand ist bereit, mit seinem Namen für das Ergebnis einzustehen.

Weiterführende Literatur

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (opens in new tab)
• METR, We are Changing our Developer Productivity Experiment Design (Update vom Februar 2026) (opens in new tab)
• DORA, 2025 State of AI-assisted Software Development (opens in new tab)
• Google Cloud, Introducing DORA's inaugural AI Capabilities Model (opens in new tab)
• Stack Overflow, 2025 Developer Survey: AI (opens in new tab)
• LinearB, AI in software development: what the 2026 data shows (opens in new tab)
• Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (opens in new tab)
• Addy Osmani, Own the Outer Loop (opens in new tab)
• Unsere Beiträge: Das 23,5-Prozent-Problem und Verständnisschulden sind die eigentliche KI-Steuer