*Was sich ändert, wenn ein AI-Agent das Hauptwerkzeug ist, und was nicht*
—
Die Idee, KI-Agenten als primäres Werkzeug in der Softwareentwicklung einzusetzen, wird derzeit breit diskutiert. Die Versprechen reichen von massiver Produktivitätssteigerung bis hin zur vollständig autonomen Code-Generierung. Die Praxis sieht erwartungsgemäß differenzierter aus. In diesem Beitrag berichten wir aus fünf Wochen Projektarbeit, in denen ein AI-Agent, konkret Claude Code von Anthropic, als primäres Entwicklungswerkzeug eingesetzt wurde. Dabei zeigen wir, wo sich die Produktivität tatsächlich verändert hat, wo sie gleich geblieben ist und welche neuen Herausforderungen entstanden sind, die in klassischer Softwareentwicklung so nicht existieren.
Die Zahlen des Projekts: 345 Commits in 35 Tagen, umgesetzt von 1,5 Personen. 28.600 Zeilen Code, verteilt auf 32 Pull Requests.
Das Ergebnis: **AgentTicket**, ein AI-gestütztes Ticket-Routing-System mit LLM-Pipeline, ERP-Anbindung, Blazor-Dashboard, Keycloak-Authentifizierung und OTOBO-Integration. Kein Prototyp, sondern ein System, das auf einer Azure VM in Produktion läuft. Keine Zeile davon wurde von Hand geschrieben. Jede Zeile Code, jeder Test, jedes Dockerfile wurde vom AI-Agenten implementiert, gesteuert durch menschliche Spezifikation und Verifikation.
Heißt das, AI macht alles zehnmal schneller? Nein. Es heißt, dass sich fundamental verschiebt, wo die Zeit hingeht. In der Literatur zu Human-AI Collaboration wird dieses Phänomen als *Task Reallocation* beschrieben: Die Gesamtarbeit bleibt vergleichbar, aber die Verteilung zwischen kognitiven und mechanischen Tätigkeiten verändert sich erheblich.
## Der Feature-Workflow
Jedes Feature in unserem Projekt folgt einem standardisierten Ablauf, der sich über die fünf Wochen als stabil und reproduzierbar erwiesen hat:
```
PRD schreiben
↓
Claude erarbeitet technischen Plan
↓
Review und Diskussion
↓
Plan approven
↓
Claude implementiert
↓
Smoke Test → Doku-Update → Commit
```Am Anfang steht immer eine **PRD** (Product Requirements Document): Was wollen wir erreichen, was existiert bereits im System und welche Constraints gelten? Claude liest die PRD, analysiert die bestehende Codebasis und schlägt einen technischen Plan vor. Dieser Plan wird gemeinsam diskutiert, in Frage gestellt und gegebenenfalls revidiert. Erst nach explizitem Approval wird implementiert.
Diese Trennung zwischen Spezifikation und Implementierung ist kein Zufall, sondern eine bewusste methodische Entscheidung. Sie stellt sicher, dass die fachliche Verantwortung durchgehend beim Menschen verbleibt, während der Agent die Umsetzung übernimmt. In gewisser Weise formalisiert dieser Workflow eine Rollenverteilung, die in der klassischen Softwareentwicklung zwischen Architekt und Entwickler existiert, nur dass der „Entwickler“ hier ein Agent ist, der in Minuten umsetzt, wofür ein Mensch Stunden benötigt.
Ein konkretes Beispiel verdeutlicht den Ablauf: die Knowledge-Base-Integration. Die PRD lautete schlicht: „Die Pipeline braucht Zugriff auf Produktdokumentation.“ Claude analysiert daraufhin die bestehende Pipeline-Architektur, identifiziert die geeignete Einfügestelle und schlägt einen neuen Verarbeitungsschritt vor. Wir diskutieren, wie der Index strukturiert sein soll, nach welchen Kriterien Ticket-Inhalte auf Artikel gematcht werden und wie mit Mehrdeutigkeiten umgegangen wird. Plan approved, Claude implementiert: den neuen Step, eine MockERP-Erweiterung, fünf Knowledge-Base-Artikel und die zugehörigen Tests. Anschließend Smoke Test, Doku-Update, Merge. Zwei Tage vom PRD zum fertigen, verifizierten Feature. In einer klassischen Entwicklungsumgebung hätte allein die Iteration zwischen Spezifikation und funktionierendem Code eine Woche in Anspruch genommen.
## Produktivitätsgewinne
Am produktivsten Tag haben wir 35 Commits und 5 Pull Requests gemerged: Dashboard-Authentifizierung, Sidebar-UI, TicketFeeder und Jaeger-Tracing. An einem einzigen Tag. Schauen wir uns systematisch an, welche Tätigkeiten durch den Agenten konkret schneller wurden und warum.
**Boilerplate und Scaffolding.** Einen neuen Pipeline-Step anlegen, also Interface-Definition, Implementierung, DI-Registrierung und zugehörige Tests, dauert mit dem Agenten etwa 15 Minuten statt zwei Stunden. Das zugrunde liegende Muster ist immer dasselbe, und genau bei solchen repetitiven Strukturen spielt der Agent seine Stärke aus. Er kennt die Konventionen des Projekts und wendet sie konsistent an. In der Software Engineering-Forschung wird dieser Vorteil als *Pattern Compliance* beschrieben: Der Agent weicht nicht von etablierten Mustern ab, weil er nicht müde wird und nicht abkürzt.
**Exploration und API-Integration.** Die Anweisung „Lies die OTOBO-REST-API-Doku und schreib einen Client“ liefert einen funktionierenden Client, weil der Agent Dokumentation schneller verarbeitet und in lauffähigen Code übersetzen kann als ein Mensch. Besonders bei unbekannten APIs spart das erheblich Zeit, die sonst in das Lesen, Verstehen und iterative Ausprobieren von Dokumentation fließen würde. Der Agent nimmt die gesamte Spezifikation auf einmal auf und produziert einen ersten funktionierenden Entwurf, der dann nur noch verfeinert werden muss.
**Refactoring im großen Stil.** 13 Skills umbenannt, 45 Tickets in eine neue Verzeichnisstruktur verschoben, alle Querverweise aktualisiert. Ein Nachmittag statt ein ganzer Tag. Solche weitreichenden, aber mechanischen Änderungen sind genau die Aufgaben, bei denen manuelles Arbeiten fehleranfällig und zeitaufwändig ist. Der Agent kann dabei sicherstellen, dass keine Referenz vergessen wird, weil er systematisch alle Abhängigkeiten traversiert.
**Dashboard-UI.** Tailwind und Blazor folgen klaren Patterns, und der Agent beherrscht sie. Layouts, Komponenten und responsive Anpassungen entstehen in einem Bruchteil der Zeit, die manuelle Implementierung erfordern würde. Besonders bei UI-Arbeit, die typischerweise viele kleine Iterationsschleifen erfordert, beschleunigt der Agent den Zyklus zwischen Änderung und Ergebnis erheblich.
**Infrastruktur.** Dockerfiles, Docker Compose Konfigurationen und Keycloak-Setup sind im Wesentlichen Pattern-Arbeit. Der Agent generiert funktionsfähige Konfigurationen auf Basis weniger Anforderungen, die anschließend nur noch geprüft und gegebenenfalls angepasst werden müssen. Die Fehlerrate bei Infrastruktur-Konfigurationen war in unserem Projekt auffallend niedrig, vermutlich weil der Agent auf ein breites Repertoire bekannter Konfigurationsmuster zurückgreifen kann.
Grob geschätzt waren diese Tätigkeiten drei- bis fünfmal schneller als in einer klassischen Entwicklungsumgebung. Wichtig ist dabei die Einschränkung: Diese Beschleunigung betrifft ausschließlich Tätigkeiten mit hohem Anteil an mechanischer Umsetzung und geringem Anteil an konzeptioneller Neuschöpfung.
## Was gleich langsam war
Nicht alles wird schneller. Und es ist wichtig, diese Grenze ehrlich zu benennen, weil sie fundamental ist für das Verständnis dessen, was Agentic Engineering leisten kann und was nicht.
**Architektur-Entscheidungen.** Die Frage, welche Steps die Pipeline braucht, wo die Grenzen zwischen ihnen liegen und welche Daten zwischen ihnen fließen, ist eine konzeptionelle Aufgabe. Der Agent kann Optionen präsentieren, Vor- und Nachteile auflisten und Beispiele aus vergleichbaren Systemen anbieten. Aber die Entscheidung selbst muss der Mensch treffen. Architektur entsteht aus dem Verständnis der Domäne, der technischen Constraints und der langfristigen Wartbarkeit. Diese Form von Urteilsvermögen lässt sich nach unserem Erleben nicht an den Agenten delegieren, zumindest nicht bei dem aktuellen Stand der Technologie.
**Datenmodell-Design.** Die Trennung zwischen Step Results und Context Snapshot, also die Frage, welche Daten wo, in welcher Granularität und in welcher Struktur gespeichert werden, hat drei Iterationen und mehrere intensive Gespräche erfordert. Jede Iteration setzte ein tieferes Verständnis der Zusammenhänge zwischen den Pipeline-Steps voraus. Der Agent konnte die jeweilige Variante schnell umsetzen. Aber die konzeptionelle Arbeit, die Abwägung zwischen Normalisierung und Zugriffsperformanz, zwischen Flexibilität und Konsistenz, war nicht beschleunigbar. Dieses Phänomen ist konsistent mit der Beobachtung, dass generative KI bei *divergentem Denken*, also dem Erzeugen neuer Lösungsansätze, weniger Beschleunigung bietet als bei *konvergentem Denken*, also dem Umsetzen einer bereits definierten Lösung.
**Prompt-Engineering.** Jeder Prompt für die LLM-Pipeline brauchte drei bis fünf Durchläufe mit echten Tickets, um fachlich korrekte Ergebnisse zu liefern. Prompt-Engineering ist Domänenarbeit im eigentlichen Sinne: Man muss verstehen, welche Nuancen in einem Support-Ticket relevant sind, wie Dringlichkeit sprachlich zum Ausdruck kommt, welche Kontextinformationen das Modell benötigt und wo es zu Fehlinterpretationen neigt. Das geht nicht schneller, nur weil der Agent den umgebenden Code in Minutenschnelle anpasst. Die eigentliche Bottleneck-Ressource ist das fachliche Verständnis, nicht die Implementierungsgeschwindigkeit.
**Debugging von Agent-Fehlern.** Wenn der Agent in die falsche Richtung läuft, kann das Zurückrollen teurer werden als die ursprünglich gesparte Zeit. Besonders bei längeren Sessions, in denen der Agent schrittweise den Überblick über den Gesamtkontext verliert, entstehen subtile Fehler, die erst spät sichtbar werden. Dieses Risiko ist spezifisch für Agentic Engineering und existiert in klassischer Entwicklung in dieser Form nicht. Es lässt sich als eine Art *Automation Complacency* interpretieren: Je reibungsloser der Agent arbeitet, desto seltener hinterfragt man seine Zwischenergebnisse.
Die zentrale Erkenntnis lässt sich auf einen Satz verdichten: Der Agent beschleunigt die Umsetzung, nicht das Denken. Das klingt offensichtlich, hat aber weitreichende Konsequenzen für die Projektplanung. Die zeitintensiven Phasen verschieben sich von der Implementierung hin zur Spezifikation und Verifikation.
## Empfehlungen für die Praxis
Aus fünf Wochen Agentic Engineering haben wir eine Reihe konkreter Empfehlungen mitgenommen, die wir beim nächsten Projekt von Tag eins an beherzigen würden. Sie betreffen sowohl die methodische Ebene als auch den konkreten Umgang mit dem Agenten im Arbeitsalltag.
**Kohärente Testdaten am ersten Tag.** Nicht am zehnten. Einen Nachmittag in gute, in sich konsistente Sampledaten zu investieren, spart im weiteren Verlauf Wochen an Debugging-Aufwand. Wir haben das in Woche zwei auf die harte Tour gelernt, als inkonsistente Testdaten zu falschen Verifikationsergebnissen führten. Dieser Punkt ist so zentral für Agentic Engineering, dass wir ihm einen eigenständigen Artikel gewidmet haben. Kohärente Testdaten sind nicht nur ein Qualitätsinstrument, sondern fungieren als implizite Spezifikation, die dem Agenten fachlichen Kontext vermittelt.
**Kleine, verifizierbare Einheiten erzwingen.** „Implementiere Step 1, Smoke Test, dann Step 2″ statt „Implementiere die Pipeline“. Der Agent ist so schnell, dass die Versuchung groß ist, alles auf einmal machen zu lassen. Das rächt sich unweigerlich, weil Fehler sich akkumulieren und bei wachsender Komplexität schwerer zu isolieren sind. Kleine, einzeln verifizierbare Einheiten sind in Agentic Engineering noch wichtiger als in klassischer Entwicklung, weil der Feedback-Zyklus zwischen Implementierung und Verifikation kürzer sein muss, um Agent-Fehler frühzeitig zu erkennen.
**Wiederkehrende Abläufe als Skills formalisieren.** Prozesse wie `/smoke-test`, `/docupd` oder `/release` sollten so früh wie möglich als formale Skills definiert werden. Das macht den Agenten bei Routineaufgaben zuverlässiger und den gesamten Workflow reproduzierbar. In unserem Projekt hat sich gezeigt, dass formalisierte Skills die Fehlerrate bei wiederkehrenden Aufgaben erheblich senken, weil der Agent nicht mehr improvisieren muss, sondern einem klar definierten Ablauf folgt. Letztlich ist das nichts anderes als die Standardisierung von Prozessen, ein in der Softwareentwicklung wohlbekanntes Prinzip, angewandt auf die Interaktion mit einem KI-Agenten.
**Das Context-Fenster respektieren.** Lange Sessions werden qualitativ schlechter. Die Aufmerksamkeit des Agenten, wenn man so will, nimmt mit wachsendem Kontextfenster ab. Eine frische Session mit klarem Briefing liefert konsistent bessere Ergebnisse als eine Marathon-Session, in der der Agent schrittweise den Überblick verliert. Wir haben gelernt, Sessions thematisch zu begrenzen und bei jedem Kontextwechsel, etwa von Backend-Logik zu Dashboard-UI, neu zu starten. Die Analogie zur menschlichen Arbeit liegt nahe: Fokussierte, zeitlich begrenzte Arbeitsphasen an einem klar definierten Thema sind produktiver als lange, fragmentierte Sessions.
## Fazit
Agentic Engineering verschiebt den Engpass in der Softwareentwicklung: weg vom Code schreiben, hin zum Code spezifizieren und verifizieren. Der Workflow lässt sich auf eine einfache Formel bringen: Der Mensch denkt, der Agent setzt um, der Test verifiziert.
Das bedeutet nicht, dass weniger Arbeit anfällt. Es bedeutet, dass *andere* Arbeit anfällt. Die Fähigkeit, präzise Anforderungen zu formulieren, Ergebnisse fachlich zu bewerten und Architektur-Entscheidungen fundiert zu treffen, wird in einem agentengestützten Kontext wichtiger, nicht unwichtiger. Die klassischen Software-Engineering-Kompetenzen, Domänenverständnis, Systemdenken, Qualitätssicherung, verlieren nicht an Relevanz. Sie verschieben sich lediglich in der Gewichtung.
Wer erwartet, Agentic Engineering reduziere Software-Entwicklung auf Prompt-Eingabe, unterschätzt die Komplexität der Aufgabe. Wer hingegen versteht, dass es die Gewichte innerhalb des Entwicklungsprozesses verschiebt und bereit ist, die eigene Arbeitsweise entsprechend anzupassen, kann die damit verbundenen Produktivitätsgewinne tatsächlich realisieren. Die Zukunft der Softwareentwicklung liegt vermutlich nicht in der vollständigen Automatisierung, sondern in einer bewussten Arbeitsteilung zwischen menschlicher Urteilskraft und maschineller Umsetzungsfähigkeit.