Gute Entwickler sind nicht skeptisch. Sie stellen die richtigen Fragen.

Heute hat Rachel Laycock, CTO bei Thoughtworks, einen Beitrag auf martinfowler.com veröffentlicht: Why are good developers so wary of agentic development?. Der Beitrag ist lesenswert. Aber beim Lesen hatte ich das Gefühl, einen Text aus dem Jahr 2025 zu lesen.

Der Beitrag stellt die richtigen Fragen. Das Problem ist, dass viele dieser Fragen bereits Antworten haben. Wir arbeiten seit über einem Jahr daran, unter dem Namen Spec-Driven Development.

In diesem Beitrag zeige ich, was Rachel beschreibt, warum es etwas spät wirkt und wo ich ihr voll zustimme.

Zwei Drittel am Whiteboard sind keine Überraschung

Rachel beschreibt ein Experiment. Ein Team aus Senior Engineers, Infrastruktur-Leuten und Product-Leuten arbeitete eine Woche lang an einer Airline-Anwendung. Niemand schrieb Code. Alles schrieben die Agenten.

Das interessante Ergebnis: Das Team verbrachte etwa zwei Drittel der Zeit am Whiteboard. Es erarbeitete die Domäne, zog Grenzen und machte Pläne, mit denen die Agenten arbeiten konnten. Das andere Drittel ging in den Harness: Tests, Contracts, Architektur-Checks und die Pipeline. Und die Product-Person committete mehr Feature-Code als alle anderen.

Für mich ist das keine Überraschung. Das ist Spec-Driven Development. Wenn der Agent den Code schreibt, verschiebt sich die Arbeit der Menschen nach links: zu den Anforderungen, zum Domänenmodell, zu den Use Cases und zu den Checks, die das Ergebnis prüfen. Die Spezifikation wird zum wichtigsten Artefakt. Der Code ist etwas, das der Agent daraus erzeugt.

Dass die Product-Person am meisten Code committete, überrascht mich auch nicht. Wenn die Spezifikation gut ist, kann die Person, die das Business am besten kennt, den Agenten am besten steuern.

Das Experiment bestätigt also, was viele von uns in echten Projekten gesehen haben. Das ist eine gute Bestätigung. Aber es ist keine neue Entdeckung.

Die offenen Fragen haben Antworten

Rachel listet mehrere Fragen auf, die das Team diskutiert hat. Sie schreibt, dass niemand sie in einer Woche gelöst hat und dass sie niemandem trauen würde, der das behauptet. Das verstehe ich. Aber wir fangen nicht bei null an. So beantwortet der AI Unified Process diese Fragen.

Frage aus dem Beitrag	Antwort im AI Unified Process
Welche Rolle spielt TDD, wenn der Agent die Tests zusammen mit dem Code schreibt?	Die Spezifikation ist das Orakel, nicht der Code. Die Tests werden aus der Use-Case-Spezifikation abgeleitet: Hauptszenario, alternative Abläufe und Geschäftsregeln. Wenn Test und Code nicht übereinstimmen, bleibt der Test rot. Der Agent darf den Test nicht ändern, nur damit der Build grün wird.
Wie wissen wir, dass die Tests das Richtige prüfen?	Jeder Test trägt die ID des Use Cases, den er prüft. Ein Coverage-Check zeigt, welche Schritte, Abläufe und Regeln Code und Tests haben und welche nicht.
Wie viel Design braucht es, bevor der Agent startet?	So viel, dass der Use Case eindeutig ist. Zuerst kommen Anforderungen, Glossar, Entitätsmodell und Use-Case-Spezifikation. Ein Use Case wird erst umgesetzt, wenn sein Status Approved ist. Offene Fragen kommen in eine zentrale Datei, und der Agent darf nicht raten.
Wo geben Akzeptanz- und Contract-Tests am meisten Sicherheit?	An den Grenzen, die der Use Case definiert. End-to-End-Testfälle verbinden mehrere Use Cases zu einer User Journey. Nicht-funktionale Anforderungen stehen im Architekturdokument und werden ebenfalls zu Tests.
Was ist die richtige Batch-Grösse?	Der Use Case. Keine Story, kein Epic und keine Task-Ebene dazwischen. Ein Use Case ist klein genug für Review und Test und gross genug, um echten Nutzen zu liefern.

Nichts davon ist Magie. Es ist altes Wissen aus dem Unified Process und Use-Case 2.0, angepasst für Coding-Agenten. Genau das ist der Punkt: Wir müssen nicht alles neu erfinden. Viele Praktiken, die wir auf die harte Tour gelernt haben, funktionieren immer noch. Sie werden einfach wichtiger.

Wo Rachel recht hat

Ich will nicht nur kritisieren. Drei Punkte im Beitrag sind wichtig, und ich stimme ihnen voll zu.

Gebaut ist nicht dasselbe wie in Produktion funktionierend. Das ist der stärkste Punkt des Beitrags. Wir haben noch keine Systeme, die grösstenteils von Agenten gebaut wurden und dann jahrelang in Produktion liefen, viele Änderungen überstanden und wartbar blieben. Diese Erfahrung kann niemand vortäuschen. Wir müssen sie uns erarbeiten. Darum ist mir Nachvollziehbarkeit so wichtig: Wenn in zwei Jahren etwas kaputtgeht, muss man die Anforderung hinter dem Code finden können.

Ein roter Build muss etwas bedeuten. Das Team hatte oft einen roten Build, während die Anwendung lief. Viele Agenten arbeiten parallel, und Änderungen kommen schneller, als die Checks fertig werden. Wenn die Leute anfangen, rote Builds zu ignorieren, verliert Continuous Integration ihren Wert. Ich stimme Rachel zu, dass Continuous Delivery und DevOps wegen der Agenten eine zweite Welle der Aufmerksamkeit erleben werden.

Batch-Grösse. Rachel hört, dass Teams von Stories zu Epics wechseln, weil Agenten schnell sind. Das ist gefährlich. Grössere Batches bedeuten längere Feedback-Schleifen, schwierigere Reviews und mehr rote Builds. Schnelles Code-Schreiben hilft nicht, wenn die Pipeline und die Menschen nicht mithalten können. Kleinere Arbeitseinheiten sind die Antwort, nicht grössere.

Sie macht auch einen fairen Punkt über erfahrene Entwickler. Sie sind keine Nachzügler. Sie sehen die Risiken, weil sie schon um drei Uhr morgens wegen eines Produktionsproblems geweckt wurden. Ihr Urteilsvermögen ist genau das, was wir brauchen.

Fazit

Rachel schliesst mit der Idee, dass uns niemand eine Landkarte geben wird. Ich sehe das etwas anders. Die Karte ist nicht vollständig, aber grosse Teile sind schon gezeichnet. Spec-Driven Development, Use Cases, Nachvollziehbarkeit, die Spezifikation als Test-Orakel: Das sind keine Experimente mehr. Es funktioniert heute in echten Projekten, auch in Brownfield-Projekten.

Gute Entwickler sind nicht skeptisch. Sie stellen die richtigen Fragen. Und Ende 2026 sollten wir nicht mehr nur fragen, ob wir mit Agenten arbeiten. Die eigentliche Frage ist wie. Meine Antwort ist einfach: Mit den Anforderungen beginnen, die Spezifikation zum wichtigsten Artefakt machen und den Agenten das tun lassen, was er am besten kann.

Wenn du mehr erfahren willst, schau dir den AI Unified Process an.