KI lässt schwache Architektur schneller scheitern.
Dieser Satz gehört für mich zu den wichtigeren in der aktuellen Diskussion über KI und Softwareentwicklung. Nicht, weil er besonders dramatisch klingt, sondern weil er eine Verschiebung beschreibt, die vielen Teams erst auffällt, wenn schon eine Menge Code entstanden ist.
KI ist ein Beschleuniger. Das stimmt.
Aber diese Beschreibung greift zu kurz.
KI ist vor allem ein Verstärker.
KI beschleunigt die Arbeit nicht nur. Sie verstärkt die Systemform, die bereits vorhanden ist.
Hat ein System klare Grenzen, verstärkt KI diese Klarheit. Aufgaben lassen sich leichter zuschneiden. Änderungen bleiben kleiner. Reviews werden konkreter. Tests haben ihren Platz. Fachbegriffe tragen mehr Gewicht. Der nächste Schritt lässt sich leichter erklären, weil das System bereits eine erkennbare Form hat.
Hat ein System schwache Grenzen, verstärkt KI diese Schwäche. An den falschen Stellen entsteht schneller mehr Code. Kleine lokale Lösungen breiten sich im System aus. Begriffe werden uneinheitlich. Zuständigkeiten verschwimmen. Was früher langsam unübersichtlich wurde, wird nun schneller unübersichtlich.
Dieser Punkt geht in der Produktivitätsdebatte oft verloren. Es geht nicht nur darum, wie schnell sich Code schreiben lässt. Entscheidend ist auch, welche bestehende Systemform diese Geschwindigkeit aufnimmt.
Architektur ist Systemdesign über die Zeit
Wenn ich hier von Architektur spreche, meine ich nicht nur Diagramme, Schichten oder die übliche Diskussion darüber, ob etwas ein Monolith oder ein verteiltes System ist.
Architektur ist Systemdesign.
Sie beschreibt, welche Teile Verantwortung tragen. Welche Grenzen wichtig sind. Welche Begriffe stabil bleiben müssen. Wo Variation erlaubt ist. Wo das System bewusst eng zugeschnitten sein sollte. Welche Entscheidungen jetzt getroffen werden müssen und welche offenbleiben können.
Architektur beschreibt auch, wofür ein System gebaut wird.
Software wird selten nur für den Moment gebaut. Manchmal muss sie einfach zuverlässig laufen. Manchmal muss sie wachsen. Manchmal muss sie sich an einen Markt anpassen. Manchmal muss sie erweitert, integriert, abgesichert, betrieben oder an andere Menschen übergeben werden.
Dieser Zeithorizont ist wichtig.
Software wird selten nur für den Moment gebaut. Sie muss über die Zeit etwas tragen.
Ein Wegwerfskript braucht eine andere Architektur als der Kern eines Produkts. Ein internes Werkzeug braucht andere Grenzen als eine öffentliche Plattform. Ein Prototyp kann andere Risiken eingehen als ein System, das Kundendaten verarbeitet. Ein MVP braucht noch nicht die perfekte endgültige Form, aber genug Struktur, damit die nächsten Entscheidungen nicht versehentlich verbaut werden.
Wenn Implementierung günstig wirkt
KI verschiebt diesen Zielkonflikt, weil sich Implementierung plötzlich günstig anfühlt.
Wenn sich eine Idee in wenigen Minuten in Code verwandeln lässt, kann Struktur wie Reibung wirken. Warum Zeit in Grenzen investieren, wenn der nächste Bildschirm, Endpunkt, Adapter oder Test sofort generiert werden kann?
Hier beginnt das Risiko.
Schwache Architektur scheitert selten an einem einzelnen schlechten Commit. Sie scheitert daran, dass viele kleine Entscheidungen in unterschiedliche Richtungen ziehen. Eine Komponente übernimmt ein bisschen zu viel. Ein Service kennt auf einmal Details, die er nicht kennen sollte. Ein Begriff wird in drei Bedeutungen verwendet. Aus einer technischen Abkürzung wird ein Weg, auf dem sich weitere Abkürzungen ansammeln.
KI kann diesen Prozess beschleunigen, weil sie sehr gut darin ist, plausible lokale Lösungen zu erzeugen.
Lokal plausible Lösungen sind nicht automatisch gute Systementscheidungen.
Lokal plausibler Code ist nicht automatisch eine gute Systementscheidung.
Das ist für mich der Kern.
Ein KI-Assistent kann eine Funktion ergänzen. Er kann einen Ablauf umbauen. Er kann einen Fehler beheben. Er kann Tests vorschlagen. Er kann ein vorhandenes Muster aufgreifen und schnell mehr davon erzeugen.
Ist das Muster gut, ist das nützlich.
Ist das Muster schwach, wird auch diese Schwäche vervielfacht.
Ein System mit klaren Modulen, klaren Verträgen und klaren Zuständigkeiten gibt KI bessere Leitplanken. Der Kontext ist kleiner. Die Aufgabe ist stärker eingegrenzt. Im Review lässt sich prüfen, ob die Änderung zur Systemform passt. Das Team kann sagen: Diese Logik gehört hierhin. Diese Entscheidung bleibt dort. Diese Schnittstelle ist die Grenze. Diese Fachregel darf nicht in der UI verschwinden.
Ein System ohne diese Form lässt KI zu viel Raum für plausible Antworten.
Dann arbeitet der Assistent produktiv, aber die Produktivität verteilt sich überallhin. Er legt Code dort ab, wo gerade Kontext verfügbar ist. Er wiederholt Muster, die gerade sichtbar sind. Er optimiert den nächsten Schritt, weil der größere Rahmen unklar ist.
Das fühlt sich zunächst schnell an.
Später wird es teuer.
Nicht unbedingt, weil KI schlechten Code schreibt. Oft ist der einzelne Code in Ordnung. Das Problem liegt eine Ebene höher. Der Code beantwortet die lokale Frage, aber das System verliert seine Form. Architekturprobleme sind keine Syntaxfehler, die man nur aus größerer Entfernung betrachtet. Es sind Entscheidungen über Kopplung, Änderbarkeit, Betrieb, Sicherheit und Fachsprache.
Die Architekturfrage rückt nach vorn
Darum wird Architektur in der KI-gestützten Entwicklung nicht unwichtiger. Sie wird früher sichtbar.
Früher mussten Teams viel Energie aufwenden, um überhaupt eine erste lauffähige Version zu schaffen. Heute entsteht diese erste Version schneller. Damit rückt die eigentliche Frage nach vorn:
Was muss dieses System über die Zeit tragen?
- Muss es nur eine Idee überprüfen?
- Muss es zuverlässig laufen?
- Werden mehrere Menschen es erweitern?
- Wird es externe Integrationen tragen?
- Muss es Sicherheits-, regulatorische oder organisatorische Grenzen einhalten?
- Wird es zum Produktkern, oder soll es bewusst ein kleines Arbeitswerkzeug bleiben?
Das sind Architekturfragen. Sie entscheiden, welche Art von Geschwindigkeit gesund ist.
Ein praktischer Moment aus Projekten
Ein praktisches Beispiel aus meiner eigenen Arbeit: Wenn aus einem Proof of Concept plötzlich ein MVP-Kandidat wird, ändern sich die Maßstäbe. Am Anfang reicht oft ein funktionierender vertikaler Ausschnitt. Ein paar Bildschirme. Ein Ablauf. Ein Signal, dass die Idee funktionieren kann.
Sobald das Ganze weiterleben soll, kommen andere Fragen auf.
- Wie wird es betrieben?
- Wo liegen die Sicherheitsgrenzen?
- Welche Teile dürfen direkt miteinander sprechen?
- Welche Datenflüsse sind kritisch?
- Was passiert, wenn mehrere Menschen gleichzeitig daran arbeiten?
- Welche Adapter sollten austauschbar bleiben?
- Wo sind klare Ports wichtig?
- Welche Entscheidungen gehören in die Anwendung, welche in die Infrastruktur und welche in einen späteren Produktkern?
KI hilft in so einer Situation enorm bei der Geschwindigkeit. Aber sie ersetzt nicht den Rahmen.
Sie macht fehlende Leitplanken sogar sichtbarer. Wenn ich schnell zehn Änderungen erzeugen kann, muss ich noch klarer wissen, ob diese zehn Änderungen in dieselbe Richtung führen. Sonst gibt es sichtbaren Fortschritt und gleichzeitig Drift im System.
Darum ist Architektur für mich auch so eng mit Kontext verbunden.
Architektur muss zum Kontext passen
Gute Architektur ist nicht abstrakt gut. Sie passt. Sie passt zum Problem. Zur Lebensdauer. Zum Risiko. Zum Team. Dazu, wie sich das Produkt voraussichtlich verändern wird.
KI kann dabei helfen, aber sie kennt diesen Kontext nur so gut, wie wir ihn explizit machen.
Bleibt der Kontext diffus, verstärkt KI die Unschärfe.
Ist der Kontext klar, verstärkt KI die Klarheit.
Bleibt der Kontext diffus, verstärkt KI die Unschärfe. Ist der Kontext klar, verstärkt KI die Klarheit.
Das verändert die Rolle von Architekturarbeit. Sie muss weder schwerer noch umfangreicher oder formeller werden. Sie muss expliziter werden.
- Welche Grenzen gelten?
- Welche Begriffe sind zentral?
- Welche Module tragen welche Verantwortung?
- Welche Änderungen sollen einfach sein?
- Welche Risiken werden bewusst akzeptiert?
- Welche Teile sind Prototyp und welche bilden das Fundament?
Diese Fragen müssen nicht alle in einem großen Architekturdokument landen. Oft reichen eine gute Systemübersicht, eine klare Entscheidungsliste, ein paar robuste Tests, saubere Modulgrenzen und ein Team, das dieselbe Sprache verwendet.
Aber irgendwo müssen diese Antworten festgehalten sein.
Sonst füllt KI die Lücken mit Code.
Die Systemform explizit machen
Das ist keine Kritik an KI. Es ist eine Diagnose der Arbeit.
Wenn die Codeproduktion günstiger wird, gewinnen andere Tätigkeiten an Bedeutung: entscheiden, eingrenzen, benennen, zuschneiden, prüfen und in den Kontext einordnen. Dort ist Architektur zu Hause.
KI produktiv einzusetzen heißt nicht, Architekturarbeit zu überspringen. Es heißt, Architektur so konkret zu machen, dass KI innerhalb dieser Form arbeiten kann.
Dann wird Geschwindigkeit zum Hebel.
Ohne diese Form wird Geschwindigkeit zur schnelleren Wiederholung bestehender Schwächen.
KI lässt schwache Architektur schneller scheitern.
Darum braucht schnelle KI-gestützte Entwicklung früh eine stärkere Systemform, nicht erst später.
