Seit KI-Assistenten in der Softwareentwicklung breiter eingesetzt werden, rückt ein Thema in den Vordergrund, das lange als lästige Pflicht galt: die Dokumentation. In einem Interview zum Ansatz Continuous Architecture – einem Vorgehen, das Architekturarbeit als fortlaufende Tätigkeit statt als einmalige Planungsphase versteht – beschreibt Murat Erder, wie KI die Entwicklung verändern kann, ohne die grundlegenden Prinzipien guter Architektur außer Kraft zu setzen. Genau in dieser Kombination liegt der praktische Kern: Die Werkzeuge ändern sich, die Anforderungen an Struktur und Nachvollziehbarkeit bleiben.

Für Unternehmen, die Software betreiben oder entwickeln lassen, ist das eine überraschend handfeste Aussage. Denn sie verschiebt die Frage weg von „Welches Modell nutzen wir?“ hin zu „Wie gut ist unser Projekt eigentlich beschrieben?“.

Warum Kontext zum begrenzenden Faktor wird

KI-Assistenten erzeugen Vorschläge auf Basis dessen, was sie sehen: Quellcode, Konfigurationen, Kommentare, Tickets, Architekturbeschreibungen. Dieses Material bildet den Kontext. Ist er lückenhaft oder widersprüchlich, entstehen Vorschläge, die formal plausibel wirken, aber nicht zum tatsächlichen System passen.

Typische Muster kennen viele Teams aus dem Alltag:

  • Ein Architekturdiagramm zeigt einen Dienst, der längst abgelöst wurde.
  • Eine README beschreibt ein Setup, das seit zwei Releases nicht mehr funktioniert.
  • Konventionen für Namensgebung oder Fehlerbehandlung existieren – aber nur im Kopf von zwei Personen.

Solche Lücken waren immer schon teuer, fielen aber vor allem beim Onboarding neuer Teammitglieder auf. Mit KI-Unterstützung wird derselbe Effekt alltäglich: Das Werkzeug übernimmt die veralteten Annahmen und reproduziert sie an neuen Stellen im Code.

Dokumentation ist kein Selbstzweck mehr

Bisher war Dokumentation häufig eine Investition mit diffusem Rückfluss. Sie zahlte sich bei Personalwechseln aus, bei Audits, bei Übergaben an einen neuen Dienstleister – also selten und schwer messbar. Das ändert sich, wenn Dokumentation zur Eingabe für ein Werkzeug wird, das täglich im Einsatz ist.

Praktisch heißt das: Ein knapper, aber aktueller Überblick über Systemgrenzen, Datenflüsse und bewusste Entscheidungen wirkt unmittelbar auf die Qualität der Vorschläge. Umgekehrt wird jede nicht gepflegte Seite zu einem Störsignal. Wer aufräumt, tut das also nicht mehr für einen hypothetischen Nachfolger, sondern für den nächsten Arbeitstag.

Hilfreich ist dabei eine ehrliche Reduktion. Lieber zehn Seiten, die stimmen, als achtzig Seiten, von denen niemand weiß, welche davon noch gelten. Dokumentation, die niemand verantwortet, sollte entweder einen Eigentümer bekommen oder entfernt werden.

Architekturprinzipien bleiben der Maßstab

Die zweite Hälfte der Aussage ist ebenso wichtig: KI setzt gute Architektur nicht außer Kraft. Klare Verantwortlichkeiten zwischen Komponenten, saubere Schnittstellen, bewusste Entscheidungen über Abhängigkeiten – all das bleibt notwendig, unabhängig davon, wer oder was den Code schreibt.

Eher verstärkt sich der Effekt in beide Richtungen. In einem gut geschnittenen System lassen sich Änderungen lokal halten, Tests greifen zuverlässig, und ein Assistent kann innerhalb klarer Grenzen arbeiten. In einem verflochtenen System ohne erkennbare Struktur beschleunigt dasselbe Werkzeug vor allem die Entstehung weiterer Verflechtungen.

Deshalb ist die Reihenfolge entscheidend: Erst Struktur und Beschreibung, dann Geschwindigkeit. Wer umgekehrt vorgeht, erhöht den Durchsatz an Code, nicht den Wert der Software.

Was Teams konkret tun können

Ein Aufräumprojekt muss nicht groß sein. Sinnvoll ist ein schrittweises Vorgehen, das sich in bestehende Abläufe einfügt:

  1. Bestandsaufnahme: Welche Dokumente existieren, wer hat sie zuletzt angefasst, welche sind noch gültig? Alles Unklare kommt auf eine Liste.
  2. Entscheidungen festhalten: Kurze Notizen zu zentralen Architekturentscheidungen – was wurde gewählt, welche Alternativen gab es, warum fiel die Wahl so aus.
  3. Nähe zum Code: Beschreibungen dort ablegen, wo sie im Arbeitsalltag auffallen, idealerweise im Repository statt in einem selten geöffneten Ablagesystem.
  4. Pflege in den Prozess einbauen: Dokumentationsänderungen gehören in dieselbe Änderung wie der Code und werden mitgeprüft.
  5. Konventionen explizit machen: Benennungen, Fehlerbehandlung, Teststrategie – als Text, nicht als mündliche Überlieferung.

Der Aufwand dafür ist überschaubar, vor allem im Vergleich zu den Folgekosten falscher Annahmen, die sich über Monate im System verteilen.

Einordnung für Projekte und Budgets

Für Entscheiderinnen und Entscheider verschiebt sich damit die Argumentation. Ausgaben für Dokumentation und Architekturarbeit lassen sich nicht mehr nur mit Risikovorsorge begründen, sondern mit Entwicklungstempo und Codequalität im laufenden Betrieb. Wer eine KI-gestützte Arbeitsweise einführen will, sollte dafür Budget einplanen, bevor Lizenzen für Werkzeuge gekauft werden.

Auch bei Ausschreibungen und Dienstleisterwechseln gewinnt der Punkt an Gewicht. Ein System, das sauber beschrieben ist, lässt sich schneller übernehmen, realistischer schätzen und mit geringerem Risiko weiterentwickeln – ob mit oder ohne KI-Unterstützung.

Was das für Web- und Softwareprojekte heißt

In Web- und TYPO3-Projekten entscheidet künftig weniger die Frage, ob ein Team KI-Werkzeuge einsetzt, sondern wie gut das Projekt für solche Werkzeuge beschrieben ist. Aktuelle Architekturübersichten, dokumentierte Entscheidungen und verbindliche Konventionen werden damit zu einem direkten Produktivitätsfaktor, nicht zu einer nachgelagerten Fleißaufgabe. Wer jetzt in Ordnung investiert, verbessert gleichzeitig die Wartbarkeit, die Übergabefähigkeit und den Ertrag aus jedem weiteren Automatisierungsschritt.

Quellen