Coding-Agenten in echten Codebases: Was sie kosten und wo sie scheitern
Claude Code, Codex und Gemini CLI sind in Demo-Repos beeindruckend. In gewachsenen Codebases entscheidet, wie Token, Reviews und Antipatterns gemanagt werden - nicht das Modell.
In einem leeren Repo schreibt jeder zweite Agent eine TODO-App in fünf Minuten. In einer 200.000-Zeilen-Codebase mit 12 Jahren Geschichte sieht das anders aus. Die Frage ist nicht mehr "kann der Agent das?", sondern "was kostet es uns, wenn er es darf?".
Wo Coding-Agenten heute zuverlässig liefern
Drei Aufgabentypen lösen wir aktuell mit Agenten besser, als wenn ein Mensch sie alleine macht:
- Repetitive Migrationen. Ein Loop über 70 Modulnamen, die nach demselben Schema umbenannt werden, ist Agenten-Arbeit. Klare Diff-Reviews, kein Grübeln.
- Test-Schreiben gegen vorhandenen Code. Ein gut spezifizierter Skill ("schreibe Tests für die exportierten Funktionen in
src/lib/billing.ts") liefert in zehn Minuten 20 Tests. Was davon bleibt, entscheidet das Review. - Erste-Hilfe-Recherche. "Wo lebt die Logik X?" - Agenten mit Repo-Suche und Lesezugriff sind dafür schneller als jede IDE-Suche.
Wo sie noch scheitern
Genauso ehrlich: drei Bereiche bleiben Menscharbeit.
- Architekturentscheidungen mit langem Schatten. Wenn die Antwort "es kommt darauf an" lautet, fängt der Agent meistens an, sich Argumente auszudenken.
- Performance-Tuning ohne Telemetrie. Ohne Metriken vor Augen rät der Agent. Ergebnis: zehn theoretische Optimierungen, keine messbar.
- Code in dünn dokumentierten Codebases. Ohne Doku, ohne Tests, ohne Konventionen produziert der Agent plausibel klingende Lösungen, die an unsichtbaren Verträgen vorbeibauen.
Was Token wirklich kosten
Im Schnitt sehen wir bei nicht-trivialen Tasks 50.000-200.000 Token Input und 5.000-30.000 Output pro Task. Das macht pro Tag und Entwickler:in zwischen 5 und 30 Euro - bei guten Setups deutlich darunter, wenn das Caveman-Pattern oder ähnliche Token-Sparmechanismen aktiv sind. Das ist nicht der teure Teil. Der teure Teil ist die Review-Zeit für Output, der nicht hätte produziert werden müssen.
Vier Antipatterns, die wir in jedem zweiten Projekt sehen
- "Großer Wurf"-Prompts. "Refactore das Modul XY" liefert 800 geänderte Zeilen, die niemand mehr fair reviewen kann.
- Fehlende Erfolgskriterien. "Mach es besser" hat keine Stop-Bedingung. Agenten halluzinieren weitere Verbesserungen, bis sie gestoppt werden.
- Keine Tests im Loop. Ein Agent ohne Testfeedback baut sich seine eigene Wahrheit. Mit Test-Runner im Loop fällt ein großer Teil der Fehler schon vor dem Review auf.
- Kein Kontext-Budget. Jeder Tool-Call zieht Kontext. Ohne Disziplin füllt sich das Fenster mit irrelevantem Krempel und der Agent verliert den Faden.
Pragmatischer Mittelweg
Coding-Agenten ersetzen kein Engineering-Urteil, aber sie verschieben den Hebel. Drei Maßnahmen reichen für die meisten Teams:
- Ein gemeinsamer, versionierter Skill-Katalog (siehe unseren Beitrag zu Skills).
- Pull-Requests bleiben der einzige Pfad in den Hauptbranch - egal wer den Diff geschrieben hat.
- Jeden Sprint genau eine Retrospektive zur Frage: "Welcher Task hätte Agenten-Output gebraucht, hat ihn aber nicht bekommen - und welcher hätte ihn gar nicht gebraucht?"
Mit dieser Disziplin liegt der Gewinn dort, wo Tasks klar abgrenzbar sind - und es entsteht eine deutlich sauberere Trennung zwischen "Agent-Arbeit" und "Mensch-Arbeit".