Warum schnellere Code-Generierung nicht dasselbe ist wie bessere Software — und was Agentic Engineering dagegen tut.
Langform-Begleittext zum Vortrag „Coding is cheap, Software is not! – Agentic Engineering explained“, den Henning Teek und ich im April 2026 beim Agentic Shift Meetup in Dortmund gehalten haben.
KI-Assistenten schreiben heute Code schneller, als es ein Mensch je könnte. Das ist der einfache Teil. Der schwierige Teil — der, an den die meisten Teams gerade stoßen — ist, dass schnellerer Code nicht bessere Software ist.
Das ist die zentrale Spannung dieses Moments. Das Tooling hat eine Schwelle überschritten. Die Methodik ist nicht nachgezogen. Das Ergebnis ist eine Lücke zwischen dem, was technisch möglich ist, und dem, was tatsächlich auslieferbar ist — und viele Projekte fallen hinein.
Der Weg über diese Lücke hat einen Namen: Agentic Engineering. Es lohnt sich auseinanderzunehmen, was es ist, warum es gebraucht wird und wie es in der Praxis aussieht.
Die Ära, in der wir wirklich sind
Kurz zur Einordnung, denn Kontext zählt.
Von 2020 bis 2022 — die Foundation-Ära — machte GPT-3 plausible Code-Generierung möglich. Codex und Copilot verwandelten natürliche Sprache in Code. ChatGPT machte es massentauglich. Der Tagline jener Ära: KI schlägt vor, Menschen entscheiden. Autocomplete auf Steroiden.
2023 bis 2024 kam die kambrische Explosion. GPT-4. Cursor. Codeium, Windsurf, Tabnine, Sourcegraph, CodeWhisperer. Bis Ende 2024 nutzten Millionen Entwickler täglich KI-Tools. Der Tagline verschob sich: vom Copilot zum Co-Entwickler. KI begann, Kontext zu verstehen.
2025 und 2026 sind die Agentic-Ära. 85 % der Entwickler nutzen KI-Tools. Cursor erreichte eine Bewertung von 29,3 Mrd. USD. Claude Code knackte in sechs Monaten 1 Mrd. USD ARR. Codex überschritt 2 Mio. wöchentlich aktive Nutzer. Der Tagline erneut: von Autocomplete zu autonom. Agenten schlagen nicht nur Zeilen vor — sie übernehmen Aufgaben.
Jeder Übergang war schneller als der vorige. Und jeder hat die Lücke zwischen dem, was KI produzieren kann, und dem, was Teams tatsächlich in Produktion bringen können, vergrößert.
Was Vibe Coding wirklich ist
„Vibe Coding“ ist zu einem populären Begriff geworden, und wie viele populäre Begriffe meint er etwas Loseres, als er klingt. Präzision lohnt sich:
Vibe Coding ist, wenn man eine KI promptet und schaut, was herauskommt. Keine Struktur. Keine Verifikation. Keine Spezifikation. Nur Absicht → Output → Hoffnung.
Für Prototypen funktioniert es erstaunlich gut. Ein lauffähiger Demo von nahezu allem ist die Arbeit eines Nachmittags. Der Output ist oft beeindruckend genug, dass Teams zu glauben beginnen, das sei die neue Normalität.
Es ist die neue Normalität — für Prototypen.
Für Produktionssoftware bricht Vibe Coding in dem Moment zusammen, in dem Komplexität auftritt. Und Komplexität tritt immer auf. Mehrsprachigkeit. Ein Schema-Update. Eine neue Nutzerrolle. Ein Edge Case in der Abrechnungslogik. Echte Software muss weiter funktionieren, wenn die Realität hereinbricht — und Vibe Coding hat keine Verteidigung gegen die Realität.
Das Muster ist über Teams hinweg konsistent: Ein schneller Prototyp funktioniert wunderbar, die Erwartungen steigen, ein zweites Projekt startet mit demselben Ansatz, und irgendwo um die dritte oder vierte Anforderung wird das Datenbankmodell korrumpiert, das Schema driftet vom Code weg, und das Projekt kollabiert unter seinem eigenen Gewicht.
Die Wand ist gut kartiert. Worauf es ankommt, ist der Weg dahinter.
Die Leiter
Bevor es darum geht, wie Agentic Engineering in der Praxis aussieht, hilft ein mentales Modell dafür, wo ein Team auf der Kurve steht. Die Progression ist eine Leiter mit fünf Stufen:
- Chat — einfache Interaktion mit einem Modell. Fragen, erhalten, kopieren.
- Mid-loop generation — KI generiert Code-Blöcke, die in einen größeren Kontext eingefügt werden.
- In-the-loop agentic — KI assistiert innerhalb der Entwicklungsumgebung, mit Zugriff auf Dateien, Terminals, Tools.
- On-the-loop agentic — KI arbeitet mit reduzierter direkter Aufsicht. Menschen setzen Ziele; Agenten führen aus; Menschen prüfen nach.
- Multi-Agent Coding — mehrere Agenten kooperieren an komplexen Problemen, oft mit spezialisierten Rollen.
Die meisten Entwickler stehen heute irgendwo zwischen Stufe 2 und Stufe 3. Die spannende Arbeit — die, die tatsächlich verändert, wie Software gebaut wird — passiert auf Stufe 4 und 5.
Der Haken: Die Leiter lässt sich nicht ohne Engineering-Disziplin erklimmen. Jede Stufe nach oben bedeutet weniger direkten menschlichen Review pro Code-Zeile. Dieser Tausch funktioniert nur, wenn das System um den Agenten herum — Spezifikationen, Guardrails, Verifikationsschichten — entsprechend stärker wird.
Vibe Coding auf Stufe 4 ist, wie Produktionsdatenbanken korrumpiert werden.
Die Spezifikation ist die Schnittstelle
Der Mindset-Shift, der am längsten braucht, um verinnerlicht zu werden:
In der klassischen Softwareentwicklung sind Anforderungen eine Dokumentations-Übung. Sie werden geschrieben, Stakeholder geben ihr Okay, Entwickler ziehen sie zurate, wenn es passt, und sie driften langsam aus dem Code heraus. Sie sind nice to have. Sie sind selten tragend.
In Agentic Engineering werden Anforderungen zur Laufzeitkomponente.
Systemprompts, Skill-Definitionen, Tool-Beschreibungen, Akzeptanzkriterien — das sind keine Artefakte, die der Agent einmal liest und vergisst. Es ist das, was der Agent jedes Mal liest, wenn er entscheidet, was als Nächstes zu tun ist. Eine vage Spec bedeutet einen ratenden Agenten. Eine mehrdeutige Tool-Beschreibung ist ein Live-Bug. Ein fehlender Edge Case ist keine Dokumentationslücke — es ist ein Produktions-Incident, der nur darauf wartet zu passieren.
Das verändert die Ökonomie des Spec-Schreibens.
Im alten Modell war Zeit, die in eine präzise Anforderung floss, Zeit, die nicht ins Bauen floss. Es gab einen Trade-off. Im neuen Modell ist die Spec Teil des Bauens. Zeit, die in die Spec fließt, multipliziert sich — jeder zukünftige Agent-Aufruf profitiert davon.
Es gibt auch eine Rückkopplungsschleife, die die meisten Teams noch nicht entdeckt haben: KI ist außergewöhnlich gut darin, beim Schreiben von Anforderungen zu helfen. Sie kann klärende Fragen stellen, Edge Cases ausloten, Annahmen sichtbar machen, die Menschen unbewusst treffen, Meeting-Transkripte in strukturierte User Stories verwandeln, Konflikte über große Anforderungs-Sets hinweg markieren und Test-Szenarien direkt aus Akzeptanzkriterien erzeugen.
Je besser Teams darin werden, KI zum Schreiben von Anforderungen zu nutzen, desto besser folgen ihre Agenten diesen. Das ist keine Metapher — es ist eine buchstäbliche Kausalkette.
Die Guardrails
Spezifikationen sagen dem Agenten, was zu bauen ist. Guardrails sagen dem System, was abzulehnen ist, wenn der Agent es falsch macht. Beides ist nötig. Keines allein genügt.
Sechs Guardrails machen den größten Unterschied. Keine davon ist neu. Neu ist, dass sie von „guter Engineering-Hygiene“ zu „tragender Infrastruktur“ geworden sind.
1. Continuous Integration mit kurzlebigen Branches
KI generiert Code in Mengen, die klassische Git-Workflows sprengen. Ein langlebiger Feature-Branch, der zwei Wochen lebt, sammelt so viel agentengenerierte Veränderung an, dass das Zurückmergen zu einem Projekt für sich wird.
Die Regel: Branches sollten Stunden leben, nicht Tage. Häufig mergen. Konflikte früh auflösen. Die Veränderungsrate beherrschbar halten. Continuous Integration bleibt nur kontinuierlich, wenn Integration tatsächlich kontinuierlich passiert.
2. Statisch typisierte Sprachen
Der Compiler ist ein kostenloser Guardrail. Er fängt eine Kategorie von Halluzination ab, die dynamische Sprachen stillschweigend durchlassen.
TypeScript, C#, Java, Rust — die konkrete Sprache zählt weniger als das Prinzip. Das Typsystem ist die billigste, schnellste, zuverlässigste Feedback-Schleife, die es gibt.
Ein subtiles Muster, das es wert ist, genannt zu werden: Primitive Obsession vermeiden. LLMs vertauschen häufig gleichtypige Argumente. Eine Funktion wie greet(name: string, id: string) ist eine Vertauschung von einem Bug entfernt, den der Compiler nicht fangen kann. Ersetze sie durch greet(name: PersonName, id: PersonId) — Domain-Typen — und der Compiler fängt die Vertauschung sofort. Kostenloser Guardrail, null Laufzeitkosten.
3. Linting und Formatierung – deterministisch, nicht KI
Bitte die KI nicht, Code zu formatieren. Nutze Prettier, CSharpier, ESLint — was der Stack erwartet. Deterministische Tools sind schneller, zuverlässiger und verbrennen keine Tokens.
Führe sie auf dem Diff aus, nicht auf der ganzen Codebasis. Stage nur das Geänderte. Halte das Kontextfenster sauber für die Arbeit, die wirklich Schlussfolgern erfordert.
4. Architektur-Unit-Tests
Dieser ist unterbenutzt. Tools wie ArchUnit erlauben die programmatische Durchsetzung von Design-Constraints — „die UI-Schicht darf nie direkt die Datenbank aufrufen“, „dieses Modul darf nicht von jenem abhängen“, „Domain-Logik darf keinen Framework-Code importieren“.
Der Agent muss sich die Architektur nicht merken. Die Tests tun es. Wenn der Agent ein Muster verletzt, fällt der Build sofort. Kein menschlicher Review, keine Architekturdiagramme zum Nachschlagen, kein langsames Driften über Monate.
5. Behavior-Unit-Tests, nicht Coverage-Tests
100 %-Coverage-Ziele sind, wie Teams bei KI-generierten Slop-Tests landen. Der Agent schreibt bereitwillig Tests, die jede Zeile durchlaufen und nichts verifizieren.
Teste Verhalten, nicht Coverage. Teste die zentralen Domain-Use-Cases — die Dinge, die wehtun würden, wenn sie brächen. Schreibe Tests, die Refactoring überleben: Wenn sich das Verhalten nicht geändert hat, sollte der Test nicht brechen. Ein Test, der jedes Mal bricht, wenn Interna umsortiert werden, testet das Falsche.
6. Code-Quality-Tools mit MCP
Der neuere Trend, der gleich alles verändern wird: Tools wie SonarQube und CodeScene unterstützen jetzt das Model Context Protocol. Quality-Reports können direkt an den Agenten zurückgefüttert werden, der dann autonom refactoren kann.
Zyklomatische Komplexität, Code Smells, Schwachstellen, tief verschachtelte Logik, „Bumpy-Road“-Erkennung — all das wird zum Input für den nächsten Agent-Aufruf. Die Feedback-Schleife schließt sich. Der Agent schreibt nicht nur Code; er liest das Urteil über seinen Code und überarbeitet ihn.
Das ist eines der interessantesten Dinge, die gerade im Tooling passieren — und die meisten Teams haben es noch nicht aufgegriffen.
Was das mit Teams macht
Hier werden die Implikationen unbequem, denn sie sind organisatorisch, nicht nur technisch.
Jahrzehntelang galt das Argument des Mythical Man-Month: Mehr Menschen in ein Softwareprojekt zu stecken, macht es nicht schneller — oft sogar langsamer. Mehr Entwickler bedeutet mehr PRs, mehr Orchestrierungs-Overhead, mehr gegenseitiges Im-Weg-Stehen. Teams umgingen das, indem sie trotzdem größere Mannschaften aufbauten und die Reibung als Kosten des Geschäfts akzeptierten.
Agentic Engineering bricht diese Rechnung.
Zwei Entwickler, die sich mit gut instrumentierten Agenten abwechseln, können ein Zwanziger-Team outshippen. Nicht weil die Entwickler einzeln heroisch sind, sondern weil der Orchestrierungs-Overhead kollabiert. Individuelle Verantwortung ersetzt Team-Koordination. Lines of Code sind nicht mehr der Engpass — Review, Testing und QA werden zum Engpass.
Auch die Form des Entwicklungs-Funnels ändert sich.
Im alten Modell war der Software-Funnel bewusst verlustbehaftet. Fünfhundert Nutzerprobleme wurden auf fünfzehn heruntergebrochen, fünf programmiert und ausgeliefert. Code zu schreiben war zu teuer, um es spekulativ zu tun — also passierte an jeder Stufe starkes Filtern.
Im neuen Modell springt ein in den Agenten eingefügter Screenshot direkt zu geschriebenem Code. Alles, was spezifiziert wird, wird geschrieben. Der Filter verschwindet nicht — er verschiebt sich. Er verschiebt sich zu Review, zu Testing, zu QA, zu Deployment. Dort sammelt sich jetzt der Backlog. Hunderte PRs liegen unausgeliefert — nicht, weil der Code nicht fertig ist, sondern weil alles drumherum nicht im selben Tempo billiger wurde.
Das ist die Arbeit, die für Menschen bleibt, und sie ist nicht weniger wichtig als das, was vorher kam. Sie ist wohl wichtiger. Den Review zu verantworten, die QA zu verantworten, die Auslieferung zu verantworten — dort liegt jetzt der Hebel.
Große Teams sind Flugzeugträger. Kleine Teams mit Agenten sind Schnellboote. Beides hat seinen Platz, aber die Wette für das meiste, was heute gebaut wird, liegt auf Schnellbooten.
Was Agentic Engineering wirklich bedeutet
Drei Prinzipien, destilliert:
Baue zuerst die Guardrails. Vor jeder Feature-Arbeit: die CI-Schleife, die statischen Typen, die Linter, die Architektur-Tests, die Behavior-Tests aufsetzen. Am ersten Tag ist es langsamer. Es ist der einzige Grund, warum das Projekt bis Tag dreißig überlebt.
Schreibe die Spec vor dem Code. Kein Dokument für Stakeholder — ein Dokument für den Agenten. Sei präzise. Sei eindeutig. Sei explizit bei Edge Cases. Lass die KI beim Schreiben helfen; genau darin ist sie gut.
Verschiebe die Rolle des Teams. Hör auf, Entwickler als die Menschen zu denken, die Code schreiben. Beginne, sie als die Menschen zu denken, die den Prozess verantworten — Anforderungen, Architektur, Review, Auslieferung. Der Agent erledigt Aufgaben. Menschen treffen Entscheidungen.
Coding ist billig. Software nicht. Die Lücke zwischen beiden ist, wo die echte Arbeit passiert — und auch, wo der echte Wert für das nächste Jahrzehnt liegen wird.
