Hauptgedanke

Dateien, die zu groß werden, fehlende Tests, Fachlogik, die über die Endpunkte verstreut ist, Architekturen, die für den Bedarf zu kompliziert sind, Neuentwicklungen, die man vor sich herschiebt: Nichts davon ist mit den Entwicklungsassistenten aufgekommen. Teams bauten schon vorher eine Kathedrale, um ein Regal anzubringen, und Unternehmen verwechselten schon vorher Delivery-Geschwindigkeit mit echtem Wert.

Was sich ändert, ist also nicht die Art der Mängel, sondern das Tempo, in dem sie entstehen. Ein Assistent beschleunigt, was ohnehin schon zu schnell lief, macht unsichtbarer, was ohnehin schon schlecht verstanden war, und erlaubt es, in wenigen Stunden Entscheidungen aufeinanderzustapeln, die niemand wirklich getroffen hat.

Die Folge: Ein System kann heute eine äußerliche Reife zeigen, ohne die Schritte durchlaufen zu haben, die sie gewöhnlich hervorbringen. Der Mangel ist nicht neu; neu ist, dass er sich inzwischen schneller anhäuft, als das Verständnis des Teams mitwächst.

Warum das wichtig ist

Das verschiebt die Diagnose. Wer diese Mängel dem Werkzeug zuschreibt, sucht ein besseres Werkzeug oder verbietet seinen Einsatz; wer sie als alte, verstärkte Krankheitsbilder erkennt, rüstet die Mechanismen wieder auf, die sie schon früher nur mühsam eindämmten — Review, Architekturabwägung, Tests, ausdrückliche Entscheidung.

Es liefert auch eine Lesart für Projekte, die schnell verfallen: Nicht die Codegenerierung hat sie brüchig gemacht, sondern der Umstand, dass sie die Frist beseitigt hat, in der sich die Brüchigkeit noch beheben ließ.

Ergänzt durch „Vier Tage vibe coding…“ (2026-07-28). Aus der Nähe beobachtet, über vier Tage Bauarbeit hinweg, nimmt der Mechanismus eine genaue und wiederkehrende Form an. Eine Datei beginnt vernünftig, schwillt dann an, bis sie ein bisschen alles erledigt, und die Kosten zeigen sich drei Tage später, wenn man sie ändern muss. Die Schichten vermischen sich, weil nichts dazu zwingt zu entscheiden, wohin die Fachlogik gehört. Eine API, die dreißigtausend Elemente zurückgibt, wird behandelt wie eine, die zweihundert zurückgibt. Keine dieser Handlungen ist neu; neu ist, dass sie sich in wenigen Stunden anhäufen und die Demo trotzdem gelingt. Der Mechanismus reicht auch über den Code hinaus: Werkzeuge, die irgendwo im Stillen entstehen, ohne Wartung und ohne Governance, sind ein Problem, das Unternehmen seit den Tabellenkalkulationen und Makros kennen — auch das erfindet der Assistent nicht, er senkt die Einstiegshürde und damit die Zahl der Objekte, die diesen Weg nehmen.

Nuancen und Grenzen

Der Maßstabswechsel ist nicht neutral: Ab einem gewissen Durchsatz wird aus einem Unterschied der Menge ein Unterschied der Art, weil die menschlichen Kontrollmechanismen — gegenlesen, diskutieren, abwägen — nicht derselben Kurve folgen.

Und manche disziplinierten Teams erzielen die umgekehrte Wirkung: Derselbe Assistent schreibt die Tests, trennt die Fachdomäne von der technischen Infrastruktur und schlägt eine einfachere Lösung vor, sobald man ihn ausdrücklich darum bittet. Was er von selbst tut und was er kann, sind zwei verschiedene Dinge.

Offene Fragen

• Ab welchem Produktionsdurchsatz sind die menschlichen Kontrollmechanismen nicht mehr ausreichend bemessen, und wie misst man das vor dem Vorfall?