Code­qua­lität und Refac­to­ring

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 neben­ein­an­der­ge­legt. Grundlage der Auswertung (externe Seite, gitclear.com) sind 623 Millionen Änderungen aus diesem Zeitraum.

Vier Kennzahlen, eine Richtung

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 auf­ein­an­der­fol­gende 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. Die Auswertung (externe Seite, gitclear.com) nennt das eine Steuer, die jeder doppelte Block erhebt: Bei jeder Änderung an einer Kopie ist für alle anderen zu prüfen, ob die Änderung auch dort hingehört.

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 Stellen anfasst, die seit über einem Jahr liegen. Die Auswertung (externe Seite, gitclear.com) folgert daraus, dass diese Pflege immer öfter ausbleibt.

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: Laut der Refactoring-Erhebung (externe Seite, arxiv.org) zielen die Agenten in 26,1 Prozent der Commits ausdrücklich auf einen Umbau.

Das ist mehr als jeder vierte Commit, 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: Bei den Agenten überwiegen laut derselben Erhebung (externe Seite, arxiv.org) kleinteilige Änderungen, die vor allem für Einheitlichkeit sorgen.

Variablentypen anpassen, Parameter umbenennen, Variablen umbenennen. Was dabei ausbleibt, benennt dieselbe Arbeit (externe Seite, arxiv.org): Die Agenten ziehen örtlich begrenzte Verbesserungen den Änderungen am übergeordneten Entwurf vor, die beim Umbauen durch Menschen üblich sind.

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.

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 in seinem Erfahrungsbericht (externe Seite, openai.com) so: Jeden Freitag, also 20 Prozent der Woche, verbrachte das Team mit Aufräumen.

Ein Fünftel der Arbeitswoche, als fester Termin. Mit der Zeit reichte er nicht mehr, und das Team ersetzte ihn durch einen Aufräumlauf: Hin­ter­grund­auf­gaben von Codex suchen laut Bericht (externe Seite, openai.com) in festem Takt nach Abweichungen und öffnen gezielte Pull Requests zum Umbau.

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 zeigt, welche dieser Größen sich im eigenen Projekt messen lassen.

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 Größen lassen sich mit gewöhnlichen Mitteln zählen. Zwei davon stammen aus der Erhebung, die Dateigröße ist die einfachste von allen.

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. GitClears Auswertung (externe Seite, gitclear.com) stellt fest, dass neuer Code immer weniger mit dem vorhandenen Bestand verwoben ist.

Was ein Zähler nur annähert

Für einige der geläufigen Begriffe gibt es Werkzeuge, die sie als Code Smells zählen, etwa für eine Klasse mit zu vielen Zuständigkeiten. Die Refactoring-Erhebung (externe Seite, arxiv.org) hat solche Smells vor und nach jedem Umbau der Agenten gezählt, getrennt nach Entwurf und Umsetzung. Laut ihrem Abschnitt 4.4 blieb die Zahl in beiden Gruppen im Median gleich.

Ein solcher Zähler arbeitet mit Faustregeln. Ob eine Datei zu viel tut, hängt davon ab, was sie tun soll, und eine Maschine sieht die Zeilenzahl. Für technische Schuld als Ganzes nennt keine der Erhebungen dieses Kapitels eine Zahl, und das Kapitel rechnet deshalb nicht mit ihr.

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 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Das Ende der Zeile entscheidet, ob der Agent die Meldung überhaupt sieht. Ein Linter endet bei einem Befund gewöhnlich mit dem Rückgabewert 1. Claude Code wertet ihn als Fehler, der nichts aufhält, und zeigt im Verlauf einen Hinweis mit der ersten Zeile der Fehlerausgabe. Damit Claude selbst die Meldung liest, nennt die Referenz (externe Seite, code.claude.com) den Rückgabewert 2: Dann sieht Claude den Fehlerkanal, obwohl das Tool schon gelaufen ist. Deshalb leitet der Befehl die Ausgabe des Linters dorthin um und endet bei einem Befund mit 2.

Was ein solcher Hook sonst kann und woran er scheitert, steht in Kapitel 12. Für dieses Kapitel zählt die Grenze: Er prüft jede Datei für sich, auch wenn er über den ganzen Baum läuft, 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. Wachsen kann sie nur über einen eigenen Schritt, der den Stand neu einfriert und in der Ver­si­ons­ge­schichte sichtbar bleibt.

Diese Seite fährt eine solche Prüfung für die Größe ihrer gebauten Seiten. Die Liste dazu ist eine Textdatei, 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.

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 Ver­fah­rens­an­wei­sung 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: Wo die Dokumentation nicht ausreicht, überführt es die Regel laut seinem Erfahrungsbericht (externe Seite, openai.com) in Code.

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: Laut GitClear (externe Seite, gitclear.com) haben die baulichen Gewohnheiten, die einen Bestand wartbar halten, bei jedem gemessenen Signal nachgelassen.

Die andere misst an 15.451 Umbauten, dass Agenten die Struktur verbessern: Agentisches Refactoring bringt laut der Refactoring-Erhebung (externe Seite, arxiv.org) kleine, aber statistisch signifikante Verbesserungen bei den Struk­tur­kenn­zahlen.

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. Am deutlichsten ist das bei Umbauten mittlerer Stufe, die Signatur und Methodenrumpf zugleich ändern. Laut der Erhebung (externe Seite, arxiv.org) sinkt dort die Klassengröße im Median um gut fünfzehn Zeilen. Umbauten, die nur Signaturen ändern, bewegen die Kennzahlen kaum. Die Zahl der Code Smells bleibt laut Abschnitt 4.4 der Arbeit im Median gleich.

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. Ein Umbau verbessert die Stelle, die er anfasst, und Umbauten werden seltener, gemessen an allem, was daneben entsteht. Die zweite Zahl entscheidet über den Zustand eines Projekts nach zwei Jahren.

Beim Neben­ein­an­der­stellen 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 in der Wartungsstudie (externe Seite, arxiv.org), und der dritte ist der unbequemste.

Maschi­nen­ge­schrie­bene Dateien werden seltener gepflegt als Code, den Menschen geschrieben haben. Beobachtet sind die ersten sechs Monate nach dem Anlegen einer Datei. Der Abstand ist im ersten Monat am größten und wird ab dem vierten Monat klein. Ob die Dateien stabil sind oder ob man sie meidet, lassen die Autoren offen; beide Erklärungen nennen sie im Abschnitt zu den Folgerungen. Wird an ihnen doch gearbeitet, dann am häufigsten, um Funktionen anzubauen, während an Dateien, die Menschen geschrieben haben, die Fehlerbehebung überwiegt. Und den weitaus größten Teil dieser Pflege leisten Menschen.

In dieselbe Richtung zeigt GitClears Kennzahl für alten Code, die von 1,7 auf 0,46 Prozent gefallen ist. Die beiden Messungen überblicken verschiedene Zeiträume: Die Wartungsstudie folgt einer Datei sechs Monate lang, GitClear zählt Änderungen an Code, den seit über einem Jahr niemand angefasst hat. Die Auswertung (externe Seite, gitclear.com) fasst ihre Beobachtung in ein Bild: Der Bestand wächst mit neuen Funktionen in erster Fassung nach außen, während seine älteren Schichten eingefroren liegen bleiben.

Die automatische Sicherheitsdurchsicht

Für einen Teil dieser Arbeit gibt es ein Werkzeug beim Hersteller. Claude Code kennt einen Befehl für die Sicher­heits­durch­sicht, und daneben steht eine GitHub-Aktion. Laut Anleitung (externe Seite, support.claude.com) läuft sie von selbst an, sobald ein neuer Pull Request geöffnet wird. Sie sieht dann die Änderungen auf Schwachstellen durch und setzt ihre Befunde als Kommentare in den Pull Request. Welche Prüfwerkzeuge Anthropic inzwischen daneben anbietet, steht in Claude Code, Kapitel 25.

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: Laut der Beschreibung der Aktion (externe Seite, github.com) schließt das Werkzeug von selbst eine Reihe von Befunden aus, die wenig Wirkung haben oder zu Fehlalarmen neigen.

Weggelassen werden unter anderem Über­las­tungs­an­griffe, fehlende Ratenbegrenzung und allgemeine Hinweise zur Eingabeprüfung, deren Auswirkung nicht belegt ist. 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 auf­schluss­reichste Satz steht in der Beschreibung des Werkzeugs (externe Seite, github.com) selbst: Die Aktion ist gegen Prompt Injection nicht gehärtet und soll nur Pull Requests prüfen, denen man vertraut. Als Vorkehrung empfiehlt die Beschreibung eine Einstellung im Repository, mit der Workflows für Beiträge von außen erst laufen, wenn ein Maintainer den Pull Request angesehen hat.

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 ohne diese Freigabe an einem offenen Projekt einsetzt, in das 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 (externe Seite, support.claude.com) zieht daneben eine zweite Grenze, und zwar für das Ergebnis: Automatische Sicher­heits­durch­sichten helfen, viele verbreitete Schwachstellen zu finden, und sollen die bestehenden Sicher­heits­ver­fahren und die Durchsicht von Hand ergänzen, ohne sie zu ersetzen.

Der Nutzen bleibt. Eine Durchsicht, die bei jedem Pull Request von selbst anläuft, findet Dinge, die sonst niemand sucht. Sie kostet einen Lauf von Claude Code.

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 Takt für den Umbau. Bei OpenAI war es zuerst der Freitag, ein Fünftel der Woche von Hand. Das reichte nicht, und heute suchen dort Hintergrundläufe in festem Takt nach Abweichungen. Ob es ein Wochentag ist, jede fünfte Runde oder ein eigener Lauf, entscheidet das Projekt; entscheidend ist, dass der Takt unabhängig vom Vorgangsvorrat besteht.

Ein Lauf, der fremden Text zu lesen bekommt, steht in einer Umgebung, die das aushält. Das gilt für die Sicher­heits­durch­sicht 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 seit über einem Jahr unberührt liegt, und sie steht bei 0,46 Prozent. Gesunde, langlebige Repositories brauchen laut GitClear (externe Seite, gitclear.com) Entwickler, die regelmäßig zu altem Code zurückkehren: ihn zusammenführen, dokumentieren, stilllegen.