EU AI Act & Regulierung
Beim Vibe Coding geben Sie Verhalten und Architektur vor, den Code schreibt das Modell. Wann sich das lohnt, wo es scheitert und was es kostet.
Vibe Coding heißt: Sie geben vor, was die Software tun soll und wie sie aufgebaut ist. Die Umsetzung – Syntax, Boilerplate, Logikstrukturen – übernimmt ein Large Language Model. Sie schreiben nicht mehr jede Zeile selbst, Sie steuern. Das lohnt sich wirtschaftlich vor allem dort, wo schnelle Ergebnisse zählen, bei Prototypen und in Greenfield-Projekten. Es stößt an Grenzen, sobald reguliert, sicherheitskritisch oder in einem gewachsenen Bestandssystem gearbeitet wird.
Der Begriff klingt nach Spielerei. Ist er aber nicht mehr, sobald man ihn wirtschaftlich betrachtet: Wer weiß, wann Vibe Coding trägt und wann nicht, spart handfeste Entwicklerstunden. Wer es blind einsetzt, produziert teure Nacharbeit. Dieser Beitrag ordnet beides ein – Definition, Wirtschaftlichkeit, Grenzen.
Stichwort: Ich sehe in Beratungsprojekten immer wieder dasselbe Muster. Teams starten euphorisch, weil der erste Prototyp in einem Nachmittag steht. Zwei Wochen später kämpfen dieselben Teams mit Nacharbeit, weil niemand die Grenzen des Ansatzes vorher benannt hat. Genau diese Grenzen stehen weiter unten – nicht um Vibe Coding schlechtzureden, sondern um es gezielt einzusetzen.
Beim klassischen Programmieren schreiben Entwickler jede Zeile selbst oder passen Codeschnipsel gezielt an. Beim Vibe Coding delegieren sie die technische Umsetzung fast vollständig an ein Sprachmodell. Menschen agieren nicht mehr als Autoren einzelner Codezeilen, sondern geben das gewünschte Verhalten und die Architektur der Anwendung vor – der Rest entsteht im Dialog mit dem Modell.
Für die KI ist Code dabei nur eine weitere Sprache, Programmiersprachen sind letztlich Dialekte. Mit der richtigen Instruktion wechselt ein Modell wie Claude Opus in Sekunden die Rolle – vom Unit-Test bis zur TypeScript-Migration. Diese Flexibilität bildet keine feste Personalstruktur ab. Das senkt die Einstiegshürde für Softwareprojekte spürbar: Auch kleinere Unternehmen können komplexere Softwareprodukte in-house realisieren, ohne auf große Standardlösungen mit unzähligen Funktionen zurückzugreifen, die sie nur zu einem Bruchteil nutzen.
Eine vollständige, glossarartige Definition mit Beispiel finden Sie im Beitrag Was ist Vibe Coding?.
Ein häufiger Einwand: Vibe-Coding-Projekte hätten gravierende Sicherheitsmängel. Das stimmt oft – korreliert aber weniger mit der Unfähigkeit der KI als mit der Kompetenz der Person, die sie steuert. Erfahrene Entwickler entlocken einem Modell völlig andere Ergebnisse als jemand, der ein Tool zum ersten Mal bedient. Die Qualität des Outputs bleibt ein Resultat des fachlichen Inputs.
Damit verschiebt sich die Rolle der Entwickler: weg vom Codeautor, hin zum Regisseur. Sie definieren Akzeptanzkriterien, Architekturentscheidungen, Schnittstellenverträge und Risikoabwägungen. Die Maschine liefert den Großteil der Implementierung – aber nur innerhalb der Leitplanken, die Sie vorgeben.
Interessant wird es bei der Frage, wer diese Rolle ausfüllen muss. Die Grundannahme vieler Modelle ist, dass ein Senior-Entwickler die KI steuert – nur dann ist produktionsreifer Code realistisch zu erwarten. In der Praxis zeigt sich aber: Auch Mid-Level-Entwickler mit gut ausgebauter Tooling-Infrastruktur – CI-Pipelines, automatisierte Linting-Regeln, Code-Review-Bots, feste Testrahmen – erzielen ähnlich verlässliche Ergebnisse. Automatisierte Qualitäts-Gates fangen Fehler ab, die im Prompt selbst nicht antizipiert wurden. Gutes Tooling hebt so die effektive Steuerungsqualität an, ohne dass zwingend teureres Personal nötig wird.
Maschinell generierter Code ist besonders sinnvoll, wenn schnell Ergebnisse gebraucht werden – wenn also das „Wie" zweitrangig ist und das Resultat im Vordergrund steht. Drei Muster, in denen Vibe Coding zuverlässig trägt:
Vibe Coding versetzt Unternehmen zudem in die Lage, eigene Softwarekomponenten zu bauen, statt auf große Lösungen mit unzähligen Funktionen zurückzugreifen, die sie nicht brauchen. Der Vendor-Lock-in bricht damit langsam, aber sicher auf. Auch Software-Manufakturen profitieren: Sie können mit Vibe Coding Kundenbedürfnisse abseits ihres Tagesgeschäfts bedienen und so neue Zielgruppen erschließen.
Ökonomisch betrachtet sind Sprachmodelle hervorragende, flexible Generalisten – solange schnelle Rückmeldung verhindert, dass einzelne Iterationen eskalieren. Genau deshalb spielt Vibe Coding seine Stärken dort aus, wo Tests und Tooling zügiges Feedback liefern: Der Eskalationsgrad sinkt, Nacharbeit bleibt kontrollierbar. Fehlt dieses schnelle Feedback, kippt das Bild schnell – dazu mehr im nächsten Abschnitt.
In regulierten, sicherheitskritischen oder stark gekoppelten Systemen wächst nicht nur der Aufwand – vor allem wächst der Aufwand, Korrektheit nachzuweisen. Dort wird das Modell eher zum Helfer als zum Hauptautor.
Starkes Brownfield – also ein gewachsener, komplexer Codebestand – erhöht den Kontextbedarf, das Regressionsrisiko und die Zahl der Integrationsschleifen. Viele Integrationen erzeugen komplexe Fehlerbilder, die selten im ersten Anlauf passen. Volatile, sich ständig ändernde Anforderungen entwerten den Kontext und erzeugen Nacharbeit, wenn kein stabiler Zielkorridor existiert. Fehlende Tests oder Observability machen jede Änderung riskant und treiben den Preis jeder Iteration nach oben.
In solchen Fällen bleibt der Mensch der wirtschaftliche Stabilisator. Architektur, Abwägungen, Sicherheitsdenken und Abnahme lassen sich nicht zuverlässig delegieren. Wer aus regulatorischen Gründen zusätzlich nur Open-Source-Modelle einsetzen darf – etwa in der Verwaltung oder in Air-Gap-Infrastrukturen –, zahlt oft einen messbaren Aufpreis, weil diese Modelle im Schnitt mehr Nacharbeit erzeugen.
Das TBM legt damit eine Trennlinie offen, die weniger zwischen „Code schreiben" und „nicht schreiben" verläuft als zwischen dem, was die Maschine verifizieren kann, und dem, was sie nicht kann. Klare Akzeptanzkriterien, Tests, die invariantes Verhalten beweisen, Architekturentscheidungen, Schnittstellenverträge und Betriebsanforderungen wie Monitoring oder Rollback-Strategien bleiben Aufgabe des Menschen. Innerhalb dieser Leitplanken kann die Maschine dann den Großteil der Implementierung liefern.
Bei professionellen Projekten bewegen sich die reinen Tokenkosten meistens im Rahmen von 3.000 bis 15.000 Euro – oft deutlich darunter, je erfahrener das Team ist, das die KI steuert. Der entscheidende Hebel ist dabei nicht der Preis pro Token, sondern die Zuverlässigkeit des eingesetzten Modells: Ein günstiges Modell mit viel Nacharbeit wird schnell teurer als ein teures, verlässliches.
Wie Sie das für Ihr eigenes Projekt grob überschlagen, erklärt der Beitrag Was kostet Vibe Coding? Tokenbudget schätzen. Wer direkt rechnen will, nutzt den TokenBudgetModel-Rechner unter tbm.stefanai.de.
Das wird teurer als gedacht, sobald die Modellwahl eingeschränkt ist: Wer nur Open-Source-Modelle einsetzen darf, weil proprietäre Cloud-Dienste aus Compliance-Gründen ausscheiden, sollte diesen Umstand explizit in die Budgetplanung einpreisen – nicht erst, wenn die Nacharbeit bereits läuft.
Die Landschaft an Vibe-Coding-Tools reicht von agentischen Code-Editoren bis zu App-Buildern für Nicht-Entwickler. Ein neutraler Überblick mit Vergleichstabelle steht im Beitrag Vibe-Coding-Tools 2026: Überblick und Auswahl.
Ist Vibe Coding dasselbe wie Copy-Paste-Programmieren mit ChatGPT? Nein. Beim Copy-Paste-Ansatz bleibt der Mensch Autor einzelner Codezeilen und fügt KI-Vorschläge manuell ein. Beim Vibe Coding übernimmt das Modell die technische Umsetzung weitgehend selbst – der Mensch definiert Verhalten, Architektur und Abnahmekriterien.
Brauche ich Programmierkenntnisse für Vibe Coding? Für Prototypen und einfache Anwendungen nicht zwingend. Für produktionsreifen, professionellen Code schon: Die Qualität des Ergebnisses hängt direkt von der fachlichen Steuerung ab. Ein erfahrener Entwickler holt aus demselben Modell ein deutlich besseres Ergebnis heraus als ein Laie.
Eignet sich Vibe Coding für produktive Unternehmenssoftware? Ja, unter Bedingungen: klare Akzeptanzkriterien, Tests, Architekturentscheidungen und Sicherheitsprüfungen bleiben Aufgabe des Menschen. Ohne diese Leitplanken entsteht Code, dessen Korrektheit niemand belegen kann.
Was ist der größte Unterschied zwischen Vibe Coding in Greenfield- und Brownfield-Projekten? In Greenfield-Projekten ist der Kontext klein und überschaubar, Fehler zeigen sich schnell und lassen sich günstig korrigieren. In Brownfield-Projekten mit vielen Integrationen und Altlasten wächst der Kontextbedarf, und jede Änderung birgt Regressionsrisiko – das treibt Aufwand und Kosten deutlich nach oben.
Wie hängen Vibe Coding und Kosten zusammen? Über das sogenannte Tokenbudget: Je nach Modellqualität, Projektkomplexität und Integrationsanzahl variieren die Kosten stark. Details und ein Rechenbeispiel liefert der Beitrag zu Vibe-Coding-Kosten und Tokenbudget.
Stefan Müller ist Referent, Berater und Software-Entwickler bei StefanAI – Research & Development. Er unterstützt Unternehmen und öffentliche Einrichtungen beim sicheren und produktiven Einsatz von KI. www.stefanai.de
"Ich schicke regelmäßig kostenlose Updates zum Thema KI, Sicherheit und Anwendungen."
Wählen Sie direkt einen freien Slot in meinem Kalender.
Schreiben Sie mir Ihr Anliegen — ich melde mich zeitnah.
