Vibe Coding vs. Engineering: Wann KI-Code reicht und wann nicht

28. Oktober 2026

Der Nachmittag, der zu gut lief

Stell dir Folgendes vor: Ein Kunde braucht ein internes Tool, das Anfragen erfasst, filtert und als CSV exportiert. Du öffnest deinen KI-Assistenten, beschreibst in drei Absätzen, was du willst, und nach zwei Stunden läuft eine Oberfläche, die aussieht, als hätte ein Team drei Wochen daran gesessen. Der Kunde ist begeistert. Du auch.

Sechs Monate später soll ein neues Feld dazukommen. Plötzlich zeigt sich: Die Validierung steckt an vier Stellen im Code, der State liegt halb in der Komponente und halb im Local Storage, und niemand weiß, warum ein bestimmter Request doppelt rausgeht. Der Code funktioniert, aber keiner hat ihn je richtig gelesen. Du auch nicht.

Das ist ein Gedankenexperiment, aber ich bin mir sicher, dass es genau so gerade in vielen Projekten passiert. Und darum geht es in diesem Beitrag. Vibe Coding ist weder Unsinn noch Weltuntergang. Es ist ein Werkzeug mit einem klaren Einsatzgebiet. Ärger gibt es erst, wenn wir den Unterschied zu Engineering vergessen.

Was Vibe Coding eigentlich ist

Der Begriff geht auf Andrej Karpathy zurück, der ihn Anfang 2025 geprägt hat. Gemeint ist ein Arbeitsstil: Man beschreibt der KI, was man haben möchte, übernimmt das Ergebnis, ohne es im Detail zu prüfen, und steuert nur über das Resultat nach. Läuft es? Gut. Fehlermeldung? Kopieren, einfügen, weiter. Man folgt den Vibes und lässt den Code im Hintergrund entstehen.

Wichtig ist die Abgrenzung. Wer KI-Vorschläge liest, versteht und gezielt übernimmt, vibe-codet nicht, sondern arbeitet mit einem sehr schnellen Pair-Programming-Partner. Vibe Coding im engeren Sinn beginnt dort, wo man das Verständnis des Codes bewusst aufgibt.

Warum ist das so verlockend? Aus drei Gründen:

Tempo: Vom Gedanken zur lauffähigen Oberfläche in Minuten.
Niedrige Hürde: Auch wer kaum programmieren kann, bekommt etwas Funktionierendes.
Flow: Kein Hin und Her zwischen Doku, Suchmaschine und Editor.

Ehrlich gesagt fühlt sich das großartig an. Gerade deshalb lohnt sich ein nüchterner Blick darauf, was dabei passiert. Beim Vibe Coding verschiebt sich die Arbeit, sie verschwindet nicht. Das Schreiben von Code wird billig. Das Verstehen, Prüfen und Verantworten bleibt, und es fällt später an, meistens zu einem ungünstigeren Zeitpunkt.

Wo Vibe Coding glänzt

Ich will hier nicht den Eindruck erwecken, ich wäre dagegen. Es gibt Situationen, in denen es genau die richtige Wahl ist.

Prototypen und Ideenvalidierung. Wenn die Frage lautet, ob das überhaupt jemand nutzen würde, ist die Codequalität zweitrangig. Ein klickbarer Prototyp an einem Nachmittag spart Wochen an Diskussion. Entscheidend ist, dass der Prototyp auch als Prototyp behandelt und danach weggeworfen wird.

Wegwerf-Skripte. Eine einmalige Datenmigration, ein Skript, das 300 Dateien umbenennt, eine Auswertung für heute Nachmittag. Läuft es einmal korrekt durch, ist der Job erledigt. Hier reicht es, das Ergebnis zu prüfen, nicht den Code.

Interne Tools für einen kleinen Kreis. Ein Dashboard für drei Kollegen, das keine sensiblen Daten anfasst und nichts im Produktivbetrieb stören kann. Das Risiko ist begrenzt, der Nutzen sofort da.

Lernen und Erkunden. Eine unbekannte Bibliothek ausprobieren, zwei Ansätze gegeneinander testen, ein Konzept in Code sehen, bevor man es sauber baut. Die KI ist dafür ein hervorragender Sparringspartner, solange man danach nicht einfach alles unbesehen übernimmt.

Was diese Fälle verbindet: Der Schaden bei Fehlern ist klein, die Lebensdauer kurz und der Kreis der Betroffenen überschaubar. Sobald eines dieser drei Kriterien kippt, wird es heikel.

Wo es kippt

Problematisch wird es, wenn aus dem Prototyp still und leise Produktivcode wird. Das passiert häufiger, als man denkt, denn es läuft ja schon, und der Kunde fragt nach dem nächsten Feature.

Sicherheit. KI-Code sieht plausibel aus, auch wenn er es nicht ist. Typische Kandidaten sind fehlende Eingabevalidierung, zu großzügige CORS-Einstellungen, Secrets im Client oder Datenbankabfragen, die aus Strings zusammengebaut werden. Wer den Code nie liest, merkt das nicht. Angreifer lesen ihn sehr wohl.

Wartbarkeit. Das Modell optimiert auf "funktioniert jetzt", nicht auf "lässt sich in einem Jahr noch ändern". Heraus kommen oft Duplikate, uneinheitliche Muster und Abstraktionen, die nur im Kontext des aktuellen Prompts Sinn ergeben.

Debugging. Hier zahlt man den Preis am deutlichsten. Wer Code nicht versteht, kann einen Bug nicht eingrenzen. Man landet in einer Schleife: Fehler einfügen, Fix bekommen, neuer Fehler. Manchmal löst die KI das Problem tatsächlich. Manchmal baut sie einen Workaround um das Symptom, und die Ursache wandert eine Ebene tiefer.

Verantwortung. Wenn ein Kunde Daten verliert, fragt er nicht, welches Modell den Code geschrieben hat. Er fragt die Person, die er beauftragt hat. Gerade als Freelancer ist das ein Punkt, den ich nicht abgeben kann und auch nicht will.

Technische Schulden, die niemand bemerkt

Klassische technische Schulden kennt man: Man weiß, dass man gerade eine Abkürzung nimmt, und nimmt sie bewusst. Beim Vibe Coding entstehen Schulden, von denen man gar nichts weiß, weil man den Code nie gelesen hat. Das ist ein Unterschied, der in der Praxis richtig wehtut.

Ein Beispiel aus dem Frontend-Alltag. So etwas liefert ein Assistent auf Zuruf:

async function loadUser(id: string) {
  const res = await fetch(`/api/users/${id}`)
  const data = await res.json()
  return data as User
}

Der Code ist kurz, gut lesbar und macht im Test genau das Richtige. Trotzdem steckt einiges drin:

Es gibt keinen Check auf res.ok. Ein 404 oder 500 landet als vermeintlicher User im Code.
Das as User ist keine Prüfung, sondern ein Versprechen an den Compiler. Kommt vom Server etwas anderes zurück, merkt man es erst an ganz anderer Stelle, mit einer kryptischen Fehlermeldung.
Die id wird ungeprüft in die URL eingebaut.
Bei schnellen Eingaben oder Navigation können sich Requests überholen, weil nichts abgebrochen wird.

Eine Variante, die ich ohne Bauchschmerzen ins Projekt nehmen würde:

import { z } from 'zod'

const UserSchema = z.object({
  id: z.string(),
  name: z.string(),
  email: z.email()
})

type User = z.infer<typeof UserSchema>

async function loadUser(id: string, signal?: AbortSignal): Promise<User> {
  const res = await fetch(`/api/users/${encodeURIComponent(id)}`, { signal })

  if (!res.ok) {
    throw new Error(`Benutzer konnte nicht geladen werden (${res.status})`)
  }

  return UserSchema.parse(await res.json())
}

Das ist nicht komplizierter, aber ehrlicher. Fehler werden sichtbar, und die Daten werden zur Laufzeit geprüft, statt nur im Typsystem behauptet. Der Punkt ist nicht, dass die KI das nicht auch könnte. Sie kann es, wenn man danach fragt. Wer aber nicht weiß, wonach er fragen muss, bekommt die erste Variante. Und genau dieses Wissen ist Engineering.

Was Engineering trotzdem ausmacht

Es gibt die Vorstellung, Softwareentwicklung bestehe vor allem aus Tippen. Wer so denkt, sieht in KI zwangsläufig einen Ersatz. In der Praxis ist das Schreiben von Code aber nur ein Teil der Arbeit, und selten der schwierigste.

Engineering bedeutet für mich vor allem Entscheidungen:

Architektur: Wo liegt welche Verantwortung? Was darf sich später leicht ändern, was nicht? Ein Modell sieht den Prompt, aber nicht die Firma, die Roadmap oder die Eigenheiten des Kunden.
Tests: Sie sind keine Pflichtübung, sondern die Antwort auf die Frage, woher ich weiß, dass es noch funktioniert, nachdem ich etwas geändert habe. Gerade bei generiertem Code sind sie das wichtigste Sicherheitsnetz.
Review: Jemand muss den Code verstehen, bevor er live geht. Das gilt für Code von Kollegen genauso wie für Code von einer KI. Und je schneller Code entsteht, desto mehr wird Review zum Flaschenhals.
Betrieb: Logging, Fehlerbehandlung, Updates, Abhängigkeiten. Alles, was nach dem ersten Deployment kommt und nie im Demo-Video auftaucht.

Was ich dabei besonders mag: Gute Engineering-Praxis und KI-Nutzung schließen sich nicht aus, sie verstärken sich. Striktes TypeScript, ein sauber konfigurierter Linter und eine brauchbare Testabdeckung sind Leitplanken, an denen auch ein Modell abprallt, wenn es Unsinn baut. Wer solche Leitplanken hat, kann der KI deutlich mehr zutrauen. Wer keine hat, fährt blind mit hoher Geschwindigkeit.

Die Rollen verschieben sich also: weniger Tippen, mehr Lesen, Einordnen und Entscheiden. Das ist keine Abwertung des Berufs, eher im Gegenteil.

Eine Faustregel für den Alltag

Die Frage ist also nicht, ob man KI nutzt, sondern wie viel Kontrolle man dabei abgibt. Ich stelle mir vor jeder Aufgabe drei Fragen:

Was passiert, wenn es falsch ist? Ärgert sich im schlimmsten Fall eine Person kurz, oder gehen Daten, Geld oder Vertrauen verloren?
Wie lange lebt der Code? Läuft er heute einmal und ist morgen vergessen, oder wird er in einem Jahr noch erweitert?
Wer muss ihn später verstehen? Nur ich, ein Team oder ein Kunde, der ihn irgendwann übernimmt?

Lauten die Antworten "wenig", "kurz" und "nur ich", darf die KI laufen: Prompt rein, Ergebnis prüfen, fertig. Fällt auch nur eine Antwort deutlich anders aus, übernehme ich die Kontrolle. Das heißt konkret:

In kleinen Schritten arbeiten. Ein Feature pro Anfrage, nicht die ganze Anwendung auf einmal. Kleine Diffs kann man tatsächlich lesen.
Rahmen vorgeben. Welche Bibliotheken, welche Muster, welche Fehlerbehandlung. Je klarer die Vorgaben, desto weniger Überraschungen.
Jede Zeile lesen, die ich übernehme. Wenn ich etwas nicht verstehe, frage ich nach oder schreibe es um, bis ich es verstehe.
Tests zuerst oder direkt danach. Auch die Tests dürfen von der KI kommen, aber ich muss prüfen, ob sie das Richtige testen und nicht nur das, was der Code gerade tut.
Typen und Linter scharf stellen. Je mehr der Compiler abfängt, desto weniger muss ich selbst finden.

Das klingt nach Bremse, ist aber keine. Die Zeit, die man ins Lesen investiert, spart man beim Debugging mehrfach wieder ein.

Fazit: Vibes sind kein Fundament

Vibe Coding ist ein großartiger Weg, schnell von einer Idee zu etwas Anfassbarem zu kommen. Für Prototypen, Skripte und kleine interne Helfer nutze ich diesen Ansatz gerne und ohne schlechtes Gewissen. Sobald aber echte Nutzer, echte Daten oder echtes Geld im Spiel sind, reichen Vibes nicht mehr.

Meine Haltung ist deshalb ziemlich klar: Für Produktivcode ist Vibe Coding in Reinform keine gute Idee. Nicht, weil die KI schlecht wäre, sondern weil sich Verantwortung nicht delegieren lässt. Wer den Code ausliefert, muss ihn verstehen oder zumindest bereit sein, ihn zu verstehen, wenn es darauf ankommt.

Das Spannende ist, dass KI den Beruf nicht überflüssig macht, sondern den Schwerpunkt verschiebt. Code zu erzeugen wird billig. Zu beurteilen, ob er gut ist, bleibt wertvoll. Wer das kann, hat mit diesen Werkzeugen einen enormen Hebel in der Hand. Wer es nicht kann, handelt sich sehr schnell sehr viel Ärger ein.

Mein Rat zum Mitnehmen: Nutze die KI so, wie du einen talentierten, aber unerfahrenen Kollegen einsetzen würdest. Gib klare Aufgaben, lies, was zurückkommt, und übernimm nichts, was du nicht erklären kannst. Dann bekommst du das Tempo von Vibe Coding und die Verlässlichkeit von Engineering.