Warum ich meinen eigenen Subagenten nicht glaube
Ein Subagent meldet 'erledigt, alle Tests grün'. Das ist eine Behauptung, kein Beweis. Warum ich Selbstberichte von LLM-Agenten gegen Ground-Truth prüfe — mit drei konkreten Fällen.
Notizen, Lernsignale und Reflexionen aus dem laufenden Bau agentischer Systeme. Kein Ratgeber, kein Hype — eher Werkbuch.
Ein Subagent meldet 'erledigt, alle Tests grün'. Das ist eine Behauptung, kein Beweis. Warum ich Selbstberichte von LLM-Agenten gegen Ground-Truth prüfe — mit drei konkreten Fällen.
Ein Modell baut, das andere reviewt — und bei jedem Accept tauschen sie die Rollen. Wie ich eine Relay-Schleife zwischen Claude und Codex gebaut habe und welche Sandbox-Falle dabei lauerte.
Ein Agent mit Shell-Zugriff kann jeden Befehl tippen, auch rm -rf oder DROP TABLE. Wie ich einen PreToolUse-Hook gebaut habe, der destruktive Kommandos abfängt — und was beim Bau schiefging.
Ein headless gestarteter Codex-Build fror 45 Minuten ein. Im eigenen Log stand nichts. Ein inoffizielles CLI-Upgrade hatte zwei ungeschriebene Annahmen gleichzeitig gebrochen — und die Diagnose lag nicht dort, wo ich sie suchte.
Ein Test bestand isoliert, fiel aber in der vollen Suite durch. Die Ursache lebte nicht im Dateisystem, sondern im Prozess-Speicher: ein anderer Test hatte ein Modul neu geladen und dabei eine Registry leergeräumt.
Zweimal hat eine Test-Suite meine produktive Datenbank geleert, obwohl ich sicher war, isoliert zu testen. Die Diagnose: ein eingefrorener Pfad zur Import-Zeit. Was daraus folgt.
Vollautomation ist selten das Ziel. Wer Agenten produktiv einsetzt, muss entscheiden, an welchen Stellen ein Mensch zustimmen muss. Wie ich das im DCO geloest habe.
Ein GitHub-Account-Rename ging glatt durch: git push funktionierte weiter, alles schien in Ordnung. Fünf Tage später zeigte die Live-Seite immer noch den alten Stand. Kein Fehler, kein Alert — nur ein Webhook, der ins Leere lief.
Eine NotebookLM-Extraktion fror mitten im Lauf ein. Kein Fehler, kein Timeout, nur Stille. Die Ursache war kein Bug im Code, sondern ein voller Betriebssystem-Puffer — und eine subprocess-Annahme, die an großen Daten zerbricht.
Der DCO begann als Telegram-Bot, der die Claude-CLI aufruft. In der ersten Woche scheiterte jeder Aufruf auf eine neue Art: erst fand Windows das Programm nicht, dann zerfielen die Umlaute, dann war der Gesprächskontext kaputt.
Wenn dich ein Thema vertieft interessiert oder du eine andere Sicht hast: schreib mir.