Vibe Coding im Deep Dive: Von Karpathys Tweet zur Produktionsrealität 2026

Vibe Coding im Deep Dive

Am 2. Februar 2025 schrieb Andrej Karpathy, Mitgründer von OpenAI und ehemaliger KI-Leiter bei Tesla, einen Tweet, der die Softwarebranche bis heute prägt: „There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Gemeint war eine fast schon sorglose Haltung – man beschreibt, was man will, akzeptiert, was das Modell liefert, und kümmert sich kaum noch um Details. Karpathy selbst ordnete das explizit als Methode für „Wegwerf-Wochenendprojekte” ein.

Was danach passierte, hat mit dieser ursprünglichen Beiläufigkeit kaum noch etwas zu tun. Der Begriff wurde vom Collins Dictionary zum Wort des Jahres 2025 gekürt, landete im Merriam-Webster als Slang-Eintrag, und ein Jahr später generiert KI nach GitHub-eigenen Angaben rund 46 Prozent des gesamten neuen Codes auf der Plattform. Gleichzeitig erklärte Karpathy Anfang 2026 seinen eigenen Begriff für „passé” und schlug einen Nachfolger vor: „Agentic Engineering”. Dieser Deep Dive nimmt beide Seiten der Geschichte auseinander – die Euphorie und die Ernüchterung – und zeigt, was das für deine eigene Arbeit als Entwickler oder Entscheider bedeutet.

Vom Tweet zum Massenphänomen: Wie sich der Begriff verschoben hat

Ursprünglich beschrieb Karpathy eine sehr spezifische, fast schon experimentelle Praxis: Code entsteht komplett aus dem Prompt heraus, ohne dass eine Zeile davon wirklich gelesen wird. „Vibe” steht dabei wörtlich für Stimmung, Gefühl – man bewertet das Ergebnis danach, ob es sich richtig anfühlt, nicht danach, ob es sauber implementiert ist.

Ein Jahr später revidierte Karpathy diese Sichtweise selbst. In einem vielbeachteten Folge-Post im Februar 2026 erklärte er, die Modelle seien inzwischen so viel leistungsfähiger geworden, dass professionelles KI-gestütztes Programmieren längst zum Standard-Workflow geworden sei – „außer mit deutlich mehr Aufsicht und Prüfung”. Sein Vorschlag für den treffenderen Begriff: Agentic Engineering – „agentisch”, weil man in 99 Prozent der Fälle Code nicht mehr selbst tippt, sondern KI-Agenten orchestriert und beaufsichtigt; „Engineering”, um zu betonen, dass darin Kunstfertigkeit, Wissenschaft und Expertise stecken, die man lernen und verbessern kann.

Diese Unterscheidung ist mehr als Semantik – sie ist die zentrale Weggabelung, an der sich Teams 2026 orientieren sollten:

Wie Vibe Coding in der Praxis abläuft

Der Workflow selbst hat sich seit den Anfängen kaum verändert – verändert hat sich vor allem, wie ernst die einzelnen Schritte genommen werden. Vier Phasen prägen den Ablauf:

1. Anforderung formulieren. Du beschreibst in natürlicher Sprache, was entstehen soll – Kontext, Technologie-Stack, Randbedingungen, gewünschtes Verhalten. Die Qualität des Ergebnisses hängt direkt an der Qualität dieser Beschreibung: Ein vager Prompt („bau mir ein Login”) liefert generischen Code; ein präziser Prompt („Login-Formular mit E-Mail/Passwort, Rate-Limiting nach 5 Fehlversuchen, Passwort-Hashing mit Argon2id, Session-Cookie httpOnly und secure”) liefert etwas, das tatsächlich produktionsnah ist.
2. KI generiert Code. Der Assistent – Claude Code, Cursor, GitHub Copilot oder ein anderes Tool – erzeugt Code auf Basis der Anforderung und des Kontexts der bestehenden Codebase. Moderne Agenten arbeiten dabei zunehmend dateiübergreifend: Sie ändern nicht nur eine einzelne Funktion, sondern orchestrieren Änderungen über mehrere Dateien, Migrationen und Konfigurationen hinweg.
3. Review und Iteration. Hier trennt sich professionelle Praxis von reinem Vibe Coding im ursprünglichen Sinn. Generierten Code lesen und tatsächlich verstehen, testen, Fehler identifizieren, über Folgeprompts verfeinern („Das funktioniert, aber optimiere die Performance” oder „Füge Error-Handling hinzu”). Wer diesen Schritt auslässt, produziert genau die Risiken, die im folgenden Abschnitt zur Sprache kommen.
4. Integration und Testing. Code in die bestehende Codebase integrieren, automatisierte Tests ausführen, Edge Cases explizit prüfen. Die wichtigste Regel dabei: niemals blind deployen, ohne verstanden zu haben, was der Code tatsächlich tut.

Die Zahlen hinter dem Hype

Die Adoption ist kein Nischenphänomen mehr, sondern branchenweiter Standard. Rund 92 Prozent der Entwickler in den USA nutzen laut aktuellen Erhebungen täglich KI-Coding-Tools, weltweit liegt die wöchentliche Nutzung bei über 80 Prozent. Im Winter-2025-Jahrgang des Startup-Inkubators Y Combinator hatten rund ein Viertel der Unternehmen Codebases, die zu 95 Prozent oder mehr KI-generiert waren. Die Kosten für ein funktionsfähiges SaaS-Produkt sind Schätzungen zufolge von rund 200.000 auf etwa 5.000 US-Dollar gefallen, die Bauzeit von sechs Monaten auf sechs Wochen.

Gleichzeitig zeigt sich ein bemerkenswerter Bruch zwischen Nutzung und Vertrauen: Während die Adoption steigt, ist das Vertrauen in die Genauigkeit von KI-generiertem Code im gleichen Zeitraum von rund 40 auf unter 30 Prozent gesunken. Die Branche nutzt ein Werkzeug also intensiver, dem sie gleichzeitig zunehmend misstraut – ein Muster, das sich am deutlichsten bei der Sicherheit zeigt.

Das Sicherheitsproblem: Warum „es funktioniert” nicht „es ist sicher” heißt

Hier liegt der wichtigste Unterschied zwischen Demo und Produktion. KI-Codegeneratoren optimieren für Funktionalität, nicht für Sicherheit – ein Code-Snippet, das im Test durchläuft, kann trotzdem gravierende Lücken enthalten.

Die OWASP-Organisation hat auf diese Entwicklung reagiert und in ihre aktualisierten Top-10-Sicherheitsrisiken 2025 erstmals einen eigenen Bewusstseinspunkt zu KI-generiertem Code aufgenommen – ein deutliches Signal, dass es sich nicht um exotische Randfälle handelt, sondern um ein strukturelles Problem.

Typische, immer wiederkehrende Schwachstellenmuster in KI-generiertem Code:

• Hartcodierte Zugangsdaten – API-Schlüssel oder JWT-Secrets direkt im Quellcode statt in Umgebungsvariablen.
• Schwache Kryptografie – veraltete Hash-Verfahren wie MD5 ohne Salt, weil sie in Trainingsdaten häufiger vorkommen als moderne Standards wie Argon2id.
• Fehlende Autorisierungsprüfung – Auth-Checks landen im Frontend statt serverseitig, wo sie tatsächlich schützen.
• Unvalidierte Nutzereingaben – klassische Einfallstore für SQL-Injection und Cross-Site-Scripting.
• Halluzinierte Abhängigkeiten – die KI schlägt Pakete vor, die gar nicht oder mit bekannten Schwachstellen existieren.

Wie du produktionsreif mit KI entwickelst

Die gute Nachricht: Diese Risiken sind kein Grund, auf KI-gestützte Entwicklung zu verzichten – sie sind ein Grund, sie mit Prozess statt mit blindem Vertrauen zu betreiben. Fünf Bausteine haben sich in der Praxis als wirksam erwiesen:

• Sicherheitsanforderungen explizit in den Prompt schreiben. Modelle implementieren Input-Validierung, parametrisierte Queries oder sichere Token-Speicherung zuverlässig, wenn man danach fragt – automatisch tun sie es in der Regel nicht.
• Automatisierte Scans in die CI/CD-Pipeline integrieren. Statische Analyse (etwa mit Semgrep oder SonarQube), Dependency-Scanning (Snyk, npm audit) und Secret-Detection (gitleaks, truffleHog) fangen einen Großteil der bekannten Muster ab, bevor Code überhaupt gemerged wird.
• Verpflichtendes Code-Review etablieren. Nur knapp die Hälfte der Entwickler prüft KI-generierten Code laut aktuellen Umfragen konsequent, bevor er committet wird. Genau hier entsteht das systemische Risiko: hohe Nutzung, geringes Vertrauen, inkonsequente Prüfung.
• Klare Freigabekriterien definieren, welche Projekte wie viel Aufsicht brauchen. Ein internes Tool oder ein Prototyp verträgt mehr Risiko als eine Anwendung, die Zahlungsdaten oder personenbezogene Informationen verarbeitet. Diese Unterscheidung sollte dokumentierte Policy sein, nicht Bauchgefühl im Einzelfall.
• Menschliche Verantwortung nicht outsourcen. Am Ende trägt nicht die KI die Verantwortung für einen Sicherheitsvorfall, sondern das Unternehmen, das den Code veröffentlicht hat. Diese Verantwortung lässt sich durch keinen Prompt und kein Tool delegieren.

Die Tool-Landschaft 2026 im Überblick

Der Markt hat sich in zwei grobe Kategorien ausdifferenziert, und die erfahrensten Teams kombinieren beide:

KI-IDEs und Terminal-Agenten für produktionsnahe Arbeit mit bestehenden Codebases: Cursor, Windsurf, GitHub Copilot und Claude Code. Sie zeichnen sich durch tiefe Integration in bestehende Projekte, dateiübergreifendes Arbeiten und – bei Terminal-Agenten wie Claude Code – direkten Zugriff auf Build-Tools, Tests und Deployment-Kommandos aus.

Full-Stack-App-Generatoren für schnelles Prototyping ganzer Anwendungen aus einem einzigen, hochrangigen Prompt: Lovable, Bolt.new, Replit und v0 von Vercel. Ein verbreitetes Muster: Prototyp in Lovable oder Bolt bauen, für die produktionsreife Weiterentwicklung dann zu Cursor oder Claude Code wechseln.

Für Teams mit strengen Datenschutzanforderungen gewinnen zudem lokale Stacks an Bedeutung – etwa Open-Source-Modelle wie Qwen3-Coder oder DeepSeek, betrieben über Ollama, wenn Code oder Trainingsdaten das eigene Netzwerk nicht verlassen dürfen.

Für wen sich Vibe Coding eignet – und für wen nicht

Vibe Coding ist heute kein exklusives Werkzeug für Entwickler mehr. Rund 63 Prozent der Nutzer identifizieren sich selbst nicht als Entwickler, sondern als Produktmanager, Gründer, Designer oder Marketing-Verantwortliche, die eigene Ideen ohne klassisches Entwicklerteam umsetzen. Das ist einer der eigentlich spannenden Effekte der Entwicklung: Software-Bau wird zugänglicher.

Das ändert aber nichts an der Kernaussage der ursprünglichen digitalherrmann-Einordnung: Programmierkenntnisse bleiben relevant, weil sie die Fähigkeit vermitteln, KI-Output überhaupt zu bewerten. Für sehr einfache, isolierte Aufgaben mag es ohne Vorkenntnisse funktionieren – mit erheblichem Risiko, weil du Fehler, Sicherheitsprobleme und Wartungsschulden nicht erkennen kannst, die die KI dir unterjubelt. Vibe Coding beschleunigt erfahrene Entwickler spürbar; es ersetzt fehlende Grundkenntnisse nicht, sondern verschiebt lediglich, wo diese Kenntnisse gebraucht werden – weg vom Tippen von Syntax, hin zur Bewertung von Architektur und Ergebnis.

Bei der Technologiewahl gilt: JavaScript/TypeScript und Python liefern die zuverlässigsten Ergebnisse, weil sie in den Trainingsdaten der Modelle am stärksten vertreten sind. Populäre Frameworks wie React, Next.js oder Astro werden deutlich besser unterstützt als Nischen-Technologien, und auch SQL sowie Shell-Scripting funktionieren erfahrungsgemäß sehr zuverlässig.

Fazit: Vom Vibe zur Disziplin

Karpathys ursprüngliche Beschreibung – „fully give in to the vibes… forget that the code even exists” – war eine ehrliche Beobachtung für einen ganz bestimmten, risikoarmen Anwendungsfall: das Wochenendprojekt, das niemand außer dir selbst je zu Gesicht bekommt. Ein Jahr später ist daraus etwas anderes geworden, für das sein eigener Nachfolgebegriff „Agentic Engineering” ehrlicher klingt: die professionelle Orchestrierung leistungsfähiger KI-Agenten unter menschlicher Aufsicht, mit demselben Anspruch an Qualität, den Software schon vor Vibe Coding brauchte.

Die praktische Konsequenz für dich als Entwickler oder Entscheider ist unspektakulär, aber wichtig: Nutze die Geschwindigkeit, die dir KI-gestützte Entwicklung tatsächlich bringt – bei Prototypen, MVPs und internen Tools ist sie enorm. Verzichte aber nicht auf die Disziplin, die Software schon immer brauchte: Code lesen und verstehen, testen, Sicherheitslücken systematisch prüfen und Verantwortung nicht an ein Werkzeug delegieren, das sie nicht tragen kann. Genau dieser Punkt trennt 2026 die Teams, die von KI-gestützter Entwicklung profitieren, von denen, die ihr eigenes Produkt zur Schlagzeile machen.

Mehr zu den konkreten Werkzeugen, dem detaillierten Arbeitsablauf und echten Praxisprojekten findest du in den weiterführenden Artikeln zu Vibe-Coding-Tools, zum Vibe-Coding-Workflow und zu Vibe-Coding-Praxisprojekten.