Zum Inhalt springen

Wissensbasis

Supervision und Drift

Wer Coding-Agents beaufsichtigt, braucht Kapazität für Verifikation und Review, und der Bedarf an dieser Kapazität wächst mit dem Output der Agents. Die dafür nötigen Coding-Skills verkümmern, wenn sich Entwickler:innen auf KI stützen. Teams halten die Qualität mit deterministischen Checks in CI, inferenziellen Reviews außerhalb davon, benannten Reviewer:innen mit Verantwortung für den Merge und weiterer Übung im Handwerk.

Verfasst von

Aktualisiert:

Tools 4

Unsere Position. Das Engineering-Wissen eines Teams gehört ins System statt in die Köpfe einzelner Leute (öffnet in einem neuen Tab). Es soll in Lintern, strukturellen Tests, Akzeptanzkriterien und deterministischen Guardrails stecken, statt dass sich das Team darauf verlässt, jede Zeile zu lesen. Wer das Verstehen überspringt, um mit dem Generierungstempo mitzuhalten (öffnet in einem neuen Tab), verliert die Fähigkeit, Probleme zu erkennen. Je weniger ein Team beaufsichtigt, desto mehr seines Feedbacks muss deterministisch sein (öffnet in einem neuen Tab).

Wie prüft und reviewt ihr Code, den Agents geschrieben haben?

Schreiben Agents den Großteil des Codes, wird die Verifikation zur tragenden Wand. Der Talk State of Play bietet dafür ein Denkmodell mit zwei Seiten:

  • Feed-forward Guides lenken einen Agent, bevor er handelt.
  • Feedback Sensors fangen Probleme ab, nachdem er gehandelt hat.

Beide sind entweder inferenziell oder computational. Inferenziell heißt: Ein LLM beurteilt ein LLM und läuft auf einer GPU. Computational heißt: statische Analyse, Linter und Codemods, die auf einer CPU laufen.

Die schärfste Regel des Talks betrifft die Platzierung. Inferenzielle Sensoren bleiben aus CI heraus, denn “you don’t want the green or red state of your pipeline to depend on semantic interpretation of an LLM”. Macht der Agent einen Fehler einmal pro Woche, ist eine billige deterministische Lint-Regel besser, als bei jedem Lauf Kontext nachzuschieben.

Teure inferenzielle Reviews für Modularität, Aktualität der Dependencies und Security gehören in einen wöchentlichen “garbage collection”-Durchlauf. Ihre Ergebnisse triagiert ihr wie Sicherheitslücken, und sie laufen nicht bei jedem Commit. Codemods wie OpenRewrite mit KI zu kombinieren ist das Muster hinter Amazons Angabe, bei Java-Upgrades Hunderte Entwicklerjahre gespart zu haben (State of Play: AI Coding Assistants (öffnet in einem neuen Tab), Juni 2026).

Baz baut eine eigene Version davon mit zwei Retrieval-Mechanismen, die sich ergänzen. Der eine sucht über Vektorähnlichkeit, der andere über einen deterministischen Graph aus Modulen und Referenzen im Code. Den Output misst Baz per Benchmark mit einem LLM-as-Judge. Dieser Judge läuft gezielt auf einem anderen Modell als die Produktion, denn “models like their own results” (Baz über den Bau eines Code-Review-Agents (öffnet in einem neuen Tab), Juni 2025).

Am Review staut sich die Parallelität tatsächlich. Bisher postet man oft in den Team-Channel, und eine reaktionsschnelle Person übernimmt die meisten Reviews. Wenn die Zahl der PRs explodiert, bricht dieses informelle Muster zusammen. Teams müssen Reviews dann einzelnen Personen zuweisen und Service Level Objectives durchsetzen. Sie optimieren die Latenz jeder einzelnen Antwort statt der gesamten Durchlaufzeit, weil Review ein Quality Gate ist. Der einzige bekannte Weg, gute Reviewer:innen auszubilden, ist Apprenticeship (Developer Experience in the Age of AI Coding Agents (öffnet in einem neuen Tab), Dezember 2025).

Ein:e Praktiker:in argumentiert, Code Review sei heute der wichtigste einzelne Engineering-Skill. Teams sollten im Interview darauf prüfen statt auf Algorithmus-Puzzles (Vibes won’t cut it (öffnet in einem neuen Tab), August 2025). Sourcegraphs Amp geht die Review-Last mit einem eigenen Diff-Viewer an. Er bietet eine geführte “tour of the change” und nennt die Dateien, die ihr zuerst lesen solltet. Dazu kommen teilbare Threads, damit Teammitglieder voneinander das Prompten lernen (Sourcegraph über Amp (öffnet in einem neuen Tab), Dezember 2025).

Ona (früher Gitpod) hat seinen Agent-Workspace auf derselben Prämisse neu gestaltet. Jeder Wechsel vom Chatfenster in einen Code-Editor zwingt das Gehirn, Kontext zu verwerfen und neu zu laden. Deshalb holte Ona das Review in die Konversation. Dort gibt es einen durchsuchbaren Dateibaum, lesbare Diffs und Inline-Kommentare, die direkt in den Dialog zurückfließen. Außerdem entkoppelte Ona die Konversation von der Laufzeitumgebung. So können Entwickler:innen weggehen und finden den Agent bei ihrer Rückkehr dort, wo sie ihn verlassen haben (Ona, Herstellerangabe, Redesigning Ona conversations (öffnet in einem neuen Tab), April 2026).

Verantwortung zählt so viel wie Tooling. OpenHands stellte fest, dass PRs im Besitz des Bots ein Anti-Pattern sind. Die auslösende Person konnte diese PRs selbst freigeben, und fehlschlagende PRs blieben verwaist liegen. Die Lösung: Der PR läuft auf den Namen der Person, die ihn ausgelöst hat. Diese Person verantwortet den Merge und alles, was danach kaputtgeht.

Dazu gehört die Haltung, dass von Agents geschriebener Code billig und wegwerfbar ist. OpenHands berichtet, ungefähr die Hälfte seiner spekulativen, per Sprache diktierten PRs zu verwerfen. Liegt ein Agent nah dran, iteriert das Team im Thread. Liegt er weit daneben, startet es frisch neu (OpenHands über Coding-Agents (öffnet in einem neuen Tab), Juli 2025).

Verkümmern durch KI die Skills, mit denen ihr sie beaufsichtigt?

Eine Warnung aus der Praxis kehrt immer wieder und schränkt diese Antwort ein. Wer sich auf KI stützt, baut genau die Skills ab, die die Aufsicht über sie verlangt.

Ein:e Entwickler:in entfernte alle LLM-Integrationen aus dem Editor, nachdem die Person einen Verlust dessen bemerkte, was sie Fingerspitzengefühl nennt. Gemeint ist das Low-Level-Gespür, das Seniors für Pointer, die Wahl in der Standardbibliothek und “something feels off” entwickeln. Seitdem gilt:

  • KI bleibt komplett getrennt vom Editor.
  • Kontext kommt von Hand dazu, damit die Reibung absichtlich hoch bleibt.
  • Sicherheitskritischen Code wie JWT-Signierung und RBAC schreiben und reviewen Menschen.

Das Fazit lautet: “if you cannot code without AI, you cannot code” (Why I stopped using AI code editors (öffnet in einem neuen Tab), April 2025).

Anthropics eigene Forschung beschreibt das als Paradox der Supervision: “effectively using Claude requires supervision, and supervising Claude requires the very coding skills that may atrophy from overusing AI”. Laut dem Bericht setzt die Atrophie innerhalb von Monaten ein. Deshalb wies ein Engineering Director sein Team an, Agents nicht für Aufgaben einzusetzen, die kritisches Denken verlangen (We all fell for it (öffnet in einem neuen Tab)).

Dieselbe Kritik verwirft die Idee, Prompting in natürlicher Sprache sei einfach die nächste Abstraktionsschicht über Python, so wie C über Assembler lag. Ihre Begründung: “a high level of ambiguity is not a higher level of abstraction”. Auffällig ist, dass professionelle Software Engineers als letzte Gruppe gelten, die diese Tools übernimmt. Bei früheren Umbrüchen wie Versionskontrolle und Cloud griffen Entwickler:innen als Erste zum Neuen (Vibes won’t cut it (öffnet in einem neuen Tab), August 2025).

Verwandte Seiten

Quellen

Artikel

Posts

Talks und Videos