Technische Schulden mit KI einschätzen

1. Warum technische Schulden mit KI messbar werden

Technische Schulden bleiben in den meisten Teams eine gefühlte Größe: „Dieser Teil der Codebasis fühlt sich schlecht an“, ohne dass jemand beziffern kann, wie hoch das tatsächliche Risiko ist oder was eine Behebung kosten würde. Technische Schulden mit KI einzuschätzen verändert diese Situation, weil Claude in der Lage ist, eine gesamte Codebasis systematisch nach konkreten Indikatoren zu durchsuchen: veraltete Abhängigkeiten mit bekannten Sicherheitslücken, fehlende Testabdeckung in häufig geänderten Dateien, zyklische Abhängigkeiten zwischen Modulen, die eigentlich getrennt sein sollten.

Der entscheidende Unterschied zu einer rein subjektiven Einschätzung liegt in der Konsistenz. Ein Entwickler, der seit drei Jahren an einem Modul arbeitet, empfindet dessen Probleme anders als jemand, der es zum ersten Mal öffnet. Claude bewertet jede Datei nach denselben Kriterien, unabhängig davon, wer sie zuletzt bearbeitet hat oder wie vertraut das Team mit ihr ist. Das macht die Einschätzung technischer Schulden vergleichbar über verschiedene Teile eines großen Projekts hinweg.

Wichtig ist die Erwartungshaltung: Claude bei der Einschätzung technischer Schulden ersetzt nicht die Entscheidung, was tatsächlich behoben wird. Diese Entscheidung bleibt eine Geschäftsentscheidung, die Aufwand gegen Nutzen abwägt. Claude liefert die Datengrundlage für diese Entscheidung, die sonst auf Vermutungen basieren würde.

2. Kategorien technischer Schulden systematisch erfassen

Technische Schulden sind kein einheitliches Phänomen, sondern lassen sich in mehrere Kategorien unterteilen, die jeweils unterschiedliche Behebungsstrategien erfordern. Bewusste Schulden entstehen, wenn ein Team eine schnelle Lösung wählt, um einen Termin zu halten, mit dem Wissen, dass später eine sauberere Lösung folgt. Unbewusste Schulden entstehen durch fehlendes Wissen zum Entwurfszeitpunkt. Umgebungsschulden entstehen, wenn sich externe Abhängigkeiten weiterentwickeln, während der Code selbst unverändert bleibt, etwa ein veraltetes Framework mit bekannten Sicherheitslücken.

Bei der Einschätzung technischer Schulden mit Claude lohnt sich diese Kategorisierung, weil sie unterschiedliche Reaktionen erfordert. Bewusste Schulden mit dokumentierter Begründung sind oft weniger dringend als unbewusste Schulden, die auf tatsächlichen Missverständnissen der Domäne beruhen. Umgebungsschulden mit aktiven Sicherheitslücken haben in der Regel höchste Priorität, unabhängig davon, wie „unangenehm“ der betroffene Code subjektiv empfunden wird.

# Ask Claude Code to categorize technical debt across the codebase
claude "Scan src/ for technical debt indicators. Categorize each finding as:
'deliberate' (has a TODO/FIXME comment explaining a conscious tradeoff),
'unintentional' (design mismatch with current domain understanding),
or 'environmental' (outdated dependency, deprecated API usage).
Output a markdown table with file path, category, and one-line description."

3. Codebasis mit Claude Code auf Schuldenindikatoren scannen

Claude Code kann direkt im Repository arbeiten und dabei mehrere konkrete Indikatoren für technische Schulden systematisch prüfen: Zyklomatische Komplexität pro Funktion, Duplizierter Code über mehrere Dateien hinweg, fehlende Typannotationen in dynamisch typisierten Sprachen, veraltete Abhängigkeiten mit bekannten CVEs, und Dateien, die seit Jahren nicht mehr angefasst wurden, obwohl sie kritische Geschäftslogik enthalten.

Ein besonders wertvoller Indikator, den Claude gut erkennen kann, ist die Kombination aus hoher Änderungshäufigkeit und hoher Komplexität. Eine Datei, die selten geändert wird, verursacht selbst bei hoher Komplexität selten akuten Schmerz. Eine Datei, die wöchentlich geändert wird und gleichzeitig eine hohe zyklomatische Komplexität aufweist, ist hingegen ein aktiver Bremsklotz für die Entwicklungsgeschwindigkeit des gesamten Teams. Diese Kombination aus Git-Historie und statischer Codeanalyse liefert deutlich präzisere Priorisierung als jede der beiden Metriken allein.

# Pseudo-approach Claude Code uses when combining change frequency with complexity
def calculate_debt_hotspot_score(file_path: str) -> dict:
    """Combines git change frequency with static complexity to find hotspots."""
    change_count = count_commits_touching_file(file_path, since_months=12)
    complexity = calculate_cyclomatic_complexity(file_path)
    test_coverage = get_test_coverage_percentage(file_path)

    # High change frequency + high complexity + low coverage = highest risk
    hotspot_score = change_count * complexity * (1 - test_coverage / 100)

    return {
        "file": file_path,
        "change_count_12mo": change_count,
        "cyclomatic_complexity": complexity,
        "test_coverage_pct": test_coverage,
        "hotspot_score": round(hotspot_score, 2),
    }

4. Priorisierung nach Risiko und Änderungshäufigkeit

Eine lange Liste gefundener technischer Schulden ohne Priorisierung ist praktisch nutzlos, weil kein Team die Kapazität hat, alles gleichzeitig zu beheben. Bei der Priorisierung technischer Schulden mit Claude hat sich eine Matrix aus zwei Achsen bewährt: geschäftliches Risiko bei Nichtbehebung und Behebungsaufwand. Diese Matrix teilt Funde in vier Quadranten: hohes Risiko bei niedrigem Aufwand sollte sofort behoben werden, hohes Risiko bei hohem Aufwand braucht eine geplante Initiative, niedriges Risiko bei niedrigem Aufwand kann opportunistisch mitgenommen werden, niedriges Risiko bei hohem Aufwand sollte in der Regel unangetastet bleiben.

Claude kann bei dieser Einordnung helfen, indem es für jeden Fund eine grobe Aufwandsschätzung und eine Risikobewertung liefert, basierend auf Faktoren wie: Wird dieser Code-Pfad häufig durchlaufen? Gibt es eine bekannte Sicherheitslücke in der betroffenen Abhängigkeit? Wie viele andere Module hängen von diesem Code ab? Diese Faktoren lassen sich zumindest grob aus der Codebasis selbst extrahieren, ohne dass ein Mensch jede Datei einzeln bewerten muss.

5. Zinssatz berechnen: Was kostet das Nichtstun wirklich

Die Analogie zur finanziellen Verschuldung ist bei technischen Schulden mehr als ein Sprachbild: Schulden, die nicht bedient werden, wachsen durch Zinsen. Bei technischen Schulden äußert sich dieser Zins in Form von langsamerer Entwicklungsgeschwindigkeit, mehr Bugs in betroffenen Modulen und längerer Onboarding-Zeit für neue Teammitglieder. Claude kann helfen, diesen Zins grob zu quantifizieren, indem es die durchschnittliche Zeit für Änderungen in schuldenbelasteten Dateien mit der Zeit in gut gewarteten Dateien vergleicht.

Ein konkretes Beispiel aus der Praxis: Eine Analyse zeigte, dass Änderungen an einem bestimmten, stark verschuldeten Zahlungsmodul im Durchschnitt drei mal länger dauerten als vergleichbare Änderungen in anderen Modulen, gemessen an der Zeit zwischen erstem Commit und Merge eines Pull Requests. Diese konkrete Zahl, drei mal langsamer, überzeugte das Management deutlich schneller als eine allgemeine Aussage wie „der Code ist unübersichtlich“, weil sie den tatsächlichen Zinssatz der technischen Schulden in einer nachvollziehbaren Metrik ausdrückt.

6. Einen realistischen Refactoring-Plan mit Claude erstellen

Nach der Priorisierung braucht es einen konkreten, umsetzbaren Plan, nicht nur eine Liste von Problemen. Claude eignet sich gut, um aus den priorisierten Funden einen gestaffelten Refactoring-Plan zu erstellen, der kleine, in sich abgeschlossene Schritte definiert, die jeweils unabhängig getestet und deployt werden können, statt einen großen, riskanten Big-Bang-Umbau vorzuschlagen.

Ein guter Plan berücksichtigt zusätzlich die laufende Feature-Entwicklung. Statt zwei Wochen Entwicklungsstopp für ein reines Refactoring vorzuschlagen, was in den meisten Teams politisch schwer durchsetzbar ist, kann Claude einen Plan erstellen, der Refactoring-Schritte mit ohnehin geplanten Feature-Änderungen im selben Modul kombiniert. Diese Kopplung senkt den wahrgenommenen Zusatzaufwand erheblich, weil das betroffene Modul ohnehin angefasst wird.

# Generate a staged refactoring plan tied to existing roadmap items
claude "Given the debt hotspot analysis in docs/debt-report.md and the
upcoming feature roadmap in docs/roadmap-q3.md, create a staged
refactoring plan. Combine debt reduction with modules that are already
scheduled for feature work in Q3, so refactoring effort rides along with
planned changes instead of requiring a separate freeze. Each stage must
be independently testable and deployable."

7. Technische Schulden gegenüber dem Management kommunizieren

Technische Schulden konkurrieren im Backlog immer mit sichtbaren Feature-Anfragen, und wer nur mit „der Code ist unsauber“ argumentiert, verliert diesen Wettbewerb fast immer. Bei der Einschätzung technischer Schulden mit Claude ist die Übersetzung in geschäftliche Konsequenzen der entscheidende letzte Schritt: nicht „dieser Code ist schlecht“, sondern „Änderungen in diesem Modul dauern dreimal länger und verursachen doppelt so viele Produktionsfehler wie im Rest der Anwendung“.

Claude kann bei der Erstellung dieser Übersetzung helfen, indem es aus der technischen Analyse eine für Nicht-Techniker verständliche Zusammenfassung mit konkreten Zahlen erstellt: geschätzte zusätzliche Entwicklungszeit pro Sprint durch die Schulden, Anzahl der durch das betroffene Modul verursachten Produktionsvorfälle im letzten Quartal, geschätztes Sicherheitsrisiko bei veralteten Abhängigkeiten. Diese Übersetzung von technischem Befund zu geschäftlicher Konsequenz ist oft der Unterschied zwischen einem genehmigten und einem abgelehnten Refactoring-Vorschlag.

8. Typische Fallstricke bei der KI-gestützten Einschätzung

Der größte Fallstrick bei der Einschätzung technischer Schulden mit Claude ist, statische Metriken wie zyklomatische Komplexität als alleinigen Maßstab zu nehmen. Ein komplexer, aber stabiler und gut getesteter Algorithmus in einem selten geänderten Modul ist keine dringende technische Schuld, selbst wenn die Komplexitätsmetrik hoch ausfällt. Die Kombination mit Änderungshäufigkeit und tatsächlicher Fehlerrate ist unverzichtbar, um echte Prioritäten von akademisch interessanten, aber praktisch irrelevanten Befunden zu trennen.

# Context checklist before trusting an AI technical debt assessment
debt_assessment_context = {
    "static_complexity_metrics": None,   # cyclomatic complexity, duplication
    "git_change_frequency": None,        # commits per file over last 12 months
    "production_incident_history": None, # incidents linked to specific modules
    "test_coverage_per_module": None,
    "dependency_vulnerability_scan": None,  # e.g. from npm audit, composer audit
}

def is_debt_priority_reliable(ctx: dict) -> bool:
    """Complexity alone without change frequency overweights stable, unused code."""
    return ctx["static_complexity_metrics"] is not None and ctx["git_change_frequency"] is not None

Ein zweiter Fallstrick ist, Claude eine vollständige Behebung ohne menschliche Prüfung durchführen zu lassen, insbesondere bei tief verwurzelten architektonischen Schulden. Claude kann einen Vorschlag für ein Refactoring erstellen, aber die tatsächliche Umsetzung sollte in kleinen, überprüfbaren Schritten erfolgen, mit Tests, die vor und nach jeder Änderung laufen. Ein dritter Fallstrick: Die Einschätzung technischer Schulden als einmaliges Audit statt als wiederkehrenden Prozess zu behandeln. Schulden akkumulieren kontinuierlich, ein jährliches Audit reicht meist nicht, um gegenzusteuern.

9. Methoden zur Einschätzung technischer Schulden im Vergleich

Die folgende Tabelle vergleicht Ansätze zur Einschätzung technischer Schulden, mit unterschiedlicher Eignung je nach Projektgröße und verfügbarer Zeit.

In der Praxis funktioniert die Kombination am besten: statische Analyse-Tools liefern die Rohdaten, Claude kombiniert diese mit Git-Historie und Kontext zu einer priorisierten Liste, und bei hochkritischen Systemen ergänzt ein periodisches externes Audit die kontinuierliche interne Einschätzung.

10. Zusammenfassung

Technische Schulden mit KI einzuschätzen ersetzt das subjektive Bauchgefühl durch eine konsistente, codebasisweite Analyse. Claude kombiniert statische Metriken wie zyklomatische Komplexität mit Git-Historie und tatsächlicher Fehlerrate, um echte Prioritäten von akademisch interessanten, aber praktisch irrelevanten Befunden zu trennen. Die Priorisierungsmatrix aus Risiko und Aufwand hilft, aus einer langen Fundliste einen umsetzbaren Plan zu machen.

Der entscheidende letzte Schritt bleibt die Übersetzung technischer Befunde in geschäftliche Konsequenzen, denn nur konkrete Zahlen zu Entwicklungsgeschwindigkeit und Produktionsvorfällen überzeugen im Wettbewerb um Backlog-Kapazität gegen sichtbare Feature-Anfragen. Claude liefert die Datengrundlage, die tatsächliche Priorisierungsentscheidung bleibt eine geschäftliche Abwägung des Teams.

11. FAQ: Technische Schulden mit KI einschätzen