Generative KI verändert, wie Software entsteht. Sprachmodelle formulieren Klassen, Konfigurationen und Testfälle in Sekunden, und die reine Schreibarbeit am Code verliert an Gewicht. Ein aktueller Beitrag im Entwicklungsumfeld bringt es auf einen einfachen Nenner: Große Sprachmodelle werden Softwarearchitektur grundlegend verändern – die grundsätzlichen Probleme der Softwareentwicklung bleiben davon jedoch unberührt.

Genau diese Doppelbewegung ist für Projektverantwortliche interessant. Es wird schneller, etwas zu bauen. Es wird nicht automatisch leichter, das Richtige zu bauen.

Der Engpass wandert nach vorne

In klassischen Projekten lag ein großer Teil des Aufwands in der Umsetzung: Schnittstellen anbinden, Datenmodelle abbilden, Templates ausarbeiten. Wenn dieser Teil günstiger und schneller wird, tritt hervor, was vorher davon verdeckt war – die Frage, welches Verhalten das System eigentlich zeigen soll.

Unklare Anforderungen produzierten früher Verzögerung. Heute produzieren sie funktionierenden, aber falschen Code, und das oft in beachtlicher Menge. Ein Sprachmodell fragt nicht nach, ob eine Rabattregel in dieser Form überhaupt der Geschäftslogik entspricht. Es erzeugt eine plausible Umsetzung dessen, was in der Aufgabenstellung stand.

Damit verschiebt sich der Wert einer Zusammenarbeit dorthin, wo er immer schon war, aber selten sichtbar wurde: in die gemeinsame Klärung von Begriffen, Zuständigkeiten und Abläufen zwischen Fachbereich und Entwicklung.

Kollaborative Modellierung als Arbeitsform

Modellierung meint hier nicht das Zeichnen möglichst vollständiger Diagramme. Gemeint ist die gemeinsame Arbeit an einem geteilten Verständnis: Welche fachlichen Objekte gibt es? Wann ändert sich ihr Zustand? Wer darf was auslösen? Welche Regeln gelten, und welche Ausnahmen sind erlaubt?

Solche Klärungen entstehen im Gespräch – an einer Wand mit Karten, an einem Whiteboard, in einem Workshop mit den Menschen, die den Prozess täglich ausführen. Das Ergebnis ist ein Modell, das alle Beteiligten lesen können, nicht nur die Entwicklungsabteilung.

Der praktische Nutzen ist doppelt. Erstens verhindert ein sauberes Modell, dass ein Missverständnis in Code gegossen wird. Zweitens liefert es genau die Präzision, mit der sich KI-gestützte Werkzeuge sinnvoll steuern lassen: Wer ein Domänenmodell mit klaren Begriffen hat, formuliert deutlich bessere Vorgaben als jemand, der aus einem vagen Anforderungstext heraus arbeitet.

Was Architektur weiterhin leisten muss

Architekturentscheidungen sind Entscheidungen über Konsequenzen, die sich später nur teuer korrigieren lassen. Sie betreffen unter anderem:

  • Schnitt der Domäne: Welche Bereiche gehören zusammen, welche werden bewusst getrennt?
  • Datenhoheit: Welches System ist die führende Quelle für welche Information?
  • Integrationswege: Synchron oder ereignisgesteuert, und mit welchen Fehlerfällen ist zu rechnen?
  • Betrieb und Sicherheit: Wie wird deployt, wie wird beobachtet, wie werden Berechtigungen abgebildet?
  • Änderbarkeit: Welche Teile sollen sich häufig ändern dürfen, welche müssen stabil bleiben?

Für diese Fragen liefert ein Sprachmodell Vorschläge, aber keine Verantwortung. Die Abwägung zwischen Aufwand, Risiko und organisatorischer Realität bleibt eine menschliche Aufgabe – und sie setzt Kenntnis des konkreten Unternehmens voraus.

Konsequenzen für TYPO3- und Webprojekte

Gerade im Web zeigt sich der Effekt schnell. Ein Content-Management-System bildet Redaktionsprozesse, Rechtestrukturen und Inhaltstypen ab. Wenn diese Struktur unsauber modelliert ist, entstehen Workarounds: Felder, die zweckentfremdet werden, Inhaltselemente, die niemand mehr zuordnen kann, Freigabewege, die an der Organisation vorbeilaufen.

Solche Altlasten lassen sich mit generierter Umsetzungsgeschwindigkeit nicht auflösen – sie vervielfachen sich eher. Umgekehrt zahlt jede Stunde, die vorab in ein klares Modell von Inhaltstypen, Rollen und Publikationsprozessen fließt, doppelt zurück, wenn Umsetzung günstiger wird.

Praktisch bedeutet das eine Verschiebung im Projektzuschnitt:

  1. Mehr Zeit für Anforderungs- und Domänenworkshops mit dem Fachbereich, weniger für reine Spezifikationsdokumente.
  2. Entscheidungen dokumentieren, nicht nur Ergebnisse – damit später nachvollziehbar bleibt, warum eine Struktur so aussieht.
  3. Review und Tests aufwerten: Wer mehr Code in kürzerer Zeit erzeugt, braucht belastbare Prüfmechanismen, sonst verlagert sich der Aufwand nur in die Fehlersuche.
  4. Fachliche Begriffe konsequent im Code und in der Konfiguration verwenden, damit Modell und System nicht auseinanderdriften.

Kein Automatismus

Es wäre voreilig, aus dieser Entwicklung ein Ende der Programmierarbeit abzuleiten. Sinnvoll ist die vorsichtigere Lesart: Die Gewichte verschieben sich. Tippgeschwindigkeit wird weniger zum Unterscheidungsmerkmal, Urteilsvermögen mehr. Wie stark der Effekt in einem konkreten Projekt ausfällt, hängt von Domäne, Systemlandschaft und Reifegrad der Organisation ab.

Für Web- und Softwareprojekte heißt das konkret: Der kritische Pfad liegt zunehmend in der gemeinsamen Klärung mit dem Fachbereich, nicht in der Umsetzung. Wer sein Domänenmodell, seine Rollen und seine Prozesse sauber beschreibt, bekommt aus KI-gestützter Entwicklung tatsächlich Tempo heraus. Wer es nicht tut, bekommt vor allem schneller Ergebnisse, die niemand so bestellt hat.

Quellen