Der Flaschenhals in der Softwareentwicklung liegt nicht mehr im Schreiben von Code, sondern in der Entscheidung, was entwickelt, wie es miteinander verbunden und wie es im Zuge von Änderungen gewartet werden soll. Zwei Jahrzehnte lang lag der Engpass in der Produktionskapazität; heute ist die Codeerzeugung im Überfluss vorhanden und kostengünstig, und der Engpass hat sich vollständig auf Designentscheidungen verlagert, die kein Codegenerierungstool für Sie treffen kann.
Dies hat konkrete geschäftliche Konsequenzen für jedes Unternehmen, das im Jahr 2026 Entwicklungsdienstleistungen bezieht: Der Stundensatz für die Programmierung sinkt, und die Kosten einer Fehlentscheidung in der Architektur steigen. Wer beim Einkauf noch so vorgeht wie im Jahr 2019 – und Anbieter nur nach Preis und Geschwindigkeit vergleicht – optimiert die falsche Variable.
Intuition legt nahe, dass Projekte schneller abgeschlossen sein sollten, wenn die Codeerstellung beschleunigt wird. Die Daten zeichnen jedoch ein anderes Bild.
Der DORA-Bericht 2024 von Google Cloud, der auf Basis von Daten von rund 39.000 Branchenexperten erstellt wurde, ergab, dass ein Anstieg der KI-Nutzung um 251.000 Tsd. mit einem Rückgang des Durchsatzes um 1,51.000 Tsd. und der Stabilität um 7,21.000 Tsd. einherging. Dies lag nicht an grundsätzlich schlechtem Code, sondern an den zunehmenden Änderungspaketen: Es wurde mehr Code gleichzeitig bereitgestellt, die Überprüfungen waren weniger gründlich und es traten mehr Fehler auf. In derselben Studie gaben 39.210 Tsd. Entwickler an, wenig bis gar kein Vertrauen in KI-generierten Code zu haben.
GitClear analysierte 211 Millionen Codezeilen zwischen 2020 und 2024 und dokumentierte die andere Seite desselben Phänomens: Refaktorierter oder "verschobener" Code sank von etwa 251 Tsd. 300 im Jahr 2021 auf weniger als 101 Tsd. 300 im Jahr 2024, während das Kopieren und Einfügen von 8,31 Tsd. 300 auf 12,31 Tsd. 300 anstieg und doppelte Codeblöcke sich verachtfachten.
Übersetzt: Es wird mehr geschrieben, weniger umgeordnet. Es häuft sich an.
Die METR-Studie vom Juli 2025 brachte eine Nuance ans Licht, die einer ehrlichen Auseinandersetzung bedarf. In einer kontrollierten Studie mit 16 erfahrenen Open-Source-Entwicklern und 246 realen Aufgaben benötigten die Teilnehmer mit KI 191 TP3T länger, obwohl sie eine 241 TP3T schnellere Bearbeitung erwartet hatten und nach dem Test immer noch glaubten, 201 TP3T schneller gewesen zu sein. METR selbst überprüfte das Studiendesign im Februar 2026 auf mögliche Selektionsverzerrungen, und eine größere Kohorte zeigte einen deutlich geringeren Unterschied. Das genaue Ergebnis ist diskussionswürdig. Unstrittig ist hingegen das sekundäre Ergebnis: Die wahrgenommene und die tatsächliche Geschwindigkeit entkoppeln sich.
Wenn die Geschwindigkeitswahrnehmung von der Realität abweicht, ist nicht die Ausführung die Disziplin, die den Kurs korrigiert. Es ist die Planung.
Nicht alle technischen Entscheidungen haben das gleiche Gewicht. Der praktische Unterschied liegt darin, was innerhalb einer Woche geändert werden kann und was die nächsten fünf Jahre prägen wird.
Art der Entscheidung | Beispiel | Kosten für den nachträglichen Wechsel |
Werkzeug | Frontend-Framework, Grafikbibliothek | Niedrig: Wochen |
Modellanbieter | Wechsel von einem LLM-Studiengang zu einem anderen | Wenn es darunter eine Abstraktionsebene gibt |
Datenmodell | Wie man einen Kunden oder eine Bestellung vertritt | Hoch: Beeinflusst alles, was darüber gebaut ist |
Grenzen zwischen Systemen | Welches Modul besitzt welche Informationen? | Sehr hoch: teilweise Überarbeitung |
Genehmigungsvorlage | Wer kann was sehen und tun, und mit welcher Rückverfolgbarkeit? | Sehr hoch: impliziert Sicherheit und Compliance |
Die ersten beiden Zeilen erzeugen in technischen Besprechungen die meisten Diskussionen. Die letzten drei Zeilen entscheiden darüber, ob das Unternehmen sein System in drei Jahren weiterentwickeln oder komplett neu schreiben muss.
Ein konkretes Beispiel aus Logistik, Versicherungswesen und Gesundheitswesen ist die Frage, ob eine «Patientenakte» eine eigenständige Entität mit eigenem Lebenszyklus oder lediglich eine Ansicht auf Basis anderer Tabellen ist. Diese Entscheidung fällt meist in der zweiten Projektwoche, ohne Diskussion, und bestimmt jahrelang, ob Änderungen nachvollziehbar sind, ob die Datenaufbewahrung durchgesetzt werden kann und ob die Akte über eine API an Dritte weitergegeben werden darf. Kein Codegenerator kann diese Entscheidung treffen, denn es handelt sich nicht um eine Programmierfrage, sondern um eine betriebswirtschaftliche Frage.
Das ist die Arbeit, die wir leisten in kundenspezifische Softwareentwicklung [interner Link] Bevor Sie die erste Zeile schreiben: Definieren Sie, was existiert, wem was gehört und welchen Vertrag jedes Modul mit den anderen hat.
Die Architektur eines Unternehmenssystems wird durch vier Grenzen definiert. Sind alle vier klar definiert, entwickelt sich das System weiter. Sobald eine Grenze verschwimmt, verschlechtert sich die Systemleistung, selbst bei einwandfreiem Code.
Die Datengrenze. Jedes Datenelement sollte nur einem einzigen System zugeordnet sein: einem System, das die Daten steuert, und anderen, die sie abfragen. Die Alternative – drei Systeme, die dieselben Informationen schreiben – führt zu Widersprüchen, die keine höhere Ebene auflösen kann, und ist die Hauptursache dafür, dass die meisten Business-Intelligence-Projekte in Streitigkeiten darüber enden, welche Zahl korrekt ist.
Die Grenze der Verträge. Die Module kommunizieren über explizite, versionierte und dokumentierte Schnittstellen. Ein Vertrag ist ein Versprechen: «Das liefere ich, das garantiere ich, das ändere ich nach vorheriger Ankündigung.» Ohne Verträge bedeutet jede Integration eine neue Kopplung und jede Änderung eine Aushandlung.
Die Grenze der Genehmigungen. Wer was sehen und wer was tun darf, sollte eine Systemebene bilden, keine Bedingung, die an vierzig Stellen wiederholt wird. Diese Abgrenzung ist mit dem Aufkommen von KI-Agenten, die Aktionen ausführen, kritisch geworden: War das Berechtigungsmodell schon bei menschlichen Nutzern anfällig, so versagt es bei nicht-menschlichen Identitäten.
Die Grenze der Beobachtbarkeit. Ein System, in dem es unmöglich ist, nachzuvollziehen, was, wann und warum geschah, ist weder wartungsfreundlich noch überprüfbar. Und seitdem probabilistische Komponenten in die Lieferkette eingeführt wurden, ist Rückverfolgbarkeit nicht mehr nur eine bewährte Betriebspraxis, sondern eine zwingende Anforderung an die Unternehmensführung geworden.
Diese vier Grenzen bilden die Struktur einer zusammensetzbaren Architektur, ein Ansatz, den wir in unserer Analyse detailliert entwickeln. Zusammensetzbare Architektur, APIs und künstliche Intelligenz
Für die Erkennung erster Symptome ist keine formelle Prüfung erforderlich. Folgende Indikatoren treten zuerst auf:
Wenn drei oder mehr dieser Symptome auftreten, beschleunigt der Ausbau der Entwicklungskapazitäten nichts. Er erhöht lediglich die Anzahl der Personen, die auf eine Designentscheidung warten.
Die Argumentation für Architektur wird oft in ingenieurwissenschaftlichen Begriffen formuliert, weshalb sie in Managementgremien an Zustimmung verliert. In der Sprache der Betriebswirtschaftslehre ausgedrückt, erfüllt gute Architektur vier messbare Kriterien:
Reduzieren Sie die Kosten für einen Meinungswechsel. Ein Unternehmen, das sein Angebot, seinen Abrechnungsprozess oder sein Preismodell innerhalb weniger Wochen ändern kann, positioniert sich anders im Wettbewerb als ein Unternehmen, das sechs Monate benötigt.
Technologie sollte zu einem Vermögenswert und nicht zu einer wiederkehrenden Ausgabe werden. Ein System mit klar definierten Verantwortlichkeiten für den Code, Dokumentation und expliziten Verträgen ist im Rahmen der Due-Diligence-Prüfung wertvoll. Ein System, das sich auf einen einzigen Anbieter verlässt, ist es nicht.
Dadurch können Teile ausgetauscht werden, ohne die gesamte Baugruppe neu aufbauen zu müssen. Dies gilt insbesondere für KI-Modelle, deren Preise, Fähigkeiten und Nutzungsrichtlinien sich mehrmals im Jahr ändern.
Es macht Entscheidungen nachvollziehbar. Angesichts der zunehmend strengeren europäischen Rechtsvorschriften ist es wichtig, nachweisen zu können, was das System geleistet hat und mit welchen Daten es sich von wünschenswert zu erforderlich entwickelt hat.
Bei The Cloud Group ist dies in TCG-SAF™, unserem Systemarchitektur-Framework, formalisiert: fünf Phasen – Vision, Domänen, Module, Entwicklung, Ausführung – und ein einziges Architekturdokument, das den gesamten Aufbau steuert. Dies ist keine Frage der Ästhetik. Es ist der Grund, warum wir schriftliche Termingarantien geben können: Ein Termin kann nur dann verbindlich festgelegt werden, wenn der Umfang vor Beginn strukturiert ist.
Auf dem Höhepunkt des Hypes ging man davon aus, dass sich die Fähigkeiten angleichen würden, wenn alle Zugriff auf dieselben Modelle hätten. Das Gegenteil ist eingetreten. Zwei Unternehmen mit identischem Zugriff auf dieselben Werkzeuge erzielen radikal unterschiedliche Ergebnisse. Der Unterschied liegt in ihren firmeneigenen Daten, ihrem Fachwissen und der Qualität der Systemintegration.
Modelle werden zur Massenware. Codegenerierungswerkzeuge werden zur Massenware. Was jedoch nicht zur Massenware wird, ist die Fähigkeit, generische Funktionen in ein spezifisches, zuverlässiges und proprietäres System zu transformieren.
Diese Fähigkeit hat einen alten und eher unglamourösen Namen: Ingenieurwesen.
Softwarearchitektur ist die Gesamtheit der Entscheidungen darüber, welche Komponenten existieren, welche Informationen jede einzelne enthält und wie sie miteinander kommunizieren. Sie ist wichtiger als der Code selbst, da Code innerhalb weniger Wochen neu geschrieben werden kann, während Änderungen am Datenmodell oder an den Systemgrenzen eine teilweise Überarbeitung des Produkts erfordern können.
Typische Symptome sind: kleine Änderungen dauern genauso lange wie große, Schätzungen sind unzuverlässig, jede neue Integration kostet genauso viel wie die erste, es gibt Bereiche des Systems, die das Team meidet, und das Wissen über den Informationsfluss hängt von einer einzigen Person ab.
Nein, es erhöht sie. Wenn die Codegenerierung günstig ist, verlagert sich die Knappheit auf die Entscheidung, was entwickelt und wie es verbunden werden soll. Der DORA-Bericht von 2024 stellte fest, dass eine verstärkte Nutzung von KI mit einer geringeren Stabilität der Bereitstellung korreliert, eben weil das Änderungsvolumen zunimmt, ohne dass die Designdisziplin entsprechend zunimmt.
Die drei teuersten Aspekte bei einer Rücksetzung sind das Datenmodell (die Darstellung von Geschäftseinheiten), die Zuständigkeitsgrenzen zwischen Systemen (welches Modul welche Informationen kontrolliert) und das Berechtigungs- und Rückverfolgbarkeitsmodell. Der Wechsel von Frameworks oder Modellanbietern ist vergleichsweise kostengünstig.
Es hängt vom Grad der Kopplung ab, aber typischerweise steigen die Kosten mit der Zeit nichtlinear an: Jeder Monat, in dem an einer schlecht definierten Grenze gearbeitet wird, fügt Code hinzu, der von dieser Entscheidung abhängt. Deshalb kostet ein frühzeitiges technisches Audit in der Regel nur einen Bruchteil dessen, was die dadurch vermiedene Neuentwicklung kosten würde.
Ja. Üblicherweise wird das bestehende System durch explizite Verträge isoliert und die einzelnen Bereiche nacheinander ersetzt, anstatt alles auf einmal neu zu schreiben. Dies erfordert eine Vorbewertung, die anhand von Risiko und Geschäftswert priorisiert, welcher Bereich zuerst modernisiert werden soll.
Vermuten Sie, dass Ihre Architektur das Hindernis darstellt? Unser technisches Software-Audit liefert Ihnen innerhalb von 10 Werktagen eine schriftliche Diagnose zu Architektur, Code, Altlasten und Sicherheit zum Festpreis. Es wird kein kommerzielles Angebot erstellt: Erst die Diagnose, dann die Entscheidung. Audit anfordern → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
