Alle Artikel
KI & Software5. Oktober 2026 · 8 Min. Lesezeit

Wenn KI den Code schreibt: Leitplanken gegen die neue Wartungslast

KI-Assistenten schreiben in Minuten, wofür Teams früher Tage brauchten. Das macht Software schneller – und erzeugt Code, den im Team niemand mehr ganz versteht. Wer beides beherrschen will, braucht Leitplanken, die nicht verhandeln.

Was wir mit Wartungslast meinen

Wartungslast ist alles, was jede künftige Änderung an einem System teurer macht: Code, den niemand mehr überblickt, fehlende Tests, veraltete Komponenten und Wissen, das nur in einzelnen Köpfen steckt. Sie entsteht nicht durch schlechte Arbeit, sondern durch Tempo. Wer unter Zeitdruck liefert, verschiebt das Aufräumen auf später – und später kommt selten.

Neu ist, wie stark KI-Assistenten diese Rechnung in beide Richtungen verschieben:

  • Sie senken die Kosten, Bestehendes zu verstehen und umzubauen. Alten Code erklären lassen, fehlende Tests nachziehen, Dokumentation rekonstruieren, Module in eine neue Sprache übertragen – was früher Monate dauerte, ist heute in Wochen machbar.
  • Sie erhöhen das Tempo, mit dem neue Last entsteht. Ein Assistent erzeugt mehr Code, als ein Team sorgfältig prüfen kann. Ohne Gegenmaßnahmen wächst die Wartungslast damit schneller als je zuvor.

Beides gilt gleichzeitig. Deshalb entscheidet nicht das Werkzeug über das Ergebnis, sondern das Vorgehen drumherum.

Messen, bevor man urteilt

Ob ein System träge geworden ist, lässt sich messen statt erfragen. Die Forschung hinter dem Buch „Accelerate“ hat vier Kennzahlen etabliert, die sich direkt aus Versionsverwaltung und Build-System ablesen lassen:

  • Lieferzeit: Wie lange dauert es, bis eine Änderung im Betrieb ankommt?
  • Häufigkeit: Wie oft wird ausgeliefert?
  • Fehlerquote: Wie viele Auslieferungen verursachen eine Störung?
  • Wiederherstellungszeit: Wie schnell ist eine Störung behoben?

Dazu kommt die Frage, wo es hakt. Adam Tornhill hat dafür ein einfaches Prinzip beschrieben: Brennpunkte sind Stellen, die zugleich oft geändert werden und schwer verständlich sind. Beides steht in der Änderungsgeschichte. KI-Assistenten helfen anschließend, diese Stellen in Klartext zu erklären – die Bewertung bleibt beim Menschen.

Verhalten festhalten, bevor man ändert

Der gefährlichste Moment ist die erste Änderung an Code, den niemand mehr versteht. Michael Feathers hat dafür sogenannte Charakterisierungstests beschrieben: Tests, die nicht prüfen, was das System tun sollte, sondern festhalten, was es heute tut. Danach fällt jede ungewollte Abweichung sofort auf.

Früher war das mühsame Handarbeit. Heute erzeugen KI-Assistenten solche Tests in großer Zahl. Die menschliche Aufgabe verschiebt sich: nicht mehr schreiben, sondern entscheiden, ob das festgehaltene Verhalten wirklich gewollt ist – oder ob es ein alter Fehler ist, auf den sich inzwischen jemand verlässt.

Schritt für Schritt ablösen statt alles neu bauen

Der große Neubau mit Stichtag ist verlockend und riskant. Martin Fowler hat das Gegenmodell beschrieben: Neue Teile übernehmen nach und nach die Aufgaben der alten, bis das Altsystem nichts mehr zu tun hat. Beide laufen eine Zeit lang parallel, und ihre Ergebnisse werden verglichen.

KI-Assistenten machen jeden einzelnen Schritt günstiger: Ein Modul nach dem anderen wird übertragen, und der Vergleich der Ergebnisse zeigt, ob das neue Teil dasselbe leistet wie das alte. Ein Neubau ist dadurch weniger teuer als früher – das Risiko eines Stichtags, an dem alles auf einmal wechselt, bleibt aber.

Leitplanken, die nicht verhandeln

Die wichtigste Gegenmaßnahme gegen neue Wartungslast ist unspektakulär: automatische Prüfungen, die bei jedem Build laufen und im Zweifel abbrechen. Was eine Regel ist, gehört in eine Prüfung – nicht in ein Wiki, das niemand liest.

Zwei Beispiele aus unserer eigenen Arbeit:

  • Eine Umbenennung über mehr als tausend Stellen. Beim Wechsel unseres eigenen Markennamens hat eine mechanische Ersetzung einen Variablennamen im Code zerstört. Gefunden hat das kein Mensch, sondern die Typprüfung im Build – bevor die Änderung live ging.
  • Eine Regel, die sich selbst durchsetzt. In einem unserer Projekte darf die Anwendung keine Verbindung nach draußen aufbauen, weil die verarbeiteten Daten zur kritischen Infrastruktur gehören. Diese Regel steht nicht nur in der Dokumentation: Eine Prüfung durchsucht bei jeder Änderung den Code und bricht ab, wenn jemand – Mensch oder Assistent – eine solche Verbindung einbaut.

Gerade wenn ein Assistent Code erzeugt, sind solche Prüfungen der Unterschied zwischen Tempo und Wildwuchs.

„KI macht Hypothesen nicht wahr. Sie macht sie schneller testbar.“ Für Software gilt dasselbe: KI macht Code nicht richtig – sie macht ihn schneller prüfbar, wenn man die Prüfungen gebaut hat.

Wissen in Dateien, nicht in Köpfen

Ein Teil jeder Wartungslast ist Wissen, das nur bei einzelnen Personen liegt: warum etwas so gebaut ist, welche Abkürzung gefährlich ist, welcher Fehler schon zweimal passiert ist. Wir halten dieses Wissen in Dateien direkt im Projekt fest – Regeln, Entscheidungen, Fallstricke. Jede neue Arbeitssitzung liest sie zuerst, ob ein Mensch oder ein KI-Assistent sie beginnt.

Der Nebeneffekt ist für Unternehmen oft der wichtigste: Das System hängt nicht mehr an einer Person. Das zählt bei jedem Personalwechsel – und spätestens, wenn ein Käufer oder Investor nach dem Zustand der Software fragt.

Warum das Thema dringlicher wird

Veraltete Komponenten sind nicht mehr nur ein technisches Ärgernis. Mit der deutschen Umsetzung der NIS2-Richtlinie müssen deutlich mehr Unternehmen ihre Lieferkette absichern, und der Cyber Resilience Act verpflichtet Hersteller digitaler Produkte seit September 2026, ausgenutzte Schwachstellen zu melden. Wer nicht weiß, welche Fremdkomponenten in seiner Software stecken, kann diese Pflichten kaum erfüllen.

Was das für Entscheider heißt

  • Erst messen, dann entscheiden. Die vier Kennzahlen und die Brennpunkte zeigen in wenigen Tagen, wo ein System wirklich bremst.
  • Ehrlich bleiben. Nicht jedes System muss erneuert werden. Manchmal ist es klüger, einen Teil stabil zu halten und das Neue daneben zu bauen. Wir sagen das auch, wenn es gegen ein Projekt spricht.
  • KI einsetzen, aber nicht ungeprüft. Die Werkzeuge sind stark genug, um Erneuerungen in Wochen statt in Jahren zu schaffen – wenn Tests und Prüfungen mitwachsen.
  • Leitplanken übergeben, nicht nur Code. Ein erneuertes System bleibt nur dann beweglich, wenn die Prüfungen weiterlaufen, nachdem das Projekt vorbei ist.

Fazit

KI-Assistenten haben die Kosten verschoben: Bestehende Systeme zu verstehen und zu erneuern ist so günstig wie nie. Gleichzeitig entsteht neue Wartungslast schneller als je zuvor. Wer beides zusammenbringt – messen, Verhalten festhalten, schrittweise ablösen und Regeln automatisch durchsetzen –, gewinnt die Geschwindigkeit, ohne sie mit dem nächsten Stillstand zu bezahlen.

C
Clemens Pompeÿ
Gründer, Vencly GmbH · Umsetzung mit KI-Assistenten

Bremst Ihre Software das Neue aus?

Wenn Sie mindestens zwei der folgenden Aussagen mit Ja beantworten, lohnt sich ein Gespräch:

  • Eine kleine Änderung braucht vom Auftrag bis zum Betrieb mehrere Wochen.
  • An bestimmte Teile des Systems trauen sich nur noch ein oder zwei Personen heran.
  • Ihr Team nutzt KI-Assistenten, aber niemand prüft systematisch, was sie erzeugen.
  • Sie wissen nicht genau, welche Fremdkomponenten in Ihrer Software stecken und wie alt sie sind.
  • Ein Käufer, Prüfer oder Investor wird bald nach dem Zustand Ihrer Software fragen.
da39dd9