Wie verändert KI-basierte Entwicklung Softwarearchitekturen?
Wie verändert die KI-basierte Entwicklung Softwarearchitekturen?
Lange Zeit wurden Softwareprojekte vor allem als Monolithen entwickelt. Mit dem Aufkommen von Microservices begann ein Paradigmenwechsel: Vor allem große Entwicklungsteams setzten darauf, Komplexität in viele unabhängige Dienste zu zerschneiden, microservicebasierte Architekturen waren auf dem Vormarsch. Doch mit dem Einzug KI-gestützter Entwicklung könnten wir gerade einen Kippmoment erleben. Warum die modularen Monolithen für die meisten Projekte die bessere Grundlage sind und wann Microservices trotzdem die richtige Wahl bleiben.
Architekturkonzepte in großen Softwareprojekten: Von Monolithen und Microservices
Über ein Jahrzehnt lang waren Monolithen die selbstverständliche Art, Software zu bauen: eine Anwendung, ein Build, ein Deployment. Für viele Projekte funktionierte das gut, solange die Systeme überschaubar blieben. Mit der Größe der Systeme und der wachsenden Zahl von Entwicklern oder Teams im Projekt stiegen die Reibungsverluste. Änderungen an einer Stelle hatten schwer absehbare Folgen an anderer, und je mehr Entwickler an derselben Codebasis arbeiteten, desto häufiger standen sie sich gegenseitig im Weg. Microservices waren die Antwort darauf: viele kleine, unabhängig deploybare Dienste, die jeweils einen klar umrissenen Teil der Fachlichkeit übernehmen. Das Versprechen lautete Skalierbarkeit, Teamautonomie und bessere Wartbarkeit. Gerade große Organisationen mit vielen parallel arbeitenden Teams profitierten davon, weil jedes Team seinen Dienst eigenständig entwickeln und ausliefern konnte. Über Jahre war die Aufteilung deshalb die naheliegende Antwort auf wachsende Systeme, und der Begriff „Monolith“ bekam einen abwertenden Beiklang. Und es gibt auch etwas dazwischen, was oft als modularer Monolith bezeichnet wird. In diesem werden Monolithen in klare fachliche Module aufgeteilt, die technisch erzwungene Abhängigkeitsregeln und klare getrennte Verantwortlichkeiten besitzen. Der Unterschied zu Microservices liegt nicht in der Modularität, sondern darin, dass die Module zunächst innerhalb einer gemeinsamen Codebasis und eines gemeinsamen Deployments bleiben.
Wie die KI die Softwarearchitektur verändert
Mit den KI-Tools wie Claude Code, Codex oder GitHub Copilot kommt ein Faktor hinzu, der die Architektur-Abwägung verändern könnte. Diese Werkzeuge können Code schneller erzeugen, analysieren und verändern als vor wenigen Jahren denkbar war. Unter welchen Bedingungen liefern diese die besten Ergebnisse?
Damit verschiebt sich die eigentliche Frage. Sie lautet heute nicht mehr „Monolithen oder Microservices?“, sondern: Welche Architektur macht KI-gestützte Entwicklung effizient?
Stellt man die Architekturen aus der Sicht eines KI-Agenten nebeneinander, zeigt sich ein klares Muster, und zwar dort, wo die KI-Agenten konkret arbeiten: beim Lesen, Ändern und Prüfen von Code.
Microservices galten zu Beginn der KI-Entwicklung als ideale Grundlage, gerade weil ihre Dienste sauber gekapselt und klar definiert sind. Aufgrund der damals noch kleineren Kontextfenster der KI-Agenten schienen anfangs einzelne, kleine Services ideal für die KI-gestützte Entwicklung zu sein.
Monolithen mit ihrer großen Codebasis waren für die Kontextfenster der KI-Agenten schlicht zu groß. Aufgrund der Weiterentwicklung der KI-Agenten und der enormen Vergrößerung der Kontextfenster trägt diese Annahme jedoch nicht mehr. Auch große, modular aufgeteilte Softwareprojekte können vom Kontext der KI-Agenten erfasst werden.
Unserer Erfahrung nach liefern KI-Agenten mittlerweile die besten Ergebnisse, wenn der relevante Kontext an einem Ort liegt, gut navigierbar ist und sie ihre Änderungen schnell validieren können. KI-Agenten werden dann zuverlässig, wenn sie ihre eigene Arbeit sofort überprüfen können.
KI-Agenten, die eine Funktion ändern, müssen verstehen, wer sie aufruft, welche Datenstrukturen sie berühren und welche Tests sie absichern. In einem modularen Monolithen sind diese Zusammenhänge in derselben Codebasis sichtbar und die KI-Agenten können ihnen folgen.
Bei Zugriffen zwischen Diensten werden Zusammenhänge für die KI-Agenten schwer prüfbar. Eine Abhängigkeit, die von einem Dienst über eine API zu einem anderen führt, taucht meist nur in einer API-Spezifikation oder einem Abhängigkeitsgraphen auf. Eine aktuelle Untersuchung, in der führende KI-Agenten bestehende Microservices erweitern sollten, zeigt das deutlich. Bei inkrementeller Arbeit an vorhandenem Code lag die Erfolgsquote der Unit-Tests nur zwischen 50 und 76 Prozent und die Fehler häuften sich dort, wo es um serviceübergreifende Schnittstellen ging (Adnan et al., 2026).
Der Grund ist strukturell. Im Monolithen prüfen Compiler und Tests, ob zwei Module zusammenpassen. Über eine Servicegrenze hinweg übernimmt das meist keine Automatik; der Vertrag zwischen zwei Diensten existiert dann häufig lediglich als Dokumentation. Der Aufwand für Contract Tests, OpenAPI-Spezifikationen, Consumer-driven Contracts, Schema Registry, Integrationstests usw. wird selten investiert.
Dafür sorgt eine Kette schneller, automatischer Kontrollen: Typechecks stellen sicher, dass Datentypen zusammenpassen, Linter melden Stil- und Flüchtigkeitsfehler, Tests prüfen das Verhalten und der Build zeigt, ob sich das Ganze überhaupt übersetzen lässt. In modularen Monolithen laufen diese Rückkopplungsschleifen lokal und in kürzester Zeit. In einer verteilten Landschaft braucht es dafür oft mehrere laufende Dienste, Mock-Server und Integrationsumgebungen.
Den vielleicht wichtigsten Beitrag liefert der DORA-Report 2025 von Google Cloud, eine der größten Erhebungen der Branche. Seine zentrale Erkenntnis lautet: KI wirkt als Verstärker bestehender Stärken und Schwächen. Teams mit lose gekoppelter Architektur und schnellen Feedback-Loops gewinnen durch KI deutlich, Teams in eng gekoppelten, langsamen Systemen kaum. Wichtig ist dabei, wie der Report „lose Kopplung“ versteht: als die Fähigkeit eines Teams, seine Komponenten unabhängig von anderen zu ändern, zu testen und auszuliefern, nicht als Frage, ob diese Komponenten über das Netzwerk verteilt sind. Modulare Monolithen mit sauberen Grenzen erfüllen diese Kriterien ebenso und bringen die schnellen Feedback-Schleifen, die der Report als zweiten wichtigen Hebel nennt, gleich mit.
Die Kosten der Weiterentwicklung
Jede Architekturentscheidung schlägt sich über die Jahre vor allem an einer Stelle nieder: in den Kosten der Weiterentwicklung. Nicht nur der erste Wurf eines Systems ist teuer, sondern auch alles, was danach kommt: jede Änderung, jede Erweiterung, jede Fehlerbehebung. Bei einer verteilten Architektur fallen diese laufenden Kosten dauerhaft höher aus. Verteilte Systeme haben einen Preis, der gelegentlich „Distributed System Tax“ genannt wird. Sobald Daten die Servicegrenzen überschreiten, steigt die Komplexität sprunghaft: Netzwerkfehlerbehandlung, Serviceversionierung, verteiltes Monitoring und das Zusammenspiel vieler Deployments kommen hinzu. In der Praxis bindet diese Zusatzkomplexität regelmäßig erhebliche Entwicklungskapazität, die nicht in neue Funktionen fließt, sondern in Betrieb, Monitoring und Fehleranalyse. Insbesondere bei großen verteilten Teams steigt zudem der Abstimmungs- und Kommunikationsaufwand erheblich. Diese Aufwände fließen jedoch nicht in neue Funktionen, sondern gewissermaßen in das Verwalten der Verteilung. Dieser Aufwand verschwindet auch mit KI-Agenten nicht, sondern wächst eher. Weil die Agenten an Servicegrenzen blind werden, bleibt die serviceübergreifende Arbeit Handarbeit. Wie groß der Unterschied in der Praxis sein kann, zeigt das Team von Segment, das über 140 Microservices wieder zu einem System zusammenführte. Die Laufzeit diverser Tests fiel von mehreren Minuten auf wenige Millisekunden pro Durchlauf, also auf jene schnelle Feedback-Schleife, auf die KI-Agenten angewiesen sind.
Wann sind Microservices dennoch sinnvoll?
Das alles ist kein Plädoyer gegen Microservices an sich. Es gibt weiterhin klare Situationen, in denen sich die Verteilung lohnt, und dann empfehlen auch wir sie ohne Zögern:
Unterschiedliche Skalierung. Wenn einzelne Teile eines Systems völlig anders skalieren müssen als der Rest, etwa eine rechenintensive Bildverarbeitung neben einer schlanken Verwaltungsoberfläche, ist ein separat skalierbarer Dienst die saubere Lösung.
Getrennte Datenhaltung aus Sicherheits- oder Compliance-Gründen. Müssen bestimmte Daten strikt voneinander isoliert werden, etwa wegen regulatorischer Vorgaben oder interner Sicherheitsrichtlinien, ist eine harte Service- und Datengrenze oft Pflicht.
Diese Gründe betreffen meist einzelne Komponenten bzw. Funktionen und nicht das ganze System.
Unsere Empfehlung
Für die allermeisten Projekte, vom Mittelstand bis zu vielen Vorhaben großer Kunden, lautet unsere Empfehlung daher: Setzen Sie auf modulare Monolithen und machen Sie diese gezielt „agent-ready“. Erst wenn ein System eine der genannten Schwellen erreicht, also stark abweichende Skalierung, harte Datentrennung oder viele unabhängige Teams, lohnt der Schritt zur Verteilung, und dann gezielt für die betroffenen Teile, nicht für das ganze System.
Der Aufwand, der früher in die Aufteilung in Microservices geflossen wäre, ist bei modularen Monolithen an anderer Stelle besser aufgehoben. Drei Maßnahmen machen aus einem gewöhnlichen Monolithen einen, in dem KI-Agenten dauerhaft produktiv bleiben:
Modulgrenzen technisch erzwingen, statt sie nur zu dokumentieren. Eine dokumentierte Grenze ist eine Bitte, eine erzwungene Grenze ist eine Regel. Konkret heißt das: Die erlaubten Abhängigkeiten zwischen den Modulen werden im Build hinterlegt und durch automatisierte Architekturtests geprüft. Greift ein Modul unerlaubt auf die Interna eines anderen zu, schlägt der Test fehl, gleich ob ein Mensch oder ein KI-Agent die Verletzung verursacht hat. So bleibt die Architektur auch bei hoher Änderungsgeschwindigkeit intakt.
Kontext kodifizieren. Konventionen, Architekturentscheidungen und Modulverantwortungen gehören als versionierte Dateien in die Codebasis, die sowohl das Team als auch die KI-Werkzeuge lesen können. Was dokumentiert und auffindbar ist, müssen die KI-Agenten nicht raten.
Schnelle, verlässliche Feedback-Schleifen bereitstellen. Typprüfung, Linter, zügige Tests und ein schneller Build bilden die Kontrollinstanz, an der die KI-Agenten ihre eigene Arbeit messen. Je schneller und verlässlicher diese Schleife, desto zuverlässiger das Ergebnis.
So erhalten Sie beides: die Modularität, die KI-Agenten für ihre Produktivität brauchen, und die Einfachheit eines einzelnen Systems, das sich schnell und günstig weiterentwickeln lässt. Sie behalten zugleich die Tür offen, einzelne Module später herauszulösen, falls ein konkreter Grund dafür entsteht.
Die Faustregel der letzten zehn Jahre, im Zweifel aufteilen, war eine Antwort auf die Werkzeuge ihrer Zeit. Mit KI-gestützter Entwicklung haben sich diese Werkzeuge verändert, und mit ihnen die richtige Antwort. Für die meisten Projekte heißt sie heute: Modulare Monolithen, die von Anfang an für die Zusammenarbeit mit KI-Agenten gebaut sind.
Sie überlegen, wie Sie Ihre Software zukunftsfähig und KI-tauglich aufstellen? Sprechen Sie mit uns, wir schauen uns Ihre Ausgangslage gemeinsam an.
Kontakt
Lassen Sie uns gemeinsam starten!
Sie möchten wissen, wie KI-gestützte Softwareentwicklung Ihr Projekt schneller und effizienter voranbringen kann? Wir beraten Sie zur passenden Architektur und setzen die Lösung gemeinsam mit Ihnen um. Wir freuen uns auf Ihre Anfrage!
Diesen Beitrag teilen