Brownfield-Ingenieurstrategie

Wie man eine bestehende Codebasis zur KI-nativen Entwicklung überführt – wann man in-place saniert, wann man eine Strangler-Fig-Migration durchführt, wann man neu aufbaut, wann man isoliert, und die Methodik, die jeden Ansatz handhabbar macht.

Ist Ihre Codebasis tatsächlich Brownfield?

Die vier Modi auf dieser Seite gelten für Brownfield-Codebasen – bestehenden Code mit angesammelten Entscheidungen, Produktionsnutzern und einem Team, das darin arbeitet. Vor der Auswahl eines Modus den Codebasiszustand prüfen. Drei treten in der Praxis auf:

Zustand	Was es bedeutet	Was zu tun ist
Greenfield (in Entwicklung, vor GA)	Neue Codebasis, noch nicht in Produktion, oder in Produktion, aber jung genug, dass der gesamte Code noch aktiv gestaltet wird. Niedrige Reifewerte sind hier Planungsentscheidungen, keine technischen Schulden.	Entwicklung fortsetzen. Reifelücken im Roadmap-Timing schließen. Die Codereife-Bewertung zum GA-Zeitpunkt erneut ausführen und noch nicht geschlossene Lücken dann als Brownfield behandeln.
Brownfield (Produktion, angesammelt)	Code existiert, läuft in Produktion, hat echte Nutzer, trägt Jahre von Entscheidungen. Reifelücken sind technische Schulden.	Einen Modus mit den vier unten auswählen.
Hybrid	Ein neuer, Stufe-5-bereiter Dienst innerhalb einer Organisation, deren andere Systeme Brownfield sind. Der neue Dienst ist Greenfield; die Legacy-Integrationsgrenze ist Brownfield.	Den neuen Dienst als Greenfield bewerten. Für jede Legacy-Grenze separat einen Modus auswählen. Häufigste Version: eine neue KI-native App, die Daten über eine Legacy-API liest oder schreibt.

Die vier Modi

Jeder Modus ist ein anderer Weg zu Stufe 5. Die Frage ist nicht „welchen Modus hat das Team Kapazität für" – das ist eine nachgelagerte Ressourcenallokationsentscheidung. Die Frage ist „welcher Modus ist für diese Codebasis der kürzeste Weg zu Stufe 5, basierend auf der Evidenz." Teamgröße, strategische Prioritäten und Opportunitätskosten sind Inputs, die ein Mensch nach dem Lesen der Empfehlung abwägt; sie sind keine Inputs zur Empfehlung selbst.

Modus	Was „Weg zu Ebene 5" bedeutet
In-place-Sanierung	Stufe 5 geschieht in dieser Codebasis über stufenweisen Harness-Aufbau.
Strangler-Fig	Stufe 5 geschieht schrittweise – neue Teile werden Stufe-5-bereit gebaut, während alte Teile ausgemustert werden.
Vollständiger Neuaufbau	Stufe 5 geschieht in einer neuen Version dieser Codebasis; alte Version wird bei der Umstellung ausgemustert.
Isolieren und umgehen	Stufe 5 geschieht nicht in dieser Codebasis. Es geschieht in neuen Stufe-5-bereiten Codebasen daneben; diese bleibt eingefroren.

Modus 1 – In-place-Sanierung

Den bestehenden Code behalten. In das Harness investieren: Tests, Typen, Konventionen, dokumentierter Intent. KI einsetzen, um die Sanierung selbst durch die Forschung-Überprüfung-Neuaufbau-Methodik zu beschleunigen.

Wann dieser Modus richtig ist: Die Architektur ist grundlegend solide (das Problem ist das Harness, nicht die Struktur); das Team hat mit der aktuellen Codebasis verknüpftes Domain-Wissen; die Geschäftskontinuität kann keine parallelen Systeme tolerieren.

Das Risiko: Sie sanieren das Harness und der Code bleibt grundlegend auf Stufe 3, weil die Struktur sich widersetzt. Sie haben sechs Monate investiert und können Sprosse 5 immer noch nicht erreichen.

Modus 2 – Strangler-Fig-Migration

Neue Funktionalität Stufe-5-bereit neben dem alten System aufbauen. Traffic durch eine Fassade leiten. Teile des alten Systems nach und nach entfernen, sobald die neuen sich bewährt haben. Martin Fowlers Strangler Fig Pattern ist die kanonische Referenz.

Wann dieser Modus richtig ist: Das bestehende System hat klare Nähte für die Extraktion; Geschäftskontinuität ist wichtig; die Neuaufbauzeit für das gesamte System würde die Geschäftstoleranz überschreiten.

Das Risiko: Nahtidentifikation ist schwierig. Wenn die Nähte nicht sauber sind, entstehen zwei gekoppelte Systeme statt einem – doppelte Komplexität, kein Nutzen.

Modus 3 – Vollständiger Neuaufbau

Von vorne beginnen mit einer Stufe-5-bereiten Codebasis. Die zwei Systeme parallel betreiben, Daten migrieren, beim Umstellen wechseln, wenn das neue System gleichwertig oder besser ist.

Wann dieser Modus richtig ist: Die bestehende Struktur verhindert aktiv die Arbeit, die getan werden muss; die Kosten der fortgesetzten Sanierung übersteigen die Neuaufbaukosten; die durch KI unterstützte Neuaufbau-Wirtschaftlichkeit macht den Neuaufbau in einem Zeitrahmen realisierbar, der zuvor nicht viable war; die Domain ist gut verstanden (man ersetzt Wie, nicht entdeckt Was neu).

Das Risiko: Der Zweitsystem-Effekt. Neuaufbauten sammeln jede aufgeschobene Feature-Anforderung des alten Systems und scheitern unter ihrem eigenen Gewicht. Den Scope diszipliniert halten.

Modus 4 – Isolieren und umgehen

Das Legacy einfrieren. Es von menschlichen Händen auf dem Niveau pflegen, das das Geschäft noch erfordert. Neuen Wert als neue Stufe-5-bereite Apps daneben aufbauen, durch die API- oder Datenschicht leiten, die bereits funktioniert. Nicht versuchen, das Legacy selbst zu modernisieren.

Wann dieser Modus richtig ist: Sanierungskosten übersteigen den verbleibenden Wert des Legacy; neuer Wert kann parallel ohne tiefe Integration geliefert werden; das Legacy hat eine praktikable Integrationsnaht (API, Datenbank, Queue), durch die neue Apps routen können; das Geschäft toleriert einen Wartungsmodus für einen längeren Zeitraum.

Das Risiko: Umgangenes Legacy häuft im Laufe der Zeit mehr technische Schulden an. Irgendwann erzwingt etwas die Entscheidung – ein Sicherheitspatch, der nicht angewendet werden kann, ein Plattform-EOL, ein Datenmodell, das neue Anforderungen nicht halten kann. Isolieren und umgehen kauft Zeit; es löst das Problem nicht.

„Nicht investieren" ist hier ein legitimes Ergebnis. Nicht jedes Legacy ist es wert, repariert zu werden. Das Signal: Man schreibt seinen dritten Sanierungsplan für dasselbe Modul, die Tests, die man letztes Quartal hinzugefügt hat, sind nicht mehr grün, und das Geschäft liefert durch diesen Code immer noch Wert. Das ist keine Codebasis, die auf Modernisierung wartet. Das ist eine Codebasis, die auf Ersatz wartet.

Entscheidungskriterien

Frage	Sanieren	Strangler	Neuaufbau	Isolieren
Ist die Architektur grundlegend solide?	Ja	Größtenteils	Nein	Spielt keine Rolle
Gibt es klare Nähte für die Extraktion?	Nicht zutreffend	Ja	Nicht zutreffend	Mindestens ein nutzbarer Integrationspunkt
Kann das Team die Systemabsicht beschreiben?	Ja	Ja	Ja (oder Black Box zu Blueprint verwenden)	Für Legacy nicht erforderlich
Kann das Geschäft parallele Systeme tolerieren?	Nicht zutreffend	Ja	Ja	Ja
Ist die fortlaufende Schuldenzahlung günstiger als der Ersatz?	Ja	Teilweise	Nein	Ja, während neuer Wert daneben geliefert wird
Hat das Legacy noch erhaltenswerten Wert?	Ja	Ja	Ja	Ja, aber nicht wert zu reparieren
Haben Sie Teamkapazität für die schwierigere Option?	Am niedrigsten	Mittel	Am höchsten	Niedrig (das Legacy bleibt eingefroren)

Kein klares Ja in der Neuaufbau-Reihe? Nicht neu aufbauen. Der Zweitsystem-Effekt bestraft Teams, die sich für den Neuaufbau aus anderen Gründen als der Passform entschieden haben.

Mehrere „Nein"-Antworten über Sanierung/Strangler/Neuaufbau, aber Legacy hat noch Geschäftswert? Isolieren und umgehen ist wahrscheinlich der richtige Modus.

Das Technical Debt Quadrant schärft die Neuaufbau-Entscheidung:

Schuldentyp	Ursache	Sanierung
Klug, absichtlich	Wir haben den Shortcut wissentlich gemacht.	Meist sanierbar.
Klug, unabsichtlich	Wir haben später Besseres gelernt.	Sanierbar, aber prüfen, ob das Lernen strukturelle Entscheidungen ungültig gemacht hat.
Leichtsinnig, absichtlich	Wir wussten es besser, haben es trotzdem getan.	Oft mit Disziplin sanierbar, signalisiert aber Prozesspprobleme, die die Codebasis überleben.
Leichtsinnig, unabsichtlich	Wir wussten nicht, was wir taten.	Neuaufbau-Kandidat. Die Struktur spiegelt Unwissenheit wider, die späteres Wissen nicht in-place rückgängig machen kann.

Auf Ihrer Codebase ausprobieren

codebase-readiness

Brauchen Sie Hilfe bei der Auswahl des richtigen Modus? Das Codebase-Readiness-Claude-Code-Skill bewertet eine Codebasis anhand des Neun-Dimensionen-Reife-Modells und empfiehlt einen Weg zu Ebene 5 – einschließlich welcher der vier Modi zutrifft.

Auf GitHub ansehen

Die Methodik: Forschung, Überprüfung, Neuaufbau

Veröffentlicht von Fowler und EPAM in Research, Review, Rebuild, ist dies die konkreteste verfügbare Brownfield-Methodik. Sie gilt direkt für Modi 1–3; in Modus 4 gilt sie für die Integrationsnaht, auch wenn das Legacy eingefroren bleibt. Der direkte Agenteneinsatz in einer undurchsichtigen Legacy-Codebasis produziert zuverlässig selbstbewusst falschen Output. Die phasengesteuerte Struktur verhindert dies.

Phase 1 – Forschung. KI analysiert den bestehenden Code: rekonstruiert Intent, extrahiert Verhaltensverträge, identifiziert Muster, dokumentiert den Abhängigkeitsgraphen. Tools wie MCP-Konnektoren lassen Agenten die Codebasis systematisch traversieren. Output: eine Intent-Karte – was das System tut, unabhängig davon, wie es strukturiert ist.

Phase 2 – Überprüfung. Domain-Experten validieren die Intent-Karte. KI kann extrahieren, was der Code tut. Nur Menschen können absichtliches Verhalten von historischem Unfall unterscheiden. Das ist der Durchsatz-Engpass – im Bahmni-Fallstudie (AngularJS zu React) dauerte die menschliche Überprüfung etwa 20 Minuten pro Komponente. Kapazität für die Überprüfung planen, nicht nur für die Generierung.

Phase 3 – Neuaufbau. Mit validiertem Intent generiert KI Ersatzcode mit minimaler Ambiguität. Bei Bahmni: etwa 2 $ pro Komponente in unter einer Stunde, gegenüber 3–6 Tagen manuell. Die Wirtschaftlichkeit ist überzeugend, wenn Phasen 1 und 2 diszipliniert sind – und schlechter als traditionell, wenn sie übersprungen werden.

Die Reihenfolge ist tragend. Teams, die Forschung und Überprüfung überspringen, um schneller zum Neuaufbau zu gelangen, sparen keine Zeit; sie produzieren falsche Outputs schneller und verbringen die gesparte Zeit mit dem Debuggen halluzinierten Verhaltens.

Wirtschaftlichkeit: Was die Zahlen implizieren

Der Bahmni-Datenpunkt ordnet die Mathematik neu: Was eine 18-monatige Migration war, wird eine 6-monatige Migration, bei der der Engpass Reviewer-Kapazität ist, nicht Engineering-Stunden. Die eigene Erfahrung variiert je nach Architektur, Testabdeckung und Domain-Komplexität – und die Wirtschaftlichkeit funktioniert nur, wenn Forschung und Überprüfung diszipliniert sind. Das Überspringen dieser Phasen bricht die Beschleunigung.

Black Box zu Blueprint: Intent rückwärts entwickeln

Wenn das ursprüngliche Team gegangen ist, die Dokumentation falsch ist und der Code die einzige Wahrheitsquelle ist, wird Phase 1 zu einem Reverse-Engineering-Problem. Fowlers Black Box to Blueprint beschreibt fünf Techniken:

UI-Schicht-Rekonstruktion – Verhalten aus der Benutzeroberfläche und ihren Zustandsübergängen ableiten.
Change Data Capture – beobachten, wie das System Daten in der Produktion modifiziert, um Geschäftslogik abzuleiten.
Server-Logik-Inferenz – API-Grenzen und Anforderungs-/Antwortmuster analysieren, um die dahinterstehende Logik zu rekonstruieren.
Binär-Archäologie – aus Binaries, Logs und externen Schnittstellen rekonstruieren, wenn die Quelle verloren ist.
Progressive Mehrfachdurchlauf-Anreicherung – Artefakte in handhabbare Chunks aufteilen, partielle Erkenntnisse pro Durchlauf extrahieren, Kontext schrittweise aufbauen. Einmalige Ganzsystem-Analyse scheitert bei großem Maßstab.

Zwei Disziplinen sind nicht verhandelbar: Triangulation (jede Hypothese über Intent über zwei unabhängige Quellen bestätigt – UI + Logs, API + Datenbank, Code + beobachtetes Verhalten) und Herkunftsverfolgung (für jede Behauptung die zugrundeliegende Evidenz aufzeichnen, damit unzuverlässige Evidenz später identifizierbar ist).

Spec-from-Code: Die Brownfield-Inversion

Die KI-Ausführungsstandards und der Spezifikations-Leitfaden setzen voraus, dass Spezifikationen dem Code vorangehen. Brownfield invertiert dies: Der Code existiert bereits, und die Spezifikation muss daraus rückwärts entwickelt werden. Das ist ein anderer Workflow.

Spec-driven-Development-Tools wie spec-kit, Kiro und Tessl sind primär Greenfield-orientiert. Spec-kits „Brownfield Bootstrap" ist die Ausnahme: bestehende Architektur automatisch entdecken, um eine Constitution (dauerhaft geltende Leitprinzipien) zu etablieren, dann spec-driven Development auf neue Features anwenden, während Forschung und Überprüfung die Legacy-Oberfläche aufholen.

Das Muster, das funktioniert:

Die implizite Spezifikation extrahieren. Was tut das System tatsächlich? Siehe die Brownfield-Aufnahmesequenz des KI-Labors für die disziplinierte Version.
End-to-End-Szenarien schreiben, die das aktuelle erwartete Verhalten aus der extrahierten Spezifikation beschreiben.
Szenarien auf dem bestehenden Code verifizieren. Das wird Ihr Regressions-Harness.
Spec-first auf alle neuen Arbeiten anwenden. Keine Ausnahmen.
Komponente für Komponente Strangler-migrieren, mit den Szenarien als Schutz während der Migration.

Der erste Schritt ist die schwerste menschliche Arbeit im Übergang. Agenten können dokumentieren, was das System tut; nur Menschen können antworten, ob das ist, was es sollte.

Häufige Fallstricke

Den menschlichen Review-Engpass unterschätzen. KI-Generierungskosten sind um Größenordnungen gesunken. Menschliche Review-Kosten nicht. Reviewer-Kapazität als erstklassige Einschränkung planen, nicht als Nachgedanke.

Halb-Labor-Brownfield. Einen Teil des Projekts im KI-nativen Modus und einen Teil im traditionellen Modus betreiben, weil „dieser Teil auf die alte Weise schneller ist", bringt keinen der Vorteile. Die Fallstrickliste des KI-Labors benennt dies explizit.

Nähte als gegeben behandeln, wenn sie implizit sind. Strangler-Fig liest sich gut auf Whiteboards. In der Praxis sind „saubere Nähte" Orte, wo Verantwortlichkeiten ohne Kopplung an acht andere Module extrahiert werden können. Wenn das nicht für Ihre Codebasis zutrifft, wird Strangler-Fig zu einem vollständigen Neuaufbau mit zusätzlichen Schritten.

Modernisierungskosten mit Ersatzkosten verwechseln. Die Entscheidung „sanieren vs. neu aufbauen" dreht sich nicht darum, ob das Reparieren Geld kostet – beides kostet Geld. Es geht darum, ob die Struktur halten kann, was sie halten soll. Leichtsinnige, unabsichtliche technische Schulden können nicht in-place rückgängig gemacht werden, unabhängig vom Budget.

Tool-Landschaft (Momentaufnahme)

Das Rahmenwerk empfiehlt keine spezifischen Tools; die Landschaft verändert sich zu schnell. Aber wissenswert: Spec-driven Development (spec-kit, Kiro, Tessl – siehe Fowlers Vergleich); MCP-Konnektoren für systematische Codebase-Traversierung; Agenten-Plattformen (Claude Code, Cursor, Aider, Devin) mit unterschiedlichen Autonomie-/Human-in-the-Loop-Tradeoffs; Benchmarks (SWE-bench, IDE-Bench) – aber Benchmark-Scores auf kuratierten Problemen sagen Brownfield-Performance auf Ihrem Code nicht voraus.

Spiegel: Strategie und Unzuverlässigkeit

Zuverlässige Systeme entwickeln handelt davon, zuverlässige Systeme aus unzuverlässigen KI-Outputs zu bauen. Die Brownfield-Strategie handelt davon, KI-Agenten auf unzuverlässigen Codebasen wirksam zu machen. Beide konvergieren im Harness: schnelle Sensoren, dokumentierter Intent, Szenario-Validierung. Eine Brownfield-Migration, die nicht mit der Codebasis auf Reifestufe 5 endet und nicht der Unzuverlässigkeits-Disziplin entspricht, hat in Form, aber nicht in Funktion Erfolg gehabt.

Quellen

Fowler, M. (2026). "Harness Engineering for Coding Agent Users." martinfowler.com
Fowler, M. (2026). "From Black Box to Blueprint: Reverse-Engineering Legacy Systems with AI." martinfowler.com
Fowler, M. & EPAM. (2026). "Research, Review, Rebuild: AI-Assisted Legacy Modernization." martinfowler.com
Fowler, M. (2024). "Rewriting the Strangler Fig Application." martinfowler.com
Fowler, M. "Strangler Fig Application." martinfowler.com
Fowler, M. "Technical Debt Quadrant." martinfowler.com
Fowler, M. (2026). "Spec-Driven Development: The Three Tools." martinfowler.com
GitHub. "Spec Kit." github.com/github/spec-kit
Duvall, P. (2026). "AI Development Patterns." github.com/PaulDuvall/ai-development-patterns
Feathers, M. (2004). Working Effectively with Legacy Code. Addison-Wesley.
"Artificial Intelligence for Software Architecture: A Literature Review." (2025). arXiv. arxiv.org/abs/2504.04334
"IDE-Bench: Evaluating LLM Agents on Real Codebases." (2026). arXiv. arxiv.org/abs/2601.20886
SWE-bench. swebench.com

← Zurück zur Startseite · Codereife · Das KI-Labor · Zuverlässige Systeme entwickeln · Glossar