Die 79-Prozent-Falle: Freigeben ist kein Prüfen

Die Zahl, die als Erfolg gemeldet wurde

Am 22.08.2024 berichtete Andy Jassy, CEO von Amazon, in einem Post von einer Migration, die intern gelaufen war. Rund 30.000 Produktionsanwendungen mussten von Java 8 auf Java 17 gehoben werden. Das ist die Sorte Arbeit, die jeder kennt und niemand will: Abhängigkeiten nachziehen, veraltete APIs ersetzen, Tests wieder grün bekommen. Pro Anwendung überschaubar, mal 30.000 eine Lebensaufgabe.

Genau deshalb war die Meldung eine gute Nachricht. Der Aufwand pro Anwendung fiel laut Jassy von rund 50 Entwicklertagen auf wenige Stunden. Unterm Strich standen über 4.500 eingesparte Entwicklerjahre und 260 Millionen Dollar jährliche Effizienzgewinne, letztere vor allem aus den Performance-Verbesserungen der neueren Java-Version. Der AWS-Blog zu Amazon Q Developer bestätigt die Größenordnungen: Zehntausende migrierte Produktionsanwendungen, über 4.500 eingesparte Entwicklerjahre für mehr als tausend Entwickler, 260 Millionen Dollar jährliche Einsparung.

In Jassys Post steht noch eine Zahl, und die beschreibt etwas anderes als Zeit und Geld. Sie lautet: "79% of the auto-generated code reviews were shipped without additional changes." 79 % der automatisch erzeugten Änderungen gingen ohne jede Nachbesserung in Produktion. Angeführt wurde sie als Beleg für die Treffsicherheit des Werkzeugs, und als solcher funktioniert sie gut. Vier von fünf Vorschlägen saßen auf Anhieb.

Diese Zahl gehört Jassys Post, der AWS-Blog nennt sie nicht.

Die zweite Lesart

Eine Akzeptanzrate misst nicht, wie gut ein Werkzeug ist. Sie misst, wie oft niemand etwas geändert hat. Das klingt nach derselben Aussage, ist aber eine andere.

Nimm zwei Teams. Das erste liest jede generierte Änderung durch, prüft die Logik, denkt die Edge Cases nach, findet in vier von fünf Fällen nichts zu beanstanden und gibt frei. Das zweite hat nach den ersten Wochen gemerkt, dass meistens sowieso alles passt, überfliegt den Diff und klickt durch. Beide Teams produzieren am Ende eine Akzeptanzrate von 79 %. Die Zahl ist identisch, die Sachlage ist es nicht.

Dem Code sieht man nicht an, welches der beiden Teams ihn freigegeben hat. Im Dashboard stehen beide gleich gut da. Der Unterschied liegt nicht im Ergebnis, sondern in dem, was auf dem Weg dorthin im Kopf eines Menschen passiert ist, und genau das erfasst keine Metrik. Eine hohe Akzeptanzrate ist deshalb kein Qualitätsnachweis, sondern ein Messwert mit zwei möglichen Ursachen.

Diesen Gedanken hat Russ Miles ausformuliert, in der Field Note "The Engineer They Stopped Trusting" in seinem Buch The Sovereign Apprentice. Wer er ist und was er sonst noch dazu schreibt, kommt weiter unten.

Vom Verifizierer zum Genehmiger

"Mensch im Loop" meinte ursprünglich etwas ziemlich Konkretes. Da sitzt jemand, der die vorgeschlagene Änderung nachvollziehen kann. Der weiß, warum sie funktioniert, der die Alternativen kennt und der aus eigener Autorität sagen kann: ja, das ist richtig. Nicht "sieht plausibel aus", sondern "ich habe es hergeleitet und komme zum selben Ergebnis". Das ist Verifikation.

Was daraus im Alltag wird, ist etwas anderes. Da gibt jemand frei, was er nicht selbst hergeleitet hat. Er prüft nicht mehr, ob die Lösung stimmt, sondern ob sie plausibel aussieht. Das ist Genehmigung, und sie ist eine schwächere Operation. Ein Gate, das vier von fünf Mal ohne Widerstand aufgeht, ist irgendwann kein Gate mehr, sondern ein Formular.

Das Unangenehme daran: Diese Verschiebung ist unsichtbar, während sie passiert. Niemand entscheidet sich morgens dafür, ab heute nur noch durchzuwinken. Es gibt keinen Tag, an dem man vom Verifizieren zum Genehmigen wechselt. Es ist eine Kette einzeln vernünftiger Entscheidungen: Der Vorschlag stimmte die letzten dreißig Mal, das Ticket ist alt, der Sprint ist eng, die Tests sind grün. Jede einzelne dieser Entscheidungen ist verteidigbar. Die Summe ist es nicht.

Das nimmt die Schuldfrage raus. Wer nur noch genehmigt, ist weder faul noch schlecht ausgebildet. Er reagiert vernünftig auf ein Werkzeug, das ihm über Wochen hinweg recht gegeben hat. Deshalb hilft es auch nicht, sich mehr Sorgfalt vorzunehmen. Was hilft, sind Techniken, die die Verschiebung sichtbar machen, bevor sie teuer wird.

Warum du die Kontrolle über KI-Ergebnisse behalten musst, steht in KI-Tools: Warum du die Verantwortung behältst. Hier geht es um die andere Hälfte: woran du merkst, dass du sie schon abgegeben hast.

Frühjahr 2026: ein Streit, den man kennen sollte

Kaum eine Debatte über KI-Code kommt derzeit ohne diesen Fall aus, und kaum eine liest ihn genau genug.

Am 05.03.2026 war der Amazon-Shop rund sechs Stunden lang gestört, betroffen waren Checkout, Login und die Anzeige von Produktpreisen. Als Ursache nannte Amazon selbst ein Software-Deployment.

Fünf Tage später berichtete CNBC über interne Unterlagen, die die Redaktion nach eigenen Angaben eingesehen hat. Darin schreibt Treadwell, SVP eCommerce Foundation, an die Belegschaft: "Folks - as you likely know, the availability of the site and related infrastructure has not been good recently." CNBC nennt vier Sev-1-Vorfälle innerhalb einer Woche. In einem internen Dokument standen "GenAI-assisted changes" zunächst als ein Faktor eines "trend of incidents" seit dem dritten Quartal. Vor einem internen Meeting dazu wurde dieser Punkt aus dem Dokument gestrichen, CNBC hat nach eigener Darstellung beide Fassungen gesehen.

Berichtet wurde außerdem, Amazon habe neue Freigabepflichten für Entwickler eingeführt, die mit KI-Werkzeugen arbeiten. Der Erstbericht zu den Vorgängen stammt von der Financial Times (hinter Paywall).

Amazon hat dem öffentlich widersprochen. Nur einer der Vorfälle habe überhaupt mit KI-Werkzeugen zu tun gehabt. Ausgelöst worden sei er dadurch, dass ein Entwickler einem ungenauen Ratschlag folgte, den ein KI-Werkzeug aus einem veralteten internen Wiki abgeleitet hatte. Die Ursache habe aber nicht bei der KI gelegen, sondern bei den eigenen Systemen, die diesen Bedienfehler eines Engineering-Teams weiter durchschlagen ließen, als er hätte durchschlagen dürfen. Kein Vorfall habe KI-geschriebenen Code betroffen. Zur berichteten Freigabepflicht schreibt das Unternehmen wörtlich: "That is false." Und die Financial Times habe einige ihrer ursprünglichen Behauptungen selbst korrigiert.

Von außen lässt sich dieser Streit nicht entscheiden, und für diesen Artikel muss er auch nicht entschieden werden. Das Argument hier hängt nicht an den Vorfällen des Frühjahrs 2026. Es hängt an der Zahl von 2024, die Amazons CEO selbst veröffentlicht hat und der niemand widerspricht: 79 % der generierten Änderungen gingen ohne Nachbesserung durch. Was diese Zahl über das Hinsehen aussagt, steht nicht in ihr drin, und genau das ist der Punkt.

Warum es Berufsanfänger zuerst trifft

Russ Miles nennt das die hohle Krone. Man trägt sie sichtbar, alle behandeln einen entsprechend, und darunter ist nichts, was sie halten würde. Ungefähr wie die Häuserfront in einem Filmset: von der Straße aus ein Gebäude, dahinter Latten und Luft. Der Output sieht aus wie die Arbeit von jemandem mit Jahren an Erfahrung, die man selbst nicht hat. Nur verteidigen, debuggen oder weiterentwickeln kann man ihn nicht.

Wer noch keine Routine hat, arbeitet anders als jemand mit zehn Jahren im Rücken. Er macht kleinere Schritte, weil er nach jedem einen Anhaltspunkt braucht, ob er noch richtig liegt. Er fragt jemanden, der die Sache schon mal gemacht hat. Und er lässt die Finger von dem, wo er die Folgen nicht abschätzen kann. Das sind keine Anfängerschwächen, sondern genau der Weg, auf dem Erfahrung entsteht.

Ein Werkzeug, das immer da ist und nie zögert, ersetzt alle drei auf einen Schlag. Der große Schritt kostet plötzlich so wenig wie der kleine, also macht man ihn. Die Rückfrage beim Kollegen entfällt, weil die Antwort schon dasteht, im Tonfall von jemandem, der sich sicher ist. Und das Riskante sieht nicht mehr riskant aus, weil die Lösung ordentlich aussieht und die Tests grün sind. Das Werkzeug beantwortet nur die Frage, die gestellt wurde, und tut das mit einer Selbstsicherheit, die es sich nicht verdient hat.

Daraus folgt nicht, dass Berufsanfänger die Finger von KI-Werkzeugen lassen sollen. Das wäre weder durchzuhalten noch klug, weil sie damit an Aufgaben herankommen, die früher zwei Jahre außer Reichweite lagen. Was sich verschiebt, ist der eigene Wert: Die Unterschrift unter einer Änderung ist die Währung geworden.

Und das ist die gute Nachricht daran. Dafür braucht es keine zwanzig Jahre. Wer sich angewöhnt, nur freizugeben, was er auch erklären kann, sammelt an jeder einzelnen Änderung genau die Erfahrung, die zählt. Darum geht es im Rest dieses Artikels, und der gilt für alle, nicht nur für die ersten Berufsjahre.

Der Falsifikationsreflex

Die übliche Frage beim Review lautet: Ist das korrekt? Das ist eine schlechte Frage, weil das Gehirn sie zu gern mit Ja beantwortet. Generierter Code sieht aus wie das, was man selbst geschrieben hätte, und wer nach Bestätigung sucht, findet sie. Also dreh die Frage um. Nicht "ist das korrekt", sondern "wie würde ich das widerlegen". Das Gehirn sucht damit nach dem Gegenbeispiel, und das ist ein anderer Auftrag. Drei Handgriffe, mit denen man sich das antrainiert.

Benenne vor dem Akzeptieren einen Fall, in dem die Änderung falsch wäre. Ein konkreter Fall, keine Kategorie: nicht "bei ungültigen Eingaben", sondern "wenn zwei Requests für dieselbe Bestellung innerhalb einer Sekunde ankommen". Dann prüfe, ob er eintreten kann. Fällt dir keiner ein, hast du die Änderung nicht verstanden, und das ist schon das Ergebnis.

Such dir die Stelle, die du nicht erklären kannst, und geh genau die durch. Der Reflex zieht einen zu dem Teil, der bekannt aussieht. Teuer ist der andere, bei dem man nur ungefähr ahnt, was er tut. Bei generiertem Code ist das oft eine Zeile, die ein Framework-Verhalten voraussetzt, das man nie nachgelesen hat.

Schreib einen Test, der scheitern müsste, wenn die Änderung falsch ist. Er soll nicht bestätigen, dass alles gut geht, er soll die Annahme angreifen, auf der die Änderung steht. Dann überzeug dich, dass er überhaupt rot werden kann: Nimm die Änderung lokal zurück oder mach die Annahme kaputt und lass ihn laufen. Bleibt er grün, prüft er etwas anderes als du denkst. Erst wenn er einmal rot war, ist sein Grün eine Aussage.

Das kostet Zeit, aber an der billigen Stelle. Dieselbe Frage drei Wochen später im Incident-Channel kostet ein Vielfaches.

Das Ledger im Pull Request

Schreib in die Beschreibung des Pull Requests, was generiert wurde, was du verifiziert hast und was du auf Treu und Glauben übernommen hast.

Das kostet drei Zeilen und verändert die Bedeutung der Freigabe. Ein Reviewer, der weiß, welche Teile ungeprüft durchgereicht wurden, liest anders. Und du merkst beim Tippen, dass du gleich etwas hinschreibst, was du eigentlich noch prüfen könntest.

Generiert: Retry-Handling in `PaymentClient`, Migration
`V47__add_order_index.sql`.

Verifiziert: Retry-Pfade von Hand durchgespielt, inklusive Timeout und
doppelter Zustellung. Migration gegen eine Kopie der Prod-Daten laufen
lassen und geprüft, welche Tabellen sie wie lange sperrt.

Ungeprüft übernommen: die Änderung an `application-staging.yml`. Ich
konnte sie lokal nicht testen und habe sie so gelassen, wie sie kam.

Die dritte Zeile ist die, um die es geht, und sie fühlt sich die ersten Male an wie ein Geständnis. Das ist beabsichtigt. Sie erfindet kein neues Risiko, sie macht sichtbar, was ohnehin der Fall war.

Damit das funktioniert, muss im Team klar sein, dass so eine Zeile kein Eingeständnis von Schlamperei ist. Wer sie schreibt, hat sauberer gearbeitet als jemand, der sie weglässt. Wenn die erste ehrliche dritte Zeile im Review abgewatscht wird, schreibt sie nie wieder jemand hin, und dann seid ihr genau da, wo ihr vorher wart, nur mit einem zusätzlichen Ritual.

Warum die Rate kein KPI werden darf

Bleibt eine Warnung, sonst hängt die Zahl in zwei Wochen als Kachel in einem Dashboard.

Eine Größe, die zwei gegensätzliche Zustände auf denselben Wert abbildet, taugt nicht zum Steuern. Als Zielgröße wird sie noch schlechter. Wer weiß, dass eine hohe Rate nach Durchwinken aussieht, ändert in jedem zweiten Diff einen Variablennamen. Wer weiß, dass eine niedrige nach schlechtem Werkzeugeinsatz aussieht, lässt die Kosmetik weg. Beides ist in zehn Sekunden erledigt und nicht zu widerlegen. Danach enthält die Zahl zusätzlich das Rauschen dieser Anpassungen, und man weiß weniger als vorher.

Als Gesprächsanlass ist die Rate trotzdem brauchbar. "Unsere Rate liegt seit drei Monaten bei 90 %, weiß jemand, woran das liegt?" ist eine gute Frage im Team. Dieselbe Zahl als Kennzahl mit Zielwert, an der am Jahresende etwas hängt, ist wertlos.

Welche Metriken bei KI-gestützter Arbeit überhaupt etwas hergeben, steht in KI-Produktivität: Warum die Zahlen trügen. Und was sich maschinell prüfen lässt, sollte die Maschine prüfen, damit die menschliche Aufmerksamkeit für die Stellen übrig bleibt, an denen keine Regel greift: Quality-Gates gegen KI-Fehler zeigt, wie das per Git-Hook geht.

Was davon im Alltag hängen bleiben muss, sind zwei Handgriffe, und die kosten zusammen ein paar Minuten pro Änderung: einen Fall benennen, in dem die Änderung falsch wäre, und in den Pull Request schreiben, was ungeprüft durchgegangen ist. Mehr braucht es nicht, damit die eigene Unterschrift unter einer Änderung wieder etwas bedeutet.

Weiterlesen

Russ Miles ist Software-Architekt und Autor, der sich mit KI-Literacy beschäftigt. Das Bild der hohlen Krone stammt aus seinem Buch The Sovereign Apprentice. Der Apprentice richtet sich an Berufsanfänger und alle, die sie anleiten, The Sovereign Engineer an Erfahrene. Beide laufen über Leanpubs Pay-what-you-want-Modell, der Mindestpreis liegt beim Apprentice bei 0 US-Dollar, beim Engineer bei 19. Zum Harness-Ansatz für systematische Verifikation folgt demnächst ein eigener Artikel.