KI räumt sich selbst auf

Dein Repo wird jedes Mal unordentlicher, wenn ein KI-Agent ein Feature shippt. Toter Code häuft sich an. Branches brechen und bleiben liegen. Naming-Patterns driften. Nichts davon ist dramatisch. Es summiert sich, Feature nach Feature, bis die Codebasis langsamer zu ändern und beängstigender anzufassen ist.

Dieser Beitrag zeigt eine Hausmeister-Crew, die das für dich aufräumt, nach einem Zeitplan, während du schläfst. Drei Workflows. Ein Scheduler. Jeder nimmt eine andere Art von Chaos und behandelt es still. Du wachst auf, liest eine E-Mail und weißt, was gefegt, was repariert und was noch einen menschlichen Blick braucht.

Die drei kleinen Probleme, die groß werden

Die meisten Codebasis-Probleme starten nicht groß. Sie starten klein und bleiben eine Weile klein. Dann hat die kleine Version ein paar Features später Kopien an drei anderen Stellen, und das Aufräumen ist eine Woche statt einer Stunde.

Das sind die drei, die in KI-lastigen Repos am häufigsten auftauchen.

1. Toter Code, den niemand löscht

Der Agent shippt ein Feature. Eine Woche später shippst du eine andere Version dieses Features. Der alte Code liegt noch da. Niemand löscht ihn, weil niemand sicher ist, ob ihn noch etwas verwendet. Drei weitere Features später hat dein Repo drei verwaiste Helfer, zwei unbenutzte Routes und eine vollständige Seite, auf die kein Link mehr zeigt.

In einem durchschnittlichen Projekt wächst toter Code innerhalb weniger Monate auf etwa 18% des Repos. Das ist Code, der bei jedem Build getypecheckt, gelinted, gebundelt und geladen wird. Er verlangsamt Cold Builds, verwirrt neue Contributor und macht Refactorings beängstigender als nötig.

Das Problem ist nicht das Finden von totem Code. Ein Linter kann das. Das Problem ist das sichere Löschen. Du musst wissen, dass das Entfernen der Datei tatsächlich nichts bricht. Meistens hat niemand die Geduld, das Zeile für Zeile zu verifizieren, also bleibt der tote Code.

2. Kaputte Branches, die das Shippen blockieren

Ein Agent-Lauf endet. Er sagt, das Feature ist fertig. Du pullst den Branch morgens und der Build ist rot. Typfehler, fehlgeschlagener Test, fehlender Import. Kleine Sache. Du fixst es in zehn Minuten.

Außer dass du das mehrmals pro Woche morgens machst. Zehn Minuten hier. Zwanzig Minuten dort. Zwei volle Tage pro Monat für das Beheben eines kaputten Übergabefehlers, bevor du überhaupt mit der echten Arbeit anfangen kannst. Und wenn der Bruch auf main landet, wartet jedes andere Feature darauf.

Die Lösung ist in der Theorie einfach. Der Agent sollte seinen eigenen Bruch beheben. In der Praxis bedeutet das, Tests zu starten, den Fehler zu lesen, die richtige Datei zu bearbeiten und die Dinge nicht schlechter zu machen durch Raten. Das ist eine Schleife, die die meisten Agenten ohne extra Struktur nicht selbst schließen können.

3. Patterns, die still driften

Du hast vier Features, die alle ungefähr dasselbe tun: Auth, Billing, Notify, Search. Sie alle folgen einem Pattern. Gleiche Ordnerform. Gleiche Dateinamen. Gleiche Namen für die Schlüsselfunktionen.

Dann driftet ein Feature. Der Agent benennt etwas etwas anders. Oder teilt eine Datei, die die anderen zusammenhalten. Oder überspringt ein Pattern, das alle anderen teilen. Allein ist das in Ordnung. Drei Features später sieht ein neuer Agent das gedriftete Feature und kopiert diese Form statt des Originals. Jetzt hast du eine Abspaltung in deiner eigenen Codebasis, auf die sich niemand geeinigt hat.

Drift ist das teuerste Durcheinander der drei. Eine tote Datei kostet dich einen Delete. Ein kaputter Branch kostet dich einen Morgen. Ein Drift, der sich in drei weitere Features ausbreitet, kostet dich ein echtes Refactoring über den gesamten Ordner.

Die Hausmeister-Crew

Das System besteht aus drei Claude Code-Workflows, die nach einem overnight-Zeitplan laufen. Du kannst sie dir als eine Reinigungscrew vorstellen, jede mit einer engen Aufgabe.

Ein Scheduler weckt die Crew nachts. Er feuert jeden Workflow der Reihe nach. Jeder schreibt eine kurze Notiz in ein gemeinsames Log. Der letzte Schritt fasst das Log zu einer E-Mail zusammen und sendet sie dir.

Nichts wird alleine auf main geshippt. Slop-cleaner-Bearbeitungen finden hinter Tests statt. /heal arbeitet auf einem Side-Branch, nicht auf main. /drift markiert nur, schreibt nicht um. Du bleibst die Person, die den Morgenbericht akzeptiert oder ablehnt.

Hausmeister eins: slop-cleaner

Slop-cleaners Aufgabe ist es, toten Code zu löschen ohne etwas zu brechen.

Der Trick liegt in der Reihenfolge. Die meisten Dead-Code-Tools scannen, listen und lassen dann einen Menschen löschen. Das ist langsam, weil niemand die Person sein will, die Prod bricht, indem sie die falsche Datei entfernt. Der Workflow dreht die Reihenfolge um: schreib zuerst das Sicherheitsnetz, dann lösch, dann führ das Sicherheitsnetz erneut aus.

Schritt eins, schreib Regressionstests. Der Agent schaut sich die Dateien an, die gleich berührt werden, und schreibt für jede, die noch einen Aufrufer hat, einen kleinen Test. Das Ziel ist nicht vollständige Abdeckung. Das Ziel ist ein grünes Signal, das sagt: "Die Teile, die wichtig sind, funktionieren noch." Diese Tests werden auf einem Side-Branch committed, damit ein Mensch sie lesen kann.

Schritt zwei, lösch den toten Code. Der Agent nutzt eine statische Prüfung, um Kandidaten aufzulisten: Dateien ohne eingehende Imports, Funktionen, die nie aufgerufen werden, Routes ohne Links, Typen, die nie referenziert werden. Er entfernt sie in kleinen Batches.

Schritt drei, führe die Tests erneut aus. Wenn alle Tests noch grün sind, bleiben die Deletes. Wenn ein Test rot wird, wird das spezifische Delete, das ihn verursacht hat, rückgängig gemacht. Der Agent versucht nicht, den Test zu "fixen". Er nimmt an, dass das Delete falsch war, und macht es rückgängig. Nichts Subtiles.

Das Ergebnis ist ein Repo, das leichter wird ohne die übliche Angst. In einem overnight-Lauf entfernte die Crew 412 Zeilen toten Codes in einer mittelgroßen SaaS. Null Tests brachen. Null Seiten hörten auf zu rendern. Am nächsten Morgen scannte der Reviewer den Diff, klickte auf Genehmigen und machte weiter.

Slop-cleaner funktioniert nur, wenn das Test-Sicherheitsnetz ehrlich ist. Wenn der Agent fake Tests schreibt, die immer bestehen, fällt das gesamte Muster auseinander. Der Workflow erzwingt eine Regel: Jeder Test muss eine echte Funktion aufrufen und eine echte Ausgabe behaupten. Tests, die die getestete Datei nie importieren, werden abgelehnt.

Hausmeister zwei: /heal

/heals Aufgabe ist es, kaputte Branches zu reparieren ohne kaputten Code auf main zu bringen.

Wenn /heal aufwacht, liest es die Liste der aktuellen Feature-Branches. Für jeden führt es den Build, den Type-Check und die Test-Suite aus. Wenn ein Branch rot ist, fängt /heal an, daran zu arbeiten.

Das wichtige Detail: /heal arbeitet auf einem Side-Branch, nicht auf dem Original. Es kopiert den kaputten Branch in etwas wie heal/feature-name, macht dort seine Bearbeitungen und lässt das Original unverändert. Main bleibt die ganze Zeit sauber. Der ursprüngliche Autor besitzt immer noch die Fix-Entscheidung.

Die Fix-Schleife ist eng. /heal liest die erste fehlgeschlagene Prüfung und stellt eine Frage: Welche Änderung lässt genau diese Prüfung bestehen? Es bearbeitet die kleinstmögliche Oberfläche, führt die Prüfung erneut aus und geht zum nächsten Fehler über. Es refactored nicht. Es verbessert nicht. Es schließt nur die roten Signale.

Nach der Schleife führt /heal alles nochmal aus. Wenn alle Prüfungen bestehen, bewertet es sein eigenes Vertrauen auf einer Skala von null bis hundert. Der Score basiert auf einfachen Signalen: Hat der Fix eine Test-Datei oder eine Source-Datei berührt, wie viele Zeilen haben sich geändert, waren die Fehler klar und eng oder vage und breit, ist derselbe Test zweimal hintereinander fehlgeschlagen, bevor er bestand.

Dann schreibt /heal ein kurzes Urteil und schickt es per E-Mail. Das Urteil enthält den Branch-Namen, den Konfidenz-Score, die genauen geänderten Dateien und einen einzeiligen Grund. 92% Konfidenz, zwei Dateien berührt, fehlender Import im Handler. Diese Art von Notiz.

Ein Mensch entscheidet immer noch, ob gemergt wird. Hohe Konfidenz mit einem engen Diff bekommt normalerweise ein Ja. Niedrige Konfidenz oder ein breiter Diff bekommt einen näheren Blick. Der Punkt ist nicht, menschliche Überprüfung zu entfernen. Der Punkt ist sicherzustellen, dass der Mensch einen sauberen, engen Fix überprüft statt eines rohen roten Branchs.

Hausmeister drei: /drift

/drifts Aufgabe ist es, Pattern-Abweichungen bei aktuellen Features abzufangen, bevor sie sich ausbreiten.

Wenn /drift aufwacht, erstellt es eine Pattern-Map deiner Codebasis. Es nimmt eine kleine Menge von Features (normalerweise die letzten fünf bis zehn) und erfasst die Form jedes: Ordner-Layout, Dateinamen, Funktionsnamen, Import-Stil, Test-Ort. Das ist ein einfacher Schnappschuss, keine tiefe Analyse.

Dann vergleicht es. Wenn vier Features dieselbe Form haben und ein Feature etwas anders ist, ist dieses ein Ausreißer. /drift schreibt den Ausreißer nicht um. Es markiert ihn.

Eine Markierung sieht so aus: "notify verwendet sendNotification während auth, billing und search sendEmail verwenden. Naming-Drift. Kostet 4x zu fixen nach drei weiteren Features, die es kopieren." Das ist spezifisch genug, um darauf zu reagieren, und vage genug, um die finale Entscheidung beim Menschen zu lassen.

Warum markieren statt fixen. Weil Drift nicht immer falsch ist. Manchmal ist der Ausreißer die richtige Wahl und die anderen vier sind das Legacy. Ein Mensch kann sagen, welches was ist. Ein Agent kann das nicht, weil die Regel sich je nach Absicht ändert. Also erledigt /drift die Arbeit, die ein Agent gut kann (das Muster erkennen) und überlässt dir das Urteil.

Das kritische Fenster ist früh. Wenn /drift den Drift in notify abfängt, bevor drei weitere Features das Muster kopieren, ist der Fix eine Datei. Wenn es danach auffängt, ist der Fix vier Dateien plus die Koordination zwischen Teams. Daher kommt die Zahl "kostet 4x zu fixen."

Eine Nacht, ein Zeitplan

Der Scheduler ist einfach. Ein Trigger, ein Cron-ähnlicher Eintrag, feuert zu einer bestimmten Zeit jede Nacht.

Wenn er feuert, startet eine neue Claude Code-Sitzung. Der Orchestrator liest den aktuellen Zustand des Repos und führt die drei Workflows in Reihenfolge aus: slop-cleaner, dann /heal, dann /drift. Jeder schreibt eine kurze Notiz in ein gemeinsames Log bei ./overnight.log.

Die Reihenfolge ist wichtig. Slop-cleaner läuft zuerst, weil er den zu überprüfenden Code verkleinert. /heal läuft als zweites, weil es das behebt, was gerade kaputt ist. /drift läuft zuletzt, weil es die sauberste Version des Repos liest, nachdem die anderen beiden ihre Arbeit erledigt haben.

Jeder Hausmeister hat ein Zeitbudget. Wenn er zu lange läuft, beendet der Workflow diesen Schritt und geht zum nächsten über. Der Punkt ist eine vorhersehbare Morgen-E-Mail, nicht ein perfektes Overnight. Unfertige Arbeit wird markiert und in der nächsten Nacht aufgegriffen.

Nichts in diesem Setup erfordert eine Cloud-Plattform. Ein echter crontab-Eintrag auf deiner Maschine funktioniert. Eine Claude Code Desktop Scheduled Task funktioniert. Die Wahl ist operationell, nicht architektonisch. Was zählt, ist dass der Trigger feuert, eine neue Sitzung aufwacht und der Orchestrator weiß, wo er anfangen soll.

Der Morgenbericht

Der letzte Schritt des overnight-Laufs fasst das Log zu einer E-Mail zusammen und sendet sie. Das Format ist kurz, scannbar und geordnet von "braucht nichts" bis "braucht Überprüfung."

Ein echtes Morgen-Log sieht so aus:

overnight.log - janitor crew
01:00  Slop-cleaner swept the repo
       412 dead lines removed. Tests green.

02:30  /heal rescued a broken branch
       Fixed on side branch. 92% confidence.

04:00  /drift caught a naming gap
       1 file out of pattern. Flagged.

07:00  Verdict emailed to you
       3 cleanups ready for review.

Du liest es bei einem Kaffee. Vier Minuten, maximal. Jede Zeile hat eine Uhrzeit, ein kurzes Ergebnis und eine Zahl, die dir sagt, wie sicher der Hausmeister war. Die Bereinigungen mit hoher Konfidenz werden meist sofort genehmigt. Der markierte Drift bekommt einen kurzen Blick und entweder einen Fix oder ein "Lass es, das ist beabsichtigt."

Die Form der E-Mail ist der Punkt. Kurz. Konkret. Geordnet. Keine Prosa-Zusammenfassungen. Kein "Der Agent hat heute Nacht hart gearbeitet"-Füller. Du willst wissen, was sich geändert hat, wie sicher der Hausmeister ist und was du dagegen tun musst. Sonst nichts.

Wie du deine eigene Version baust

Du brauchst nicht den gesamten Stack, um den Nutzen zu haben. Das Muster ist einfach. Fang mit dieser Form an und erweitere von dort.

Schreib drei kleine Workflows. Halte sie eng. Slop-cleaner löscht toten Code nur wenn ein Test besteht. /heal repariert kaputte Branches nur auf einem Side-Branch. /drift markiert Pattern-Abweichungen nur bei aktuellen Features. Jeder hat eine einzelne Aufgabe und ein einzelnes Output-Format.

Stell sie hinter einen Scheduler. Cron ist in Ordnung. Eine geplante Claude Code-Sitzung ist in Ordnung. Du brauchst keine Job-Queue oder Message-Bus. Du brauchst einen Ping, der die Crew zu einer bestimmten Zeit aufweckt.

Schreib die Regressionstests vor dem Löschen, jedes Mal. Das ist die Regel, die slop-cleaner sicher macht. Wenn der Agent keinen ehrlichen Test für die Datei schreiben kann, die er löschen will, passiert das Delete nicht. Diese einzelne Regel ist den gesamten Workflow wert.

Halte /heal auf einem Side-Branch. Main muss sauber bleiben. Wenn /heals Fix falsch ist, wird der Side-Branch weggeworfen und der ursprüngliche kaputte Branch wartet noch auf einen Menschen. Keine Überraschungen auf main, niemals.

Lass /drift markieren, nicht fixen. Das ist die schwerste Regel zu halten. Agenten wollen Code "verbessern", wenn sie ihn sehen. Für Drift ist das der falsche Schritt. Ein Pattern, das falsch aussieht, könnte beabsichtigt sein. Die Aufgabe des Agenten ist es, es zu zeigen und aufzuhören. Die Aufgabe des Menschen ist es, zu entscheiden, was das Pattern künftig sein soll.

Beende jeden Lauf mit einer kurzen, strukturierten E-Mail. Uhrzeit, Ergebnis, Zahl, einzeiliger Grund. Sonst nichts. Wenn du die gesamte E-Mail nicht in unter fünf Minuten scannen kannst, erledigt der Hausmeister in einer Nacht zu viel Arbeit. Teile es auf.

Wo dieses Muster sonst noch gilt

Wenn du einmal eine Hausmeister-Crew für Code laufen hast, funktioniert dieselbe Form für andere Arten von langsam wachsendem Chaos.

Content-Hausmeister. Ein Workflow, der alte Blog-Beiträge durchsucht, veraltete Abschnitte markiert und dem Autor eine Notiz schreibt. Er schreibt nicht um. Er markiert.

Analytics-Hausmeister. Ein Workflow, der Event-Naming in deinem Produkt auf Drift prüft, Ausreißer markiert und eine kanonische Liste vorschlägt. Dasselbe Pattern-Map wie /drift, andere Inputs.

Dependency-Hausmeister. Ein Workflow, der ungenutzte Pakete scannt, einen Test schreibt, der jeden aktiven importiert, und den Rest entfernt, wenn Tests noch bestehen. Dasselbe Sicherheitsnetz wie slop-cleaner, angewendet auf package.json.

Die Kernidee ist nicht "KI räumt Code auf." Es ist "kleine Probleme werden nach einem Zeitplan behandelt, hinter einem Sicherheitsnetz, in einem Format, das du in fünf Minuten lesen kannst." Das funktioniert für Code, Content, Analytics und alles andere, das zwischen den großen Ships still wächst.

Eine Crew. Ein Zeitplan. Drei enge Aufgaben. Ein saubereres Repo am Morgen und eine E-Mail, die deine Zeit respektiert. Das ist das gesamte System.