KI-gestütztes Engineering statt Vibe Coding: der Unterschied, der zählt

Vibe Coding, ein Begriff, der sich 2025 verbreitete, bedeutet, einer KI zu beschreiben, was man will, zu akzeptieren, was sie produziert, und nach Gefühl zu iterieren, bis das Ergebnis richtig aussieht. Es ist ein legitimer Weg, eine Idee zu erkunden. Es ist schnell, billig und macht ehrlich Spaß. Was es nicht ist: Engineering. Denn nichts in diesem Loop verifiziert, dass sich die Software korrekt verhält, sicher bleibt oder nächsten Monat gefahrlos geändert werden kann. Das Ergebnis wird nach Augenmaß beurteilt, und der Prozess hinterlässt keine Aufzeichnung darüber, was sich geändert hat, warum, oder ob es jemand geprüft hat.

KI-gestütztes Engineering behält die Geschwindigkeit und streicht das Rätselraten. Die KI schreibt weiterhin den Code, aber jede Änderung landet in einer Delivery-Disziplin: Sie wird auf einem Branch versioniert, gegen Richtlinien geprüft, von automatisierten Tests durchlaufen, auf Sicherheitsprobleme gescannt und abgeklopft und über eine kontrollierte Pipeline mit Rollback-Pfad bereitgestellt. Ein Mensch gibt die Änderungen frei, die Konsequenzen tragen, und ein Audit-Trail protokolliert, dass er es getan hat. Der Prompt ist derselbe. Alles, was nach dem Prompt passiert, ist anders.

Die Unterscheidung ist nicht akademisch. Sie entscheidet, ob das, was ihr gebaut habt, Kundendaten halten, ein Security-Review bestehen, den Weggang seines Autors überleben oder an ein zweites Team übergeben werden kann. Wenn die Antwort auf eine dieser Fragen Ja sein muss, entscheidet die Art des Bauens. Nicht das Modell, das baut.

Der Begriff begann als Kompliment, als Name dafür, wie mühelos Generierung geworden war, und wurde zum Warnhinweis, als die erste Welle KI-gebauter Apps auf echte Nutzer traf. Nichts an dieser Warnung ist anti-KI. Die Modelle sind nicht das Problem; das fehlende System um sie herum ist es, und dasselbe Modell, in einen kontrollierten Delivery-Loop gesetzt, produziert Software, hinter der ein Unternehmen stehen kann. Deshalb geht es hier um Prozessarchitektur, nicht um Modellwahl, und deshalb gilt das Argument, egal welche Anbieter-KI ihr bevorzugt. Es gilt auch in jeder Größenordnung: Ein Zwei-Personen-Startup kann verantwortungsvoll vibe-coden, wenn es weiß, auf welcher Seite der Linie es steht; eine Bank kann es sich nicht leisten, es nicht zu wissen.

Die meisten Teams begegnen dem Problem im Übergabemoment. Jemand aus Marketing, Operations oder Produkt vibe-codet ein Tool, das gut genug funktioniert, dass Leute anfangen, sich darauf zu verlassen. Dann braucht es SSO. Dann speichert es etwas Personenbezogenes. Dann fragt eine Direktorin, wer Änderungen prüft, und die ehrliche Antwort lautet: niemand. An diesem Punkt sind die Optionen hässlich: sauber neu bauen, es unverändert übernehmen und unbekanntes Risiko erben, oder ein Tool abschalten, das Leute bereits nutzen.

Die Kosten tauchen in drei Büchern auf. Erstens Nacharbeit: Prototypen, die nicht aufsteigen können, werden von Grund auf neu gebaut. Der schnelle Weg war also in Wahrheit der langsame. Zweitens Sicherheitsexposition: Ungeprüfter generierter Code geht mit den Zugriffsmustern und Abhängigkeiten in Produktion, die das Modell zufällig gewählt hat, und niemand kann sagen, was drinsteckt. Drittens Review-Engpässe: Wenn KI das Änderungsvolumen vervielfacht, aber Review- und Testkapazität gleich bleiben, verlangsamt sich entweder das Ausliefern auf das alte Tempo, oder die Sorgfalt sinkt leise. Keins von beidem ist das Ergebnis, für das irgendjemand ein KI-Tool gekauft hat.

Es gibt auch organisatorische Kosten, die es selten ins Foliendeck schaffen: Vertrauen. Das erste per Vibe Coding gebaute Tool, das Daten korrumpiert oder einen Datensatz leakt, macht jeden künftigen KI-Bauantrag schwerer genehmigbar. Teams, die früh Disziplin etablieren, behalten ihre Erlaubnis, schnell zu sein. Teams, die sie überspringen, bekommen meist einen Vorfall, und dann ein Moratorium.

Wer Engineering leitet, kennt die schärfste Version des Schmerzes: die Asymmetrie der Schuld. Das Business feiert die Geschwindigkeit KI-gebauter Tools. Bis eines ausfällt, und der Ausfall landet bei Engineering, auch wenn Engineering das Tool nie gesehen hat. Diese Dynamik macht einen kontrollierten Pfad zum eigennützigen Schritt, nicht nur zum verantwortungsvollen: Die einzige haltbare Antwort auf unsanktioniertes Bauen ist ein sanktionierter Weg zu bauen, der genauso schnell ist. Verbote überleben den Kontakt mit einem Tool nicht, das jemandes Montagmorgen-Problem löst; bessere Defaults schon.

Ein schneller Selbsttest. Könnt ihr die letzten drei Änderungen an der App nennen und wer sie freigegeben hat? Würde euch, wenn die App jetzt sofort bräche, irgendetwas anderes als ein Nutzer davon erzählen? Könnte ein Kollege die Änderung von gestern zurückrollen, ohne dass ihr im Raum seid? Stoppt irgendetwas automatisch eine Veröffentlichung, wenn ein Login-Ablauf bricht? Wenn ihr mehr als einmal mit Nein geantwortet habt, macht ihr Vibe Coding. Egal wie euer Tooling heißt.

Nichts davon ist ein Argument gegen Prototyping nach Gefühl. Aus Exploration entstehen gute Produkte, und volle Disziplin auf einen Wegwerf-Spike zu zwingen, verschwendet die Zeit aller. Das Fehlermuster ist nicht das Prototyping; es sind Prototypen, die stillschweigend zu Produktion werden, weil niemand die Linie gezogen hat. Entscheidet, wo die Linie verläuft, bevor das Tool sie überquert, und macht das Überqueren zu einem bewussten Akt mit Checkliste. Nicht zu einer allmählichen Ansammlung von Nutzern. Wenn ihr eine strukturierte Version dieses Selbsttests wollt: Die Vibe-Coding-Risiko-Scorecard führt Frage für Frage hindurch.

Macht denselben Test auch auf Portfolio-Ebene. Die meisten Organisationen haben nicht eine KI-gebaute App; sie haben Dutzende, in unterschiedlichen Disziplinzuständen, und keine Liste. Ein Inventar mit benannten Verantwortlichen, selbst eine grobe Tabelle, verwandelt ein unbekanntes Risiko in ein gemanagtes, und meist fördert es zwei oder drei Tools zutage, die leise kritisch geworden sind, während niemand hinsah. Das sind eure ersten Kandidaten für den kontrollierten Pfad. Priorisiert nach Datensensibilität und Nutzerzahl, nicht danach, wer am lautesten ruft.

Automo wurde so gebaut, dass der schnelle Weg und der disziplinierte Weg derselbe Weg sind. Ihr beschreibt die App in einfacher Sprache, und Automo generiert echte React-, TypeScript- und Supabase-Anwendungen, die euch gehören, aber jede Änderung landet im Delivery-Loop statt daneben. Guardrails ordnet Code Geschäftsbereichen zu, erkennt riskante Änderungen, wendet Richtlinien in einfacher Sprache an, protokolliert menschliche Prüfung und hinterlässt einen Audit-Trail hinter jedem Merge. QA führt deterministische Browser-Replays, selbstheilende Tests, Smoke-Gates vor der Veröffentlichung und Produktionsprüfungen danach aus. Security führt statisches Scanning, Abhängigkeitsprüfungen und Zugriffskontroll-Proben durch und bestätigt Schwachstellen gegen die Live-App, bevor sie gemeldet werden.

Das Ergebnis: Ein Prototyp und eine Produktions-App sind auf Automo nicht zwei verschiedene Artefakte. Sie sind dasselbe Artefakt auf unterschiedlichen Prüfungsstufen, wobei die Prüfung von der Plattform kommt statt von demjenigen, der zufällig daran denkt. Der Code ist Standard-React, TypeScript und Tailwind, jederzeit in euer eigenes Repository exportierbar. Die Disziplin wird also nie zum Käfig. Für Teams mit ernsthaften Produktionsprogrammen ist das der Pitch in einer Zeile: KI-gestütztes Engineering statt Vibe Coding. Ernsthafte Entwicklungsprogramme starten bei 10.000 USD pro Jahr; eine Demo ist der schnellste Weg, den Loop einmal von Ende zu Ende laufen zu sehen.

Eine ehrliche Anmerkung: Keine Plattform macht Disziplin gratis. Richtlinien müssen weiterhin geschrieben, geschützte Zonen deklariert werden, und jemand trägt weiterhin die Urteilsentscheidungen bei markierten Änderungen. Was eine Plattform ändert, ist der Default. Auf Automo ist der undisziplinierte Weg derjenige, der zusätzliche Mühe kostet, das Gegenteil davon, wie das meiste Tooling funktioniert. In der Praxis entscheidet genau diese Umkehrung darüber, ob die Standards eines Teams den Kontakt mit einer Deadline überleben.