Codequalität und Refactoring

Eine Runde endet gut. Der Test läuft grün, der Vorgang ist geschlossen, die Änderung liegt im Zweig. Ungemessen bleibt dabei, in welchem Zustand der Rest des Programms zurückbleibt.

Für diesen Zustand gibt es Zahlen. GitClear wertet Änderungen an Programmcode aus und hat für die Jahre 2023 bis 2026 mehrere Kennzahlen nebeneinandergelegt.

623 million analyzed changes from 2023-2026 (externe Seite, gitclear.com)

Vier Kennzahlen, eine Richtung

Gemessen wird	Ausgangswert	2026
Doppelte Blöcke je Million geänderter Zeilen	40,3 (2023)	73,0
Verschobener Code, Anteil der geänderten Zeilen	21 % (2022)	3,8 %
Methodenaufrufe je tausend geänderter Zeilen	343 (2023)	223
Änderungen an über ein Jahr altem Code	1,7 % (2023)	0,46 %

Quelle: GitClear (externe Seite, gitclear.com), Stand der Erhebung Sommer 2026. Die Werte von 2026 sind Zwischenstände des laufenden Jahres.

Ein doppelter Block ist eine Stelle, die es schon einmal gibt: fünf oder mehr aufeinanderfolgende Zeilen, die anderswo gleich stehen. Ihre Zahl hat sich binnen drei Jahren fast verdoppelt, und das ist die Kennzahl mit den handfestesten Folgen. Wer eine der Kopien ändert, muss die anderen finden.

A duplicated block imposes a propagation tax (externe Seite, gitclear.com)

Verschobener Code ist die Gegenkennzahl. Wer zwei ähnliche Stellen zu einer Funktion zusammenzieht, verschiebt Zeilen, statt neue zu schreiben. Ihr Anteil liegt bei weniger als einem Fünftel des Werts von 2022.

Die dritte Zeile misst, wie stark neuer Code an den Bestand anschließt, die vierte, wie oft jemand ältere Stellen überhaupt noch anfasst.

That maintenance work is increasingly not happening. (externe Seite, gitclear.com)

Was Agenten beim Umbauen wirklich tun

Die naheliegende Erklärung wäre, dass Agenten nie aufräumen. Sie stimmt nicht. Eine Erhebung an 15.451 Umbauten in offenen Java-Projekten misst das Gegenteil:

with agents explicitly targeting refactoring in 26.1% of commits (externe Seite, arxiv.org)

Mehr als jeder vierte Commit zielt ausdrücklich auf einen Umbau, und die Messung findet dabei echte Verbesserungen an Klassengröße und Komplexität, klein, aber statistisch belastbar. Der Unterschied steckt in der Art der Eingriffe:

agentic efforts are dominated by low-level, consistency-oriented edits (externe Seite, arxiv.org)

Variablentypen anpassen, Parameter umbenennen, Variablen umbenennen. Was dabei ausbleibt, benennt dieselbe Arbeit:

reflecting a preference for localized improvements over the high-level design changes common in human refactoring (externe Seite, arxiv.org)

Damit passen beide Erhebungen zusammen. Die einzelne Stelle wird sauberer, während der Bauplan liegen bleibt. Zwei gleiche Blöcke zu einer Funktion zusammenzuziehen ist genau so ein Eingriff am Bauplan.

seitlich verschiebbar

eigene Darstellung nach GitClear und der Erhebung zum agentischen Refactoring, Stand 03.09.2026

Warum der Aufräumschritt ausfällt

Ein Agent bekommt einen Auftrag und schließt ihn ab. Kein Teil dieses Auftrags lautet, den Bestand kleiner zu machen. Wer den Umbau will, beauftragt ihn gesondert.

Bei OpenAI war diese Arbeit vorher fest eingeplant. Ein Team, das fünf Monate lang ein Produkt ohne handgeschriebene Zeile gebaut hat, beschreibt den Vorher- Zustand so:

Our team used to spend every Friday (20% of the week) cleaning up (externe Seite, openai.com)

Ein Fünftel der Arbeitswoche, als fester Termin. Fällt ein solcher Termin weg, ohne dass ihn etwas ersetzt, verschwindet die Arbeit selbst.

Drei Handgriffe

Der Umbau bekommt einen eigenen Auftrag. Er entsteht selten nebenbei, weil die Runde vorher endet. Ein eigener Durchgang mit dem ausdrücklichen Ziel, doppelte Stellen zusammenzuziehen, ist etwas anderes als der Zusatz „und räum bitte auf“.

Die Prüfung zählt, statt zu fragen. Ein Werkzeug, das doppelte Blöcke oder die Größe einer Datei misst, gibt eine Zahl zurück, die sich mit der von letzter Woche vergleichen lässt. Wie ein solcher Riegel gebaut wird, steht in Kapitel 07.

Der Umbau läuft getrennt von der Aufgabe. Ein Zweig, der eine Funktion ergänzt und gleichzeitig vier Dateien umsortiert, lässt sich nicht mehr beurteilen. Wie sich beides trennen lässt, steht in Kapitel 04.

Die Ebene darunter nimmt die vier Kennzahlen einzeln und zeigt, was sich davon im eigenen Projekt messen lässt.

Die Kennzahlen aus der Ebene davor stammen aus einer Auswertung über viele Projekte hinweg. Im eigenen Projekt ist die erste Frage, welche davon sich überhaupt erheben lassen.

Was messbar ist

Drei der vier Größen lassen sich mit gewöhnlichen Mitteln zählen.

Doppelte Blöcke. Werkzeuge dieser Gattung suchen Folgen gleicher Zeilen über den ganzen Baum. Die Zahl, die dabei herauskommt, ist als absoluter Wert wenig wert und als Verlauf viel: Fünfzig doppelte Stellen sagen nichts, fünfzig nach vierzig vor zwei Wochen sagen etwas.

Dateigröße. Eine Zeilenzahl je Datei kostet einen Einzeiler. Der Begriff für die Datei, die alles kann, ist geläufig, eine Zahl, ab der eine Datei zu groß ist, gibt es dagegen nicht.

Anschluss an den Bestand. Wie oft neuer Code eine vorhandene Funktion ruft, lässt sich aus dem Syntaxbaum zählen. Das ist die aufwendigste der drei und zugleich die aussagekräftigste, denn sie misst genau das Gegenteil der Wiederholung.

New code is less and less woven into the existing codebase. (externe Seite, gitclear.com)

Was nicht messbar ist

Für einige der geläufigen Begriffe gibt es keine Erhebung, auf die sich hier verweisen ließe. Magische Zahlen im Code, technische Schuld, die Datei mit zu vielen Zuständigkeiten: Diese Begriffe beschreiben etwas Wirkliches, und wer sie beziffern will, findet für den Betrieb mit Agenten keine belastbaren Werte. Das Kapitel benennt sie deshalb und rechnet nicht mit ihnen.

Der Grund ist derselbe wie bei jeder Qualitätsaussage: Ob eine Datei zu viel tut, hängt davon ab, was sie tun soll. Eine Maschine sieht die Zeilenzahl.

Wo ein Linter aufhört

Ein Linter prüft eine Datei gegen Regeln, die für eine Datei formuliert sind: unbenutzte Variablen, Formatierung, verbotene Sprachmittel. Er läuft schnell und meldet zuverlässig.

Genau deshalb sieht er die Kennzahl nicht, um die es hier geht. Zwei Dateien, die denselben Block enthalten, sind einzeln betrachtet beide in Ordnung. Der Linter meldet nichts, und die Zahl der doppelten Blöcke steigt trotzdem.

Wer den Agenten an einen Linter binden will, hängt ihn hinter den Schreibvorgang. In Claude Code sieht das so aus:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npm run lint -- --max-warnings 0" }
        ]
      }
    ]
  }
}

Was ein solcher Hook kann und woran er scheitert, steht in Kapitel 08. Für dieses Kapitel zählt die Grenze: Er misst die Datei, die gerade geschrieben wurde, und beantwortet damit keine Frage über den Bestand.

Die eingefrorene Bestandsliste

Ein fester Grenzwert scheitert an vorhandenen Projekten. Wer heute anordnet, dass keine Datei über 400 Zeilen haben darf, bekommt beim ersten Lauf dreihundert Meldungen und schaltet die Prüfung ab.

Die Bauform, die das aushält, misst gegen einen eingefrorenen Stand. Eine Liste hält fest, was am Stichtag schon zu groß war. Neues über der Schwelle ist ein Befund, Bekanntes wird geduldet, und ein Eintrag, der die Schwelle wieder unterschreitet, muss aus der Liste verschwinden. Damit darf die Liste schrumpfen und nie wachsen.

Diese Seite fährt eine solche Prüfung für die Größe ihrer gebauten Seiten. Die Liste dazu ist eine Textdatei mit zwei Einträgen, und in ihrem Kopf steht der Satz, der die Bauform ausmacht: Altlast, kein Sollzustand.

Der Unterschied zu einem Grenzwert ist der Umgang mit dem Bestand. Ein Grenzwert verlangt, dass zuerst aufgeräumt wird, bevor er wirken kann. Eine Bestandsliste wirkt ab dem ersten Tag und lässt das Aufräumen zu, wann es passt.

seitlich verschiebbar

eigene Darstellung, Stand 03.09.2026

Warum die Anweisung im Auftrag wenig ausrichtet

Der naheliegende Weg wäre, dem Agenten das Aufräumen im Auftragstext mitzugeben. Für einen verwandten Fall gibt es dazu eine Messung: Bei der testgetriebenen Entwicklung hat eine Verfahrensanweisung im Prompt ohne passenden Kontext die Zahl der Rückfälle über den Ausgangswert getrieben, nachzulesen im Beitrag Erst der rote Test.

Auf die Codequalität übertragen heißt das: Die Bitte, sauber zu arbeiten, ist schwächer als eine Zahl, die nach dem Lauf verglichen wird. Was ein Lauf hinterlässt, wird gemessen, und was er verspricht, steht im Protokoll.

Bei OpenAI hat das Team denselben Schluss gezogen und es an eine Bedingung geknüpft:

When documentation falls short, we promote the rule into code (externe Seite, openai.com)

Der Umbau als eigener Durchgang

Ein Zweig, der eine Funktion ergänzt und dabei vier Dateien umsortiert, ist nicht mehr zu beurteilen. Beim Lesen des Unterschieds lässt sich die inhaltliche Änderung von der Verschiebung nicht trennen, und genau darauf käme es an.

Deshalb gilt für den Umbau dieselbe Trennung wie für parallele Arbeit in Kapitel 04: eigener Zweig, eigener Auftrag, eigene Abnahme. Die Bedingung dafür sind Tests, die vorher liefen, denn sie sind die einzige Auskunft darüber, ob das Verhalten gleich geblieben ist.

Die Ebene darunter nimmt die beiden Erhebungen ernst, die sich zu widersprechen scheinen, und sieht sich an, wer den Code eigentlich pflegt, den ein Agent geschrieben hat.

Zwei Erhebungen aus demselben Zeitraum kommen zu entgegengesetzten Befunden. Die eine misst über 623 Millionen Änderungen hinweg, dass die Struktur zurückgeht:

the structural habits that keep codebases maintainable have eroded across every signal we measure (externe Seite, gitclear.com)

Die andere misst an 15.451 Umbauten, dass Agenten die Struktur verbessern:

agentic refactoring yields small but statistically significant improvements in structural metrics (externe Seite, arxiv.org)

Beide Sätze halten der Prüfung stand. Der Unterschied liegt in der Bezugsgröße.

Was jede der beiden zählt

Die Refactoring-Arbeit misst Änderungen. Sie nimmt Umbauten, die stattgefunden haben, und vergleicht die betroffene Klasse vorher und nachher. Der Befund lautet: Wenn umgebaut wird, wird es etwas besser, im Median um gut fünfzehn Zeilen Klassengröße.

GitClear misst Anteile am Ganzen. Die Kennzahl für verschobenen Code sagt, welcher Bruchteil aller geänderten Zeilen auf Umbauten entfällt. Dieser Bruchteil fällt, während der absolute Ausstoß steigt.

Damit sind beide Sätze gleichzeitig wahr. Umbauten werden besser und seltener, gemessen an allem, was daneben entsteht. Die zweite Zahl entscheidet über den Zustand eines Projekts nach zwei Jahren.

seitlich verschiebbar

eigene Darstellung nach GitClear und der Erhebung zum agentischen Refactoring, Stand 03.09.2026

Beim Nebeneinanderstellen gehört eine Einschränkung dazu. Die Refactoring-Arbeit untersucht ausschließlich Java-Projekte und stützt sich auf einen Datensatz namens AIDev. Dieselbe Gruppe hat mit demselben Datensatz die Anschlussfrage untersucht, und zwei Autoren arbeiten an beiden Arbeiten mit. Beide stehen damit auf derselben Grundlage und wiegen zusammen weniger, als zwei Titel vermuten lassen.

Wer den Code danach pflegt

Die Anschlussarbeit vom Mai 2026 sieht sich an, was mit dem Code geschieht, nachdem er im Hauptzweig liegt. Grundlage sind über 1.000 Dateien und rund 3.200 Änderungen aus 100 verbreiteten Projekten. Drei Befunde stehen darin, und der dritte ist der unbequemste:

AI-generated files receive less frequent maintenance than human-authored code (externe Seite, arxiv.org)

the most frequent modifications to AI code are feature extensions, whereas human updates focus on bug fixes (externe Seite, arxiv.org)

human developers perform the large majority of this maintenance (externe Seite, arxiv.org)

An maschinengeschriebenen Dateien wird also seltener gearbeitet, und wenn, dann wird angebaut. Die Pflege selbst liegt bei Menschen.

Das passt zu GitClears Kennzahl für alten Code, die von 1,7 auf 0,46 Prozent gefallen ist. Beides beschreibt dieselbe Bewegung aus verschiedenen Blickwinkeln: Der Bestand wächst nach außen, während die älteren Schichten liegen bleiben.

The codebase grows outward with new v1 features, while its older strata are left frozen. (externe Seite, gitclear.com)

Die automatische Sicherheitsdurchsicht

Für einen Teil dieser Arbeit gibt es ein Werkzeug beim Hersteller. Claude Code kennt einen Befehl für die Sicherheitsdurchsicht, und daneben steht eine GitHub-Aktion, die bei jedem Beitrag von selbst anläuft:

Triggers automatically when new pull requests are opened. (externe Seite, support.claude.com)

Claude will analyze your codebase and identify potential security concerns. (externe Seite, support.claude.com)

Der Katalog dahinter ist breit und reicht von eingeschleustem Code über Rechtefehler bis zu fest verdrahteten Zugangsdaten. Was der Lauf ausdrücklich weglässt, steht ebenso dabei:

The tool automatically excludes a variety of low-impact and false positive prone findings (externe Seite, github.com)

Weggelassen werden unter anderem Überlastungsangriffe, fehlende Ratenbegrenzung und Eingabeprüfungen ohne belegte Wirkung. Diese Auswahl ist begründbar, und wer den Lauf einsetzt, sollte sie kennen: Ein leerer Bericht ist eine Aussage über den Katalog.

Die Grenze des Prüfers

Der aufschlussreichste Satz steht in der Beschreibung des Werkzeugs selbst.

This action is not hardened against prompt injection attacks and should only be used to review trusted PRs. (externe Seite, github.com)

Ein Werkzeug, das Pull Requests auf Schwachstellen ansieht, bekommt fremden Text zu lesen. Genau das ist die Lage, in der eine Prompt Injection über den Inhalt wirkt, und der Hersteller schreibt hin, dass sein Werkzeug dagegen ungehärtet ist. Wer es an einem offenen Projekt einsetzt, wo Beiträge von außen kommen, benutzt es außerhalb seiner Zusage.

Damit ist es derselbe Fall wie in Kapitel 08 und Kapitel 09: Die Vorkehrung liegt eine Ebene tiefer, in der Umgebung, in der der Lauf stattfindet.

Die Anleitung zieht daneben eine zweite Grenze, und zwar für das Ergebnis:

While automated security reviews help identify many common vulnerabilities, they should complement, not replace, your existing security practices and manual code reviews. (externe Seite, support.claude.com)

Der Nutzen bleibt. Eine Durchsicht, die bei jedem Pull Request von selbst anläuft, findet Dinge, die sonst niemand sucht, und sie kostet einen Modellaufruf. Sie tritt an die Stelle einer Durchsicht, die vorher meistens ausfiel.

Was sich daraus einrichten lässt

Aus den Zahlen folgen drei Vorkehrungen, und alle drei sind Messungen.

Eine Kennzahl je Woche, verglichen mit der Vorwoche. Welche, ist weniger wichtig als die Regelmäßigkeit. Doppelte Blöcke sind der beste Kandidat, weil die Zahl ohne Deutung auskommt und mit dem Aufwand steigt, den eine spätere Änderung kostet.

Ein fester Termin für den Umbau. Bei OpenAI war es der Freitag, ein Fünftel der Woche. Ob es ein Wochentag ist oder jede fünfte Runde, entscheidet das Projekt; entscheidend ist, dass der Termin unabhängig vom Vorgangsvorrat existiert.

Ein Lauf, der fremden Text zu lesen bekommt, steht in einer Umgebung, die das aushält. Das gilt für die Sicherheitsdurchsicht wie für jeden anderen Agentenlauf über Beiträge von außen.

Die letzte Kennzahl aus der Erhebung ist zugleich die stillste. Sie misst, wie oft überhaupt noch jemand Code anfasst, der älter als ein Jahr ist, und sie steht bei 0,46 Prozent.

Healthy, long-lived repositories require developers to periodically return to old code: consolidate it, document it, retire it. (externe Seite, gitclear.com)