Vibe Coding auf Deutsch: Was es ist, was es nicht ist

Vibe Coding heißt, Software zu bauen, indem du einem KI-Werkzeug in normaler Sprache beschreibst, was entstehen soll, und den erzeugten Code nicht liest. Andrej Karpathy hat den Ausdruck am 2. Februar 2025 geprägt, Collins hat ihn im November 2025 zum Wort des Jahres erklärt.

Der Begriff verspricht, dass Arbeit verschwindet. Sie verschwindet nicht, sie wandert. Aus dem Tippen von Code wird das Schreiben eines Auftrags und das Prüfen eines Ergebnisses. Das lässt sich an unserem eigenen Auftrag nachzählen: In dem Auftrag, mit dem wir vor Publikum eine funktionierende Seite bauen, sind 25 von 179 Wörtern das Ziel. Die anderen 154 sind Kontext, Grenzen und ein durchgerechnetes Beispiel. Wer glaubt, es reiche zu sagen, was man will, hat den kürzesten der vier Blöcke für den ganzen Auftrag gehalten.

Was ist Vibe Coding?

Vibe Coding ist eine Arbeitsweise, bei der ein Mensch in natürlicher Sprache beschreibt, was eine Software tun soll, ein Sprachmodell den Code dazu erzeugt, und der Mensch diesen Code nicht liest, sondern nur das Ergebnis beurteilt. Das Weglassen der Durchsicht ist der Kern, nicht der Einsatz von KI.

Karpathy beschrieb es am 2. Februar 2025 als eine neue Art zu programmieren, bei der man sich "ganz den Vibes hingibt, den Exponentialverlauf annimmt und vergisst, dass der Code überhaupt existiert" (Andrej Karpathy auf X).

Collins nahm den Ausdruck im selben Jahr als Wort des Jahres und definiert ihn als "the use of artificial intelligence prompted by natural language to write computer code", also den Einsatz künstlicher Intelligenz, die per natürlicher Sprache angewiesen wird, Computercode zu schreiben (Collins Dictionary, 6. November 2025).

Die schärfste Abgrenzung stammt von Simon Willison, und sie ist die, an der die meisten deutschen Erklärtexte vorbeischreiben: "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works, that's not vibe coding, it's software development" (simonwillison.net, 19. März 2025).

Daraus folgt etwas Unbequemes. Das meiste, was hierzulande als Vibe Coding beschrieben wird, ist nach der ursprünglichen Definition keins. Wer das Ergebnis prüft, entwickelt Software mit einem sehr schnellen Werkzeug. Das ist keine Wortklauberei, sondern der Unterschied zwischen einer Arbeitsweise, die trägt, und einer, die nur so lange trägt, bis etwas kaputt ist.

Gibt es ein deutsches Wort dafür, und kann ich auf Deutsch prompten?

Ein eingebürgertes deutsches Wort gibt es nicht, und es wird vermutlich keins geben. Auf Deutsch arbeiten kannst du trotzdem, und zwar vollständig.

Umschreiben lässt sich der Begriff als Programmieren durch Beschreiben. Das trifft die Sache, verliert aber den entscheidenden Teil, nämlich den Verzicht auf die Durchsicht. Wer den deutschen Ausdruck benutzt, sollte ihn deshalb dazusagen.

Wichtiger ist die zweite Frage, und die Antwort darauf ist praktisch. Wir schreiben unsere Aufträge auf Deutsch, auch den, der weiter unten wörtlich steht und den wir vor Publikum tippen. Die Sprache, in der du beschreibst, ist unabhängig von der Sprache, in der der Code und seine Bezeichner am Ende stehen. Beides gehört in den Auftrag hinein, wenn es dir wichtig ist, und dann ist es geklärt. Was du auf Deutsch nicht bekommst, ist die Masse an deutschsprachigen Beispielen: Wer beim Suchen nicht weiterkommt, findet die Antwort fast immer auf Englisch. Welche Einstellungen dabei wirklich auf Deutsch laufen, von der Antwortsprache bis zur Dokumentation, steht in Claude Code auf Deutsch.

Was passiert wirklich, wenn jemand nur den Vibe beschreibt?

Er beschreibt nicht nur den Vibe. Das ist der empirische Befund, und er stammt nicht von uns.

Advait Sarkar (University of Cambridge und University College London) und Ian Drosos (Microsoft Research) haben fünf aufgezeichnete Vibe-Coding-Sitzungen ausgewertet, zusammen 8 Stunden und 27 Minuten, in denen die Beteiligten laut mitdenken (arXiv:2506.23253, 29. Juni 2025). Was sie beobachten, ist nicht Hingabe an den Vibe, sondern Steuerung: Die Beteiligten mischen vage Richtungsangaben mit detaillierten technischen Vorgaben, benennen einzelne Stellen im Code beim Namen, gliedern Anweisungen in Listen, fügen Fehlermeldungen ein und beziehen sich auf frühere Ausgaben.

Die Autoren beschreiben außerdem einen Effekt, den jeder wiedererkennt, der das schon einmal gemacht hat: context momentum. Frühe Entscheidungen im Lauf verengen die späteren. Was in den ersten Minuten festgelegt wurde, bestimmt mit, was danach überhaupt noch leicht änderbar ist. Genau deshalb ist der Anfang eines Auftrags nicht die Stelle, an der man sich kurz fasst.

Die linke Spur fühlt sich schneller an, weil der erste Schritt zehn Sekunden dauert. Sie kostet die Zeit hinten, in Runden, die niemand geplant hat. Die rechte kostet die Zeit vorn, einmal.

Wie sieht ein Auftrag aus, der trägt?

Er hat vier Blöcke, immer dieselben: Ziel, Kontext, Grenzen, Beispiel. Das ist die Struktur, die wir im Kurs unterrichten und die wir selbst tippen, auch live. Ein Auftrag, der alle vier klärt, braucht keine Rückfrage und meistens keine zweite Runde. Du kannst die vier Blöcke im Prompt Generator ausfüllen, er setzt sie zu einem Auftrag zusammen.

Was in jeden Block gehört:

1. Ziel. Das Ergebnis, nicht der Weg. Eine Seite, auf der jemand in fünf Fragen einen Richtpreis bekommt, nicht "baue mir ein Formular".
2. Kontext. Was der Agent wissen muss und nicht raten soll: was technisch schon steht, wie das Geschäft rechnet, welche Preise gelten. Der Block, den fast alle zu kurz halten.
3. Grenzen. Was ausdrücklich nicht passieren soll. Keine Datenbank, keine Anmeldung, mobil zuerst. Grenzen halten die Runden kurz und damit auch die Rechnung.
4. Beispiel. Ein Fall, durchgerechnet, mit dem Ergebnis, das herauskommen soll. Daran prüft sich der Agent selbst, und beim Schreiben merkst du, ob deine eigene Logik stimmt.

So sieht das ausgeschrieben aus. Das ist kein nachgebautes Muster, sondern der Auftrag aus unserem Live-Build, wörtlich, für einen erfundenen Beispielbetrieb mit einer ausgedachten Preisliste:

Ziel: Eine öffentliche Seite /preisrechner, auf der ein Brautpaar in fünf Fragen
einen unverbindlichen Richtpreis für einen Hochzeitsfotografen bekommt und
danach eine Anfrage abschicken kann.

Kontext: Next.js App Router mit Tailwind, steht schon. Das Geschäft ist ein
Solo-Fotograf in Köln. Preisliste: Grundpaket sechs Stunden 1.400 Euro, jede
weitere Stunde 150 Euro, zweiter Fotograf 450 Euro, Album 390 Euro, Anfahrt ab
50 Kilometer 50 Cent pro Kilometer, und auf die Summe 20 Prozent Aufschlag,
wenn es ein Samstag zwischen Mai und September ist.

Grenzen: Keine Datenbank, keine Anmeldung. Das Ergebnis erscheint sofort im
Browser, ohne dass jemand seine E-Mail hinterlässt. Die E-Mail kommt erst beim
Absenden der Anfrage. Unter dem Formular ein Satz zum Datenschutz mit Link auf
/datenschutz und eine Checkbox, die gesetzt sein muss. Mobil zuerst, die Seite
wird auf dem Handy benutzt.

Beispiel für ein gutes Ergebnis: acht Stunden, zweiter Fotograf, Samstag im
Juni, 30 Kilometer Anfahrt, kein Album ergibt 2.580 bis 2.970 Euro, und die
Rechnung steht aufgeschlüsselt darunter, damit der Preis nicht wie geraten
wirkt.

Jetzt zähl die Blöcke nach. Das Ergebnis ist der Grund, warum dieser Artikel existiert.

Das Ziel ist der kürzeste Block, mit 25 von 179 Wörtern, also 14 Prozent. Kontext und Grenzen zusammen sind 119 Wörter, also 66 Prozent. Der längste Block ist der, in dem steht, was nicht passieren soll.

Das ist die ganze Lektion in einer Zahl. Vibe Coding wird verkauft als "sag einfach, was du willst". In einem Auftrag, der wirklich funktioniert, ist "was du willst" der kleinste Teil. Der Rest ist die Arbeit, die vorher niemand gemacht hat, weil sie im Kopf des Programmierers stattfand.

Woran merkst du, dass es fertig ist?

An einer Gegenprüfung, die läuft, ohne dass du sie machst. Das ist die Stelle, an der sich entscheidet, ob du eine Sache abgeben kannst oder ob du sie nur scheinbar abgegeben hast.

Karpathys eigene Beschreibung endet beim Ergebnis. Er schrieb, er sehe Dinge, sage Dinge, führe Dinge aus und kopiere Dinge, "and it mostly works", also: es funktioniert meistens (Andrej Karpathy auf X, 2. Februar 2025). "Meistens" ist bei einem Wochenendprojekt in Ordnung und bei einer Seite, die Anfragen von Fremden entgegennimmt, nicht.

Wie das bei uns aussieht, lässt sich zählen. Diese Website trägt 163 automatisierte Tests in sieben Dateien, ausgeführt am 21.09.2026 vor der Veröffentlichung dieses Artikels. Dazu kommen die Regeln, die beim Bauen greifen: Allein die Prüfung der Blogbeiträge kennt 15 Bedingungen, bei denen der Build abbricht, statt die Seite zu veröffentlichen. Eine fehlende Quellenangabe, ein Datum im falschen Format, ein interner Link auf einen Beitrag, den es nicht gibt, eine Meta-Description über 155 Zeichen: Jeder dieser Fälle bricht den Bau, und niemand muss daran denken.

Daraus folgt die praktische Regel, und sie gilt unabhängig vom Werkzeug. Du kannst genau so viel abgeben, wie deine Gegenprüfung trägt. Wer Tests hat, kann viel abgeben. Wer keine hat, gibt das Tippen ab und prüft danach trotzdem alles selbst, und der versprochene Zeitgewinn ist weg.

Für den Anfang muss das keine Testsuite sein. Eine Gegenprüfung kann auch sein: das durchgerechnete Beispiel aus Block vier, ein zweiter Mensch, der das Ergebnis benutzt, oder schlicht die Regel, dass nichts online geht, was du nicht einmal selbst von Anfang bis Ende durchgeklickt hast.

Wo hört Vibe Coding auf?

Bei allem, was Schaden anrichten kann, wenn es falsch ist. Das ist keine Haltung, sondern die Grenze, die auch die Befürworter ziehen.

Willison nennt sie im selben Beitrag, in dem er Vibe Coding ausdrücklich verteidigt. Seine Prüffrage lautet, wie viel Schaden der Code anrichten könnte, wenn er Fehler oder Sicherheitslücken hat. Konkret rät er ab, wo nach Verbrauch abgerechnet wird, und er hält fest, dass man bei Zugangsdaten und privaten Daten verstehen muss, wie der Code funktioniert (simonwillison.net).

Das Fraunhofer IESE ordnet denselben Punkt aus der Engineering-Perspektive ein: Vibe Coding sei kein Hype, sondern ein neuer Entwicklungsansatz, der auf klassisches Software Engineering trifft, und die Risiken liegen dort, wo niemand mehr überblickt, was entstanden ist (Fraunhofer IESE, 27. November 2025).

Bei uns hat das eine sehr konkrete Folge im Auftrag oben. Der Satz zum Datenschutz unter dem Formular und die Checkbox, die gesetzt sein muss, stehen im Block Grenzen, nicht im Block Ziel. Das ist der Teil, den wir ausdrücklich nicht dem Vibe überlassen, weil dort personenbezogene Daten von Fremden entgegengenommen werden. Alles andere auf dieser Seite darf entstehen, wie es entsteht.

Eine gute Faustregel für den eigenen Fall: Wenn du die Frage "was passiert im schlimmsten Fall" nicht in einem Satz beantworten kannst, ist die Sache zu groß für diese Arbeitsweise.

Womit fängst du an?

Mit einer Sache, die niemandem schadet, wenn sie falsch ist, und die du diese Woche ohnehin brauchst. Ein Rechner, eine Übersicht, ein kleines Werkzeug nur für dich.

Drei Schritte, mehr nicht:

1. Schreib die vier Blöcke auf, bevor du das Werkzeug öffnest. Wenn du den Kontext-Block nicht füllen kannst, weiß der Agent es auch nicht.
2. Rechne dein Beispiel selbst durch. Ein falsches Beispiel im Auftrag ist teurer als gar keins, weil der Agent sich daran ausrichtet.
3. Leg vorher fest, woran du merkst, dass es stimmt. Vor dem ersten Lauf, nicht danach.

Welches Werkzeug du dafür nimmst, ist die kleinere Frage. Wenn du dich trotzdem entscheiden musst, haben wir sie in Claude Code vs Cursor entlang der Arbeitsweise beantwortet, und was der Monatsbetrag am Ende wirklich treibt, steht in Claude Code Kosten.

Die Schicht darüber ist das, was aus einem gelungenen ersten Lauf eine Arbeitsweise macht: die vier Blöcke, die Datei mit deinen Regeln, die Gegenprüfung und am Ende Aufgaben, die ohne dich zu Ende laufen. Genau das unterrichten wir im Claude Code System, vier Wochen mit wöchentlichen Live-Sessions. Wer vorher sehen will, wie ein solcher Auftrag live getippt wird und was dabei passiert, kommt in ein kostenloses Live-Webinar. Alle Kurse stehen unter Kurse, und wer dahintersteckt, auf Über uns.