Wenn niemand den KI-Code versteht: Verständnis zurückholen

Viele Teams haben in den vergangenen Monaten den Schalter umgelegt: Neue Arbeit geht zuerst an Claude Code, Cursor oder Codex, Handarbeit braucht eine Begründung. Die ersten Monate fühlen sich meist hervorragend an. Was danach passieren kann, wenn niemand auf das gemeinsame Verständnis des Codes achtet, zeigt ein Erfahrungsbericht, der gerade in der Entwickler-Community breit diskutiert wird. Für Engineering Manager ist er eine Warnung, die sich vor der Einführung ernst nehmen lässt und nicht erst danach.

Ein Jahr Agenten-Pflicht: was ein Team berichtet

In einer viel kommentierten Diskussion auf Reddit beschreibt ein Entwickler, wie die Leitung seines Unternehmens vor einem Jahr festlegte, dass sämtliche Arbeit über Agenten läuft. Etwa ein halbes Jahr lang lieferte das Team mehr als je zuvor. Inzwischen ist die Codebasis nach seiner Schätzung rund dreimal so groß wie vorher, und kaum jemand kann erklären, wie der größte Teil davon funktioniert.

Auch die Agenten selbst kommen mit dem Ergebnis schlechter zurecht: Sie schreiben Hilfsfunktionen neu, die es an anderer Stelle schon gibt, weil von vielem inzwischen vier Varianten existieren. Mehr Code bedeutet hier also nicht mehr Fähigkeit, sondern mehr Rauschen im Kontext, das jede weitere Agenten-Sitzung ausbaden muss.

Den eigentlichen Schaden sieht der Autor aber bei den Menschen. Die beiden Kollegen, die bisher jeden Pull Request gelesen und widersprochen haben, sind nicht mehr im Unternehmen. Ein KI-Review-Tool wie CodeRabbit kommentiert weiterhin jeden Pull Request, doch niemand kann mehr einschätzen, welcher Kommentar relevant ist. Also werden alle aufgelöst. Jetzt bittet das Management darum, wieder mehr selbst zu schreiben, nur ist die Routine weg: Eine Aufgabe, die früher einen Nachmittag gedauert hätte, kostete den Autor zwei Tage.

Review ohne Urteilsvermögen ist nur Zeremonie

Der Bericht zeigt eine Lücke, die viele Teams unterschätzen. Ein automatischer Reviewer erzeugt Kommentare, aber kein Urteil. Ob ein Hinweis auf eine echte Schwachstelle zeigt oder Rauschen ist, entscheidet ein Mensch, der das System kennt. Wenn genau diese Menschen gehen und niemand nachwächst, bleibt der Prozess formal bestehen und verliert seinen Inhalt.

Das deckt sich mit dem Befund aus Reviewzeit statt Tippzeit: Der Engpass verlagert sich vom Schreiben zum Prüfen. Ein Team, das nur die Erzeugung beschleunigt, ohne gezielt Prüfkompetenz aufzubauen, hat am Ende viel Code und wenig Kontrolle darüber. Eine strukturierte Review-Checkliste für KI-Pull-Requests hilft nur, wenn jemand sie mit Sachverstand abarbeitet.

Fundament und Fassade unterschiedlich behandeln

Einen praktikablen Gegenentwurf beschreibt Maude Lemaire im Podcast The Pragmatic Engineer. Sie hat bei Slack das Backend-Performance-Team geleitet, bei GitHub an der Datenbank-Skalierung gearbeitet und zuletzt an der Performance von Cursor. Sie nutzt KI in ihrer Arbeit, behält Entscheidungen und Abwägungen aber ausdrücklich bei sich.

Ihr zentraler Punkt: Bei fundamentaler Arbeit, also Plattform- und Infrastrukturcode, prüft sie jede Ausgabe eines Sprachmodells persönlich, weil ambitionierte Strukturen ein stabiles Fundament brauchen. Diese Trennung zwischen fundamentalem und weniger kritischem Code lässt sich direkt in Teamregeln übersetzen. In einer AGENTS.md oder in .cursor/rules kann ein Team festhalten, welche Verzeichnisse als Fundament gelten, und per CODEOWNERS dafür sorgen, dass Änderungen dort immer bei einer benannten Person landen.

Ein zweiter Gedanke aus dem Gespräch passt ebenfalls: Lemaire beschreibt am Beispiel von Active Record bei GitHub, wie eine bequeme Abstraktion dazu führte, dass Entwickler die Datenbanklast ihrer Abfragen weder kannten noch beachteten. Agenten sind eine noch mächtigere Abstraktion. Wer nur noch Ergebnisse abnimmt, verliert den Blick dafür, was im System tatsächlich passiert.

Verständnis gezielt zurückholen

Aus beiden Quellen lassen sich konkrete Gegenmaßnahmen ableiten:

• Erklärpflicht im Review: Wer einen agentengenerierten Pull Request einreicht, muss die Änderung in eigenen Worten erklären können. Kann er das nicht, ist der Pull Request nicht fertig.
• Duplikate aktiv suchen: Vor neuen Hilfsfunktionen lässt man den Agenten im Repository nach vorhandenen suchen und hält bekannte Helfer in der Kontextdatei fest.
• Fundament markieren: Kritische Bereiche werden benannt und bekommen strengere Review-Regeln.
• Rotation: Lemaire empfiehlt, dass Plattform- und Produktentwickler regelmäßig die Seiten wechseln. Ähnlich lässt sich Wissen über Agenten-Code im Team verteilen, statt es bei wenigen Personen zu bündeln.
• Handarbeit bewusst üben: Nicht-triviale Aufgaben gelegentlich ohne Agent lösen, damit die Routine nicht verloren geht.

Was das für Ihr Entwicklerteam bedeutet

Der Bericht ist kein Argument gegen Coding-Agenten, sondern gegen eine Einführung per Anweisung ohne Regeln für Verständnis und Review. Wer heute eine Agenten-Pflicht einführt oder ungeordnete Einzelnutzung zulässt, sollte von Anfang an festlegen, wer welchen Code verstehen muss, wie Reviews mit Urteil statt mit Abhaken laufen und wie Wissen nicht an zwei Personen hängt. Eine Einführung in Stufen mit Pilotteam gibt dafür den Raum, solche Regeln zu testen, bevor sie für alle gelten.

Die gute Nachricht: Diese Regeln sind kein Großprojekt. Sie bestehen aus ein paar Zeilen in der Kontextdatei, einer CODEOWNERS-Datei und einer klaren Erwartung an jeden Pull Request. Entscheidend ist, dass sie gelten, bevor die Codebasis aus dem Ruder läuft.

Sie wollen Agenten im Team einsetzen, ohne das Verständnis für Ihren eigenen Code zu verlieren? Im Inhouse-Training entstehen Review-Regeln, Kontextdateien und Arbeitsweisen direkt an Ihrem Repository. Inhouse-Training anfragen.