Vibe Coding vs. Agentic Engineering: Wann welches Modell zur Aufgabe passt

In vielen Engineering-Teams hat sich ein spürbarer Wendepunkt eingestellt. Code-Vorschläge der aktuellen KI-Agenten mussten plötzlich seltener korrigiert werden, ganze Aufgabenpakete liefen ohne Eingreifen durch, und die Frage verschob sich von „Wie bekomme ich brauchbaren Code aus dem Modell?“ zu „Wie organisiere ich Verantwortung, wenn Agenten den Großteil der Tipparbeit übernehmen?“.

Genau in diesem Zeitfenster haben sich auch zwei Begriffe geschärft, die heute die Diskussion prägen: Vibe Coding und Agentic Engineering. Beide stammen von Andrej Karpathy, einer der einflussreichsten Stimmen in der KI-Community. Vibe Coding prägte er Anfang 2025 als Beschreibung einer intuitiven, beinahe verspielten Arbeitsweise mit KI-Modellen; Agentic Engineering führte er ein Jahr später nach, um die professionelle Disziplin davon abzugrenzen, mit der KI-Agenten produktive Software bauen.

Für Unternehmen, die KI sinnvoll in ihre Entwicklungsprozesse integrieren wollen, lohnt sich ein klarer Blick auf beide Modi. Welche Aufgaben passen wohin? Wo entstehen Risiken, die man bewusst kalkulieren muss? Und wie sieht ein professioneller Übergang von schnellen Experimenten zu produktionsreifer Software aus?

Vibe Coding: Den Boden anheben

Vibe Coding beschreibt einen Arbeitsstil, bei dem Entwickler:innen ein Vorhaben in natürlicher Sprache formulieren und das Ergebnis weitgehend unverändert übernehmen. Der Code wird oft nicht Zeile für Zeile gelesen, sondern auf seine Funktion geprüft: Läuft er, geht es weiter; läuft er nicht, beschreibt man das Problem erneut und lässt das Modell nachbessern.

Karpathy selbst bringt den Modus auf eine treffende Formel: Vibe Coding hebt den Boden, also die untere Grenze dessen, was Menschen ohne tiefe Programmierkenntnisse bauen können. Wer eine Idee, eine kleine Demo oder ein internes Hilfswerkzeug braucht, kommt heute in Stunden zu einem funktionierenden Prototyp, der vor zwei Jahren nur mit erheblichem Aufwand zu bekommen gewesen wäre. Das ist ein echter Zugewinn, gerade für Fachbereiche, die bisher auf Engineering-Kapazitäten warten mussten.

Die Schwäche zeigt sich an der Grenze zur Produktion. Wenn nicht klar ist, was der Code im Detail tut, bleibt unklar, wie er sich in Last-, Fehler- und Sicherheitsfällen verhält. Sprachmodelle erzeugen mitunter Lösungen, die oberflächlich funktionieren, aber unsichere Standardwerte verwenden, Eingaben unzureichend prüfen oder veraltete Bibliotheken einbinden. In schnellen Iterationen entstehen so technische Schulden, die später nur mit erheblichem Aufwand korrigiert werden können.

Vibe Coding ist deshalb kein schlechter Modus, sondern ein bewusst eingesetzter Modus für klar abgegrenzte Aufgaben. Probleme entstehen erst dann, wenn aus einem im Vibe-Modus erstellten Prototyp ohne Refactoring ein produktives System wird.

Agentic Engineering: Die Qualitätslatte bewahren

Agentic Engineering setzt auf einer anderen Ebene an. Statt eines einzelnen Modells, das auf Prompts reagiert, kommen mehrere spezialisierte Agenten zum Einsatz, die ein Ziel arbeitsteilig bearbeiten. Ein Agent plant Schritte und legt Akzeptanzkriterien fest, ein anderer schreibt Code, ein dritter führt Tests aus, ein vierter prüft auf Sicherheits- und Architekturmuster. Die Agenten greifen auf Werkzeuge zu, führen Befehle aus, lesen Dateien, durchsuchen Repositories, rufen APIs auf und tauschen Zwischenergebnisse aus.

Karpathy formuliert den Anspruch dieses Ansatzes pointiert: Während Vibe Coding den Boden anhebt, geht es bei Agentic Engineering darum, die Qualitätslatte zu bewahren, die professionelle Software bisher hatte. Die Verantwortung für Sicherheit, Wartbarkeit und Architektur lässt sich nicht an einen Agenten delegieren, nur weil er schneller tippt. Der Begriff „Engineering“ ist dabei bewusst gewählt, als Disziplin, die man lernen, üben und beherrschen kann.

Vier Arbeitsmuster, ursprünglich von Andrew Ng als Designprinzipien für agentische Workflows beschrieben, prägen diesen Ansatz:

• Reflection: Der Agent überprüft seine eigenen Ergebnisse, identifiziert Schwächen und schlägt Korrekturen vor, bevor er weiterarbeitet.
• Tool Use: Statt nur Text zu erzeugen, ruft der Agent Werkzeuge auf: Compiler, Test-Runner, Linter, Datenbankabfragen.
• Planning: Komplexe Aufgaben werden in Teilziele zerlegt; der Agent dokumentiert seinen Plan und kann ihn anpassen.
• Multi-Agent Collaboration: Mehrere Agenten mit klaren Rollen (Architektur, Implementierung, Review, Sicherheit) arbeiten an einem gemeinsamen Ziel.

Im Zentrum steht ein Loop, der sich vereinfacht als Plan → Execute → Verify beschreiben lässt. Der Plan ist explizit und überprüfbar, die Ausführung nachvollziehbar protokolliert, die Verifikation umfasst Tests, statische Analyse und gegebenenfalls eine menschliche Freigabe. Damit verschiebt sich auch die Rolle der Entwickler:innen: Sie definieren Ziele, Architektur und Qualitätsstandards, prüfen Pull Requests von Agenten wie von menschlichen Kolleg:innen und greifen dort ein, wo Entscheidungen Domänenwissen oder Verantwortung verlangen.

Die Unterschiede im Überblick

Die Tabelle zeigt: Es geht nicht um besser oder schlechter, sondern um passend oder unpassend zur Aufgabe.

Jagged Intelligence: Warum Aufsicht weiter zählt

Ein zentraler Punkt, den Karpathy in den letzten Monaten immer wieder betont hat, ist die jagged (also gezackte) Form der heutigen Modellintelligenz. Aktuelle Modelle können große Codebasen umstrukturieren oder Sicherheitslücken aufspüren, die menschlichen Reviewern entgangen sind. Im selben Atemzug empfehlen sie aber gelegentlich völlig absurde Dinge: zu einer 50 Meter entfernten Autowäsche zu fahren statt zu laufen, weil die Aufgabe sie aus dem trainierten Bereich herausführt.

Der Grund liegt in der Art, wie diese Systeme entstehen. Sprachmodelle werden mit Reinforcement Learning auf verifizierbaren Aufgaben trainiert: Mathematik, Code, formale Logik. In diesen Bereichen erreichen sie beeindruckende Spitzen. Außerhalb davon liegt ein flacheres, lückenhafteres Plateau. Die Folge: Ein Modell kann in einer Aufgabe Senior-Niveau zeigen und in der nächsten Sekunde an einem trivialen Detail scheitern.

Für die Praxis bedeutet das zwei Dinge. Erstens: Man kann Agenten nicht blind vertrauen, nur weil sie in der vorherigen Aufgabe brillant waren. Zweitens: Verifizierbarkeit ist der entscheidende Hebel. Wo sich Ergebnisse maschinell prüfen lassen (durch Tests, Compiler, Linter, formale Constraints), entfalten Agenten ihre volle Stärke. Wo Ergebnisse subjektiv, kontextuell oder regulatorisch begründet sind, bleibt menschliche Aufsicht der Engpass.

Sicherheit und Wartbarkeit als zentrale Trade-offs

Bei reinem Vibe Coding entstehen Sicherheitsrisiken vor allem dadurch, dass der Code ungelesen übernommen wird. Modelle reproduzieren Muster aus ihren Trainingsdaten, und in diesen Daten sind sowohl saubere als auch unsichere Implementierungen enthalten. Ohne Review fließen unsichere Vorlagen ungefiltert in das System.

Agentic Engineering adressiert dieses Problem, schafft aber eigene Herausforderungen. Wenn Agenten autonom über mehrere Schritte hinweg arbeiten, können sich kleine Fehler aufschaukeln: Ein leicht falsches Verständnis im Plan führt zu einer ungenauen Implementierung, die in den nachgelagerten Schritten weiter interpretiert wird. Ohne saubere Logs, ohne deterministische Replays und ohne klare Stop-Bedingungen ist die Fehlersuche aufwendig.

Aus unserer Erfahrung mit komplexeren Engineering-Aufgaben ergeben sich drei Prinzipien, die in beiden Modi tragen:

1. Code-Reviews bleiben Pflicht, unabhängig davon, ob ein Mensch oder ein Agent den Pull Request erstellt hat. Die Verantwortung für integrationsfähige Änderungen liegt nicht beim System, sondern bei den Reviewern.
2. Test-Abdeckung ist nicht verhandelbar. Ein Agent, der Tests schreiben kann, sollte Tests auch dann schreiben, wenn es schneller ginge, sie wegzulassen. Tests sind die einzige automatisierte Antwort auf die Frage, ob ein Ergebnis nicht nur jetzt, sondern auch nach der nächsten Änderung noch funktioniert.
3. Architektur-Entscheidungen bleiben menschlich. Welche Datenbank, welches Caching-Modell, welche Trennung zwischen Diensten: Solche Entscheidungen wirken über Jahre und brauchen Kontextwissen, das sich nicht in einen Prompt fassen lässt.

Wann welches Modell sinnvoll ist

Eine pragmatische Faustregel hilft im Alltag: Je näher eine Aufgabe an Produktion, Compliance oder kritischen Geschäftsprozessen liegt, desto stärker gehört sie in einen agentischen Workflow mit klaren Reviews. Je explorativer und kurzlebiger eine Aufgabe ist, desto eher rechtfertigt sie einen schnellen Vibe-Modus.

Konkret:

• Für eine erste Skizze einer Produktidee, einen Demo-Build für einen Pitch oder ein internes Hilfswerkzeug, das niemand außer der erstellenden Person nutzt: Vibe Coding ist effizient.
• Für eine produktive Webanwendung, die Kundendaten verarbeitet, Zahlungen abwickelt oder regulatorischen Anforderungen unterliegt: agentenbasierte Workflows mit menschlicher Kontrolle, sauberen Tests und nachvollziehbarer Versionierung.
• Für Wartung und Migrationen großer Bestandssysteme, etwa beim Umbau einer monolithischen Anwendung in eine modulare Architektur: Hier zeigt agentisches Arbeiten besondere Stärken, weil viele kleine, gut definierte Teilaufgaben parallelisiert werden können.

Wichtig ist, diese Trennung nicht implizit, sondern explizit vorzunehmen. Teams, die klar benennen, welcher Code in welchem Modus entsteht, vermeiden, dass ein schnell skizzierter Prototyp unbemerkt zur produktiven Grundlage wird, eine Verschiebung, die sich rückblickend nur mit Refactoring-Aufwand korrigieren lässt.

Was sich an der Rolle der Entwickler:innen ändert

Die größere Verschiebung liegt nicht in den Werkzeugen, sondern im Selbstverständnis. Wer überwiegend Code tippt, wird in Zukunft weniger Zeit damit verbringen und mehr mit dem, was Code zu gutem Code macht: Anforderungen scharf formulieren, Architektur prägen, Testbarkeit sicherstellen, Reviews führen, Trade-offs abwägen.

Karpathy hat in diesem Zusammenhang eine instruktive Beobachtung formuliert: Die alte Faustregel vom „10x-Engineer“ greift in einer Welt mit gut orchestrierten Agenten zu kurz. Der Produktivitätsabstand zwischen Entwickler:innen, die Agenten souverän führen, und denen, die im alten Modus arbeiten, kann ein Vielfaches davon erreichen, nicht weil die einen mehr tippen, sondern weil sie ihre Aufmerksamkeit präziser auf die Hebel richten, die wirklich zählen: Spezifikation, Architektur, Review.

Junior-Entwickler:innen profitieren stark von KI-Unterstützung bei Routineaufgaben, gewinnen aber dann an Wert, wenn sie genau diese Engineering-Disziplinen früh aufbauen. Die Vorstellung, KI ersetze Engineering, verkennt, was Engineering tatsächlich ausmacht.

Das wirkt sich auch auf die Auswahl von Talenten aus. Klassische Coding-Puzzles im Bewerbungsprozess sagen wenig darüber aus, wie jemand mit Agenten ein größeres Projekt durchzieht, einen sauberen Plan erstellt und am Ende ein robustes, sicheres Ergebnis abliefert. Sinnvoller sind Aufgaben, die nahe an realen Engineering-Situationen liegen: ein definiertes Vorhaben mit Agenten umsetzen, dokumentieren und gegen reale Angriffsmuster absichern.

Was Unternehmen jetzt tun können

Wer KI strukturiert in die eigene Webentwicklung integrieren will, kann mit überschaubarem Aufwand beginnen, ohne sofort die gesamte Engineering-Kultur umzustellen. Drei Schritte haben sich in der Praxis bewährt:

• Aufgaben kategorisieren. Welche Arbeit eignet sich für schnelle Iteration ohne tiefe Reviews? Welche braucht Audit-Trails? Eine einfache Matrix reicht aus, um die richtige Erwartung an Tempo und Qualität zu setzen.
• Leitplanken festlegen. Welche Repositories sind für agentenbasierte Beiträge geöffnet, welche bleiben menschlich? Welche Tests müssen vor einem Merge grün sein? Welche Bibliotheken dürfen ohne Freigabe ergänzt werden? Klare Regeln vermeiden, dass jede:r Entwickler:in eine eigene Praxis entwickelt.
• Wissen teilen. Prompts, Agenten-Konfigurationen und Lessons Learned gehören in interne Dokumentation, nicht in private Notizen. So wächst ein Team-Standard, der unabhängig von einzelnen Personen trägt.

Diese Vorbereitungsarbeit zahlt sich schnell aus. Ohne sie laufen Teams Gefahr, dass alle mit eigenen Werkzeugen, eigenen Prompts und eigenen Qualitätsmaßstäben arbeiten und dass Inkonsistenzen erst beim ersten produktiven Vorfall sichtbar werden.

Ausblick: Agent-native Infrastruktur und der Engpass Verstehen

Die Trennung zwischen Vibe Coding und Agentic Engineering wird nicht verschwinden, aber unschärfer werden. Werkzeuge entwickeln sich in beide Richtungen: Schnelle Konversations-Editoren bekommen mehr Sicherheits- und Test-Mechanismen, agentenbasierte Plattformen werden zugänglicher und schneller. Das Ergebnis ist ein Spektrum mit zwei klaren Polen und einem Mittelfeld, in dem Teams zwischen Geschwindigkeit und Robustheit bewusst wählen können.

Eine zweite Verschiebung steht noch bevor. Bislang ist fast die gesamte Software-Infrastruktur (Dokumentationen, SDKs, Konfigurationsoberflächen) für menschliche Nutzung gebaut. Je mehr Agenten zum primären Empfänger dieser Informationen werden, desto stärker wird sich die Frage stellen, wie eine agent-native Infrastruktur aussieht: Dokumentationen, die direkt in Agenten geladen werden können; APIs, die für Agenten ebenso gut benutzbar sind wie für Menschen; Deployment-Schritte, die ein Agent ohne UI-Klickerei erledigen kann. Karpathy beschreibt das mit dem prägnanten Bild, dass viele Anleitungen heute noch sagen: „Klicke hier, gehe dorthin“, obwohl die eigentlich relevante Frage längst lautet: Was ist der Text, den ich in meinen Agenten kopieren kann? Wer diese Schicht früh durchdenkt, vermeidet Brüche, die später teuer werden.

Eine Beobachtung schwebt über dem ganzen Thema, die Karpathy zuletzt von anderer Seite aufgegriffen hat und seither regelmäßig zitiert: Sie können Ihr Denken auslagern, aber nicht Ihr Verstehen. Agenten können Texte zusammenfassen, Code schreiben, Hypothesen testen, aber wer entscheidet, ob das Ergebnis sinnvoll ist, braucht ein eigenes Modell der Sache. In unseren Projekten zeigt sich regelmäßig, dass die Frage nicht lautet, ob KI in den Entwicklungsprozess gehört, sondern wo genau sie welchen Beitrag leistet, wer welche Entscheidung trägt und wie das Verstehen im Team weiterhin lebendig bleibt. Eine fundierte Antwort darauf ist eine architektonische Entscheidung, keine Werkzeugfrage. Und sie ist die Voraussetzung dafür, dass aus KI-Unterstützung tatsächlich produktive, wartbare und sichere Software entsteht.