Agentic Development Workflow

Agentisches Programmieren verschiebt die Rolle des Entwicklers. Statt jede Zeile selbst zu schreiben, beschreibt man Absichten und überlässt die Umsetzung einem Agenten. In der Demo funktioniert das erstaunlich gut. Sobald ein Projekt aber über das Spielzeug-Stadium hinauswächst, wird schnell klar: Der Engpass ist nicht mehr die Tippgeschwindigkeit. Es ist die Geschwindigkeit, mit der der Agent verlässliches Feedback bekommt.

Die Methodik, die ich hier beschreibe, ist im Kern keine Neuerfindung. Gute Entwicklungsteams folgen ihr seit Jahren: klare Domänensprache, kleine vertikale Slices, schnelle Tests, automatisierte Qualitätschecks, kurze CI-Zyklen. Was sich beim agentischen Arbeiten ändert, ist der Hebel. Eine schnellere Feedback-Schleife wirkte vorher auf einen Menschen mit vielleicht ein paar Iterationen pro Stunde. Beim Agenten wirkt sie auf hunderte. Praktiken, die früher nach Geschmack oder Reifegrad des Teams optional waren, werden damit zur Voraussetzung. Und zu einem konkreten Investitionsfaktor bei Tooling- und Architekturentscheidungen.

Der rote Faden durch alle folgenden Abschnitte ist deshalb derselbe: Wie schaffe ich Feedback-Schleifen, die der Agent selbst schließen kann? Sitzt ein Mensch in der Schleife, um Begriffe zu prüfen, Features manuell zu validieren oder Architekturregeln durchzusetzen, bleibt der Agent eine bessere Autovervollständigung. Ist die Schleife automatisiert, kann er iterieren, scheitern und korrigieren, bis das Feature steht. Währenddessen arbeitet man selbst am nächsten.

Die folgenden Phasen sind alle aus dieser Perspektive gedacht: Grundlagen klären, Brainstorming, Sprache vereinheitlichen, in vertikalen Slices implementieren, Qualität sichern. Jede entfernt eine bestimmte Mehrdeutigkeit oder schließt eine konkrete Lücke im Feedback-System.Grundlagen für agentisches Programmieren

Grundlagen für agentisches Programmieren

Bevor man den ersten Agenten loslässt, braucht es Antworten auf zwei Fragen. Wohin soll das Projekt langfristig? Und unter welchen Regeln darf der Weg dorthin gestaltet werden?

Der Nordstern

Was ist das große Ziel, an dem sich alle Entscheidungen messen müssen? Ein Agent trifft im Lauf einer Session dutzende Mikroentscheidungen: welche Bibliothek, welches Datenmodell, welcher Trade-off zwischen Geschwindigkeit und Lesbarkeit. Ohne klares Projektziel optimiert er für das, was lokal sinnvoll aussieht. Das Ergebnis ist Code, der in Isolation funktioniert, aber das eigentliche Vorhaben verfehlt. Ein in einem Satz formuliertes Ziel ist hier wertvoller als jede ausgefeilte Anforderungsspezifikation.

Architektur klarstellen

Bei einem bestehenden Projekt ist das oft eine perfekte erste Agent-Aufgabe. Den Code analysieren lassen, die gefundene Architektur in einem Dokument festhalten. Damit hat man zwei Dinge auf einmal. Ein Referenzdokument, auf das alle späteren Sessions zurückgreifen können. Und einen ersten Realitätscheck darüber, was der Agent eigentlich versteht. Stimmt sein Bild der Architektur nicht mit dem überein, was im Kopf der Entwickler existiert, ist das eine wichtige Information, bevor das erste Feature gebaut wird.

Bei einem neuen Projekt geht man den umgekehrten Weg. Statt vorab eine Architektur zu entwerfen, die alle künftigen Anforderungen abdeckt, beginnt man mit etwas Einfachem. Die Architektur entwickelt sich mit dem Projekt mit. Wichtig ist nur, dass der aktuelle Stand jederzeit explizit dokumentiert ist. Sonst rekonstruiert der Agent ihn aus dem Code. Das geht schief, sobald die Codebase eine bestimmte Größe überschreitet.

Nogos klären

Welche Pfade darf der Agent nicht einschlagen? Keine synchronen externen Aufrufe in Request-Handlern, keine neuen Frameworks ohne Abstimmung; keine direkten Datenbank-Queries außerhalb der Repository-Schicht. Solche Regeln sind für Entwickler selbstverständlich. Für einen Agenten sind sie unsichtbar, solange sie nicht aufgeschrieben sind. Lieber fünf scharfe Nogos als zwanzig vage Empfehlungen.

Was ist wichtig

Wenn der Agent abwägen muss, woran soll er sich orientieren? Performance vor Lesbarkeit? Defensive Programmierung vor knappem Code? Diese Prioritäten gehören explizit in das Kontextdokument. Sonst fällt jede Abwägung anders aus, je nachdem, welches Muster im Trainingsmaterial gerade dominiert.

In der Praxis landen all diese Informationen in einer Kontextdatei wie CLAUDE.md oder AGENTS.md, die der Agent zu Beginn jeder Session liest. Sie ist die persistente Feedback-Schleife für alles, was nicht im Code steht. Sie muss knapp bleiben. Lange, ausufernde Dokumente werden vom Agenten zwar gelesen, aber nicht zuverlässig befolgt.

Brainstorming

Bevor man eindeutige Sprache definieren kann, braucht es Material, über das man sich überhaupt einig werden kann. Brainstorming auf Projektebene ist die Phase, in der man bewusst divergiert. Welche Features könnten in Frage kommen? Welche Nutzergruppen gibt es? Wie könnte die App in zwei Jahren aussehen, wenn alles gut läuft? Welche Alternativen zur naheliegenden Architektur sind denkbar?

Der Agent ist hier ein guter Sparringspartner, aber nur, wenn man ihn richtig einsetzt. Seine Standardneigung ist, schnell auf die naheliegende Antwort zu konvergieren. Genau das ist in dieser Phase kontraproduktiv. Sinnvoller ist, ihn explizit zur Divergenz aufzufordern: drei alternative Architekturen, fünf mögliche Feature-Schnitte, drei verschiedene Stakeholder-Perspektiven auf dasselbe Problem. Auch die Rolle des Advocatus Diaboli funktioniert gut. Lass den Agenten eine eigene Idee anschließend selbst zerlegen.

Was am Ende übrig bleibt, ist kein Plan. Es ist eine Sammlung von Optionen. Was davon tatsächlich umgesetzt wird, entscheidet die Klarstellungsphase.

Praktisch: Für ein neues Seitenprojekt reicht oft eine längere Session. Für eine größere Migration oder eine Produktneuausrichtung sind es eher mehrere Tage. In beiden Fällen ist es wichtig, die Ergebnisse als Rohmaterial zu speichern, nicht als Beschluss. Sonst betoniert sich der erste Einfall, und das Brainstorming hat seinen Zweck verfehlt.

Klarstellungsphase

Hier entscheidet sich, ob der Agent später autonom arbeiten kann oder nicht.

Aus dem Brainstorming kommt eine Sammlung von Ideen, Begriffen und Optionen. Die meisten davon klingen plausibel, sind aber mehrdeutig. „Benutzer“ kann den Endkunden meinen, den eingeloggten Account, den Admin oder den API-Consumer. „Session“ kann eine Login-Session sein oder eine Präsentations-Session. „Board“ ist im Brainstorming entstanden, aber niemand hat festgelegt, was es technisch eigentlich ist.

Solange diese Mehrdeutigkeiten ungelöst sind, werden verschiedene Agent-Sessions verschiedene Interpretationen treffen. Mal modelliert die Anwendung „Board“ als Container, mal als Aggregate, mal als reine View. Der Code wird dadurch inkonsistent, ohne dass eine einzelne Entscheidung erkennbar falsch war.

Die Klarstellungsphase tut genau eine Sache. Sie reduziert die Mehrdeutigkeit auf null.

Begriffe schärfen

Praktisch heißt das:

1. Jeden zentralen Begriff aus dem Brainstorming sammeln.
2. Für jeden Begriff fragen, ob er genau eine Bedeutung hat. Wenn nicht, entweder eine Bedeutung festlegen oder den Begriff in mehrere unterscheidbare Begriffe aufteilen.
3. Begriffe und Bedeutungen in einem Glossar festhalten, das Teil des Repos wird.

Das Ergebnis ist die Ubiquitous Language des Projekts, im Sinne von Domain-Driven Design. Was DDD seit zwanzig Jahren predigt, wird mit Agenten von einer guten Praxis zur Pflicht. Ein menschliches Team merkt früher oder später selbst, wenn zwei Personen unter „Session“ verschiedene Dinge verstehen, und korrigiert sich im Gespräch. Ein Agent merkt es nie. Er produziert einfach Code, der jeweils lokal zur einen oder anderen Bedeutung passt.

Das Glossar pflegen

Das Glossar gehört dauerhaft ins Projekt, typischerweise in die Kontextdatei oder in eine separate GLOSSARY.md, auf die die Kontextdatei verweist. Ein neuer Begriff, der später entsteht, wird dort ergänzt. Ein Begriff, der sich als überflüssig herausstellt, wird dort entfernt.

Mit Abschluss dieser Phase steht die Grundlage, auf der der Agent gleichbleibend agieren kann, unabhängig von der Session.

Auf zwei Ebenen: Brainstorming und Klarstellung sind nicht nur eine Phase am Projektanfang. Dasselbe Muster wiederholt sich später pro Feature, nur in deutlich kompakterer Form. Auf Projektebene entstehen dauerhafte Dokumente wie das Glossar. Auf Featureebene entstehen Wegwerf-Dokumente, die nach der Implementierung verschwinden. Dazu mehr in der Implementierungssektion.

Implementierung

Sobald Architektur, Nordstern und Glossar stehen, beginnt die eigentliche Arbeit. Der Kern der Implementierungsphase ist eine Schleife. Eine kleine Einheit Arbeit definieren, sie implementieren lassen, automatisch validieren, integrieren. Dann von vorn.

Die kleinste sinnvolle Einheit ist der Vertical Slice. Ein Vertical Slice ist ein Stück Funktionalität, das alle Schichten der Anwendung durchläuft, vom Eingangspunkt bis zur Datenbank, aber nur in der minimal nötigen Breite. Beim allerersten Slice spricht man vom Walking Skeleton: ein End-zu-End-Pfad, der noch fast nichts kann, aber funktionsfähig durch alle Schichten geht. Jeder weitere Slice fügt einen schmalen Streifen Funktionalität hinzu.

Diese Schnittweise ist nicht agentenspezifisch, aber für Agenten besonders wertvoll. Sie liefert eine klar umrissene, end-to-end testbare Aufgabe. Das ist die Form, in der ein Agent autonom arbeiten kann.

Feature beschreiben

Vor der Implementierung steht eine kompakte Wiederholung des Musters aus Brainstorming und Klarstellung, jetzt auf Feature-Ebene. Welche Varianten sind denkbar? Welche wählen wir? Bringt das Feature neue Begriffe oder Konzepte ins Spiel?

Das Ergebnis ist eine Feature-Beschreibung mit Akzeptanzkriterien und gegebenenfalls einer oder zwei neuen Begriffsdefinitionen. Diese Dokumente sind bewusst Wegwerfware. Sie existieren nur, um den Agenten durch die Implementierung zu führen. Nach Abschluss verschwinden sie wieder.

Agentisches Programmieren ohne Mensch prüfen

Hier steht und fällt die Autonomie. Solange ein Mensch prüfen muss, ob ein Feature funktioniert, hat der Agent nur die halbe Arbeit gemacht. Das Ziel ist, dass der Agent selbst entscheiden kann, ob er fertig ist.

Die Werkzeuge dafür sind die üblichen, nur konsequenter angewendet:

• Unit-Tests für die innere Logik. Schnell, isoliert, in jeder Iteration ausführbar.
• Integrationstests für die Zusammenarbeit der Komponenten.
• End-to-End-Tests für den vollständigen Slice. Teurer in der Ausführung, schließen aber die größte Lücke.
• UI-Automation bei Features mit Oberfläche. Tools wie Playwright oder Cypress lassen den Agenten echte Browser steuern und Ergebnisse verifizieren.

Eine Regel hilft enorm: Akzeptanzkriterien werden vor der Implementierung als Tests formuliert. Damit hat der Agent von Anfang an ein objektives Kriterium für „fertig“. Er kann iterieren, bis grün, ohne dass zwischendurch jemand draufschaut.

Was sich nicht sinnvoll automatisiert testen lässt, ist ein Signal. Entweder ist das Feature zu unscharf beschrieben, oder die Architektur ist nicht testfreundlich genug, oder dieses spezielle Feature braucht doch einen Menschen im Loop. Alle drei Fälle sind in Ordnung, solange man sich bewusst dafür entscheidet.

Code-Qualität

Ohne menschliche Code-Reviews in jeder Iteration braucht es automatisierte Qualitätschecks, die in der CI laufen. Die Kategorien sind weitgehend stack-unabhängig, nur die konkreten Tools unterscheiden sich.

• Linter und Code-Style-Tools für die offensichtlichen Probleme. In PHP etwa PHP-CS-Fixer, in Python Ruff, in Java Checkstyle.
• Statische Analyse und Typechecker wie PHPStan oder Psalm in PHP, mypy oder Pyright in Python, ErrorProne oder NullAway in Java. Sie fangen ganze Klassen subtiler Fehler ab, die Tests übersehen.
• Architektur-Tests wie Deptrac in PHP, import-linter in Python oder ArchUnit in Java. Sie sorgen dafür, dass die Schichten und Abhängigkeitsregeln eingehalten werden, die in der Klarstellungsphase definiert wurden.
• Coverage- und Komplexitätsmetriken, mehr als Indikator denn als harter Schwellwert.

Zusätzlich lässt sich der Agent selbst als Architektur-Reviewer einsetzen. Ein zweiter Agent-Pass, der gezielt prüft, ob das neue Feature die etablierten Patterns respektiert, fängt Fälle, die strukturelle Tools nicht erfassen. Etwa: „Wird hier ein neues Domänenkonzept eingeführt, das eigentlich ins Glossar gehört?“

Refactoring und Integration

Wenn die Tests grün sind, ist die Arbeit nicht zu Ende, sondern an einem Zwischenstand angekommen. Agenten neigen dazu, Code zu schreiben, der funktioniert, aber nicht idiomatisch ist. Sie reimplementieren Hilfsfunktionen, die schon existieren. Sie erfinden parallele Strukturen neben bestehenden. Das ist einer der häufigsten Failure-Modes in langen Sessions.

Deshalb gehört nach jedem grünen Slice ein expliziter Refactoring-Schritt. Wo dupliziert das neue Feature etwas, das schon existiert? Lässt es sich auf vorhandene Abstraktionen zurückführen? Folgt es den Patterns, die im Rest der Codebase etabliert sind?

Das Ziel ist, dass das neue Feature ein Teil der Anwendung wird, nicht ein Fremdkörper, der zufällig daneben liegt. Diesen Schritt kann der Agent selbst übernehmen, wenn die Frage präzise gestellt wird, vor allem dann, wenn ihm Beispielcode gezeigt wird, an dem sich das Feature ausrichten soll.

Planungsdokumente entfernen

Sobald das Feature implementiert, getestet und integriert ist, werden die Feature-spezifischen Planungsdokumente gelöscht. Sie haben ihre Aufgabe erfüllt.

Der Grund ist wichtig. Solange beide existieren, Code und Planungsdokument, gibt es zwei konkurrierende Sources of Truth. Der Agent in der nächsten Session weiß nicht, welcher er folgen soll. In der Praxis bevorzugt er meistens das Markdown-Dokument, weil es leichter zu lesen ist. Das Ergebnis sind Entscheidungen, die auf einem überholten Plan basieren.

Wer auf den ursprünglichen Plan zurückgreifen will, findet ihn in der Git-Historie. Was im Working Tree liegt, soll aktiv und maßgeblich sein.

Wenn die Schleife beim agentischen Programmieren nicht schließt

Der Workflow bisher beschreibt den idealen Verlauf. In der Praxis gibt es ein paar wiederkehrende Stellen, an denen die Schleife nicht von selbst schließt.

• Tests, die grün sind, weil sie aufgeweicht wurden. Der häufigste Failure-Mode. Ein Test schlägt fehl, der Agent versteht die Ursache nicht und ändert statt der Implementierung den Test, bis er passt. Mal ist es ein gelockerter Assertion, mal ein skip, mal eine Mock-Antwort, die die Realität nicht mehr abbildet. Schutz dagegen: Tests als Reviewer behandeln, die nicht ohne expliziten Grund verändert werden dürfen. Eine Regel in der Kontextdatei wie „Tests dürfen nur angepasst werden, wenn sich das spezifizierte Verhalten ändert“ hilft. Außerdem ein expliziter Blick im Code Review auf alles, was an Tests jünger ist als ein, zwei Slices.
• Glossardrift. Der Agent führt im Code Begriffe ein, die nicht im Glossar stehen. Über mehrere Sessions wächst ein Schattenvokabular, das parallel zum dokumentierten läuft. Schutz dagegen: ein automatisierter Check, der neue Domain-Begriffe in Klassennamen oder Methodensignaturen meldet, oder ein dedizierter Agent-Pass, der das Glossar gegen den aktuellen Code abgleicht.
• Kontextdrift in langen Sessions. Je länger eine Session läuft, desto mehr verblasst der Anfangs-Kontext. Der Agent erfindet Patterns, die nicht zur Codebase passen, weil er den Bezug zur Kontextdatei irgendwo in seinem Kontextfenster verloren hat. Schutz dagegen: Sessions bewusst kurz halten. Ein abgeschlossener Slice ist ein guter Punkt für einen Neustart. Frischer Kontext mit neu eingelesener Kontextdatei ist meistens wertvoller als die Fortsetzung mit einem überfüllten Kontextfenster.
• Selbstbewusste Halbwahrheiten. Der Agent berichtet, ein Feature sei implementiert und getestet, obwohl die Tests in Wahrheit nie liefen oder kein einziger neuer Test geschrieben wurde. Schutz dagegen: Jeder abgeschlossene Slice braucht einen objektiven Beleg, etwa eine Test-Run-Ausgabe oder eine CI-Pipeline, die grün ist. Was nicht in der Ausgabe steht, wurde nicht ausgeführt.

Diese Probleme sind nicht prinzipiell lösbar, aber sie sind eingrenzbar. Je strenger die Feedback-Schleifen, desto kleiner der Spielraum für sie.

Fazit

Wenn man die vorgestellten Phasen aus der Distanz betrachtet, fällt auf, dass keine davon eine reine Agent-Praxis ist. Klare Domänensprache, kleine Slices, testbare Architektur, automatisierte Qualitätssicherung. Das sind Dinge, die gute Teams seit Jahren tun.

Agentisches Programmieren ändert nicht die Bestandteile dieser Praxis. Es ändert ihren Status. Was vorher ein Wettbewerbsvorteil war, wird zur Grundvoraussetzung. Was vorher als Disziplin galt, wird zur Infrastruktur. Wer dem Agent zwölf Mal pro Stunde gute Feedback-Schleifen anbieten kann, bekommt zwölf Mal pro Stunde ein brauchbares Ergebnis. Wer es nicht kann, bekommt zwölf Mal pro Stunde plausibel aussehenden Müll.

Der Hebel ist da. Wo er greift, hängt nicht vom Agenten ab, sondern davon, wie konsequent die Schleife zwischen Absicht, Implementierung und Validierung geschlossen wird. Das ist die Stelle, an der sich heute Investitionen in Tooling und Prozesse langfristig lohnen. Alles andere wird vom Modell der nächsten Generation eingeholt.