Mein Agent hat an einem Abend 3 PRs ausgeliefert. 40 % meiner Nachrichten waren Korrekturen.

Mein KI-gesteuerter Coding-Agent hat an einem einzigen Abend drei Pull Requests gepusht, aber 40 % der 30 Nachrichten, die ich gesendet habe, waren Korrekturen.

Die Session lieferte einen MCP-Client, einen Azure AI Agent und einen M365 Copilot Agent. Automatisierte Checks haben alle drei PRs freigegeben, und ich habe keine einzige Zeile Code selbst bearbeitet. Doch das Transkript erzählt eine andere Geschichte: Von insgesamt 710 Nachrichten habe ich 30 getippt, und 12 davon haben den Agenten wieder auf Kurs gebracht. Die „Steuerungsrate“ – der Anteil meiner Nachrichten, die Korrekturen waren – liegt bei 40 %.

Wie die Pipeline aufgebaut war

  • Claude entwarf einen High-Level-Implementierungsplan.
  • DeepSeek V4-Flash fungierte als Orchestrator und überprüfte den Plan.
  • Codex generierte den eigentlichen Code.
  • Der Orchestrator prüfte den Code und eröffnete die Pull Requests.

Die vorgesehene Rolle des Orchestrators war rein verbindend – er sollte Konflikte zwischen den Komponenten lösen, anstatt selbst Code zu schreiben. In der Praxis produzierte der Agent in etwa 40 Minuten 3.500 Zeilen Code über die drei PRs hinweg, unterlief ihm jedoch auch zwei wiederkehrende Fehlerklassen.

Die zwei Fehlerfamilien

  1. Workflow-Verletzungen – der Orchestrator übernahm gelegentlich den Coding-Schritt, ignorierte seine Rolle als „Bindeglied“ und schrieb selbst Implementierungsdetails.
  2. Fehler beim Kontextabruf – trotz expliziter Anweisungen wählte der Agent das falsche SDK oder die falsche Version. Die korrekten Informationen befanden sich im Prompt-Kontext, aber das Modell schaffte es nicht, sie zum richtigen Zeitpunkt abzurufen.

Dies sind keine Lücken in der Argumentationsfähigkeit; es sind Engineering-Bugs in der Art und Weise, wie der Workflow eingeschränkt wird. Selbst ein leistungsfähigeres Sprachmodell bräuchte eine strikte, unübersehbare Regel, die den Orchestrator auf seine Nicht-Coding-Aufgaben festlegt und die korrekte SDK-Auswahl erzwingt.

Was ich geändert habe, um den Agenten zu bändigen

Ich hörte auf davon auszugehen, dass das System seine Rolle aus der Schrittliste ableiten würde. Ich fügte eine direkte Anweisung hinzu: „Du bist ein Orchestrator. Du implementierst nicht.“ Es brauchte fünf Korrekturnachrichten, bis die Anweisung wirksam wurde, wonach der Agent die Grenze respektierte.

Ich habe auch die Logik des Kontextabrufs verschärft. Wenn das falsche Tool auftauchte, behandelte ich dies als Bug in der Retrieval-Pipeline statt als Halluzination, und ich schrieb den Prompt, der die SDK-Details einspeist, um sicherzustellen, dass die korrekte Version nicht übersehen werden kann.

Praktische Erkenntnisse für die KI-gestützte Entwicklung

  • Zählen Sie Ihre eigenen Nachrichten. Ein hohes Volumen an akzeptierten PRs kann einen fehlerhaften Prozess maskieren. Ihre Anzahl an Korrekturen ist ein Frühindikator dafür, wo das System Schwachstellen aufweist.
  • Geben Sie die Rolle explizit an. Agenten leiten ihre Identität nicht aus einer Checkliste ab; sie benötigen eine klare, fest verankerte Anweisung darüber, wer sie sind und was sie tun dürfen.
  • Behandeln Sie Fehler bei der Werkzeugwahl als Engineering-Bugs. Wenn der Agent ein spezifiziertes SDK ignoriert, liegt der Fehler im Mechanismus der Kontextbereitstellung, nicht am „Wissen“ des Modells.
  • Fehler in wiederverwendbare Fähigkeiten umwandeln. Ich ließ den Agenten eine Validierungsroutine aus seinen eigenen Fehlern generieren und machte so aus einem Scheitern eine zukünftige Sicherheitsmaßnahme.

Was auf dem Spiel steht