So funktioniert strukturiertes Coding mit KI-Agenten

Die meisten Agenturen, die KI-Coding-Agenten nutzen, machen die gleiche Erfahrung: die erste Viertelstunde läuft gut, dann schreibt das Modell eine Datei um, die es gar nicht anfassen sollte, erfindet eine Abhängigkeit und die nächste Stunde verbringst du damit, es wieder auseinanderzunehmen. Das Problem ist nicht der Agent. Das Problem ist das fehlende Prozess.

Agent-gestützte Entwicklung ist nicht nur Autocomplete im großen Maßstab. Es ist eine andere Arbeitsweise, die eine andere Art von Disziplin erfordert. Die Studios, die echte Ergebnisse damit erreichen, schreiben nicht bessere Prompts. Sie strukturieren die Arbeit anders, Phase für Phase, bevor eine einzige Zeile Code geschrieben wird.

Mit einer Spezifikation starten, nicht mit einem Prompt

Der häufigste Fehler. man öffnet ein Chat-Fenster und beschreibt die Funktion, die man haben will. Das gibt dem Agenten ein unterbestimmtes Problem in die Hand und erlaubt ihm, Architektur-Entscheidungen zu treffen, die du selbst noch gar nicht durchdacht hast.

Ein funktionierendes Vorgehen beginnt mit einer schriftlichen Spezifikation. Keine formale PRD, aber ein präzises Dokument: was die Funktion tut, was sie nicht tut, wie die Datenstrukturen aussehen und welche Akzeptanzkriterien gelten. Zwei Seiten reichen meistens. Der Punkt ist, alle großen Entscheidungen zu treffen, bevor der Agent an der Codebasis anfasst.

Das fühlt sich langsam an. Es ist es nicht. Jeder vage Satz in deiner Spezifikation ist eine Debug-Session, die auf dich wartet. Die Spezifikation ist auch das Dokument, das du dem Agenten zu Beginn jeder Session als Kontext zur Verfügung stellst. Dadurch wiederholst du dich nicht mehr und der Agent driftet nicht ab.

Die Arbeit in Phasen mit expliziten Checkpoints aufteilen

Sobald die Spezifikation existiert, teile die Umsetzung in Phasen auf, die klein genug sind, dass du das Ergebnis jeder Phase lesen und verstehen kannst, bevor du zur nächsten gehst. In der Praxis bedeutet das Phasen von etwa einer bis drei Stunden Agent-Arbeit, die eine diskrete, testbare Einheit produzieren.

Am Ende jeder Phase siehst du dir das Diff an. Nicht die ganze Datei, nur das Diff. Du prüfst, ob der Agent in seinem Scope geblieben ist. Du prüfst, ob er Seiteneffekte in benachbarten Modulen erzeugt hat. Wenn ja, du stoppst, revertierst und präzisierst die nächste Anweisung, bevor du weitermachst.

Das ist der Checkpoint. Ihn zu überspringen ist, wo sich Kontext-Schulden ansammeln. Wenn der Agent über zwei oder drei Phasen hinweg auf einem Fehler aufgebaut hat, behebst du nicht mehr einen Bug, du machst Archäologie.

Eine nützliche Faustregel. wenn du das Diff nach einer fünfminütigen Review nicht mergen würdest, war die Phase zu groß.

Kontext steuern, nicht nur Prompts

Agenten werden mit Entfernung schlechter. Je weiter ein Modell von seinem initialen Kontext entfernt ist, desto mehr füllt es Lücken mit Mustern aus dem Training statt mit Mustern aus deinem Codebase. Das ist kein Fehler, den du durch bessere Prompts beheben kannst. Es ist eine Eigenschaft, wie diese Systeme funktionieren.

Die praktische Antwort ist aggressives Kontext-Management. Starte eine neue Session für jede Phase. Gib dem Agenten die Spezifikation, die relevanten Dateien und sonst nichts. Widerstehe dem Drang, ein langes Gespräch fortzuführen, weil es sich effizient anfühlt. Lange Gespräche fühlen sich effizient an. Sie sind es nicht. Du fütterst das Modell mit seinen eigenen früheren Annahmen neben deinen neuen Instruktionen.

Einige Teams halten eine kurze Kontext-Datei neben jedem Modul. eine einfache Textdatei, die beschreibt, was das Modul tut, was es nicht tut und welche Dateien es anfassen darf. Der Agent bekommt diese Datei bei jeder Session als Teil seines Kontexts. Es klingt nach Bürokratie. Es reduziert Scope Creep erheblich.

Es gibt einen verwandten Punkt zu Datei-Grenzen. Agenten werden bereitwillig über Dateien hinweg refaktorieren, wenn du ihnen den Scope dafür gibst. Das willst du meistens nicht. Explizite Anweisungen darüber, welche Dateien für eine gegebene Phase in Scope sind, sind nicht überängstlich. Sie sind die Arbeit.

Testen ist nicht optional und es ist nicht die Idee des Agenten

Der Agent wird Tests schreiben, wenn du ihn darum bittest. Er wird Tests schreiben, die gegen den Code, den er gerade geschrieben hat, durchlaufen. Das ist nicht dasselbe wie Tests, die das Verhalten beschreiben, das deine Spezifikation verlangt.

Die Disziplin hier ist, die Test-Fälle selbst zu schreiben, in der Spezifikations-Phase, bevor irgendeine Implementierung stattfindet. Beschreibe die Eingaben, die erwarteten Ausgaben und die Grenzfälle. Dann übergib das dem Agenten als Teil seiner Anweisungen für jede Phase. Jetzt sind die Tests in der Spezifikation verankert, nicht in der Implementierung.

Das ist eine Version von Test-Driven Development, angewendet auf Agent-Workflows. Es geht nicht um Methodik um ihrer selbst willen. Es geht darum, die Ausgabe des Agenten falsifizierbar zu halten. Wenn du nicht feststellen kannst, ob der Agent das getan hat, was du wolltest, kannst du nicht darauf aufbauen.

Was das für Agenturen bedeutet

Für Studios, die gleichzeitig drei oder vier Produkt-Workstreams laufen haben, hat diese Art von Struktur noch einen zweiten Vorteil neben besserer Output-Qualität. Sie macht Agent-gestützte Arbeit überprüfbar für jemanden, der nicht in der Session dabei war.

Eine Spezifikation, ein Phasen-Log und eine Diff-Historie sind nachvollziehbar. Ein langer Chat-Thread ist es nicht. Wenn ein Kunde fragt, warum eine Komponente so funktioniert, oder wenn ein Developer ein Projekt in der Mitte übernimmt, zahlt sich der strukturierte Prozess aus.

Die Teams, die am meisten aus Agent-gestützter Entwicklung herausholen, sind nicht die, die die fähigsten Modelle oder die cleversten Prompts nutzen. Es sind die, die Prozess-Design genauso ernst nahmen wie das Werkzeug. Der Agent ist schnell. Struktur ist das, was schnell nützlich macht.

Wenn dein aktueller Workflow ein Chat-Fenster und Optimismus ist, das ist ein verständlicher Startpunkt. Es ist einfach nicht der Ort, wo du bleiben solltest.