Vibe Coding vs. Software-Architektur: Warum Governance und „Taste" wichtiger werden

Vibe Coding beschreibt einen Arbeitsstil, bei dem man ein Ergebnis beschreibt und den Code vom Modell erzeugen lässt – ohne ihn Zeile für Zeile zu durchdringen. Für Prototypen, interne Werkzeuge und Wegwerf-Skripte ist das ein enormer Gewinn. In gewachsenen Produktsystemen kippt derselbe Stil schnell ins Gegenteil.

Der Grund ist unspektakulär: Ein Modell optimiert auf die Aufgabe im Kontextfenster, nicht auf die Struktur des Gesamtsystems. Es liefert etwas, das funktioniert. Ob es an der richtigen Stelle sitzt, entscheidet es nicht.

---

1) Was in der Praxis schiefgeht

Öffentliche Erfahrungsberichte aus Produktteams – unter anderem rund um die Arbeit an Basecamp-Produkten, wo DHH und Team offen über KI-gestützte Entwicklung sprechen – benennen wiederkehrende Muster. Unabhängig vom konkreten Projekt sehen wir dieselben vier:

• Duplizierte Logik. Der Agent baut eine neue Hilfsfunktion, weil er die bestehende nicht im Kontext hatte. Nach einigen Wochen existiert dieselbe Regel an vier Stellen – mit drei Abweichungen.
• Verletzte Schichtgrenzen. Datenzugriff landet in der Darstellungsschicht, weil das dort am kürzesten war. Funktioniert – und macht jede spätere Änderung teuer.
• Tests, die die Implementierung abbilden. Der Agent schreibt Tests, die genau das prüfen, was er gebaut hat. Sie werden grün und beweisen nichts über die Anforderung.
• Stille Abhängigkeiten. Zusätzliche Bibliotheken für Kleinigkeiten, ohne dass jemand Wartung, Lizenz und Sicherheitslage bewertet.

Keiner dieser Punkte fällt am ersten Tag auf. Alle vier zeigen sich, wenn ein Umbau nötig wird.

---

2) Warum „Taste" plötzlich ein Produktionsfaktor ist

Wenn Codeerzeugung günstig wird, wird Auswahl der Engpass. Und Auswahl braucht ein Urteil, das nicht im Code steht: Passt dieses Modell zur Domäne? Ist diese Abstraktion in einem Jahr noch verständlich? Ist die einfachere Variante trotz geringerer Flexibilität die bessere?

Das ist gemeint, wenn Entwickler von Taste sprechen: nicht Geschmack im dekorativen Sinn, sondern die Fähigkeit, aus mehreren funktionierenden Lösungen die tragfähige zu erkennen. Genau diese Fähigkeit beschreibt das Glossar als Differential Evaluation – und sie ist trainierbar, aber nicht delegierbar.

---

3) Leitplanken, die in KI-gestützter Entwicklung wirklich tragen

A) Architektur explizit machen

Was im Kopf der Senior-Entwicklerin liegt, sieht ein Agent nicht. Schichten, erlaubte Abhängigkeitsrichtungen, Namenskonventionen, Zuständigkeiten je Modul gehören schriftlich in das Repository – kurz, aktuell und maschinenlesbar. Das ist keine Bürokratie, sondern Kontext.

B) Regeln automatisiert erzwingen

Alles, was ein Linter, ein Architekturtest oder eine Schema-Prüfung durchsetzen kann, gehört dorthin. Menschliche Reviews sollten über Entwurf und Angemessenheit entscheiden, nicht über Importpfade.

C) Tests gegen Anforderungen, nicht gegen Implementierung

Vorgabe: Der Test wird aus der Anforderung geschrieben, bevor der Agent implementiert – oder mindestens unabhängig vom erzeugten Code geprüft. Grüne Tests, die derselbe Lauf erzeugt hat, sind kein Nachweis.

D) Änderungsgröße begrenzen

Kleine, thematisch geschlossene Änderungen sind prüfbar. Ein Vorschlag über dreißig Dateien wird faktisch nicht gelesen. Wer Agenten einsetzt, braucht deshalb strengere Größenregeln als vorher, nicht lockerere.

E) Produktverständnis im Review verankern

Die wichtigste Reviewfrage ist nicht „läuft das?", sondern „ist das das Richtige?". Diese Frage kann nur jemand beantworten, der das Produkt, die Nutzer und die nächsten zwei Quartale kennt.

---

4) Wo Vibe Coding genau richtig ist

Die Kritik gilt nicht dem Stil, sondern dem Einsatzort. Klar sinnvoll ist er bei:

• Prototypen zur Machbarkeitsprüfung, die danach verworfen werden
• internen Werkzeugen mit lesendem Zugriff und kleinem Nutzerkreis
• einmaligen Datenaufbereitungen und Auswertungen
• Wegwerf-Automationen für eine einzelne Kampagne

Genau dieses Muster beschreibt der Begriff Malleable Software: kurzlebige Werkzeuge, deren Neuerstellung billiger ist als ihre Pflege. Die Grenze verläuft dort, wo Code dauerhaft läuft, echte Daten verarbeitet oder Zusagen an Kunden erzeugt.

---

5) Governance, die nicht ausbremst

Drei Festlegungen genügen für den Anfang:

1. Zonen definieren. Welche Bereiche der Codebasis dürfen agentisch verändert werden, welche nur mit Review durch eine benannte Person?
2. Rechte trennen. Agenten schlagen vor, Menschen übernehmen. Direkte Schreibrechte auf Produktionssysteme bleiben die Ausnahme mit begründetem Fall.
3. Spuren behalten. Auftrag, erzeugte Änderung, Prüfung, Entscheidung – dokumentiert. Das ist gleichzeitig die Grundlage für Audits und für das Lernen im Team.

---

Fazit

KI-gestützte Entwicklung verschiebt Aufwand von Tippen zu Entscheiden. Das macht Architektur nicht unwichtiger, sondern zur entscheidenden Leitplanke: Sie ist der Kontext, ohne den ein Agent zwangsläufig lokal optimiert. Wer Struktur schriftlich festlegt, Regeln automatisiert prüft und Reviews auf Angemessenheit statt Syntax richtet, kann schnell arbeiten, ohne die Basis zu beschädigen.

Weiterführend: Warum der Engpass danach nicht in der Umsetzung liegt, sondern in der Vision, steht in Der neue Flaschenhals in IT-Organisationen.