Codereife

Ihr KI-Coding-Agent ist nur so gut wie das Harness Ihrer Codebasis. KI verstärkt die bestehende Struktur – eine disziplinierte Codebasis liefert schneller, eine undisziplinierte liefert schneller confidently falschen Code. Das Harness (Fowler: Agent = Model + Harness) ist das, was diese Seite Ihnen hilft zu messen.

Eine neun-dimensionale Diagnose mit einem 1–5-Bewertungsraster pro Dimension. Drei sind blockierend – niedrige Werte kompromittieren die Agentenarbeit grundlegend und können nicht durch hohe Werte anderswo ausgeglichen werden. Die anderen sechs sind einschränkend. Bewerten Sie jede Codebasis mit einem Befehl über das kostenlose Open-Source-Claude-Code-Skill.

Die fünf Reifestufen

Jede Stufe ist durch den Feedbackmechanismus definiert, den sie hinzufügt. Man kann keine Stufen überspringen; was die nächste Stufe freischaltet, ist immer eine weitere Feedbackschleife, kein weiteres Tool.

Stufe	Name	Was vorhanden ist	Was Agenten tun können
0	Undurchsichtig	Keine erzwungenen Typen. Kaum bis keine Testabdeckung. CI fehlt oder ist unzuverlässig. Docs veraltet. Modulgrenzen unklar.	Isolierte Einzelfunktions-Vorschläge. Alles darüber hinaus produziert halluzinierten Code ohne korrigierendes Signal.
1	Instrumentiert	Typen zur Build-Zeit erzwungen. Einige Tests vorhanden. CI liefert Bestehen/Fehlschlagen innerhalb von Minuten.	Einzelfunktions-Generierung mit grundlegendem Vertrauen. Engbereichige Refaktorierungen. Signal ist schwach, aber vorhanden.
2	Validiert	Sinnvolle Abdeckung auf sich ändernden Codepfaden. CI unter 30 Min. (unter 5 Min. ist besser). Mindestens ein End-to-End-Integrationspfad.	Mehrdateiige Refaktorierungen im begrenzten Umfang. Bugfixes durch bestehende Tests validiert. Mindeststufe für Sprosse 3 (gesteuertes Vorgehen).
3	Lesbar	Modulgrenzen klar. Naming konsistent. Architektur dokumentiert. Verhaltensverträge an Schnittstellengrenzen deklariert.	Modulübergreifende Arbeit mit vorhersagbaren Ergebnissen. Agenten können über die Codebasis nachdenken, ohne Walkthroughs.
4	Spezifiziert	Intent in Spezifikationen erfasst, nicht nur im Code. Neue Arbeiten sind spec-first. Historische Entscheidungen dokumentiert.	Autonome Feature-Generierung aus Spezifikation (Sprosse 4). Der Mensch spezifiziert; der Agent baut und testet.
5	Szenarien-gesteuert	End-to-End-Szenarien decken kritische Pfade ab. Zufriedenheitsmetriken ersetzen binäres Bestehen/Fehlschlagen. Observability vollständig.	Vollständig autonome Produktion (Sprosse 5). Das Betriebsmodell des Labors wird nachhaltig.

Fowler nennt die strukturellen Eigenschaften von Stufe 3+ Ambient Affordances – Eigenschaften, die eine Codebasis für einen Agenten lesbar machen, ohne zusätzliche Anweisung. Ihr Fehlen zwingt den Agenten, Struktur zu erfinden.

Das AI Codebase Maturity Model, validiert an einem echten Projekt mit 91 % Abdeckung und unter 30 Minuten Bug-to-Fix-Zyklen, formulierte den Kernbefund direkt: „Die Intelligenz eines KI-getriebenen Entwicklungssystems liegt nicht im KI-Modell selbst, sondern in der Infrastruktur aus Anweisungen, Tests, Metriken und Feedbackschleifen, die es umgeben."

Die Deckelregel

Engineering-Praxis (die Sprossen 0–5 des Rahmenwerks) betrifft wie das Team arbeitet. Codereife (Stufen 0–5) betrifft was der Code unterstützt. Sie sind verknüpft:

Die Reifestufe einer Codebasis ist die Decke für die Engineering-Sprosse, die zuverlässig auf ihr betrieben werden kann.

Ein Team auf Sprosse 5, das Agenten in eine Stufe-2-Codebasis schickt, produziert dieselben Fehler wie ein Team auf Sprosse 2 – schneller. Die Feedbackschleifen, die Sprosse 5 ehrlich halten, existieren nicht. Das ist das häufigste Versagensmuster bei der Brownfield-KI-Adoption: Teams sehen Sprosse-5-Demos auf Greenfield-Repositories und nehmen an, das Arbeitsmodell lasse sich übertragen. Das wird es nicht, bis das Harness aufgebaut ist.

Das Codereife-Raster (Codebase Readiness Grid)

Neun Dimensionen. Jede beantwortet eine Frage. Jede 1–5 bewerten. Der niedrigste Wert ist die Decke für die Reifestufe, auf der Sie zuverlässig operieren können; Ihre schwächste Dimension ist dort, wo Agenten zuerst scheitern werden.

Auf Ihrer Codebase ausprobieren

codebase-readiness

Das Codereife-Raster (Codebase Readiness Grid) als Claude-Code-Skill. Läuft auf jeder Codebasis, erfasst Signale pro Dimension, produziert eine Scorecard mit einer Weg-zu-Ebene-5-Empfehlung. Open Source, MIT-lizenziert.

Auf GitHub ansehen

#	Dimension	Typ	Beantwortete Frage	Bewertungsraster (1–5)
1	Testabdeckung und Feedback-Latenz	blockierend	Gibt es sinnvolle Abdeckung auf den Codepfaden, die sich am häufigsten ändern? Wie schnell ist CI?	1 = keine Tests oder tote Tests. 2 = niedrige Abdeckung, langsame CI. 3 = sinnvolle Abdeckung auf Hot-Paths, CI unter 30 Min. 4 = erzwungener Schwellenwert, CI unter 5 Min., Fehler lokalisieren. 5 = Verhaltensszenarien decken kritische Pfade ab, CI schnell und grün als Deployment-Gate.
2	Typstriktheit	blockierend	Werden Typen zur Build-Zeit erzwungen? Ist `any` selten oder allgegenwärtig?	1 = ungetypt oder Typen deaktiviert. 2 = Typen optional, `any` überall. 3 = Typen erzwungen, einige Ausstiegsmöglichkeiten. 4 = Strikter Modus an, `any` selten und begründet. 5 = Strikter Modus in CI, null `any`, Verträge an jeder Grenze.
3	Dateigröße und Kontext-Lesbarkeit	einschränkend	Kann ein Agent über eine Datei nachdenken, ohne den Rest des Systems zu laden?	1 = Gottdateien (2000+ Zeilen), gemischte Verantwortlichkeiten. 2 = viele 1000+-Zeilen-Dateien, verschlungen. 3 = die meisten Dateien unter 500 Zeilen, einige Ausreißer. 4 = die meisten unter 300 Zeilen, Ausreißer selten und begründet. 5 = jede Datei auf eine Verantwortlichkeit zugeschnitten.
4	Modulgrenzen-Klarheit	einschränkend	Kann ein neuer Entwickler (oder Agent) den Modulgraphen nach 30 Minuten beschreiben? Werden Grenzen erzwungen?	1 = keine modulare Struktur. 2 = Struktur auf Papier, in der Praxis verletzt. 3 = klare High-Level-Module, gelegentliche Lecks. 4 = erzwungene Grenzen, stabile Verträge. 5 = Modulgraph ist eine navigierbare Karte; Architektur dokumentiert und aktuell.
5	API-Direktheit	blockierend	Ist der HTTP/RPC-Aufruf an der Aufrufstelle sichtbar, oder hinter Wrapper-Schichten versteckt?	1 = Zugriff über opake Abstraktionen (Factory, dynamischer Dispatch, ORM mit unsichtbaren Queries). 2 = signifikante Abstraktion, mit Mühe nachverfolgbar. 3 = Mischung aus direkten und abstrahierten Aufrufen. 4 = überwiegend direkte Aufrufe mit typisierten Antworten. 5 = Aufrufstellen zeigen, was passiert; keine versteckten Netzwerk- oder Datenbankoperationen.
6	Dokumentierter Intent	einschränkend	Ist das Warum separat vom Wie dokumentiert? Sind Architekturentscheidungen aufgezeichnet?	1 = keine Intent-Docs; Code ist die einzige Wahrheit. 2 = verstreute Docs, oft veraltet. 3 = Modul-READMEs, einige ADRs. 4 = aktuelles ADR-Log, kritische Module dokumentiert, CLAUDE.md / AGENTS.md vorhanden. 5 = jede nicht-triviale Entscheidung hat eine Spezifikation oder ein ADR; historischer Kontext erhalten.
7	Observability	einschränkend	Können Sie sehen, was das System für eine bestimmte Anfrage getan hat? Produzieren Fehler reproduzierbare Testfälle?	1 = keine strukturierten Logs, keine Traces, keine Metriken, kein Error-Tracking. 2 = einige Logs, kein Tracing. 3 = strukturierte Logs und grundlegende Metriken; Error-Tracking vorhanden. 4 = vollständige Telemetrie mit Query-Zugriff. 5 = Produktion vollständig beobachtbar; Fehler produzieren reproduzierbare Testfälle.
8	Dev- und Deploy-Einfachheit	einschränkend	Können Sie Dev mit einem Befehl einrichten? Deployen mit einem (oder automatisch)?	1 = Dev-Setup dauert Tage oder Stammwissen; Deployments manuell und fragil. 2 = geskriptet, aber fragil; Deployments erfordern Runbook-Schritte. 3 = dokumentierte Befehle, zuverlässiges Deployment. 4 = Ein-Befehl-Setup; Ein-Befehl- (oder Auto-)Deployment. 5 = Dev, CI, Produktion architektonisch identisch.
9	Abhängigkeits- und Runtime-Aktualität	einschränkend	Ist die Runtime unterstützt? Sind Frameworks innerhalb von 1–2 Hauptversionen des aktuellen Stands? Gibt es aufgegebene Bibliotheken?	1 = Runtime EOL, Framework 2+ Hauptversionen zurück, aufgegebene Bibliotheken, gemischte Paradigmen. 2 = Runtime aktuell, aber viele Abhängigkeiten 1+ Hauptversionen zurück. 3 = Runtime aktuell, die meisten Abhängigkeiten innerhalb einer Hauptversion, gelegentliche Legacy-Muster dokumentiert. 4 = konsistente moderne Paradigmen. 5 = aggressive Abhängigkeits-Hygiene; Konventionen entsprechen aktuellen Community-Standards.

Hinweise zu den weniger selbstverständlichen Dimensionen. D1: Langsame CI ist das häufigste Brownfield-Defizit – eine 72-Stunden-Test-Suite ist kein Sensor, sie ist ein Bericht. D3: Kleine Dateien sind keine Stilpräferenz, sie sind eine Kontextfenster-Disziplin; Agenten, die drei Dateien brauchen, um eine Funktion zu verstehen, halluzinieren die fehlenden Teile. D5: Opake Abstraktionen verbergen nicht nur Details – sie produzieren selbstbewusst falschen Code, wenn der Agent rät, was UserFactory.resolve() tut. D6: Code dokumentiert sich selbst; Intent nicht. Das ist das am schwersten schnell zu behebende Defizit. D9: Agenten werden auf aktuellen Bibliotheksversionen und Idiomen trainiert; eine Codebasis mit 2–3 Jahre alten Mustern erhält Code, der seinen eigenen Konventionen widerspricht.

Wie die Bewertung funktioniert

Vier Regeln bestimmen, wie die Scorecard zu lesen ist. Sie wirken kumulativ – alle vier gelten gleichzeitig.

1. Die Decke ist der niedrigste Wert. Ihre schwächste Dimension legt Ihre Reifestufe fest. Eine Codebasis mit acht 5ern und einer 1 ist auf Stufe 0, nicht Stufe 4. Agenten scheitern am schwächsten Glied.

2. Drei Dimensionen sind blockierend; sechs sind einschränkend.

Blockierend (D1, D2, D5) – niedrige Werte kompromittieren die Agentenarbeit grundlegend. Ohne Tests sind Agenten blind. Ohne Typen halluzinieren sie Formen. Bei opaken APIs produzieren sie selbstbewusst falschen Code. Diese können nicht durch hohe Werte anderswo ausgeglichen werden.
Einschränkend (D3, D4, D6, D7, D8, D9) – niedrige Werte verschlechtern die Qualität, aber Agenten können noch Wert produzieren. Mehr menschliche Überprüfung pro Änderung, mehr Bereinigung, mehr Reibung.

Wenn zwei Dimensionen bei einem niedrigen Wert gleichstehen, zuerst die blockierende erhöhen. Die Deckelregel gilt weiterhin; diese Klassifikation schärft nur die Sanierungspriorität.

3. Zurückstellungsgutschrift: eine absichtliche, dokumentierte Zurückstellung bewertet sich eine Stufe höher als dieselbe Lücke undokumentiert. Wenn Observability nicht eingerichtet ist, aber die Projektspezifikation sie auf eine GA-Ready-Phase mit Datum und Kriterien verschiebt, mit 2 statt 1 bewerten. Die Zurückstellung ist eine Entscheidung; eine gedankenlose Lücke ist es nicht. Mündliche Behauptungen zählen nicht – die Zurückstellung muss im Repository stehen.

4. Die Scorecard niemals mit einem Durchschnitt zusammenfassen. Die Scorecard ist ein Vektor, kein Skalar. Zwei Codebasen mit einem Durchschnitt von 3,0 können sich in radikal unterschiedlichen Situationen befinden: eine mit D1 bei 1 ist blind; eine mit D7 bei 1 ist operativ unreif, aber verwendbar. Durchschnitte verbergen diesen Unterschied.

Die Scorecard ist eine Momentaufnahme. Vierteljährlich neu ausführen – Codebasen bewegen sich in beide Richtungen.

Wie eine Stufe-5-Codebasis aussieht

Eine konkrete Referenz, verallgemeinert aus beobachteten Mustern. Eine Codebasis, die in allen neun Dimensionen 5 erzielt, teilt typischerweise diese Eigenschaften:

Spec-first für nicht-triviale Arbeit. API-Verträge verifiziert, Akzeptanzszenarien definiert, Entscheidungen vor dem Code dokumentiert.
Strikte Typisierung zur Build-Zeit erzwungen. Null any. Typverletzungen schlagen CI fehl.
Kleine, fokussierte Dateien. Die meisten unter einigen hundert Zeilen. Größte Dateien sind absichtliche Ausreißer, keine zufälligen Anhäufungen.
Direkter API- und Datenzugriff. Aufrufstellen zeigen, was aufgerufen wird. Keine opaken Factories, keine generischen Dispatcher.
Minimale Abhängigkeiten. Wenige Pakete, jedes begründet.
Explizite Konventionen. Dateistruktur und Naming dokumentiert. ABOUTME: Header in jeder Datei. AGENTS.md oder CLAUDE.md mit den Agentenregeln.
Kein implizites Wissen. Die Codebasis ist lesbar, weil sie sagt, was sie meint, nicht weil das Team sich erinnert.
Tests als Verträge. Einfache Mocks, Verhaltensbehauptungen, lesbare Namen.
Ein-Befehl-Build, Ein-Befehl-Deployment. Kein Kampf mit der Infrastruktur zum Ausliefern.
Aktuelle Abhängigkeiten, unterstützte Runtime. Keine EOL-Runtimes, keine aufgegebenen Bibliotheken.

Das sind keine Stilpräferenzen. Das sind die strukturellen Eigenschaften, die Agenten zuverlässige Arbeit ermöglichen – und dieselben Eigenschaften, die Menschen produktiv machen. Die beiden sind nicht getrennt.

Harness-Aufbaustrategie

Wenn die Reife unter dem liegt, auf dem das Team arbeiten muss, diese Reihenfolge für die Investition einhalten. Das Überspringen von Phasen produziert Geschwindigkeit ohne Vertrauen.

Das Harness hat zwei Teile: Sensoren (Tests, CI, Observability) verifizieren den Agentenoutput; Leitplanken (Typen, Konventionen, Architekturdocs, dokumentierter Intent) spezifizieren, was produziert werden soll. Brownfield-Codebasen haben typischerweise die Leitplanken, aber keine Sensoren – das ist die Konfiguration, die selbstbewusst falschen Code liefert.

Phase 1 – Zuerst schnelle Sensoren installieren. Nützliche Tests und schnelle CI (Feedback-Latenz unter 30 Minuten ist das Gate). Ohne Sensoren ist jede nachgelagerte Änderung eine Vermutung und Sie können nicht überprüfen, ob spätere Harness-Arbeit greift.

Phase 2 – Den Code lesbar machen. Konsistentes Naming, erzwungene Typen, klare Modulgrenzen, zentralisierte querschnittliche Belange, Löschen toter Pfade. Lesbarkeit ist das, was Agenten ermöglicht, modulübergreifend zu arbeiten, ohne Struktur zu halluzinieren.

Phase 3 – Intent erfassen. Architekturentscheidungen dokumentieren. Verhaltensverträge an Schnittstellengrenzen deklarieren. Für die kritischsten Module die implizite Spezifikation extrahieren – die tausend Entscheidungen, die sich über Jahre von Patches angesammelt haben. Agenten können dokumentieren, was das System tut; absichtliches Verhalten von historischem Unfall zu unterscheiden, bleibt menschlich. Siehe die Brownfield-Aufnahmesequenz des KI-Labors für die disziplinierte Version.

Phase 4 – Mit Szenarien steuern. Intent in End-to-End-Szenarien umwandeln. Szenarien sind für Agenten schwerer zu umgehen als Unit-Tests. Der Sprosse-5-Arbeitsmodus wird an diesem Punkt praktikabel.

Muster aus Paul Duvalls AI Development Patterns, die zu dieser Sequenz passen: Readiness Assessment (Foundation), Observable Development, Guided Refactoring.

Was zu tun ist, wenn der Wert niedrig ist

Vier Modi kommen in Betracht, ausführlich behandelt unter Brownfield-Ingenieurstrategie: In-place-Sanierung, Strangler-Fig-Migration, Vollständiger Neuaufbau oder Isolieren und umgehen. Der richtige Modus hängt von der architektonischen Solidität der Codebasis, der Nahtenverfügbarkeit und dem verbleibenden Geschäftswert ab – nicht von Teamkapazität oder strategischen Prioritäten, die außerhalb dieser Bewertung liegen.

Spiegel: Reife und Unzuverlässigkeit

Zuverlässige Systeme entwickeln behandelt KI-Output als Eingabe für Systeme. Codereife behandelt das Inverse: die Codebasis als Eingabe für KI-Agenten. Dieselbe Unsicherheit, gespiegelt.

Quellen

Mahiou et al. (2026). "AI Codebase Maturity Model (ACMM)." arXiv. arxiv.org/abs/2604.09388
Fowler, M. (2026). "Harness Engineering for Coding Agent Users." martinfowler.com
Duvall, P. (2026). "AI Development Patterns." github.com/PaulDuvall/ai-development-patterns
Google Cloud (2025). "DORA 2025 State of AI-assisted Software Development." dora.dev
"A Maturity Model for AI-Native Development." (2025). Transcode. blog.transcode.be
"The State of Generative AI in Software Development." (2026). arXiv. arxiv.org/abs/2603.16975

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