Von Vibe Coding zu Agentic Engineering

Andrej Karpathy hat den Begriff Vibe Coding am 2. Februar 2025 in einem Tweet geprägt, der über 4,5 Millionen Mal aufgerufen wurde. Genau ein Jahr später, im Februar 2026, hat er ihn selbst für überholt erklärt. Sein neuer Begriff: Agentic Engineering.

Karpathy schreibt auf X: "Today (1 year later), programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny. The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software."

Das ist mehr als eine Begriffsverschiebung. Es ist die Korrektur einer Bewegung, die viele Teams in den letzten zwölf Monaten in echte Probleme geführt hat.

Was Karpathy genau sagt

Karpathy begründet den neuen Begriff in zwei Hälften:

"Agentic", weil zu 99 Prozent der Zeit nicht direkt programmiert wird. Stattdessen orchestriert man Agenten, die programmieren, und übernimmt selbst die Aufsicht. Der Default-Modus für professionelle Softwareentwicklung 2026 ist nicht mehr "Mensch tippt Code", sondern "Mensch beauftragt Agent und prüft Ergebnis".

"Engineering", weil es Kunst, Wissenschaft und Expertise erfordert. Mit dem Wort grenzt Karpathy bewusst gegen das "give in to the vibes" seines eigenen 2025er Tweets ab. Engineering steht für Disziplin, Spezifikation, Review, Test.

Karpathy nennt seinen Vibe-Coding-Tweet inzwischen einen "shower of thoughts throwaway tweet". Er hat damit ein Gefühl getroffen, das viele Entwickler hatten, als die Modelle 2025 plötzlich gut genug für brauchbare Demos wurden. Aber die Modelle waren damals "good enough that you'd mostly use vibe coding for fun throwaway projects, demos, and explorations". Nicht für produktive Software.

2026 hat sich das geändert. Modelle wie Claude Opus 4.7, GPT-5.5 und Gemini 3.1 Pro liefern Code, der in echten Produktionssystemen läuft. Aber genau deshalb braucht es eine andere Disziplin als beim Vibe Coding. Wer ohne Review akzeptiert, schafft technische Schuld in Maschinengeschwindigkeit.

Eine nützliche Ergänzung kommt von Simon Willison. Er beschreibt Agentic Engineering als die Praxis, Software mit Hilfe von Coding Agents zu entwickeln, also Agenten, die nicht nur Code schreiben, sondern ihn auch ausführen können. Genau diese Kombination aus Tool-Loop und Codeausführung macht den Unterschied: Der Agent produziert nicht nur Text, sondern kann iterativ auf ein überprüfbares Ergebnis hinarbeiten. Gleichzeitig grenzt Willison Agentic Engineering klar gegen Vibe Coding ab. Vibe Coding bleibt bei ihm der Begriff für unreviewten, prototypischen KI-Code. Agentic Engineering beginnt dort, wo Review, Tests und belastbare Ergebnisse zur Pflicht werden.

Vibe Coding und Agentic Engineering im direkten Vergleich

Karpathys Wende ist der nächste Shift-Left

Wer länger in der Softwareentwicklung dabei ist, kennt das Muster. Was heute als Disruption wirkt, ist die nächste Stufe einer Verschiebung, die seit Jahrzehnten läuft. Der Mensch programmiert weniger direkt, der Werkzeugkasten erledigt mehr. Die Aufmerksamkeit verschiebt sich nach links im Lifecycle, also weg vom reinen Code-Schreiben, hin zu dem, was davor und daneben passiert.

Die Etappen lassen sich gut nachzeichnen:

• Maschinencode und Assembler dominierten die frühe Zeit. Wer Software bauen wollte, brauchte Wochen für etwas, das heute eine Stunde dauert. Alles andere drumherum stand im Schatten dieser Hauptarbeit.
• Der Compiler kam mit der Versprechung, Hochsprachen in Maschinencode zu übersetzen. Skepsis war groß, "der erzeugt nicht so guten Code wie ich von Hand", war ein verbreitetes Argument. Heute ist niemand mehr ernsthaft auf der Idee, ohne Compiler zu arbeiten.
• Bibliotheken und Frameworks kamen als nächste Welle. "Warum das Rad neu erfinden, wenn Spring, Django oder React es schon gelöst haben?" Auch hier war die Skepsis ehrlich, "viel zu viel Overhead, kann ich selbst besser bauen". Heute ist Eigenbau ohne Framework die Ausnahme, nicht die Regel.
• Eine lange ruhige Phase folgte. IDE-Verbesserungen, Linter, Refactoring-Tools wurden besser, aber an der Grundverteilung der Arbeit änderte sich wenig. Der Mensch schrieb Code, das Werkzeug half.
• Jetzt kommt KI und beschleunigt den Code-Teil massiv. Die Skepsis speist sich aus den gleichen Sorgen wie damals beim Compiler, also Kontrollverlust und berechtigten Qualitätsbedenken ("die KI macht Fehler, ich kontrolliere lieber selbst"). Das Muster wiederholt sich vermutlich auch hier. In ein paar Jahren wird ohne KI-Unterstützung zu programmieren genauso wirken wie heute der Verzicht auf Compiler oder Frameworks.

Bemerkenswert ist die Symmetrie: Bei jeder Welle wurde die unmittelbare Code-Arbeit billiger und schneller. Die Phasen daneben, also Anforderungen klären, Architektur entwerfen, Designs validieren, Tests schreiben, Dokumentation pflegen, Reviews organisieren, wurden in den letzten Jahrzehnten nicht im gleichen Maße automatisiert. Sie haben aber durch die freiwerdenden Kapazitäten mehr Raum bekommen als früher. Genau dorthin verschiebt Karpathys Agentic Engineering den Schwerpunkt: weg von "wer schreibt diese Funktion" und hin zu "wer beschreibt sie sauber, wer prüft sie, wer integriert sie". Die KI nimmt den Code-Anteil, der Mensch übernimmt den Rest, der ohnehin den größeren Hebel hat.

Was Vibe Coding produktiv nicht hält

Drei Probleme machen Vibe Coding für ernsthafte Software ungeeignet, und genau diese Probleme adressiert Agentic Engineering bewusst:

Sicherheitslücken. Bei einer Fehlerquote von einem Prozent erzeugt ein produktiv arbeitender Agent zehn neue Sicherheitsprobleme pro Woche, die nie jemand gesehen hat. Der Agent ist schnell, aber nicht sicher. Ohne Review-Schicht stapelt sich das.

Unmaintainable Architektur. Wer Modul für Modul prompted, ohne den Gesamtaufbau zu spezifizieren, bekommt am Ende Code, den niemand mehr versteht. Auch nicht der Agent, der ihn geschrieben hat. In sechs Monaten ist das Projekt entweder eingefroren oder wird komplett neu gemacht.

Context Collapse. Längere Sessions mit demselben Agenten produzieren mit der Zeit schlechtere Outputs, weil Kontextfenster begrenzt sind und der Agent anfängt, eigene frühere Halluzinationen als Fakten zu behandeln. Ein typisches Anti-Pattern: stundenlange Coding-Session mit demselben Agenten, am Ende eine Codebasis voller Inkonsistenzen.

Das Plain-English-Magazin nennt das in einer aktuellen Aufbereitung "Cognitive Debt". Anders als technische Schuld ist Cognitive Debt der Preis für schlecht verwaltete KI-Interaktionen, der sich erst Wochen oder Monate später zeigt.

Das neue Arbeitsmodell

Agentic Engineering ist als Disziplin in vier Schritten beschreibbar:

1. Spezifikation vor Code. Bevor ein Agent etwas baut, schreibst du auf, was gebaut werden soll. Akzeptanzkriterien, Schnittstellen, Datenmodell. Das ist die Stelle, an der die meiste Qualität entsteht oder verloren geht.
2. Module statt Monolith. Jeder Agent-Auftrag deckt einen klar abgegrenzten, überprüfbaren Teil ab. Nicht "baue mir eine App", sondern "baue mir die Auth-Middleware mit diesen drei Endpunkten". So bleibt der Review machbar.
3. Rigorose Code-Reviews. Du liest jede Zeile so, wie du den Code eines Junior-Entwicklers lesen würdest. Bei Sprache und Naming auf Konsistenz achten, bei Logik auf Edge Cases, bei Architektur auf Kohärenz mit dem Rest des Systems.
4. Tests vor Abschluss. Nichts gilt als fertig, was nicht getestet ist. Idealerweise generiert der Agent die Tests selbst, ein zweiter Lauf prüft sie auf sinnvolle Coverage.

Die Schritte sind nicht neu. Sie sind die Standardpraxis aus der klassischen Softwareentwicklung. Neu ist, dass Karpathy sie ausdrücklich für die Arbeit mit KI-Agenten formuliert. Wer 2025 das Vibe-Coding-Versprechen gekauft hatte, dass diese Schritte überflüssig wären, holt sie 2026 nach.

Was das in echten Teams bewirkt

Die Zahlen, die in der Diskussion immer wieder genannt werden, kommen aus drei Unternehmen:

• Stripe lässt nach eigenen Angaben mehr als 1.000 Pull Requests pro Woche durch Agenten erstellen und mergen. Voraussetzung: jeder PR hat einen menschlichen Reviewer.
• TELUS spart laut eigener Statistik mehr als 500.000 Stunden mit über 13.000 KI-Lösungen, die im Unternehmen produktiv laufen.
• Zapier hat eine KI-Adoption von 89 Prozent in der gesamten Organisation, also nicht nur im Engineering.

Bemerkenswert an allen drei Beispielen: Es geht nicht um den heroischen Einzelentwickler mit Vibe-Code-Magie. Es geht um Unternehmen, die Agentic Engineering als Methode breit ausgerollt haben. Die Hebel entstehen in der Skalierung der Disziplin, nicht im Geniestreich.

Was das für die Rollen heißt

Agentic Engineering verändert nicht nur, wie Code entsteht. Es verschiebt die Schwerpunkte in jeder Rolle.

Wie sich Teams neu organisieren müssen

Die Rollenverschiebungen passieren nicht nur individuell. Sie verändern auch, wie Teams sich aufstellen.

Vor Agentic Engineering war eine typische Aufstellung: zwei Leute machen Frontend, drei Leute machen Backend, eine Person kümmert sich um DevOps und Infrastruktur. Aufteilung nach Stack, weil jede Schicht eigene Spezialkenntnisse erforderte und niemand parallel an allen drei Fronten produktiv war.

Mit Agentic Engineering kippt diese Logik. Ein einzelner Mensch kann mit einem Agenten Frontend, Backend und DevOps gleichzeitig bearbeiten, weil der Agent die Stack-Spezialisierung übernimmt. Das heißt aber nicht, dass plötzlich ein Mensch das gesamte Team ersetzt. Wer den Hebel der Agenten heben will, hat trotzdem sechs Leute statt einer, weil das Tempo der Auslieferung weiter steigen soll. Diese sechs Leute arbeiten nicht mehr nach Stack getrennt, sondern parallel an möglichst isolierten Teilen der Codebasis, damit sie sich nicht ins Gehege kommen.

Das hat eine direkte Konsequenz für die Architektur:

• Modularisierung wird zur Vorbedingung. Wenn sechs Leute mit Agenten parallel an einer Codebasis arbeiten, braucht es klare Modulgrenzen. Sonst kollidieren die Änderungen, Merge-Konflikte werden zum Tagesgeschäft, oder schlimmer, Agenten überschreiben sich gegenseitig die Annahmen.
• Strukturierung wird zum Skalenfaktor. Was früher als "guter Stil" durchging, also klare Schnittstellen, eindeutige Verantwortlichkeiten, dokumentierte Abhängigkeiten, ist jetzt die Bedingung dafür, dass parallel überhaupt gearbeitet werden kann.
• Harte Grenzen statt weicher Konventionen. Wo früher ein Senior-Entwickler in der Code-Review noch einsprang und den Stil zurechtrückte, müssen Grenzen jetzt explizit und durchsetzbar sein. Linter, Architekturregeln in CI, klare API-Verträge, getrennte Repositories oder Modulgrenzen. Was nicht in der Werkzeugkette steht, hält keinen Agentic-Engineering-Tag durch.

Wer die Architektur nicht mitbewegt, bekommt das volle Tempo der Agenten in eine alte Struktur, die das nicht trägt. Die Folge sind Merge-Krisen, Reviewer-Überlastung und am Ende eine Codebasis, die niemand mehr ohne Agentic-Engineering-Disziplin handhaben kann. Die Aufgabe für Tech-Leads und Architekten 2026 ist nicht "mehr Werkzeuge ausrollen", sondern "die eigene Architektur fit machen für sechs parallele Agent-Operatoren".

Werkzeuge und Plattformen

Agentic Engineering ist nicht an ein bestimmtes Werkzeug gebunden, aber einige Werkzeuge unterstützen die Disziplin besser als andere. Eine ehrliche Standortbestimmung haben wir im Vergleich Cursor vs. Claude Code vs. Copilot zusammengefasst.

Drei Punkte sind beim Werkzeug-Auswahl wichtig:

• Multi-File-Edit: Damit der Agent kohärente Änderungen über mehrere Dateien machen kann, ohne dass jede manuell freigegeben werden muss.
• Background-Agenten oder paralleles Arbeiten: Damit du mehrere Module parallel beauftragen kannst und nicht in der seriellen Schlange wartest.
• Review-Tooling: Diff-Viewer, PR-Integration, Skill für strukturierte Code-Reviews. Cursor BugBot, GitHub Copilot Code Review oder Claude Code /ultrareview sind Beispiele.

Wer den Schritt von Einzelarbeitsplatz zu Team-Agentic-Engineering machen will, kommt an einer Plattform-Entscheidung nicht vorbei. Im aktuellen Team-Agent-Plattformen-Vergleich haben wir die vier großen Anbieter Workspace Agents, Claude Managed Agents, Gemini Enterprise und Salesforce Agent Fabric gegenübergestellt, mit DSGVO-Check und rollenspezifischen Empfehlungen.

Cognitive Debt vermeiden

Karpathys neuer Begriff hat einen interessanten Begleitbegriff bekommen, den seine Community geprägt hat: Cognitive Debt.

Anders als technische Schuld, die in Code messbar ist (Coverage, Complexity, Duplication), zeigt sich Cognitive Debt in der Diskrepanz zwischen dem, was ein Team über seinen eigenen Code weiß, und dem, was tatsächlich darin steckt. Wenn niemand mehr genau sagen kann, warum eine Funktion existiert oder welche Edge Cases sie abfängt, hat das Team Cognitive Debt aufgebaut.

Drei wöchentliche Gewohnheiten helfen, sie nicht entstehen zu lassen:

• Spezifikation vor jedem Agenten-Task. Auch bei kleinen Tasks. Eine Zeile Spec ist besser als keine.
• Jede Zeile generierten Code lesen. Ja, das kostet Zeit. Aber weniger Zeit als eine Cognitive-Debt-Krise in sechs Monaten.
• Tests vor Abschluss laufen lassen. Mit echten Daten, nicht nur den Mock-Werten, die der Agent vorgeschlagen hat.

Diese Gewohnheiten sind nicht neu. Sie sind das, was gute Entwicklerteams seit Jahrzehnten machen. Neu ist nur, dass sie 2026 nicht mehr wegoptimiert werden können, weil ein Modell gut genug wäre. Karpathy macht das im Originalpost klar: "claim the leverage from the use of agents, but without any compromise on the quality of the software."

Methodisch ist das nicht neu

Wer schon einmal in einem Industrieunternehmen gearbeitet hat, wird Karpathys Forderung wiedererkennen. Der PDCA-Zyklus (Plan, Do, Check, Act) ist seit den 1920ern Standard. Das Vier-Augen-Prinzip ist in Buchhaltung, Wirtschaftsprüfung und Produktion fest etabliert. Beide Prinzipien teilen die Einsicht: Wer seine eigene Arbeit prüft, findet seine eigenen Fehler nicht.

Die KI-Controlling-Schleife übersetzt genau das auf Agenten: Writer-Agent produziert, Reviewer-Agent prüft, Loop-Controller iteriert bis zur Qualitätsschwelle, Abbruchbedingung verhindert Endlosschleifen. Karpathys Agentic Engineering ist die Branding-Sprache für eine Disziplin, die methodisch lange beschrieben ist.

Das ist eine gute Nachricht. Ihr müsst keine neue Methode lernen, sondern eine Bekannte konsequent anwenden. Der Unterschied zu 2025: Es gibt jetzt Werkzeuge, die das Mitmachen der KI-Agenten in der Schleife unterstützen. LangGraph, CrewAI und AutoGen bringen Writer-Reviewer-Patterns direkt in den Code. Anthropics Constitutional AI lässt Modelle ihre eigenen Antworten gegen Prinzipien prüfen. Cursor, Claude Code und Copilot haben Code-Review-Modi.

Was jetzt zu tun ist

Wer Vibe Coding aus 2025 übrig hat, sollte drei Dinge tun:

• Ehrlich auf den Bestand schauen. Wo läuft Vibe-Code in Produktion, der nie reviewed wurde? Das ist Cognitive Debt im Klartext. Entweder reviewen lassen oder bewusst stilllegen.
• Spezifikations-Disziplin aufbauen. Ein PRD-Template, ein Akzeptanzkriterien-Pattern, ein Coding-Standards-Dokument. Klingt überflüssig, ist die Grundlage für Agentic Engineering.
• Review-Schleife etablieren. Mindestens ein Reviewer pro Pull Request. Mindestens ein Test vor jedem Merge. Das ist nicht Bürokratie, das ist die Bedingung dafür, dass die Hebel der Agenten überhaupt nutzbar werden.

Wer das tut, hat 2026 die echten Vorteile von KI-gestützter Entwicklung. Wer das nicht tut, häuft Cognitive Debt an, die irgendwann zurückgezahlt werden muss, mit Zinsen.

Fazit

Karpathys Wende ist mehr als eine Begriffsverschiebung. Sie ist die Korrektur einer Übertreibung von 2025, an der viele Teams gerade lernen, dass kurzfristige Hebelwirkung und langfristige Softwarequalität nicht in einem Atemzug zu haben sind, ohne Disziplin.

Vibe Coding war eine ehrliche Beschreibung eines Gefühls. Es taugt weiter als Werkzeug für Wegwerfprojekte und Prototypen. Aber für produktive Software war es nie gemeint, und Karpathy stellt das jetzt selbst klar.

Agentic Engineering ist die ernsthafte Antwort auf die Frage, wie Teams 2026 mit KI-Agenten arbeiten. Mit Spezifikation, Review, Test und der ehrlichen Anerkennung, dass die Verantwortung für das Ergebnis vollständig beim Menschen liegt. "AI builds, human owns" ist der Kernsatz.

Für DACH-Teams, die ohnehin in einer Compliance-getriebenen Umgebung arbeiten, ist das eine gute Nachricht. Die Disziplin, die Karpathy einfordert, ist die Disziplin, die DSGVO, branchenspezifische Audits und interne Qualitätsstandards sowieso verlangen. Wer hier sauber arbeitet, war in Vibe Coding nie der Star. Aber in Agentic Engineering ist diese Sauberkeit der Wettbewerbsvorteil.