# Coding Is Cheap, Software Is Not > Warum schnellere Code-Generierung nicht dasselbe ist wie bessere Software — und was Agentic Engineering dagegen tut. - URL: https://seiler.it/articles/coding-is-cheap-software-is-not/ - Author: Dr. Sven Seiler (https://seiler.it/) - Type: Article - Language: de - Published: 2026-05-17 - Updated: 2026-09-24 TL;DR - KI-Assistenten schreiben Code schneller als Menschen — aber schnellerer Code ist nicht bessere Software, und genau in dieser Lücke scheitern Projekte. - „Vibe Coding“ (Prompt → Output → Hoffnung) funktioniert für Prototypen; Produktionssoftware braucht Struktur, Verifikation und Spezifikation. - Der Weg nach vorn hat einen Namen: Agentic Engineering — ein strukturierter, nachprüfbarer Ansatz, der KI mit Guardrails verbindet. - Spezifikationen werden zur Laufzeitkomponente: Jeder Agent-Aufruf liest sie — vage Specs bedeuten ratende Agenten. - Sechs Guardrails machen den größten Unterschied: CI mit kurzlebigen Branches, statische Typen, deterministisches Linting, Architektur-Tests, Behavior-Tests und Code-Quality-Tools mit MCP. **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[^1]“, 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 — in meiner eigenen, groben Einteilung der letzten Jahre. 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, wie ich es nenne, die **kambrische Explosion**. GPT-4 erschien, und Werkzeuge wie Cursor, Codeium und Windsurf, Tabnine, Sourcegraph und CodeWhisperer wurden breit genutzt — einige davon gab es schon vorher. Aus meiner Sicht wurden KI-Tools in dieser Zeit für viele Entwickler zum Alltag. 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 regelmäßig KI-Tools[^2]. Cursor erreichte im November 2025 eine Bewertung von 29,3 Mrd. USD[^3]. Claude Code knackte sechs Monate nach dem Marktstart 1 Mrd. USD Umsatz-Run-Rate[^4]. Codex kam auf über 2 Mio. wöchentliche Nutzer (Stand März 2026, OpenAI[^5]). 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“ — geprägt von Andrej Karpathy in einem Beitrag auf X[^6] im Februar 2025 — 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. Eine lauffähige 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. Aus meiner Sicht zeigt sich immer wieder dasselbe Muster: 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. Aus meiner Sicht ist diese Wand gut bekannt. 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. Ich beschreibe die Progression als Leiter mit fünf Stufen — ein eigenes Denkmodell, kein etablierter Standard: 1. Chat — einfache Interaktion mit einem Modell. Fragen, erhalten, kopieren. 1. Mid-loop generation — KI generiert Code-Blöcke, die in einen größeren Kontext eingefügt werden. 1. In-the-loop agentic — KI assistiert innerhalb der Entwicklungsumgebung, mit Zugriff auf Dateien, Terminals, Tools. 1. On-the-loop agentic — KI arbeitet mit reduzierter direkter Aufsicht. Menschen setzen Ziele; Agenten führen aus; Menschen prüfen nach. 1. Multi-Agent Coding — mehrere Agenten kooperieren an komplexen Problemen, oft mit spezialisierten Rollen. Meine Einschätzung: 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 aus meiner Sicht noch zu wenige Teams nutzen: **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. Für mich ist das keine Metapher, sondern ein direkter Zusammenhang. ## 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 aus meiner Sicht immer wieder 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[^7] 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 aus meiner Sicht viel verändern wird: Tools wie SonarQube[^8] und CodeScene[^9] 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[^10]“-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 nach meinem Eindruck haben es die meisten Teams noch nicht aufgegriffen. ## Was das mit Teams macht Hier werden die Implikationen unbequem, denn sie sind organisatorisch, nicht nur technisch. Jahrzehntelang galt Brooks’ Gesetz[^11] aus dem *Mythical Man-Month*: Wer einem verspäteten Softwareprojekt mehr Leute gibt, macht es noch später. Mehr Entwickler bedeutet mehr PRs, mehr Orchestrierungs-Overhead, mehr gegenseitiges Im-Weg-Stehen. Trotzdem wuchsen Teams weiter, weil es kaum eine Alternative gab — die Reibung wurde als Kosten des Geschäfts akzeptiert. Agentic Engineering bricht diese Rechnung. Meine Einschätzung aus der Praxis, keine Messung: 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. Ein illustratives Beispiel, keine Messung: Aus fünfhundert Nutzerproblemen wurden fünfzehn ausgewählt, 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. PRs bleiben unausgeliefert liegen — 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. ## Quellen [^1]: Agentic Shift Meetup: „Coding is cheap, Software is not! - Agentic Engineering explained“, Veranstaltungsseite, 16. April 2026, Storm Reply, Dortmund. [meetup.com](https://www.meetup.com/agentic-shift/events/313726421/) [^2]: JetBrains Research: „The State of Developer Ecosystem 2025“, Oktober 2025. Befragung von 24.534 Entwicklerinnen und Entwicklern, April bis Juni 2025. [blog.jetbrains.com](https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/) [^3]: Cursor: „Past, Present, and Future“ (Ankündigung der Series D, 2,3 Mrd. USD bei 29,3 Mrd. USD Post-Money-Bewertung), 13. November 2025. [cursor.com](https://cursor.com/blog/series-d) [^4]: Anthropic: „Anthropic acquires Bun as Claude Code reaches $1B milestone“, 3. Dezember 2025. [anthropic.com](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) [^5]: OpenAI: „OpenAI raises $122 billion to accelerate the next phase of AI“, Unternehmensmitteilung, 31. März 2026. [openai.com](https://openai.com/index/accelerating-the-next-phase-ai/) [^6]: Andrej Karpathy: Beitrag auf X, in dem er den Begriff „vibe coding“ prägt, 2. Februar 2025. [x.com](https://x.com/karpathy/status/1886192184808149383) [^7]: ArchUnit: „ArchUnit – Unit test your Java architecture“, Projektwebsite, abgerufen 27. September 2026. [archunit.org](https://www.archunit.org/) [^8]: Sonar (Manish Kapur): „Announcing SonarQube MCP Server: Bringing code quality into your AI workflow“, Unternehmensblog, 7. Oktober 2025. [sonarsource.com](https://www.sonarsource.com/blog/announcing-sonarqube-mcp-server/) [^9]: CodeScene: „CodeScene MCP Server: Bring Code Health Insights Into Your AI Workflow“, Produktdokumentation, abgerufen 27. September 2026. [codescene.io](https://codescene.io/docs/developer-tools/mcp/codescene-mcp-server.html) [^10]: Adam Tornhill (CodeScene): „The Bumpy Road Code Smell: Measuring Code Complexity by its Shape and Distribution“, Unternehmensblog, Neuveröffentlichung 22. September 2025 (Original 2021). [codescene.com](https://codescene.com/blog/bumpy-road-code-complexity-in-context/) [^11]: Frederick P. Brooks Jr.: „The Mythical Man-Month: Essays on Software Engineering“, Buch, Addison-Wesley, 1975. [en.wikipedia.org](https://en.wikipedia.org/wiki/Brooks%27s_law)