Vor ungefähr 15 Jahren haben wir AngularJS in ein Projekt eingebaut. Die Gründe waren solide: ein modernes UI-Framework, aktive Community, gute Dokumentation. Und Google dahinter — was soll schon passieren.

Ich habe es durchgewunken.

Im Laufe der Zeit ging das Wissen über die Integration verloren. Das Team veränderte sich. Neue Entwickler kamen, andere gingen. AngularJS war tief verwachsen mit der gesamten UI-Schicht — nicht als saubere Abhängigkeit, sondern als strukturelle Grundlage. Jede View, jede Komponente, jeder Datenbindungs-Mechanismus hing daran.

Dann kam Angular 2. Komplett inkompatibel. Kein Migrationspfad. Keine Abwärtskompatibilität.

Plötzlich saßen wir auf einem Framework ohne Zukunft — und ohne einfachen Weg raus. Was folgte, waren fünf Jahre Workarounds: Abstraktionsschichten, Sonderlösungen, Parallelstrukturen. Am Ende hat uns das über 100.000 Euro gekostet. Nicht für die Migration selbst — sondern für die Jahre, in denen wir das Problem mitgeschleppt haben, weil ein Umbau immer zu teuer, zu riskant, zu aufwändig erschien.

Der eigentliche Fehler war nicht AngularJS. AngularJS war zum Zeitpunkt der Entscheidung eine vertretbare Wahl. Der Fehler war, dass die Entscheidung implizit getroffen wurde. Kein Architektur-Review, keine dokumentierte Begründung, keine Exit-Strategie. Es hat funktioniert — also blieb es drin. Und ich habe nicht nachgefragt.

Diese Geschichte ist kein Einzelfall. Eine breit angelegte Studie mit über 1.800 Software-Praktikern aus drei Organisationen kam zu einem Ergebnis, das jeder erfahrene CTO aus dem Bauch heraus bestätigen wird: Architektur-Entscheidungen sind die größte Quelle technischer Schulden. Nicht weil sie häufiger falsch sind als andere Entscheidungen — sondern weil die zeitliche Distanz zwischen Entscheidung und Konsequenz so groß ist. Wenn der Fehler sichtbar wird, ist die ursprüngliche Begründung längst verloren.

Das ist kein KI-Problem. Das war schon vor KI so.

In jedem Team, das ich in 30 Jahren geführt habe, gab es Architektur-Entscheidungen, die niemand bewusst getroffen hatte. Sie waren einfach passiert — im Alltag, unter Zeitdruck, weil eine Lösung funktionierte und niemand die Frage gestellt hat, was passiert wenn sich die Voraussetzungen ändern.

Was sich verändert hat, ist nicht das Muster. Es ist die Geschwindigkeit.

Ein Forschungsteam hat Anfang April 2026 ein Paper veröffentlicht, das genau dieses Phänomen untersucht. Der Titel: „Architecture Without Architects." Die zentrale Beobachtung: KI-Coding-Agenten wählen Frameworks, scaffolden Infrastruktur und verdrahten Integrationen — oft in Sekunden. Das sind Architektur-Entscheidungen. Aber fast niemand behandelt sie als solche.

Die Forscher haben fünf Mechanismen identifiziert, durch die Agents implizite Architektur-Entscheidungen treffen, und einen Begriff dafür geprägt: „Vibe Architecting" — Architektur, die durch Prompts entsteht statt durch bewusstes Design.

Ein konkretes Ergebnis aus dem Paper macht das greifbar: Dieselbe Aufgabe — ein Customer-Service-Chatbot — wurde mit drei unterschiedlich formulierten Prompts an Claude Code gegeben. Gleiche Anforderung, gleiche Rahmenbedingungen, gleicher Agent. Das Ergebnis: drei völlig unterschiedliche Systemarchitekturen. Von 141 bis 827 Codezeilen. Von zwei bis sechs Dateien. Unterschiedliche Frameworks, unterschiedliche Datenbankanbindungen, unterschiedliche Integrationspatterns.

Niemand hat diese Architektur-Entscheidungen bewusst getroffen. Der Prompt hat sie impliziert. Der Agent hat sie umgesetzt.

Claude Code schlägt eine Library vor. Cursor wählt ein Pattern. Lovable bindet einen Service ein. Der Entwickler prüft, ob es funktioniert — meistens tut es das.

Entscheidung gefallen.

Ich finde das nicht bedrohlich. Es ist nachvollziehbar. Architektur-Entscheidungen wurden schon immer am leichtesten implizit getroffen. Kein Entwickler setzt sich morgens hin und denkt: „Heute treffe ich eine schlechte Architektur-Entscheidung." Es passiert einfach — weil etwas funktioniert und der nächste Task wartet.

KI beschleunigt diesen Effekt auf drei Ebenen: Agents erzeugen Entscheidungen schneller, als Teams sie validieren können. KI-Empfehlungen tragen einen impliziten zeitlichen Horizont — eine Library-Empfehlung spiegelt den Zustand zum Trainingszeitpunkt wider, nicht zum Zeitpunkt des Deployments. Und das Ökosystem selbst explodiert: GitHub verzeichnet mittlerweile über 4,3 Millionen KI-bezogene Repositories, ein Anstieg von 178 Prozent im Jahresvergleich. Die Optionsliste, aus der ein Agent wählen kann, wächst schneller als jede menschliche Bewertungskapazität.

Aber die Geschwindigkeit ist nur ein Teil. Der andere Teil ist die Unsichtbarkeit.

Architektur-Fehler sind keine Bugs. Bugs findest du beim nächsten Test-Run. Eine falsch gewählte ORM-Library ist kein Zwei-Stunden-Fix. Ein Service-Coupling, das in Monat eins „praktisch" war, ist in Monat zwölf das größte Refactoring des Jahres. Genau wie bei AngularJS: nicht die Entscheidung war das Problem. Die fehlende Dokumentation war das Problem. Und die fehlende Exit-Strategie.

Es gibt einen konkreten Moment in jeder Agentic-Coding-Session, in dem die wichtigste Arbeit passiert — und die meisten Entwickler überspringen ihn.

Es ist der Moment zwischen dem Setup-Vorschlag des Agents und dem Beginn der eigentlichen Implementierung.

Der Agent hat sein Scaffolding gemacht. Frameworks gewählt. Libraries eingebunden. Patterns vorgeschlagen. Alles sieht gut aus. Alles funktioniert. Der nächste Schritt wäre: anfangen zu bauen.

Genau hier ziehe ich die Grenze.

Nicht als formalen Prozess. Nicht als Architektur-Review mit Komitee. Sondern als einen bewussten Moment: Was hat der Agent gerade entschieden? Welche Libraries sind drin? Welche Patterns wurden gewählt? Wovon hängen wir jetzt ab?

Einmal sichtbar machen. Einmal bewusst entscheiden.

Das klingt trivial. Aber es ist der Unterschied zwischen „wir wissen warum das so gebaut wurde" und „wir haben keine Ahnung, aber es läuft seit drei Jahren so."

Dieser Moment ist der letzte Moment, in dem Änderungen noch nichts kosten. Die Library austauschen, bevor tausend Zeilen darauf aufbauen. Das Pattern hinterfragen, bevor es zum Standard wird. Die Abhängigkeit prüfen, bevor sie sich durch das ganze System zieht.

Danach wird es teuer. Das weiß ich. Das hat mich 100.000 Euro gelehrt.

Hier wird die Geschichte eigentlich ermutigend.

Vor zehn Jahren hätte die Bewertung einer Library einen halben Tag Recherche bedeutet: GitHub-Issues durchlesen, Release-History prüfen, Community-Foren nach bekannten Problemen durchsuchen, Kompatibilität mit dem eigenen Stack testen. Heute kann ein gut formulierter Prompt diese Recherche in Minuten liefern: Maintenance-Status, Community-Aktivität, bekannte Inkompatibilitäten, Vergleich gegen konkrete Projektanforderungen.

KI erzeugt mehr Optionen als je zuvor. Aber KI kann gleichzeitig dabei helfen, fundierter zwischen ihnen zu wählen.

Der Unterschied liegt im Prompt. „Bau mir das Feature" delegiert die Architektur-Entscheidung an den Agent. „Vergleich mir Library A und B gegen unsere Anforderungen und zeig mir den Maintenance-Status der letzten zwölf Monate" behält die Entscheidung beim Menschen — und nutzt KI für das, was sie besser kann als jeder Mensch: große Mengen an Informationen schnell strukturieren.

Ich lasse mir gerne von AI Architektur und Setup vorschlagen. Das ist der richtige Einsatz. Aber der Vorschlag ist ein Vorschlag — kein Commit.

Die Diskussion über KI und Architektur wird oft als Entweder-Oder geführt: Entweder wir vertrauen KI-Agents oder wir kontrollieren jeden Schritt. Beides geht am Kern vorbei.

Es geht nicht um Vertrauen oder Misstrauen. Es geht um einen einzigen Moment: den Moment zwischen Vorschlag und Implementierung. Den Moment, in dem die Architektur noch formbar ist und Änderungen nichts kosten.

AngularJS war keine schlechte Wahl. Es war eine undokumentierte, nicht hinterfragte Wahl. Das hat sie teuer gemacht. Nicht sofort. Nicht im nächsten Sprint. Sondern fünf Jahre später, als sich die Voraussetzungen geändert haben und niemand mehr wusste, warum das System so gebaut wurde, wie es gebaut wurde.

Ein Agent, der heute eine Library einbindet, trifft keine schlechte Entscheidung. Er trifft eine implizite Entscheidung. Und implizite Entscheidungen werden teuer.

Nicht heute. Nicht morgen.

Aber der Tag kommt. Und dann ist es gut, wenn jemand nachgefragt hat.