Wo Vibe Coding an seine Grenzen stößt

Ich habe in den letzten Monaten vier sehr unterschiedliche Arten von Software gebaut. Sie markieren, wie ich finde, ziemlich genau die Grenze zwischen Vibe Coding und KI-Software-Engineering.

Software ist nicht gleich Software

Was ich damit meine veranschaulichen vier Projekte. Das einfachste: Eine Webseite für ein Sommerfest. Eine dynamische einseitige HTML-Seite, gebaut mit Claude, ausgespielt über Netlify. Aufwand: rund 20 Minuten. Es brauchte nichts außer einem klar strukturierten Prompt. Das ist Vibe Coding in Reinform – und es funktioniert hervorragend.

Die zweite Software: AngelDesk.vc, ein Screening-Tool, das aus einer Start-up-URL in 45 Sekunden eine strukturierte Analyse erstellt, inklusive Marktposition, Wettbewerb und Bewertungsindikatoren. Eine einfache Web-App mit Anbindung an ein Large-Language-Modell, Benutzer:innen-Verwaltung (User Management)  und eigener Datenbank. Aufwand: etwa eine Woche, nebenbei, gemeinsam mit dem Asset Manager inVenture Capital. Knapp 1.000 Mini-Due-Dilligences mehrerer hundert Investitionen liefen in den ersten Wochen bereits über das Tool. 

Das dritte: Sembla, eine Multi-Tenant-Web-App mit komplexen Discovery-Queries, eigener Datenhaltung und Nutzer:innenverwaltung. Ich habe diese zunächst für mich selbst gebaut, aber bewusst als Multi Tenant. Auch um zu prüfen, wie gut ich bereits Unternehmenssoftware mit KI bauen kann.

Das vierte: mein eigenes Betriebssystem bei Apoera – ein Verbund aus Apps, Projekten und Agenten, lose integriert, mit eigenen Datenbanken. Projekt Drei und Vier entwickle ich bereits seit rund drei Monaten weiter, zugegeben mit sehr wenig Zeiteinsatz pro Tag.

Die erste Erkenntnis: Zwischen der Party-Website und der Enterprise-Architektur liegen Welten. 

1. Meine These: Vibe Coding endet dort, wo die Kosten eines Fehlers größer als die Kosten eines Neustarts sind.
2. Wartbarkeit und laufender Betrieb tiefe Einblicke in die Architektur erfordern

Das richtige Setup für die richtige Software

Bei der Party-Website ist der schlimmste Fall: Ich werfe sie weg und baue sie neu. Zwanzig Minuten verloren. Datenverlust gleich null. Das benötigte Kontextfenster: überschaubar. 

Bei einer Unternehmenssoftware: viel komplizierter. Es gibt viele Funktionalitäten. Das Kontextfenster wird schnell sehr groß. Fehler in der Architektur haben Folgefehler zur Folge. Irgendwann wird das Aufräumen sehr aufwändig. Das Neustarten aber auch. 

Wenn ich eine App schnell und für mich baue, ist das Risiko von „Einstürzen und Neubauen“ überschaubar. Das gilt aber nicht, wenn ich eine Software raus bringe und die an Kund:innen verkaufen möchte. 

Diese Kund:innen möchten sich bei jeder zukünftigen Entwicklung darauf verlassen, dass

1. ihre Applikation sicher und stabil läuft und online bleibt
2. ihre Daten auch nach einem Versionswechsel bleiben
3. der/die Anbieter:in Fragen zu Fehlern beantworten kann

Viele Applikationen, die vibe coded wurden, erfüllen diese Kriterien nicht. Ihre „Schöpfer“ verstehen das Innere der Software nicht mehr. Die Software, die schnell mal „geshipped“ wurde, wird zu einer Black-Box für ihren Herausgeber. 

Bei einer Multi-Tenant-Anwendung mit echten Nutzerdaten ist der schlimmste Fall ein Datenleck, ein Compliance-Verstoß, ein Vertrauensbruch. Ab diesem Punkt reicht es nicht mehr, dass die KI Code *schreiben* kann. Jetzt braucht es das, was Software Engineering immer ausgemacht hat: Anforderungsmanagement, Architektur, Sicherheit, Reichweiten-Kontrolle.

Das Zeitalter des AI-enabled Requirement Engineering

Nachdem die Iterationsgeschwindigkeit in der letzten Dekade für agile Projektmethoden gesprochen hat, sorgt KI jetzt auch dafür, dass die Planung selbst viel schneller iterieren kann. Ein gutes Fachkonzept zu schreiben, wird viel einfacher. Vieles, was früher nicht getestet werden konnte ohne eine fertige Software, wird heute früher testbar. Das Requirements Engineering – die Kunst der Anforderungserfassung, ist vielleicht fast genauso stark durch KI befähigt wie das eigentliche Coding selbst.

Also kurz: KI befähigt die Projektplanung und das Projektmanagement. 

Und das ist die überraschende Erkenntnis: Diese Disziplinen verschwinden mit KI nicht. Sie werden selbst zu Agenten.

Mein persönliches Builder-System

Für alles, was über den Prototyp hinausgeht, habe ich mir ein Setup gebaut, das ich das „Builder-System" nenne. Es bildet die klassischen Rollen eines KI-Projektes oder Agenten mit eigenem Briefing, eigenen Standards und eigenen Zugriffsrechten. Wer je ein IT-Projekt in einer Bank verantwortet hat, wird die Besetzungsliste wiedererkennen:

Der Requirements Engineer und Scope-Manager schreibt und iteriert saubere Spezifikationen nach Best Practices. Er arbeitet mit Blueprints, einer festen Fragemethodik und definiert „Definition of Done" sowie Testkriterien. Was ist neu daran? Der automatisierte Zugriff auf die Code-Basis erlaubt eine laufende, technisch versierte Prüfung: Ist der Code noch in Einklang mit den Anforderungen? In meiner persönlichen Erfahrung ist Scope Drift eine der größten Projektrisiken. Und auch bei KI ist das ein übliches Phänomen: Agenten bauen gern mehr, als bestellt wurde. Scope Creep gibt es auch bei Maschinen – nur noch schneller. Und oft bleibt „ungenutzer Code“ zurück, weil refactoring nicht gefragt ist.

Das klingt banal, ist aber der größte Hebel: Die meisten fehlgeschlagenen Vibe-Coding-Projekte scheiterten nicht am Code, sondern daran, dass niemand präzise aufgeschrieben hat, was eigentlich gebaut werden sollte.

Der Complexity Challenger ist eine neue Rolle, die es in klassischen Projekten viel zu selten gibt: Er greift die Spezifikation an, bevor gebaut wird. Welche Anforderung treibt die Komplexität? Was kostet dieses Feature wirklich und braucht es das? Ein Agent, dessen einziger Job es ist, Komplexität zu reduzieren, wo sie den Nutzen nicht dezimiert. Dieses Projekt hat neun Din-A4-Seiten an Text mit möglichen Komplexitätstreibern wie zum Beispiel im Rollen- und Rechtemanagement, der Speicherung von Daten, Schnittstellen und vielem mehr. 

Der Architekt entscheidet über Performance, Kosten und Sicherheit der Architektur – mit direktem Zugriff auf die Datenbankebene. Er kennt die sogenannten nicht-funktionalen Anforderungen an Ladegeschwindigkeit, Wirtschaftlichkeit von Rechenzeit und so weiter. Architekturentscheidungen sind die teuersten Entscheidungen im Projekt. So zum Beispiel macht ein Zwischenspeichern bereits beantworteter Abfragen einen hohen Unterschied für Nutzerzufriedenheit (bereits angelegte Start-ups laden 60 Mal schneller vs. neue Start-ups) und Token-Konsum (Einsparung einiger Cents pro Abfrage). 

UX & Frontend Design baut das Designsystem auf Basis definierter Standards: UX Best Practices, Corporate Design, Referenzbeispiele. Hier hat zum Beispiel Claude.ai/design mittlerweile tolle Fähigkeiten vorgefertigt, aus denen man wählen kann. Ein riesiger Lerneffekt war: Lieber früh ein sehr standardisiertes Briefing zum Design abgeben. Neben Farbschema auch Themen wie Abstände, genutzte Objekte, grafischer Stil und so weiter so eng wie möglich definieren. KI hat sonst ein Konsistenzproblem zwischen den einzelnen Seiten einer Applikation. Und selbst kleinere Inkonsistenzen in der Optik kosten bei dem Endnutzer Vertrauen.

Der Developer verwandelt Spezifikation und Design in echten, auslieferbaren Code – mit definierter Sprache, geregelten Datenbank- und Schnittstellenzugriffen und Repository-Zugang. Da diese Rolle schon von vielen guten Leuten detailliert beschrieben wird, gehe ich hier nicht tiefer ein. Ich nutze hier persönlich Claude Code im Terminal. 

Der CISO prüft die Anwendung aus Sicherheitsperspektive. Als eigenständige Rolle, nicht als Nebensatz im Entwickler-Prompt. Gerade für die Payment- und Banking-Welt dürfte das der entscheidende Punkt sein: Security als separate, unabhängige Instanz im Prozess, nicht als nachgelagerter Check. Ob mein Ansatz, dafür bewusst ein anderes Modell zu nutzen (bei mir kontrolliert ChatGPT Claude), wirklich notwendig ist, weiß ich nicht. 

Ship übernimmt finale Prüfroutinen und das „Verpacken der Applikation“ abhängig von dem Ausspielungsprozess.

Da ich bis dato keine Software an Kund:innen verkaufe, möchte ich die nächsten zwei Rollen nur schon mal als notwendig anmerken, ohne sie, Stand heute, selber gebaut zu haben. 

Operator: Das System und sein Verhalten zu verstehen und zu überwachen, ist das, was Verfechter des Vibe Codings ausblenden. Als seriöser Anbieter von Software, muss es der Anspruch sein, Fehler zu erkennen, bevor der Kunde/die Kundin es tut. Wenn Dich Dein(e) Kund:in anruft und Dir sagen muss, dass Deine Applikation nicht verfügbar ist oder starke Fehler hat, dann hat Dein Operations-Prozess versagt. Ungewöhnliches Verhalten, Nichtverfügbarkeiten der eigenen Applikation oder relevanter Schnittstellen, fehlerhafte Daten und so weiter . muss ein gut geschultes System erkennen. 

Support: Die Aufnahme von Vorfällen bei Kund:innen und Partner:innen und der automatisierte Check up des Fehlers ist eines der großen, noch zu wenig diskutierten, Potentiale von KI. Ich glaube, dass es es hier noch ein massives Potential gibt, Anwender:innensupport durch applikationskundige KI massiv zu verbessern und dadurch Antwort- und Fehlerbehebungszeiten massiv zu reduzieren. 

Vibe Coding ist kein Allheilmittel

Erstens: Die Frage ‚Können wir das nicht einfach vibe-coden?" ist legitim - aber sie braucht eine ehrliche Antwort entlang der Komplexität. Interne Tools, Prototypen, Analysen: Vermutlich ja. Alles mit echten Kund:innendaten, Mandantenfähigkeit oder regulatorischer Relevanz: nur mit Engineering-Disziplin.

Zweitens: Diese Disziplin sollte man nicht mehr ausschließlich mit Menschen besetzen. Requirements, Architektur-Review, Security-Prüfung, Scope-Kontrolle – all das lässt sich als agentische Rollen aufsetzen, mit klaren Briefings und begrenzten Rechten. Das Projektmanagement der Zukunft ist weniger die Koordination von Menschen und mehr das Design eines Rollensystems.

Meine Überzeugung aus den letzten vier Monaten: Wer komplexe Software für Dritte baut, sollte vor seiner ersten Live-Version von Vibe Coding auf ein AI-enabled Software Engineering and Operations Prozess umstellen.