Das Feature, das niemand anfassen will
In jedem schnell gebauten Produkt gibt es irgendwann diese eine Stelle im Code. Was dahintersteckt — und wie man sie wieder beherrschbar macht.
Irgendwann in jedem Produkt gibt es sie: eine Datei, ein Modul, eine Klasse, über die niemand spricht, ohne gleichzeitig leise seufzend den Kopf zu schütteln. Das Feature, das funktioniert — solange man es nicht anfasst.
Es ist nicht kaputt. Es tut genau das, wofür es gebaut wurde. Aber jeder im Team weiß: Wenn hier etwas geändert wird, bricht woanders etwas. Niemand kann genau sagen, was. Also lässt man es stehen.
Wie es dazu kommt
KI-generierter Code entsteht oft in Schüben. Schnell, iterativ, auf ein unmittelbares Ziel hin. Das ist seine Stärke. Die Kehrseite: Zwischen den Schüben wächst implizites Wissen — über Abhängigkeiten, Seiteneffekte, unausgesprochene Annahmen —, das nirgendwo steht. Es lebt im Kopf derer, die dabei waren. Oder gar nicht.
Ein solches Modul ist keine Katastrophe. Es ist ein Warnsignal. Es zeigt, dass die Architektur an dieser Stelle nicht trägt — nicht weil der Code schlecht ist, sondern weil die Grenzen fehlen. Keine klaren Schnittstellen. Keine Tests, die sagen: „Bis hierher, und nicht weiter."
Was dahintersteckt
In den meisten Fällen, die ich sehe, ist das Problem nicht Komplexität. Es ist fehlende Modularität. Das Modul tut zu viel. Es kennt zu viel. Es entscheidet, was es nicht entscheiden sollte.
Wenn Zustand, Logik und Datenzugriff ohne Trennlinie aufeinandertreffen, entsteht ein Geflecht, das sich nicht mehr sauber lesen lässt — und damit auch nicht sauber ändern. Jede Änderung ist ein Griff ins Unbekannte.
Was hilft
Der erste Schritt ist Klarheit, nicht Neubau. Bevor etwas angefasst wird: verstehen, was das Modul wirklich tut. Was kommt rein, was geht raus, welche Annahmen hält es still.
Dann: Grenzen ziehen. Nicht alles auf einmal. Einen Teilbereich herauslösen, mit einer klaren Schnittstelle versehen, mit einem Test absichern. Dann den nächsten.
Das ist keine glamouröse Arbeit. Es gibt keinen Moment, in dem die Architektur plötzlich aufleuchtet und sich alles fügt. Aber nach einigen Iterationen passiert etwas: Das Modul wird wieder anfassbar. Nicht perfekt — aber beherrschbar.
Und das ist der Unterschied, der zählt.
Das ist ein typisches Muster der Architektur-Diagnose: Zuerst verstehen, welche Teile tragfähig sind und welche nicht — bevor etwas angefasst wird.