Vibe Coding hat Grenzen – Ihre Architektur sollte keine haben

Zwei Stunden bis zum Prototyp, drei Monate bis zum Stillstand

Eine Gründerin beschreibt ihrer KI eine App. Zwei Stunden später läuft ein Prototyp mit Login, Datenbank und Dashboard. Drei Monate und einige hundert Prompts später dauert jede kleine Änderung Tage, neue Funktionen brechen alte, und niemand kann erklären, warum dieselben Daten an drei Stellen liegen. Die KI auch nicht.

Das ist kein Versagen der KI, sondern die Grenze dessen, was Andrej Karpathy Anfang 2025 „Vibe Coding“ getauft hat: beschreiben, was man will, und übernehmen, was kommt, ohne den Code zu verstehen.

Meine These: KI beschleunigt das Schreiben von Code, aber nicht das Treffen von Architekturentscheidungen. Wer beides verwechselt, gewinnt Wochen und verliert Monate.

Wo Vibe Coding endet

Für schnelle Prototypen ist Vibe Coding großartig. Soll die Software wachsen und lange leben, zeigen sich die Grenzen:

• Kein Gedächtnis. Jeder Prompt wird für sich optimiert. Bald gibt es drei Arten der Fehlerbehandlung, und auf die Frage „Warum ist das so gebaut?“ antwortet niemand mehr.
• Kein Blick aufs Ganze. Abhängigkeiten wachsen, ohne dass jemand sie gewählt hat.
• Unsichtbare Qualität. Performance, Sicherheit und Datenschutz entstehen nicht nebenbei.
• Keine Verantwortung. Für Datenpannen und Ausfälle haftet immer ein Mensch.

Das Problem ist nicht, dass eine KI Code schreibt. Das Problem ist, dass niemand die Architektur führt.

Die Kette: vom Backlog zum Architektur-Inkrement

Agile Entwicklung liefert alle Stationen bereits. Sie müssen nur um bewusste Architekturentscheidungen ergänzt werden, bevor die KI Code schreibt.

1. Product Backlog: Qualität sichtbar machen. Qualitätsanforderungen wie Antwortzeiten, Datenschutz oder Offline-Fähigkeit stehen als eigene Einträge oder Akzeptanzkriterien im Backlog. Was dort fehlt, baut auch keine KI.
2. Refinement: Architektur-Impact markieren. Braucht die Story eine neue Komponente, Schnittstelle, Abhängigkeit oder ein geändertes Datenmodell? Ein Label genügt.
3. Sprint Planning: erst entscheiden, dann bauen. Markierte Stories kommen erst in den Sprint, wenn die Entscheidung als ADR festgehalten ist (siehe Kasten). Die KI liefert Varianten und den Entwurf, das Team entscheidet. Das ist Teil der Definition of Ready; offene Fragen klärt vorher ein kurzer Spike.
4. Umsetzung: Die KI arbeitet gegen Leitplanken. Sie bekommt ADRs, Schnittstellenverträge (z. B. OpenAPI) und Projektkonventionen als festen Kontext. Tests kommen zuerst, Aufgaben sind klein: nicht „baue Feature X“, sondern „implementiere diesen Endpunkt gemäß Contract“.
5. Review und Definition of Done: Architektur prüfen. Werkzeuge wie deptrac (PHP) oder ArchUnit (Java) verhindern verbotene Abhängigkeiten, Menschen prüfen die Struktur. Weicht der Code vom ADR ab, wird eines von beiden bewusst angepasst.
6. Delivery: Jedes Release ist ein Architektur-Inkrement. Von jeder Story führt ein Faden über ADR, Code und Test bis zum Release. Das Feedback fließt zurück ins Backlog.

Was in regulierten Branchen wie Automotive seit Jahren Pflicht ist, wird mit KI für alle relevant: nachvollziehbare Architektur, mit geringem Aufwand, wenn man sie von Anfang an einplant.

Kurz erklärt: Architecture Decision Records (ADR)

Ein ADR hält genau eine Architekturentscheidung fest, meist auf weniger als einer Seite: Titel, Status, Kontext, Entscheidung, Konsequenzen. Das Format geht auf Michael Nygard (2011) zurück. ADRs liegen nummeriert als Markdown-Dateien im Repository neben dem Code und werden nie gelöscht: Ändert sich eine Entscheidung, ersetzt ein neuer ADR den alten. Sinnvoll sind sie für Entscheidungen, die mehrere Komponenten betreffen oder schwer umkehrbar sind.

# ADR-007: OpenAPI-Contract als einzige Schnittstellendefinition

Status: akzeptiert

Kontext: Laravel-Backend und Flutter-App entstehen parallel und
überwiegend KI-gestützt. Ohne gemeinsame Vorlage driften sie auseinander.

Entscheidung: Jede Schnittstelle wird zuerst als OpenAPI-Spezifikation
beschrieben. Keine Endpunkte ohne Contract.

Konsequenzen:
+ Backend und App bleiben konsistent; die KI hat eine eindeutige Vorlage.
- Jede Schnittstellenänderung kostet einen zusätzlichen Schritt.

In der Praxis erzeugt die KI aus diesem Contract Controller, Validierung und Tests in Laravel sowie Modelle und API-Client in Flutter. deptrac schlägt Alarm, wenn ein Controller die Service-Schicht umgeht. Der ADR ist damit das Gedächtnis des Projekts, das der KI sonst fehlt: Was darin steht, kann sie einhalten.

Die KI als Sparringspartner im Architekturdesign

Die KI trifft keine Architekturentscheidungen, aber sie macht sie besser:

1. Varianten erzeugen: zwei bis drei Lösungswege, bewertet gegen die Qualitätsziele aus dem Backlog statt gegen allgemeine Best Practices.
2. Die bevorzugte Lösung angreifen: Was passiert bei Last, Netzausfall oder einem Angreifer? Welche Annahme ist am wackeligsten?
3. Gegen frühere ADRs prüfen: Widersprüche findet die KI schneller als jedes Teammitglied.
4. ADR und Prüfregeln entwerfen: vom ADR-Entwurf bis zu deptrac-Regeln, die die Entscheidung automatisch absichern.
5. Erosion aufdecken: den Ist-Code regelmäßig mit der Soll-Architektur vergleichen und Diagramme als Code aktuell halten.

Ein bewährtes Prompt-Muster: „Hier sind unsere Qualitätsziele und ADRs. Schlage drei Varianten vor, bewerte jede gegen diese Ziele, nenne ihre größte Schwäche und sage, was wir heute noch nicht entscheiden müssen.“

Die Grenze: Die KI kennt weder Budget noch Team noch Strategie, neigt zu gängigen Mustern und klingt auch dann überzeugend, wenn sie irrt. Deshalb entscheidet das Team, nur eben informierter.

Wer führt was?

Entwickler werden nicht überflüssig. Ihre Arbeit verschiebt sich vom Tippen zum Entscheiden, Prüfen und Verantworten.

Aufgabe	Wer führt	Wie die andere Seite hilft
Architekturentscheidungen	Team	KI entwirft Varianten, greift sie an, prüft gegen frühere ADRs
Schnittstellen und Datenmodell	Team	KI entwirft Contracts und Modelle
Implementierung und Tests	KI	Mensch schneidet Aufgaben und legt Prüffälle fest
Code-Review	Mensch	KI prüft vorab auf Konventionen und Fehler
Verantwortung und Freigabe	Mensch	–

Für Teamleads: Juniors brauchen weiterhin Aufgaben, an denen sie Architektur verstehen lernen. Wer nur durchwinkt, verlernt das Urteilen.

Was bedeutet das für Sie?

Sie führen KI-Coding im Entwicklerteam ein?

Im Workshop richten wir den Ablauf aus diesem Beitrag für Ihr Team ein: Backlog mit Qualitätszielen, ADRs, Kontextdateien und automatische Architekturprüfungen.

Ihre Daten dürfen das Haus nicht verlassen?

Für Beratungsstellen, Praxen, Kirchen und gemeinnützige Organisationen baue ich KI-Anwendungen mit lokalen Modellen auf eigener Hardware. Die technische Lösung kommt von mir, die rechtliche Bewertung bleibt bei Ihrem Datenschutzbeauftragten.

Gespräch über lokale KI

So arbeite ich

Ich entwickle selbst und setze KI dabei konsequent ein. Die Architektur führe ich bewusst: mit ADRs, klaren Schnittstellen und automatischen Prüfungen. KI-gestützte Code-Reviews nutze ich auch für bestehende Systeme, etwa um Sicherheitslücken in WordPress- und Joomla-Installationen und ihren Erweiterungen aufzuspüren. Meine Erfahrung aus der Qualitäts- und Prozessarbeit in regulierten Branchen bringe ich in schlanker Form mit. Und ich sage ehrlich, wo KI hilft und wo nicht.

Fazit: Kontrolle macht Tempo nachhaltig

KI ist ein extrem schneller Entwickler ohne Gedächtnis und ohne Verantwortung. Mit einer klar geführten Architektur als Leitplanke vervielfacht sie die Wirkung des Teams, ohne sie das Chaos. Dafür braucht es kein schweres Verfahren: ein paar bewusste Entscheidungen pro Sprint, festgehalten und automatisch geprüft. So bleibt das Tempo des Prototyps auch im fünften Release erhalten.