Hauptgedanke

Wenn ein Agent wie Claude Code eine Funktion implementiert, erkundet er den bestehenden Code, ändert mehrere Klassen, fügt Funktionen hinzu, schreibt Tests und liefert eine Arbeit ab, die kompiliert und deren Tests durchlaufen. Diese beiden Signale sagen, dass die Implementierung technisch korrekt ist. Über ihre Treue zur Fachlichkeit sagen sie nichts.

Drei Arten von Drift rutschen unter diesen beiden Prüfungen durch. Der Agent kann einen zweiten Namen für ein Konzept verwenden, das schon einen hatte — „Bestellschein“ neben „Auftrag“ in einem ERP. Er kann einen Begriff wieder einführen, den das Team aufgegeben hatte. Er kann eine Regel schaffen, die einer anderen an anderer Stelle im Code widerspricht: eine freigegebene Rechnung, die über einen neuen Weg wieder änderbar wird.

Keine dieser Driften lässt einen Test fehlschlagen, denn die Tests betreffen das Verhalten, das der Agent gerade geschrieben hat, nicht das Fachmodell, an das er sich hätte halten sollen.

Warum das wichtig ist

Das Risiko wächst in dem Maß, in dem Agenten einen immer größeren Teil der Änderungen übernehmen: Jede Aufgabe ist für den Agenten eine Gelegenheit, seine eigene Deutung der Fachlichkeit neu zusammenzubauen, und die Abweichungen summieren sich, ohne dass eine bestehende Prüfung sie sieht. Es fehlt ein gemeinsames fachliches Referenzwerk außerhalb des Codes, den der Agent ändert, mit dem sich seine Arbeit abgleichen lässt.

Nuancen und Grenzen

Das Phänomen ist nicht den Agenten eigen: Ein menschlicher Entwickler führt dieselben Driften ein. Was sich ändert, sind Menge und Tempo — und die Tatsache, dass ein Agent keinerlei Erinnerung an die Diskussionen hat, in denen Vokabular und Regeln festgelegt wurden.

Offene Fragen

• Welchen Anteil der fachlichen Driften, die ein Agent einführt, bemerkt ein menschlicher Reviewer im Code-Review tatsächlich?