Wenn KI den Code schreibt, wird Urteilskraft zur Arbeit

Anthropic hat vor Kurzem eine Zahl geteilt, die viele zum Innehalten bracht hat: Claude schreibt inzwischen mehr als 80 Prozent des Production Code, den ihre eigenen Engineering-Teams ausliefern. Ihre Ingenieure versenden täglich etwa achtmal mehr als noch 2024. Das sind keine Prognosen. Das passiert gerade wirklich in einem der sorgfältigsten KI-Labs der Welt.

Die erste Reaktion in den meisten Agentur- und Produktgesprächen ist, diese Zahl zu feiern. Schneller Output. Niedrigere Kosten pro Feature. Mehr Laufzeit bei gleicher Kopfzahl. Das alles stimmt. Aber die interessantere Frage ist diejenige, die niemand beim Sprint Planning stellt: Wenn das System, das den Code schreibt, auch das System verbessert, das Code schreibt, wer trifft dann eigentlich die Entscheidungen?

Die Schleife, die keiner an die Tafel gezeichnet hat

Es gibt hier eine spezifische Dynamik, die es wert ist, präzise zu benennen, weil die vage Version davon zu vagem Denken führt.

Ein Entwickler, der einen KI-Coding-Assistenten nutzt, ist immer noch der Autor. Er setzt das Ziel, prüft den Output, committed den Code, trägt die Verantwortung. Das Modell ist ein sehr schnelles, sehr fähiges Werkzeug. So sehen die meisten Produktteams ihre Situation.

Aber wenn das Modell bereits die Mehrheit seiner eigenen Infrastruktur, Test Suites und Tools generiert, ändert sich die Beziehung. Der Engineer ist nicht mehr Autor. Er ist Aufseher. Und Aufsicht bei der achtfachen Geschwindigkeit bedeutet: Jede Review-Entscheidung trägt mehr Gewicht, nicht weniger, weil der Schaden eines übersehenen Fehlers größer ist.

Das ist keine Theorie. Anthropic ringen öffentlich damit, ob selbstverbessernde KI eine koordinierte globale Entwicklungspause rechtfertigt. Dass sie die Frage überhaupt stellen, zeigt: Diese Schleife ist real. Und die Menschen, die ihr am nächsten sind, nehmen sie ernst.

Was das für Agenturen und Produktteams bedeutet

Die meisten Agenturen sind nicht Anthropic. Du bauest keine Frontier-Modelle. Aber die gleiche strukturelle Frage stellt sich im kleineren Maßstab, und sie kommt schneller, als die meisten Teams bemerkt haben.

Wenn deine Developer mit KI die meisten Codezeilen schreiben, hat sich deine eigentliche knappe Ressource verschoben. Es ist nicht mehr Tippgeschwindigkeit oder Syntax-Gedächtnis. Es ist Geschmack, Urteilsfähigkeit und die Gabe, eine plausibel wirkende falsche Antwort zu erkennen, bevor sie in Production landet. Das sind Fähigkeiten, die nicht aus Prompt-Engineering-Kursen kommen. Sie entstehen durch Jahre, in denen du Dinge debuggst, die hätten funktionieren sollen und nicht taten.

Probleme bekommen die Teams, die für Durchsatz optimiert haben, ohne in die Urteilsebene zu investieren. Sie versenden schneller, sammeln unsichtbare Schulden an und landen schließlich dort, wo niemand mehr erklären kann, warum das System so funktioniert, wie es funktioniert. Gut kommen die Teams weg, die den Speed-Gewinn als Chance nutzen, um schwerer zu denken, nicht leichter.

Es gibt auch ein Kundengespräch, auf das Agenturen sich vorbereiten sollten. Wenn ein Kunde fragt, wie lange ein Feature dauert, und die ehrliche Antwort ist "zwei Tage mit KI-Unterstützung", folgt: "Warum kostet es dann so viel?" Die Antwort ist nicht das Tippen. Es war nie das Tippen. Es ist das Scoping, die Architektur-Entscheidung, die Wahl, was nicht zu bauen ist, und der Review, der den selbstsicheren Fehler des Modells in Zeile 340 auffängt. Wenn du das nicht erklären kannst, verlierst du das Gespräch.

Die Governance-Lücke, die niemand füllt

Anthropic's interne Debatte über eine Pause bei selbstverbessernder KI-Entwicklung ist eine Governance-Frage im zivilisatorischen Maßstab. Deine Agentur-Version derselben Frage ist bescheidener, aber strukturell identisch: Wer hat die Autorität, Nein zu sagen, und an welcher Stelle im Prozess?

Die meisten Teams haben diese Frage nicht beantwortet. Sie haben KI-Coding-Tools adoptiert, weil die Produktivitätsgewinne offensichtlich sind, und angenommen, dass bestehende Code-Review-Prozesse das Nötigste abfangen. Diese Annahme steht unter Druck.

Code Review wurde für menschliches Tempo entwickelt. Wenn ein Pull Request 800 Zeilen enthält, die in 40 Minuten geschrieben wurden, findet der Review nicht mit der gleichen Tiefe statt wie bei 800 Zeilen über zwei Tage. Der Reviewer kennt die Gründe hinter jeder Entscheidung weniger, weil es keinen sichtbaren Denkprozess gab zu beobachten. Das Modell hinterlässt keine Notizen über das, was es erwogen und verworfen hat.

Einige Dinge helfen hier wirklich. Erstens. Mach die Review-Einheit kleiner. Kleinere PRs, öfter reviewed, schlagen große PRs schnell reviewed. Das bedeutet, die Commit-Cadence zu verlangsamen, kontraintuitiv, wenn es doch um Schnelligkeit ging. Mach es trotzdem. Zweitens: Der Engineer, der den Output promted hat, muss den Ansatz laut erklären, bevor der Review stattfindet. Nicht den Code, den Ansatz. Wenn er das nicht kann, sollte der Code nicht deployen. Drittens: Baue explizite Decision Logs für alles Architektonische. Nicht ein Dokument, das keiner liest, ein kurzes Protokoll darüber, was erwogen wurde, was gewählt wurde und warum. KI kann helfen, das zu schreiben, aber ein Mensch muss bestätigen, dass es stimmt.

Die Frage, die beim nächsten Retrospective lohnt

Nicht "wie viel versenden wir" sondern "wie gut verstehen wir, was wir versendet haben?"

Diese zwei Dinge hingen immer zusammen. Jetzt sind sie entkoppelt. Und die Teams und Studios, die diese Lücke zuerst sehen, sind die, die festlegen, wie das funktioniert, statt fremde Antworten zu erben.

Bei Studio Hyra arbeiten wir seit einem Jahr an dieser Frage mit Kunden in Produkt- und Agentur-Kontexten. Das Muster, das wir immer wieder sehen: Der Engpass ist nie die Fähigkeit des Modells. Es ist der menschliche Prozess drum herum. Das Modell kann Code schreiben. Die Frage ist: Ist dein Team strukturiert, um dafür Verantwortung zu tragen?

Die Verantwortungsfrage löst kein besserer Prompt. Sie löst sich dadurch, ehrlich zu sein, was dein Team wirklich versteht, Prozesse zu bauen, die Verwirrung früh offenbaren, und Urteilsfähigkeit als die Fertigkeit zu behandeln, in die es sich jetzt lohnt zu investieren, jetzt, wo roher Output billig ist.

Achtzig Prozent Code vom Modell. Achtfache tägliche Versendgeschwindigkeit. Diese Zahlen werden sich weiter bewegen. Die Urteilsebene ist die Variable, die nicht automatisch skaliert.