Von Vibe Coding zu Agentic Engineering.
Was nach dem Hype kommt.
Andrej Karpathy hat den Begriff „Vibe Coding“ geprägt. Ein Jahr später korrigiert er sich selbst: Vibe Coding war der Anfang. Das, was sich jetzt herausbildet, ist eine eigene Ingenieurdisziplin – und sie verlangt andere Fähigkeiten, als viele erwarten.
Im April 2026 spricht Karpathy bei Sequoias AI Ascent darüber, warum er sich trotz allem „never more behind as a programmer“ fühlt. Seine These: Wir stehen nicht am Ende einer Veränderung, sondern mitten in einer neuen Computing-Ära – und die meisten arbeiten noch mit dem Kopf im alten Paradigma.
Vibe Coding hebt den Boden. Agentic Engineering hält die Decke.
Karpathy unterscheidet klar zwischen zwei Disziplinen, die oft verwechselt werden:
- Vibe Coding senkt die Einstiegshürde. Jeder kann plötzlich Software bauen – Prototypen, Side Projects, MVPs. Der Boden steigt für alle.
- Agentic Engineering bewahrt den professionellen Qualitätsanspruch. Keine eingeschleppten Sicherheitslücken, keine brüchigen Abstraktionen. Die Verantwortung bleibt beim Entwickler – aber die Geschwindigkeit steigt.
„Vibe coding is about raising the floor for everyone. Agentic engineering is about preserving the quality bar of what existed before in professional software. You’re still responsible for your software just as before, but can you go faster? And spoiler is you can.“
Der entscheidende Punkt: Agentic Engineering ist nicht einfach „besseres Vibe Coding“. Es ist eine eigene Disziplin. Agents sind mächtig, aber unzuverlässig auf unerwartete Art. Sie zu koordinieren, ohne die Qualität zu opfern – das ist die Aufgabe.
Karpathys Einschätzung zum Produktivitätsgewinn: Der alte 10x-Entwickler ist nicht mehr der Maßstab. Wer Agentic Engineering beherrscht, bewegt sich weit jenseits davon.
Software 3.0: Ein neues Computing-Paradigma
Karpathy ordnet die aktuelle Entwicklung in eine größere Linie ein:
- Software 1.0: Menschen schreiben Code. Explizite Regeln.
- Software 2.0: Menschen kuratieren Daten, trainieren neuronale Netze. Die Programmierung verlagert sich in Datensätze und Architekturentscheidungen.
- Software 3.0: Das LLM ist der Interpreter. Der Prompt ist das Programm. Das Context Window ist der Hebel.
Ein konkretes Beispiel macht das greifbar: Die Installation von OpenClaw. Normalerweise ein Shell-Skript – das bei verschiedenen Plattformen und Konfigurationen schnell komplex wird. Stattdessen: ein Block Text, den man seinem Agenten gibt. Der Agent versteht die Umgebung, trifft intelligente Entscheidungen, debuggt im Loop. Kein starres Skript, sondern adaptive Ausführung.
„What is the piece of text to copy paste to your agent? That’s the programming paradigm.“
MenuGen: Wenn die ganze App überflüssig wird
Karpathys Lieblings-Selbstkritik: Er baute MenuGen – eine App, die Restaurantmenüs fotografiert, OCR macht, Bildgeneratoren ansteuert und die Gerichte visuell darstellt. Vercel-Deployment, Stripe-Integration, das volle Programm.
Dann sah er die Software-3.0-Version: Foto an Gemini schicken, ein Satz dazu, fertig. Das neuronale Netz rendert die Bilder direkt in das Menüfoto. Kein Backend, kein Frontend, keine App.
„All of my MenuGen is spurious. It’s working in the old paradigm. That app shouldn’t exist.“
Die Lektion für Entwickler: Nicht fragen „Wie baue ich das schneller?“, sondern „Muss das überhaupt gebaut werden?“ Viele bestehende Anwendungen sind Artefakte eines Paradigmas, das gerade verschwindet.
Zackige Intelligenz: Geister statt Tiere
Karpathy ringt mit der Frage, was LLMs eigentlich sind. Seine Antwort: keine Tiere, sondern Geister. Statistische Entitäten, herbeigerufen, nicht gewachsen. Ohne intrinsische Motivation, ohne Neugier, ohne Weltmodell im biologischen Sinn.
Das erklärt die bizarre Ungleichmäßigkeit ihrer Fähigkeiten – was Karpathy „Jaggedness“ nennt. Sein aktuelles Lieblingsbeispiel:
„State-of-the-art Opus 4.7 will simultaneously refactor a 100,000 line codebase or find zero day vulnerabilities and yet tells me to walk to a car wash 50 meters away with my car. This is insane.“
Die Ursache ist kein Zufall: Es hängt direkt davon ab, was die Labs in ihre Trainingsdaten und RL-Environments aufnehmen. Wo Reinforcement Learning greift, liefern die Modelle Spitzenleistung. Alles andere stagniert – unabhängig davon, wie „intelligent“ das Modell in anderen Bereichen wirkt.
Karpathys Schlussfolgerung: Wer mit diesen Modellen arbeitet, muss verstehen, in welchen „Circuits“ er sich bewegt. Innerhalb der trainierten Domänen fliegt man. Außerhalb wird es zäh – und dann hilft nur eigenes Fine-Tuning oder eine andere Architektur.
Der Mensch bleibt im Loop – aber in anderer Rolle
Was bleibt, wenn Agents immer mehr übernehmen? Karpathy ist hier überraschend konkret. Er beschreibt einen realen Bug aus MenuGen: Agents versuchten, Stripe-Zahlungen über E-Mail-Adressen mit Google-Accounts abzugleichen – statt über persistente User-IDs. Für einen Menschen offensichtlich falsch, für den Agent scheinbar naheliegend.
Solche Fehler sind typisch. Sie passieren nicht in der Syntax, sondern in der Architektur. In der Frage, was zusammengehört und warum. Genau das ist die Ebene, auf der Entwickler gebraucht werden:
- Geschmack: Erkennen, wann Code zwar funktioniert, aber „wirklich grob“ ist – aufgebläht, copy-paste-lastig, mit brüchigen Abstraktionen.
- Urteil: Entscheiden, ob eine Architektur tragfähig ist oder nur zufällig funktioniert.
- Spezifikation: Den Plan, die Docs, die Constraints formulieren. Nicht den Code – aber das, was dem Code zugrunde liegt.
„You’re in charge of the taste, the engineering, the design. And that it makes sense and that you’re asking for the right things. The engineers are doing the fill in the blanks.“
Karpathy gibt zu, dass er sich API-Details wie keep_dims vs. keepdim, dim vs. axis, reshape vs. permute nicht mehr merkt. Das übernimmt der Agent. Aber das Verständnis, dass darunter ein Tensor mit Views auf geteiltem Storage liegt – das muss bleiben. Sonst kopiert man unnötig Speicher und merkt es nicht.
Agent-native Infrastruktur: Alles muss umgeschrieben werden
Karpathys Lieblings-Ärgernis: Dokumentation, die für Menschen geschrieben ist. Tutorials, die sagen „Gehe zu dieser URL, klicke dort, konfiguriere das“. Für einen Agenten nutzlos.
„Why are people still telling me what to do? I don’t want to do anything. What is the thing I should copy paste to my agent?“
Die Konsequenz: Frameworks, Libraries, Cloud-Services – alles ist noch für menschliche Nutzer gebaut. Der eigentliche Aufwand bei MenuGen war nicht der Code, sondern das Deployment: Vercel konfigurieren, DNS einstellen, Services verbinden. Alles manuelle Schritte, die längst agent-native sein könnten.
Karpathys Lackmus-Test: Kann ein Entwickler einem Agent einen Prompt geben, der eine App baut und deployed, ohne dass ein Mensch irgendetwas anfassen muss? Solange das nicht geht, ist die Infrastruktur nicht bereit.
Denken delegieren, Verstehen behalten
Das stärkste Zitat des Gesprächs kommt am Ende. Karpathy zitiert einen Tweet, der ihn seit Wochen beschäftigt:
„You can outsource your thinking but you can’t outsource your understanding.“
Agents können recherchieren, Code schreiben, Daten verarbeiten, Pläne erstellen. Aber sie verstehen nicht, warum etwas gebaut wird. Sie haben kein Modell davon, was sinnvoll ist und was nicht. Diese Fähigkeit bleibt beim Menschen – und sie wird wertvoller, je mehr alles andere automatisiert wird.
Karpathy sieht sich selbst zunehmend als Engpass: Nicht weil er zu langsam tippt, sondern weil er nicht schnell genug versteht. Seine Lösung: LLM-gestützte Wissensdatenbanken, die Artikel und Dokumente in neue Darstellungsformen übersetzen. Jede andere Projektion auf dieselben Daten erzeugt neues Verständnis.
Vibe Coding senkt die Einstiegshürde. Agentic Engineering ist die professionelle Disziplin, die darauf aufbaut: Agents orchestrieren, ohne den Qualitätsanspruch zu opfern. Der entscheidende Skill ist nicht mehr Code schreiben – sondern verstehen, was gebaut werden soll und warum.
Wie wir helfen
Wir begleiten Entwicklungsteams beim Übergang zu agentengestützten Workflows – von der Tool-Auswahl über Agent-Konfiguration bis zur Qualitätssicherung in der neuen Arbeitsweise.
