Seit KI-Systeme Code schreiben, kommentieren, umbauen und ganze Features in wenigen Minuten ausspucken, wirkt vieles plötzlich alt. Auch SOLID. Fünf Prinzipien aus einer Welt, in der Menschen noch jede Klasse selbst tippten, wirken im Zeitalter von Agent Coding fast ein wenig museal. Wer heute mit Copilot, Cursor, Codex oder spezialisierten Agenten arbeitet, könnte versucht sein zu sagen: Hauptsache, es läuft. Architektur kann später kommen. Die Maschine liefert schnell, der Rest ist Refactoring.

Genau hier beginnt das Problem.

Denn KI hat die alten Architekturfragen nicht erledigt. Sie verschärft sie. Nicht weil Modelle grundsätzlich schlechten Code erzeugen. Sondern weil sie mit erstaunlicher Geschwindigkeit Code erzeugen, der lokal plausibel und global unbefriedigend ist. Eine Methode sieht sauber aus. Die Klasse kompiliert. Der Testfall grün. Aber das Gesamtsystem verliert an Form. Verantwortlichkeiten diffundieren. Abhängigkeiten wachsen. Sonderfälle werden nicht entfernt, sondern kapselweise aufeinandergetürmt. Und weil alles zunächst vernünftig aussieht, merkt man den Schaden oft erst spät.

SOLID ist deshalb nicht obsolet geworden.

Die fünf Prinzipien waren nie Naturgesetze. Sie waren immer Rezepte gegen strukturellen Verfall. Wer sie dogmatisch anwendet, produziert schnell jene Art von Enterprise-Code, die mehr Schichten als Erkenntnis enthält: Interfaces ohne Not, Fabriken für triviale Objekte, winzige Klassen mit eindrucksvollen Namen und lächerlich wenig Substanz. Gerade in der Java- und C#-Welt wurde SOLID oft missverstanden als Lizenz zum Aufblähen. Aus einer einfachen Funktion wird eine Service-Landschaft. Das war schon vor KI unerfreulich. Mit KI wird es gefährlich, weil Maschinen solche Muster mit großem Fleiß reproduzieren.

Agenten lieben formale Muster. Sie erkennen bekannte Strukturen, variieren sie zuverlässig und erzeugen dabei den Schein von Professionalität. Was dabei leicht verloren geht, ist die Frage, ob die zusätzliche Abstraktion in diesem konkreten Fall überhaupt einen Nutzen hat. Ein menschlicher Entwickler spürt oft noch eine gewisse Reibung: Muss ich dafür wirklich ein Interface einführen? Ist diese Entkopplung real oder nur hypothetisch? Ein Agent kennt diese Müdigkeit nicht. Er baut, was in Trainingsdaten oft gut aussah. Nicht unbedingt, was im aktuellen Projekt richtig ist.

Gerade deshalb sind die Grundgedanken von SOLID weiterhin relevant – aber nicht als Checkliste, sondern als Gegengewicht.

Das zeigt sich bereits beim ersten Prinzip, dem Single Responsibility Principle. In seiner Karikatur führt es zu atomisierten Mikroklassen, die jeweils nur noch eine atomare Idee enthalten. In seiner vernünftigen Form sagt es etwas sehr Nützliches: Ein Modul sollte einen klaren Grund haben, geändert zu werden. Für KI-generierten Code ist das zentral. Denn KI neigt dazu, Anforderungen, Infrastruktur, Validierung, Logging und Fehlerbehandlung in dieselben Bereiche zu schieben, solange das Ergebnis funktional bleibt. Das Resultat ist keine Katastrophe auf den ersten Blick, aber ein Wartungsproblem auf den zweiten. Nicht weil eine Methode zu lang ist, sondern weil sie zu viele Gründe hat, kaputtzugehen.

Auch das Open/Closed Principle wird oft überschätzt und falsch eingesetzt. In der Theorie klingt es elegant: offen für Erweiterung, geschlossen für Änderung. In der Praxis endet das nicht selten in spekulativer Architektur. Man baut Erweiterungspunkte für Fälle, die nie eintreten. KI beschleunigt genau diese Versuchung. Sie kann in Sekunden Plugin-Systeme, Basisklassen, Strategien und Events erzeugen, bevor überhaupt klar ist, ob das Produkt den nächsten Monat überlebt. Der kritische Punkt lautet daher nicht: OCP ja oder nein? Sondern: Wo existiert echte Variabilität? Wo lohnt sich ein stabiler Erweiterungspunkt wirklich? Ein reifer Umgang mit SOLID bedeutet, die Grenze zwischen Vorsorge und Fantasie zu kennen.

Besonders interessant wird es bei Interface Segregation und Dependency Inversion. Hier zeigt sich, warum SOLID im KI-Zeitalter eher wichtiger als unwichtiger wird. Denn Agenten arbeiten besser, wenn Grenzen explizit sind. Ein kleines, sauberes Interface ist nicht nur für Menschen lesbar. Es ist auch für Maschinen ein klarer Vertrag. Je eindeutiger Zuständigkeiten und Schnittstellen beschrieben sind, desto geringer wird die Wahrscheinlichkeit, dass der Agent implizite Annahmen trifft, Nebenwirkungen erzeugt oder Schichten verletzt. Dependency Inversion ist damit nicht bloß ein Testbarkeitsprinzip. Es ist auch ein Mittel gegen den architektonischen Wildwuchs, den KI sonst mit atemberaubender Produktivität erzeugt.

Liskov Substitution bleibt das am wenigsten populäre, aber vielleicht unterschätzteste Prinzip. Viele KI-Systeme produzieren Vererbungsstrukturen, die syntaktisch sauber und semantisch fragwürdig sind. Die Basisklasse verspricht etwas, das die Unterklasse nur unter Zusatzbedingungen erfüllt. Solche Fehler sind heimtückisch, weil sie nicht wie Syntaxfehler rot aufleuchten, sondern sich nur in Randfällen, Seiteneffekten und fragilen Annahmen zeigen. Gerade weil Agenten gut darin sind, bestehende Muster formal nachzubilden, braucht es hier menschliche Strenge. Nicht jede gemeinsame Eigenschaft rechtfertigt Vererbung. Nicht jede Ähnlichkeit ist Substituierbarkeit.

Die eigentliche Frage lautet also nicht, ob SOLID noch gilt. Die eigentliche Frage lautet, wofür es heute gebraucht wird.

Früher war SOLID vor allem eine Disziplin für Teams, die komplexe Systeme über Jahre stabil halten wollten. Heute ist es zusätzlich ein Korrektiv gegen eine neue Art von Beschleunigung. KI senkt die Kosten des Schreibens, aber nicht die Kosten schlechter Struktur. Im Gegenteil: Wenn Code fast kostenlos erzeugt werden kann, steigt das Risiko, dass zu viel davon entsteht. Nicht zu wenig. Das Engpassproblem verlagert sich vom Tippen zum Urteilen. Der Entwickler der Gegenwart produziert nicht mehr primär Zeichen. Er trifft Architekturentscheidungen, verwirft falsche Abstraktionen und schützt das System vor höflich formuliertem Unsinn.

Deshalb ist die vielleicht wichtigste Einsicht: SOLID ist heute weniger eine Anleitung zum Schreiben als eine Anleitung zum Weglassen.

Nicht jede Klasse braucht ein Interface. Nicht jede Änderung rechtfertigt ein Pattern. Nicht jede Wiederholung ist Fehler; manchmal ist sie billiger als eine verfrühte Abstraktion. Wer mit KI arbeitet, sollte SOLID nicht als Einladung zum Ausbau verstehen, sondern als Prüfstein: Macht diese Struktur das System robuster, verständlicher und veränderbarer? Oder macht sie es nur wichtiger, als es ist?

Die brauchbare Antwort auf die Ausgangsfrage ist daher unbequem: SOLID ist weder überholt noch sakrosankt. Als Dogma ist es so gefährlich wie eh und je. Als disziplinierende Denkform ist es in Zeiten von Agent Coding sogar wichtiger geworden.

Er sollte es als Instrument verstehen, um eine einfache Frage immer wieder brutal ehrlich zu beantworten: Macht dieser Code das System klarer – oder nur größer?