Mehr Agenten parallel laufen zu lassen macht dich nicht schneller, wenn jeder Agent deine Entscheidungen braucht. Der Ausweg: die meisten dieser Entscheidungen treffen, bevor der Agent startet.
Diese Woche hat Adam Tornhill den Beitrag Scaling Agentic Coding As If People Still Mattered veröffentlicht. Er reagiert auf einen Trend, den viele von uns sehen: Entwickler, die fünf bis zehn Coding-Agenten gleichzeitig laufen lassen, jeden in einem eigenen Terminal-Tab. Tornhill erwartet, dass das normal wird. Und er warnt vor den Kosten für die Menschen hinter den Terminals.
Ein Satz aus seinem Beitrag ist mir geblieben:
«Mit fünf parallelen Agenten jonglierst du nicht fünf Aufgaben. Es sind eher 50.»
Ich stimme zu. Und ich finde, dieser Satz erklärt sehr gut, warum wir in der agentischen Entwicklung Spezifikationen brauchen.
Der Engpass ist nicht der Agent
Tornhill macht einen einfachen Punkt: Agenten skalieren, menschliche Aufmerksamkeit nicht. Was zählt, ist nicht die Anzahl Agenten, sondern die Anzahl Fokus-Aufgaben. Eine Fokus-Aufgabe ist Arbeit, die dein Urteil und deine Freigabe braucht.
Warum ist eine Agenten-Aufgabe für dich mehr als eine Aufgabe? Tornhill verwendet die Idee der Requirements Explosion von Robert Glass. Jede Anforderung in deinem Input bringt viele versteckte Design-Entscheidungen mit sich. Wie gehen wir mit einer leeren Liste um? Was passiert, wenn der Kunde gesperrt ist? Wer darf dieses Feld sehen? Ein Agent kann diese Fragen nicht allein beantworten. Entweder fragt er dich, oder er rät.
Beide Varianten sind schlecht, wenn du fünf Agenten laufen lässt:
- Der Agent fragt. Er hält in einem unvorhersehbaren Moment an. Du wechselst den Kontext, immer wieder. Tornhill beschreibt die Kosten: Attention Residue, Decision Fatigue, Stress und weniger Kreativität.
- Der Agent rät. Er hält nicht an. Aber jetzt steckt die Entscheidung im Code, und niemand hat sie bewusst getroffen. Du findest sie später im Review, in einem Test oder in Produktion.
Das Problem ist also nicht, wie schnell der Agent Code schreibt. Das Problem ist, wo und wann die Entscheidungen getroffen werden.
Die 50 Entscheidungen einmal treffen
Die versteckten Entscheidungen kannst du nicht entfernen. Aber du kannst wählen, wann du sie triffst. Im AI Unified Process treffen wir sie vor der Implementierung, in der Spezifikation, und nicht unter Druck, während fünf Terminals auf eine Antwort warten.
Tornhill sagt, die Rolle des Software Engineers verschiebt sich zu zwei Aufgaben: entscheiden, was gebaut wird, und eine Umgebung schaffen, die steuert, wie es gebaut wird. Das ist sehr nahe an den drei Ebenen des AI Unified Process:
| Ebene | Was sie enthält | Wer sie verantwortet |
|---|---|---|
| What | Anforderungen, Use Cases, Geschäftsregeln, Entitätsmodell | Menschen |
| Harness | Stack, Architekturentscheidungen, Konventionen, Skills, Tests | Menschen |
| How | Der Code | Der Agent, gesteuert durch die beiden Ebenen darüber |
In der Praxis landen die versteckten Entscheidungen an konkreten Orten:
- Use-Case-Spezifikationen beschreiben das Hauptszenario, die alternativen Abläufe und die Geschäftsregeln. Die leere Liste und der gesperrte Kunde sind hier festgehalten.
- Das Entitätsmodell legt Datentypen, Längen und Validierungsregeln fest.
- Architecture Decision Records halten die technischen Entscheidungen fest, damit der Agent sie nicht bei jeder Aufgabe neu trifft.
- Das Log der offenen Fragen sammelt, was wir noch nicht wissen. Eine Lücke ist eine Frage an einen Menschen, nicht eine Vermutung für den Agenten.
Ein Use Case geht erst in die Implementierung, wenn er freigegeben ist. Zu diesem Zeitpunkt sind die meisten der 50 Entscheidungen getroffen. Der Agent schreibt immer noch den Code, aber er hat viel weniger Grund, anzuhalten und zu fragen, und viel weniger Raum zum Raten.
Eine Fokus-Aufgabe: der Use Case
Tornhills eigene Regel: mehrere Agenten laufen lassen, aber nur eine Fokus-Aufgabe aufs Mal. Die anderen Agenten erledigen Hintergrundarbeit, die er in den Pausen prüft.
Der AI Unified Process macht diese Regel einfach. Wir zerlegen Use Cases nicht in eine Liste kleiner Tasks. Der Use Case ist die Arbeitseinheit. Deine Fokus-Aufgabe hat also einen klaren Namen, einen klaren Umfang und ein klares Ende: UC-007 ist implementiert, getestet und abgedeckt.
Die Hintergrundarbeit passt drumherum:
- Coverage Checks, die Code und Tests mit einem Use Case vergleichen
- Spec Reviews, die Lücken und Widersprüche suchen
- Dependency-Upgrades und andere Wartungsarbeiten
- Kleine Fixes, bei denen das erwartete Verhalten bereits spezifiziert ist
Diese Aufgaben brauchen wenig Urteil, während sie laufen. Du schaust dir das Ergebnis an, wenn du Zeit hast, und nicht, wenn der Agent entscheidet, dich zu unterbrechen.
Denkzeit gehört zum Prozess
Am besten gefallen hat mir der Teil über Inkubation. Wenn ein Problem komplex ist, hilft es, einen Schritt zurückzutreten. Lerne so viel wie möglich über das Problem, dann geh spazieren. Oft kommt die Idee, wenn du aufhörst zu drücken. Tornhill sagt offen, dass die Theorie dahinter umstritten ist. Aber viele von uns kennen den Effekt aus Erfahrung.
Einen guten Use Case zu schreiben ist genau diese Art von Arbeit. Du sprichst mit dem Business, du liest alten Code, du findest die alternativen Abläufe, die niemand erwähnt hat. Dann brauchst du Zeit, bis die Antwort klar ist. Das ist keine verlorene Zeit. Hier passiert das eigentliche Design.
Wenn wir jede Pause mit einem weiteren Agenten füllen, verlieren wir diese Zeit. Dann werden die schwierigen Entscheidungen in Eile getroffen oder gar nicht. Ein Spec-first-Prozess gibt dem Denken einen Platz: Die Spezifikation ist die Fokus-Arbeit, und der Agent wartet auf sie, nicht umgekehrt.
Fazit: Keep IT simple
Die Anzahl Agenten ist kein Ziel. Tornhill erinnert uns daran, dass beschäftigt nicht dasselbe ist wie produktiv, und dass der beste Code oft der Code ist, den wir nicht schreiben.
Der AI Unified Process hilft dir nicht, 50 Aufgaben zu jonglieren. Er macht daraus Entscheidungen, die du einmal triffst, aufgeschrieben dort, wo Menschen und Agenten sie finden. Dann reicht eine Fokus-Aufgabe, und die Agenten können tun, was sie gut können.
Tornhill schreibt nicht über Spezifikationen oder den AI Unified Process. Aber seine Erkenntnisse zeigen in dieselbe Richtung: Schütze die menschliche Aufmerksamkeit und setze sie dort ein, wo sie am meisten zählt, beim Was.
Wenn du mehr erfahren willst, schau dir den AI Unified Process an.
