Agentic Engineering statt Vibe Coding: was der Shift für Unternehmen bedeutet

Ende 2025 bemerkte Andrej Karpathy, der Erfinder des Begriffs "Vibe Coding", etwas Ungewöhnliches an seiner eigenen Arbeit: Die Vorschläge seines Coding-Agenten wurden nicht nur größer, sondern konsistent richtiger. Weniger Korrekturen, mehr delegierte Aufgaben. Ein Jahr nach seinem eigenen Begriff prägte er im Februar 2026 den Nachfolger: "Agentic Engineering" [1]. Kein Rückzieher, sondern eine Abgrenzung. Und diese Abgrenzung ist für jedes Unternehmen relevant, das heute Software bauen lässt oder selbst baut, nicht nur für Entwicklerteams.

Vom Prompt zur Spec-Disziplin

Vibe Coding, im Februar 2025 von Karpathy selbst benannt, beschreibt das Programmieren, bei dem man sich "ganz den Vibes hingibt und vergisst, dass der Code überhaupt existiert". Für Prototypen, Wegwerf-Skripte und schnelles Ausprobieren ist das legitim und schnell. Für produktive, haftungsrelevante Software ist es riskant: Ohne Architektur, Tests und Review entsteht Code, den irgendwann niemand mehr versteht, auch der Agent nicht, der ihn geschrieben hat.

Agentic Engineering ist die ingenieursmäßige Weiterentwicklung davon. Der Mensch schreibt nicht mehr selbst Code, sondern orchestriert Agenten, gestaltet ihre Umgebung und beaufsichtigt das Ergebnis. Genau hier verschiebt sich die eigentliche Arbeit: weg von "Code schreiben", hin zu "Umgebungen schaffen, in denen guter Code entsteht". Das ist mehr Architekturarbeit, nicht weniger.

Konkret heißt das: Prompt Engineering wird nachrangig. Ein Agent bringt ohnehin einen mehrere tausend Tokens langen System-Prompt mit Rolle und Tools mit, der eigene Einzelprompt bewegt das Gesamtverhalten kaum noch. Was zählt, ist die Konfiguration drumherum: Kontext-Dateien, verfügbare Skills, Freigaberegeln. Und bei Spezifikationen ersetzt zunehmend die Spec den flüchtigen Prompt als Steuerungsinstrument: Ziel, Regeln, Akzeptanzkriterien und Nicht-Ziele werden vor der Umsetzung explizit gemacht, nicht danach aus dem Code rekonstruiert. Bis 2026 hat praktisch jedes große KI-Coding-Tool, von GitHub Spec Kit über AWS Kiro bis Claude Code, eine eigene Spec-first-Variante veröffentlicht [2]. Der Merksatz dahinter: Vibe Coding ist gut zum Finden, Spec-driven Development ist gut zum Skalieren.

Der Verstärker-Effekt

Der wichtigste empirische Befund zu dieser Entwicklung stammt nicht von einem KI-Anbieter, sondern von Googles DORA-Team, das seit zehn Jahren Softwareentwicklungs-Performance misst. Kernaussage für 2025: KI wirkt in der Softwareentwicklung in erster Linie als Verstärker, nicht als Ersatz. Sie vergrößert die Stärken leistungsstarker Organisationen genauso wie die Dysfunktionen schwacher. Wer schlechte Prinzipien hat und KI einsetzt, wird schneller schlechter. Wer gute Prinzipien hat, wird schneller besser.

Eine aktuelle Literaturauswertung zu KI-unterstützter Softwareentwicklung bestätigt das mit Zahlen: Pull Requests mit KI-Anteil haben im Schnitt 1,7-mal mehr gemeldete Probleme als rein menschlicher Code, und Organisationen berichten von 30 bis 41 Prozent mehr technischen Schulden innerhalb von sechs Monaten nach breiter KI-Einführung [3]. Senior-Entwickler verbringen 20 bis 35 Prozent mehr Zeit mit Code-Review, wenn Kolleg:innen stark auf KI-Assistenten setzen, und werden damit selbst zum Engpass, weil sie die Einzigen mit genug Tiefenwissen sind, um KI-generierte Logikfehler zu erkennen. Adoption ist praktisch flächendeckend (90 Prozent nutzen KI bei der Arbeit), aber nur 13 Prozent setzen sie über den gesamten Entwicklungszyklus hinweg strukturiert ein [2]. Der Engpass ist nicht Verfügbarkeit, sondern Vertrauen in das Ergebnis.

Das ist keine zwei getrennten Beobachtungen, sondern eine: Ohne Testdisziplin, Shift-Left und Feedback-Loops beschleunigt KI das Chaos. Mit ihnen skaliert sie die Stärke.

Was das praktisch bedeutet

Ein greifbares Arbeitsmuster für diszipliniertes Agentic Engineering ist der R-PIV-Loop: Research (Codebasis und Problem erkunden), Planning (Plan mit Validierungsstrategie erstellen), Implementation (Agent setzt gegen den Plan um), Validation (Tests, Review, menschliche Abnahme). Der Mensch schreibt im Idealfall keinen Code mehr selbst, bleibt aber für Problemverständnis, Planqualität und Validierung verantwortlich. Jeder Fehler des Agenten wird danach nicht als Ärgernis behandelt, sondern als Anlass, Regeln, Skills oder Tests zu verbessern, damit derselbe Fehler nicht zweimal passiert.

Praktisch heißt das auch: Spec-first arbeiten muss nicht schwergewichtig sein. Eine einseitige, gut strukturierte Spezifikation mit Zielbild, Nutzerrollen, Nicht-Zielen, Datenklassen, Akzeptanzkriterien und Rollback-Verhalten schlägt einen langen Chatverlauf ohne Abnahmekriterien. Und ein Prinzip, das leicht übersehen wird: Bei einem Modellwechsel lohnt es sich, alte, für das Vorgängermodell fein-getunte Skills und Regeln zu verwerfen statt zu vererben. Neuere Modelle haben oft bessere Defaults, nicht nur mehr Wissen, und alte Nachkonfiguration lenkt sie eher in die falsche Richtung.

Ein hilfreicher Rahmen, um den eigenen Reifegrad einzuordnen, unterscheidet fünf Autonomiestufen: von reiner Assistenz über zunehmend eigenständige Implementierung bis zur "Dark Factory", in der Agenten nahezu ohne menschliche Zwischenschritte arbeiten. Der praktische Sweet Spot für die meisten Teams liegt auf Stufe drei: Agenten implementieren, Menschen bleiben aktiv in Research, Planung und Validierung. Die höheren Stufen sind erst sinnvoll, wenn der Prozess stabil genug ist, um menschliche Eingriffe schrittweise und kontrolliert zu entfernen, nicht weil ein Anbieter sie als Feature anbietet. Wer diese Reihenfolge umdreht und gleich auf maximale Autonomie zielt, bekommt in der Regel keine schnellere Fabrik, sondern nur unbeaufsichtigten Vibe Code in Produktion.

Was das für Unternehmen heißt

Wer Software bauen lässt oder selbst entwickelt, sollte drei Fragen stellen, bevor er sich über Tool-Auswahl unterhält: Wird mit Spezifikation statt losem Prompt gearbeitet? Existieren wiederkehrende Abläufe als dokumentierte, wiederverwendbare Skills statt als Zufallsprompts? Stehen Review und Freigabe vor jedem Merge oder Deployment, nicht danach? Governance-Regeln wie zentrale Plattformfreigabe für agentische Tools, verpflichtende menschliche Review vor Produktivsetzung und vollständige Nachvollziehbarkeit von Spec zu Code zu Test sind dabei kein Bürokratie-Aufschlag, sondern genau die Hausaufgaben, die den DORA-Amplifier-Effekt in die richtige Richtung kippen.

Wer im Prozessmanagement sozialisiert ist, kennt dieses Muster aus einem anderen Feld: Auch Lean-Prinzipien oder Wertstromanalysen wurden erst zum Hebel, als sie in verbindliche, wiederholbare Struktur überführt wurden, nicht als Bauchgefühl. Disziplin schlägt Tempo nicht aus, sie macht Tempo erst haltbar. Der Unterschied zwischen einem Team, das in drei Monaten in einer Refactoring-Sackgasse landet, und einem, das dieselbe Zeit für einen echten Sprung nutzt, liegt selten am Modell. Er liegt daran, ob vorher jemand die Spec geschrieben hat.