Theorie der Softwareevolution im Zeitalter der KI

In vielen Unternehmen finden heute die meisten Entscheidungen, Ausführungen, Prüfungen und Verbesserungen auf Softwaresystemen statt. Kundenkontaktpunkte, Preis- und Vertragsänderungen, Anpassungen von Lieferungen und Beständen, die Sammlung und Analyse von Protokollen sowie interne Betriebsabläufe hängen alle stark von Software ab. Dies ist keine Phase mehr, in der IT lediglich eingeführt wurde; der Geschäftsbetrieb selbst ist an den Zustand seiner Software gebunden, und die Fähigkeit, Software zu aktualisieren, entspricht der Fähigkeit, das Unternehmen zu verändern.

Diese Situation ist nicht auf bestimmte Branchen beschränkt. Über Branchen und Unternehmensgrößen hinweg können Unternehmen, die mit einer gewissen Geschwindigkeit und Komplexität arbeiten, ohne Software im Kern nicht mehr funktionieren. Wenn sich äußere Bedingungen schneller ändern und Entscheidung-Ausführung-Zyklen häufiger werden, wird die Fähigkeit zur Veränderung selbst zu einem Wettbewerbsfaktor. Überlagern sich Veränderungen beim Kundennutzen, bei Servicebedingungen, betrieblichen Einschränkungen, regulatorischen Anforderungen und Kostenstrukturen, kann ein Unternehmen, das seine Software nicht aktualisieren kann, Entscheidungen nicht in Handlungen übersetzen, keine Korrekturen vornehmen und kommt letztlich zum Stillstand.

In diesem Umfeld zeigt sich häufig, dass Software-Updates zum Engpass für Geschäftsentscheidungen und strategische Veränderungen werden. Entscheidungen können getroffen werden, doch die für ihre Umsetzung erforderlichen strukturellen Änderungen werden nicht rechtzeitig abgeschlossen. Dadurch schrumpft die Bandbreite der Initiativen, die realistisch getestet werden können.

Je länger Software-Updates dauern, desto größer wird der Abstand zwischen Entscheidung und Ausführung. Während dieser Verzögerung verändern sich die äußeren Bedingungen weiter. Dadurch bleiben weitere Entscheidungen unausgeführt, und der operative Handlungsspielraum des Unternehmens wird allmählich kleiner.

Bei Software, die über lange Zeit genutzt wird, bleiben Systeme nur selten in ihrem ursprünglichen Zustand. Funktionen kommen hinzu, Konfigurationen ändern sich, Abläufe werden angepasst, und die Software entwickelt sich in eine Form, die sich deutlich vom ursprünglichen Entwurf unterscheidet. Frühere Spezifikationen oder Designdokumente stimmen Jahre später nur selten vollständig mit Implementierung und Betriebsrealität überein. Das bedeutet nicht, dass der ursprüngliche Entwurf bedeutungslos war; vielmehr zeigt es, dass die anfangs angenommenen Bedingungen über lange Betriebszeiten schwer aufrechtzuerhalten sind.

Während die Software weiter genutzt wird, werden ursprünglich nicht erwartete Aufgaben und Entscheidungen Teil des Alltagsbetriebs. Das Nutzerverhalten ändert sich, Umfang und Bedeutung der Daten entwickeln sich, und Beziehungen zu umliegenden Systemen verschieben sich. Zusätzliche Verarbeitung, Umorganisationen, Ersetzungen und Workarounds sammeln sich an. Was zunächst wie eine kleine Ausnahme wirkt, wird schließlich zur Norm; diese Normen wirken auf die innere Struktur zurück. Mit der Zeit wird ein einst geradliniger Entwurf komplexer, weil er reale Anforderungen aufnimmt.

Ebenso bleiben selten dieselben Menschen über die gesamte Lebensdauer eines Systems verantwortlich. Entwickler und Betreiber wechseln, Organisationsstrukturen verändern sich und Rollen werden neu verteilt. Selbst wenn die Dokumentation erhalten bleibt, werden die kontextuellen Annahmen hinter früheren Entscheidungen nicht vollständig weitergegeben. Verloren geht nicht die Menge an Informationen, sondern die Gesamtheit der Bedingungen, unter denen frühere Entscheidungen sinnvoll waren. Verblassen diese Annahmen, führt derselbe Text nicht mehr zu denselben Schlussfolgerungen. Änderungen werden vorsichtiger, lokale Behelfslösungen nehmen zu und die Gesamtkonsistenz verschlechtert sich allmählich.

Diese Veränderungen entstehen nicht durch einzelne besondere Fehler oder außergewöhnliche Umstände. Ähnliche Muster werden in verschiedenen Organisationen, Branchen und technischen Bereichen immer wieder beobachtet. Gemeinsam ist ihnen, dass Software über lange Zeit verwendet wird, während sich die Rahmenbedingungen weiter verändern. Die Art dieser Veränderungen unterscheidet sich je nach Kontext, doch dass Veränderung fortbesteht, ist überall gleich.

Kleine Unterschiede bei den Annahmen summieren sich mit der Zeit. Anpassungen, die sich einst durch Routineabläufe auffangen ließen, erfordern schließlich eine strukturelle Neubetrachtung. Dann nehmen Gewicht und Umfang der Veränderung zu. Mit wachsender Auswirkung steigen die Prüfkosten, Rollbacks werden schwieriger und Entscheidungen langsamer. Wenn Entscheidungen sich verlangsamen, können Unternehmen nicht mehr testen, was sie ausprobieren möchten. Dieser Zustand ist nicht einfach geringe Qualität, sondern gehemmtes Lernen – und je schneller sich die Umgebung verändert, desto schädlicher wird er.

Viele Entwicklungsprojekte folgten traditionell einem Modell, in dem Entwürfe vor Beginn der Implementierung möglichst vollständig abgeschlossen werden. Dieser Ansatz erleichterte Konsensbildung, Arbeitsteilung und das Management großer Projekte. In Umgebungen mit hohen Implementierungskosten und teuren Experimenten war es praktisch, Entwürfe früh zu verfestigen; Design sollte die Komplexität bei der Umsetzung reduzieren.

Dieser Ansatz hat jedoch inhärente zeitliche Einschränkungen. Sobald ein Entwurf abgeschlossen ist, beginnen sich die Bedingungen zu verändern. Je größer die Lücke zwischen Fertigstellung und Implementierung, desto stärker weichen Annahmen und Realität voneinander ab. Bei schnellen Veränderungen kann diese Abweichung bis zur Fertigstellung des Systems erheblich werden. Oft geht es nicht um kleine Spezifikationsdetails, sondern um grundlegende Prioritäten, betriebliche Zwänge oder die Bedeutung von Daten.

Das bedeutet nicht, dass der Entwurf falsch war. In vielen Fällen war er damals die bestmögliche Entscheidung. Das Problem entsteht, wenn nicht berücksichtigt wird, dass sich Annahmen mit der Zeit verschieben. Ist eine spätere Anpassung nicht vorgesehen, wird das System genau in dem Moment schwer aktualisierbar, in dem es fertiggestellt ist. Wird Fertigstellung als Endpunkt behandelt, werden spätere Änderungen als Ausnahmen behandelt und nachträglich angehäuft. Mit der Zeit stapeln sich Updates als lokale Korrekturen, die Struktur verhärtet sich und die Lerngeschwindigkeit des Unternehmens sinkt.

Dieser Entwicklungsansatz entstand aus nachvollziehbaren Gründen. Hohe Implementierungskosten und eine große Experimentierlast machten frühe Planung notwendig. Bedingungen zu bewerten, Abhängigkeiten zu ordnen und ein vollständiges System vorab zu definieren, war in solchen Umgebungen entscheidend. Konsensbildung, vorgezogene Risikobewertung und strukturierte Arbeitsteilung waren praktische Notwendigkeiten.

Wenn sich die Bedingungen ändern, verändert sich auch der Ort des Werts. Frühere Urteile, Fehlschläge und Anpassungen werden dadurch nicht ungültig. Sie werden lediglich anders herangezogen und angewendet. Erfahrungen aus Design-Reviews dienen nicht mehr dazu, die Zukunft perfekt vorherzusagen, sondern zu erkennen, wo Systeme unter Veränderung wahrscheinlich versagen. Betriebliche Erkenntnisse zeigen, welche Grundlagen fest bleiben und welche Bereiche flexibel sein sollten. Vergangene Erfahrung wird nicht verworfen, sondern wiederverwendet.

Wenn diese Wiederverwendung möglich wird, steigt der Wert von Erfahrung oft, statt zu sinken. In schnell wechselnden Umgebungen verstärken sich falsche Urteile rasch. Niedrigere Experimentierkosten bedeuten mehr Versuche – auch falsche. Dadurch beeinflussen die Qualität der Priorisierung und die Richtung gebender Entscheidungen die Ergebnisse stärker.

In den vergangenen Jahren haben sich die Entwicklungsbedingungen deutlich verändert. Die Kosten für Implementierung und Experimente sind gesunken, und die Zeit, um Hypothesen in prüfbare Formen zu überführen, hat sich verkürzt. Dazu trägt teilweise die breite Einführung KI-basierter Software bei, die Codegenerierung und -änderungen direkt unterstützt. Diese Werkzeuge senken die anfänglichen Kosten der Implementierungsvalidierung und machen es praktikabel, Entwürfe auszuprobieren, zu verwerfen und neu zu strukturieren.

Wichtig ist hier nicht, ob KI eingesetzt wird, sondern dass sich die Bedingungen verändert haben. Wenn sich Bedingungen ändern, verändern sich auch die Strukturen, die unter ihnen wirksam funktionieren.

Dabei geht es nicht darum, KI-getriebene Entwicklung gegen menschlich gesteuerte Entwicklung auszuspielen. Vielmehr verbinden sich menschliches Urteilsvermögen – etwa Priorisierung, strukturelle Entscheidungen und Kontextverständnis – und KI-gestützte Codegenerierung und -änderung. Menschen entscheiden, was ausprobiert und wo verändert wird; KI senkt die Kosten für die Umsetzung dieser Entscheidungen. Durch diese Zusammenarbeit werden Experimente und Lernen in Geschwindigkeiten möglich, die zuvor unpraktikabel waren.

Eine Entwicklung, die Software kontinuierlich im Gleichschritt mit dem Geschäft aktualisiert, ist dadurch erstmals eine realistische Option geworden.

Unter diesen Bedingungen sind Strukturen, die nachträgliche Anpassungen ermöglichen, leichter zu beherrschen als solche, die alles im Voraus festschreiben wollen. Mit wachsendem Umfang und sich entwickelnden Anforderungen wird die Fähigkeit, Strukturen neu zu bewerten und zu verändern, zur Voraussetzung. Das bedeutet nicht, auf Design zu verzichten. Es bedeutet, die feste Grundlage einzugrenzen, klar zu bestimmen, was flexibel bleiben soll, und Strukturen schrittweise mit eindeutigen Prioritäten neu zu ordnen. Grundlegendes Design wird dadurch wichtiger, nicht weniger.

Mit wachsendem Systemumfang wird Infrastruktur zwangsläufig ersetzt. Konfigurationen, die einst ausreichten, benötigen Redundanz, Partitionierung, Verteilung, Beobachtbarkeit und Wiederherstellungsmechanismen. Der laufende Betrieb bringt Anforderungen an Reorganisation und Funktionserweiterung mit sich. In realen Umgebungen sind Upgrades, Downgrades, Rollbacks, gestaffelte Migrationen, Parallelbetrieb und Teilersetzungen Routine – keine Ausnahmefälle. Strukturen, die sich nicht vorwärts und rückwärts bewegen lassen, erhöhen mit jeder Änderung Risiko und Kosten und bringen Updates schließlich ganz zum Stillstand.

Deshalb müssen Softwarestrukturen Reversibilität und Austauschbarkeit unterstützen. Sind Grenzen unklar und wachsen Systeme nur in eine Richtung, breiten sich Änderungen weit aus, die Validierung wird grob und Rollbacks werden schwierig. Klar definierte Grenzen und modulare Ersetzungseinheiten ermöglichen, durch Veränderung weiterzulernen.

Diese Entscheidungen können nicht allein dem Einfallsreichtum Einzelner überlassen werden. Was fest bleibt, was flexibel bleibt und welche Änderungen akzeptabel sind, muss als gemeinsame Annahme behandelt werden. Dafür braucht es mehr als Werkzeugauswahl oder Codierungsstandards; erforderlich ist ein gemeinsames taktisches Verständnis. Fehlt ein solches gemeinsames Urteil, werden Updates personenabhängig, die Geschwindigkeit sinkt und das Lernen kommt zum Stillstand.

Jedes Mal, wenn sich die Bedingungen verschieben, kommen für Software und Geschäft neue Einschränkungen hinzu. Frühere Entwürfe und Implementierungen sind möglicherweise nicht mehr direkt anwendbar; das macht die dahinterliegende Erfahrung jedoch nicht ungültig.

Erkenntnisse aus früheren Veränderungen – etwa wo Systeme versagen, Engpässe entstehen und wie weit sich Änderungen ausbreiten – werden erneut genutzt, wenn sich die Bedingungen wieder ändern. Auch wenn sich die konkrete Form wandelt, tauchen diese Urteile wieder auf, wenn entschieden wird, was als Nächstes ausprobiert und wo eingegriffen werden soll.

In modernen Entwicklungsumgebungen ermöglicht die Verbindung aus menschlichem Situationsurteil und KI-gestützter Implementierung, solche Erfahrungen in viel kürzeren Abständen anzuwenden. Das gesammelte Wissen bleibt in der Qualität der Entscheidungen verankert und fließt direkt in spätere Implementierungen und Validierungen ein.

Dadurch werden Systeme bei jeder Veränderung weder von Grund auf neu aufgebaut noch vergangene Formen starr bewahrt. Stattdessen wird Erfahrung genutzt, während sich die Bedingungen verschieben, und die Software entwickelt sich entsprechend weiter.

Veränderung wird fortbestehen. Neue Technologien und Einschränkungen werden entstehen. Doch gesammelte Erfahrung geht nicht verloren. Je höher die Geschwindigkeit und Häufigkeit, mit der Erfahrung wiederverwendet werden kann, desto unmittelbarer und konsistenter zeigt sich ihr Wert in den Ergebnissen.