Vibe Coding: Wo es teuer wird und was eine Prüfschicht ändert

Offenlegung: Code Guardian ist ein Angebot der Provimedia GmbH. Deren Geschäftsführer Alexander Weipprecht ist Bruder und Geschäftspartner des Herausgebers von digital zentral. Der Herausgeber setzt Code Guardian selbst für diese Seite ein. Dieser Beitrag enthält Partnerlinks: Kommt darüber ein Kauf zustande, erhält digital zentral eine Provision; der Preis für Sie ändert sich nicht.

„Vibe Coding“ beschreibt eine Arbeitsweise, bei der man Software in natürlicher Sprache beschreibt, ein KI-Modell den Code erzeugt und das Ergebnis am laufenden Programm beurteilt wird, nicht Zeile für Zeile. Andrej Karpathy, Mitgründer von OpenAI, prägte den Begriff am 2. Februar 2025; Collins Dictionary kürte ihn im November 2025 zum Wort des Jahres. Die Arbeitsweise ist für Prototypen und Wochenendprojekte ein Gewinn. Im Firmensystem wird sie teuer, und zwar an vorhersehbaren Stellen. Dieser Beitrag benennt sie und erklärt, was eine Prüfschicht daran ändert.

Was Vibe Coding ist, und was nicht

Karpathy beschrieb die Haltung so: sich ganz den „Vibes“ hingeben, den Code vergessen, Fehlermeldungen einfach in den Assistenten kopieren. Das ist eine ehrliche Beschreibung dessen, was bei einem Spielprojekt funktioniert. Das Programm läuft oder läuft nicht, und wenn es nicht läuft, verliert niemand etwas. Vibe Coding ist nicht dasselbe wie KI-gestütztes Programmieren. Wer mit Claude Code oder Codex arbeitet, den Plan liest, den Diff versteht und die Tests laufen lässt, programmiert mit KI. Vibe Coding beginnt da, wo das Lesen aufhört.

Wie verbreitet das ist, zeigt die Stack Overflow Developer Survey 2025: 84 Prozent der Befragten nutzen KI-Werkzeuge in der Entwicklung oder planen es, nach 76 Prozent im Vorjahr. Zugleich misstrauen mehr Entwickler der Genauigkeit dieser Werkzeuge (46 Prozent), als ihr vertrauen (33 Prozent). Die Frage zur Nutzung beantworteten 33.662 Personen. Die Werkzeuge sind also im Alltag angekommen, das Vertrauen nicht.

Was die METR-Studie gemessen hat

Eine viel zitierte Messung stammt von METR, einer gemeinnützigen Forschungsorganisation. In der Studie von Becker, Rush, Barnes und Rein (arXiv 2507.09089, Juli 2025) bearbeiteten 16 erfahrene Open-Source-Entwickler 246 echte Aufgaben in ihren eigenen Repositories. Die Zuteilung, ob KI-Werkzeuge erlaubt waren, erfolgte zufällig. Das Ergebnis: Mit KI brauchten die Entwickler 19 Prozent länger. Vor der Studie hatten sie eine Ersparnis von 24 Prozent erwartet; hinterher schätzten sie, 20 Prozent schneller gewesen zu sein. Die Wahrnehmung lag also in beide Richtungen daneben.

Die Studie hat Grenzen, die ihre Autoren nennen: 16 Personen, Werkzeuge von Anfang 2025, erfahrene Entwickler in Projekten, die sie gut kannten. METR selbst ordnet das Ergebnis inzwischen als historische Momentaufnahme ein. Die Lehre bleibt trotzdem: Das eigene Zeitgefühl beim KI-Einsatz ist kein Messwert. Wer sagt, die KI mache ihn schneller, hat das meist nicht gemessen.

Wo es teuer wird

Die Kosten von Vibe Coding entstehen nicht beim Schreiben, sondern danach, und sie häufen sich an vier Stellen.

• Niemand hat den Code gelesen. Wenn der Code später bricht, kennt ihn keiner. Die Fehlersuche beginnt bei null, und die Verantwortung ist nicht zuordenbar. Für interne Werkzeuge ist das lästig, für Software, die ein Unternehmen in Verkehr bringt, ist es nach Einschätzung des Anbieters ein Haftungsthema; was im Einzelfall gilt, klärt eine Rechtsberatung.
• Keine Tests, keine Eingabeprüfung. Ein Modell schreibt den glücklichen Pfad. Fehlende, falsche oder bösartige Eingaben prüft es nur, wenn jemand das verlangt. Wer nicht liest, verlangt es nicht.
• Unbekannte Fremdpakete. Modelle schlagen Pakete vor, die plausibel klingen. Manche existieren nicht; manche existieren nur, weil jemand den Namen registriert hat, den Modelle gern erfinden. Ein Paket, das ohne Prüfung installiert wird, ist Code aus fremder Hand mit allen Rechten des Projekts.
• Zerstörende Befehle. Ein Assistent, der „aufräumen“ soll, kann einen Ordner löschen, ein Schema ändern oder deployen. Die Werkzeuge fragen nach, aber die Nachfrage wird nach kurzer Zeit zum Reflex.

Sobald Nutzerdaten, Zahlungen, Anmeldung oder Rechtsfolgen im Spiel sind, reicht „es läuft“ nicht mehr. Dann braucht die Arbeit eine Schicht, die prüft, bevor etwas passiert.

Was eine Prüfschicht ändert

Eine Prüfschicht wie Code Guardian setzt nicht am Modell an, sondern am Ablauf. Sie verändert vier Dinge, die beim Vibe Coding fehlen.

Vor dem Bau ein Plan. Ab einer normalen Änderung entsteht zuerst ein Plan, ohne dass eine Datei angefasst wird. Der Mensch liest einen Plan in Prosa statt eines fertigen Diffs, und das ist der Moment, in dem Lesen wieder stattfindet. Offene Entscheidungen werden einzeln gefragt, mit Empfehlung. Details in Erst fragen, dann bauen.

Harte Sperren vor gefährlichen Befehlen. Vier Riegel halten technisch an: Löschen, Geheimnisse im Commit, Deploy und Migration. Der Lösch-Riegel liest den Befehl selbst, auch hinter Shell-Hüllen, statt nach Schlüsselwörtern zu suchen; steht sein Ziel in einer Variablen, weist er ab, statt zu raten. Mehr in Vier harte Riegel.

Ein Gate für neue Pakete. Bevor ein Paket hinzukommt, zählt eine Prüfung: Alter, Verbreitung, ein echtes Repository, Namensnähe zu bekannten Paketen. „Es existiert in der Registry“ ist dabei ausdrücklich kein Beweis, denn genau darauf setzt ein Angreifer, der erfundene Namen registriert. Siehe Die sieben Gates.

Beleg statt Behauptung. „Fertig“ gilt nur mit einem ausgeführten Befehl. Nach jeder Änderung läuft ein Audit auf sechs Ebenen, und bei riskanten Änderungen liest ein zweiter Prüfer den Diff, ohne die Begründung des Autors zu kennen. Das ersetzt nicht den Menschen, es gibt ihm etwas Prüfbares in die Hand. Mehr in Nachweisbar geprüft.

Was eine Prüfschicht nicht ändert

Sie macht aus einem Vibe Coder keinen Entwickler. Wer einen Plan nicht beurteilen kann, klickt ihn durch, und dann ist die Freigabe so viel wert wie die Nachfrage vorher. Sie findet keine Sicherheitslücke, für die kein Werkzeug im Projekt eingerichtet ist; der Anbieter nennt das als Grenze selbst. Und sie ändert nichts an der METR-Erkenntnis: Ob KI das Team schneller macht, weiß man erst, wenn man es misst.

Häufig gestellte Fragen

Ist Vibe Coding grundsätzlich schlecht?

Nein. Für Prototypen, Lernprojekte und Werkzeuge, die nur der Autor nutzt, ist es eine schnelle Art, etwas auszuprobieren. Teuer wird es, wenn das Ergebnis ohne Übergang zum Produkt wird.

Reicht ein Linter als Prüfschicht?

Ein Linter prüft Quelltext auf Stil und bekannte Muster. Er hält keinen Löschbefehl an, verlangt keinen Plan und keinen Beleg. Beides ergänzt sich; keines ersetzt das andere.

Warum fühlen sich Entwickler mit KI schneller, obwohl sie langsamer waren?

Die METR-Autoren vermuten mehrere Gründe, darunter die geringere gefühlte Anstrengung beim Schreiben und die Zeit, die beim Prüfen und Nacharbeiten der Vorschläge unterging. Entscheidend ist, dass die Schätzung in beide Richtungen danebenlag.

Hilft Code Guardian auch ohne Tests im Projekt?

Teilweise. Riegel, Gates und Plan-Freigabe funktionieren ohne Tests. Die Belegpflicht kann aber nur verlangen, dass etwas ausgeführt wird; ob das Ausgeführte etwas beweist, hängt davon ab, ob das Projekt Tests hat.

Weiterlesen in dieser Serie

• Code Guardian: Was das Prüfpaket für Claude Code und Codex wirklich tut
• Die sieben Gates von Code Guardian erklärt
• Code Guardian im Alltag: Erfahrungen aus dem Betrieb von digital zentral

Auch interessant

• Erstes vollständig KI-generiertes Spiel: Codex Mortis sorgt für gemischte Reaktionen

Code Guardian ansehen

Alle Angaben zu Umfang und Lizenz stehen beim Anbieter: Code Guardian bei Provimedia (öffnet in neuem Fenster)Anzeige. Mit dem Code PARTNER-4B79 erhalten Sie 10 % Rabatt auf den Einmalkauf der Firmenlizenz (nicht auf das Update-Abo; Stand 4. November 2026).