Fallow: das ESLint für Probleme mit KI-generiertem Code

Fallow: Das ESLint für Probleme mit KI-generiertem Code

Letzten Monat habe ich ein Feature ausgeliefert, das Claude Code fast vollständig eigenständig geschrieben hat. Es funktionierte. Tests bestanden. Der PR wurde gemergt. Ich fühlte mich etwa eine Woche lang großartig dabei.

Dann ging ich zurück, um eine kleine Änderung vorzunehmen, und fand drei Kopien der exakt gleichen Audio-Extraktionslogik in derselben Datei. Unterschiedliche Variablennamen, identisches Verhalten. Eine exportierte Funktion namens extractAllAudio, die nirgendwo in der Codebase importiert wurde. Eine dev-only Dependency in den Produktions-dependencies. Nichts davon hat etwas kaputt gemacht. Alles davon war Verfall, der sich still anhäufte.

Das ist das schmutzige Geheimnis des schnellen KI-Codens: Der Code läuft, also hört man auf hinzuschauen. Und das Werkzeug, nach dem man normalerweise greifen würde — ESLint — fängt davon nichts ab. ESLint sagt dir, dass ein Semikolon fehlt. Es sagt nichts über den 100-Zeilen-Block, den du inzwischen in vier Routen kopiert hast.

Als ich also fallow fand, ein kostenloses Codequalitäts-Tool für KI-generierten Code, das speziell für die Wartbarkeitsprobleme gebaut wurde, die KI-Codiertools einführen, räumte ich einen Nachmittag frei und richtete es auf mein unordentlichstes Repo. Was es zutage förderte, veränderte, wie ich Agent-Output überprüfe. Lassen Sie mich Ihnen genau zeigen, was es fand — und wo es sich seinen Platz in meinem Workflow verdiente, und wo nicht.

Warum KI-generierter Code auf Weisen verrottet, die ESLint nie sieht

Hier ist die Sache mit einem LLM, das Code schreibt: Es hat kein Gedächtnis dafür, was es vor vier Dateien geschrieben hat. Es optimiert für diesen Prompt, jetzt, funktionierenden Output produzieren. Wartbarkeit über die gesamte Codebase hinweg ist schlicht nicht in seiner Verlustfunktion enthalten.

Das produziert drei spezifische Fehlermodi, immer und immer wieder, in sowohl handcodiertem als auch AI-codiertem Projekten — wobei es deutlich schlimmer ist, wenn ein Agent das Tippen übernimmt.

Duplikation. Das Modell braucht dieselbe Logik an zwei Stellen, also schreibt es sie zweimal. Dann ein drittes Mal. Es extrahiert keinen gemeinsamen Helper, weil Extrahieren erfordert, die gesamte Codebase im Arbeitsgedächtnis zu halten, und das tut es nicht. Ich habe 100+ identische Zeilen gesehen, die sich in einer einzigen Datei wiederholten. ESLint zuckt dabei mit den Schultern. Der Code ist gültig.

Aufblähung und Komplexität. Bitten Sie einen Agenten, "alle Randfälle abzudecken", und er wird es tun — indem er Bedingungen in Schleifen in Bedingungen stapelt, bis eine einzelne Funktion 1.500 Zeilen umfasst und niemand, weder Mensch noch Maschine, sie im Kopf behalten kann. Jeder Zweig ist korrekt. Das Ganze ist ein Sumpf.

Totes Gewicht. Unbenutzte Dateien. Exportierte Funktionen, die nichts importiert. Dependencies, die für ein Experiment eingebunden und nie entfernt wurden. Agents erstellen ständig Scaffolding und räumen selten hinter sich auf, weil Aufräumen nicht die Aufgabe war.

Und die grausame Ironie? KI-Tools sind schlecht darin, ihren eigenen Verfall zu erkennen. Fragen Sie Claude oder Cursor "gibt es Duplikation in dieser Datei?" und Sie bekommen eine selbstbewusste, plausible, häufig falsche Antwort. Es ist eine probabilistische Vermutung über den eigenen Output. Was Sie tatsächlich brauchen, ist etwas Deterministisches — etwas, das den Code parst statt darüber zu räsonieren.

Das ist die Lücke, die fallow füllt. Und die Art, wie es das tut, ist der interessante Teil.

Was fallow eigentlich ist (und warum Rust hier wichtig ist)

Fallow ist Codebase-Intelligenz für TypeScript und JavaScript, vollständig in Rust gebaut. Das Team dahinter — die fallow-rs Organisation auf GitHub — beschreibt es als die Konsolidierung einer ganzen Suite von statischen Analysetools in eine einzige Sub-Sekunden-Binary. Anfang Juni 2026 befindet es sich auf der 2.8x-Releaselinie und liefert fast täglich Updates.

Das Modell teilt sich sauber in zwei:

Statische Intelligenz — vollständig kostenlos, Open Source. Dies analysiert die Struktur Ihres Codes: Dead Code, Duplikation, zirkuläre Abhängigkeiten, Komplexität, Architekturgrenzen. Das ist der Teil, den ich nutze, und worum es in diesem gesamten Artikel geht.
Runtime-Intelligenz — eine optionale kostenpflichtige Schicht, die Hot-Path-Review und Cold-Path-Löschungsnachweise aus realem Produktionsverkehr hinzufügt. Sie sagt Ihnen, welcher "tote" Code tatsächlich tot ist, basierend auf dem, was in der Produktion läuft. Nützlich für große Teams, die Löschungsentscheidungen treffen. Ich habe nicht dafür bezahlt, und ich möchte ehrlich sein: Ich bewerte die kostenlose statische Schicht, denn dort liegt der alltägliche Nutzen.

Sie müssen nichts installieren, um es auszuprobieren. Ein Befehl:

# Führe eine vollständige Analyse des aktuellen Repos durch, keine Installation nötig
npx fallow

Beim ersten Durchlauf erkennt fallow automatisch Ihren Stack. Bei meinem Vite + TanStack Query-Projekt lud es Plugins für Vite, TanStack Query und Tailwind CSS, ohne dass ich etwas konfigurieren musste — es wird mit etwa 95 Framework-Plugins ausgeliefert und verbindet die richtigen basierend auf Ihrer package.json. Es legt außerdem ein .fallow-Cache-Verzeichnis an, damit nachfolgende Durchläufe schnell sind.

Warum ist Rust wichtig? Weil Geschwindigkeit Verhalten verändert. Ein Linter, der 40 Sekunden braucht, wird einmal pro Woche ausgeführt. Ein Linter, der fertig ist, bevor Sie Ihre Hand von der Tastatur genommen haben, wird bei jedem Speichern ausgeführt, in jedem PR, von jedem Agenten in einer Schleife. Sub-Sekunden-Analyse macht fallow innerhalb eines agentischen Workflows praktikabel — und das ist, wie ich später argumentieren werde, wo es wirklich mächtig wird.

Aber zuerst der Bericht. Denn das erste Mal, wenn Sie einen fallow-Bericht über KI-geschriebenen Code lesen, ist es ein wenig demütigend.

Einen fallow-Bericht lesen: die vier Abschnitte, die zählen

Als ich es ausführte, gliederte sich der Output in klare Kategorien. Ich gehe sie so durch, wie ich sie gelesen habe — schlimmste Übeltäter zuerst.

Dead Code: die Sachen, die du vergessen hast geschrieben zu haben

Dieser Abschnitt findet drei Dinge, und KI-Workflows generieren alle drei in großem Volumen:

Unbenutzte Dateien — Module, die nichts importiert. Agent-Scaffolding, das nie angeschlossen wurde.
Unbenutzte Exports — das extractAllAudio, das ich erwähnte. Exportiert, öffentlich aussehend, von nichts importiert. Fallow markiert es mit der genauen Position.
Unbenutzte Dependencies — und diese ist tückisch. Es fing eine Test-Bibliothek ab, die in den Produktions-dependencies saß, obwohl sie in devDependencies hätte sein sollen. Das ist nicht nur Unordnung; das sind Bytes, die ohne Grund an Benutzer ausgeliefert werden.

Dead Code ist der einfache Gewinn. Es ist auch die Kategorie, in der fallows Auto-Fix glänzt — dazu komme ich noch.

Duplikation: der wichtigste Abschnitt, Punkt

Das ist der, der mir am meisten bedeutet, und es ist dort, wo KI-Code am schlechtesten abschneidet. Fallow meldet Duplikation mit konkreten Zeilenbereichen — nicht "es gibt irgendwo Duplikation", sondern "Zeilen 412-518 hier stimmen mit Zeilen 1.090-1.196 dort überein." Konkret. Handlungsfähig.

Das Feature, das mich aufhorchen ließ, waren Clone Families: Statt 40 paarweise Duplikatwarnungen auszuschütten, gruppiert es wiederkehrende Muster in Familien. Ein Stück Logik, das der Agent in fünf Route-Handler kopiert hat, erscheint als eine Familie mit fünf Mitgliedern, nicht als zehn laute Paare. Diese Gruppierung ist der Unterschied zwischen einem Bericht, nach dem man handelt, und einem Bericht, den man schließt.

Duplikation läuft in zwei Modi, und der Unterschied ist wichtig:

Mild Mode (der Standard) fängt Duplikate ab, bei denen die Variablennamen identisch sind. Konservativ, wenige False Positives.
Semantic Mode fängt Duplikate ab, bei denen die Logik identisch ist, aber die Variablennamen abweichen — genau die Art von Sache, die ein LLM produziert, wenn es dieselbe Funktion mit leicht unterschiedlichen Namen jedes Mal neu schreibt. Strikter, gründlicher, mehr Rauschen.

Für eine KI-lastige Codebase ist der Semantic Mode der, den Sie wollen, weil Variablennamen-Drift die Signatur des LLM ist. Mehr zum Umschalten der Modi weiter unten.

Komplexität: der Gesundheitscheck, den niemand durchführt

Dieser Abschnitt ist ein Check-up für Funktionen, die außer Kontrolle geraten sind. Vier Zahlen erledigen die Arbeit:

Funktionsgröße — markiert die Monster. Ich hatte eine, die auf 1.500 Zeilen zuging.
Zyklomatische Komplexität — die Anzahl unabhängiger Zweige durch eine Funktion. Ein Wert von 115 Zweigen bedeutet 115 verschiedene Pfade. In der Praxis nicht testbar.
Kognitive Last — wie schwer der Code für einen Menschen nachzuvollziehen ist, wobei verschachtelte Schleifen und Bedingungen stark gewichtet werden. Ein verschachteltes Durcheinander kann 133 erzielen, selbst wenn die zyklomatische Komplexität nur schlecht aussieht.
CRAP-Score — Change Risk Anti-Patterns. Das ist der clevere. Er kombiniert Komplexität mit Testabdeckung. Eine komplexe Funktion, die gut getestet ist, erzielt einen niedrigen Wert — Sie können sie sicher ändern. Eine komplexe Funktion ohne Tests erzielt einen brutal hohen Wert, weil eine Änderung ein Münzwurf ist. CRAP ist die Zahl, die Ihnen sagt, wo die echte Gefahr lauert.

Diese letzte Metrik hat neu gerahmt, wie ich über technische Schulden denke. Es ist nicht "diese Funktion ist komplex." Es ist "diese Funktion ist komplex und nichts fängt mich auf, wenn ich sie kaputt mache." Das sind völlig unterschiedliche Dringlichkeitsstufen.

Die Scores: Gesundheit, Risiko und der, der Ihre Arbeit für Sie priorisiert

Fallow rollt alles in ein paar zusammengesetzte Zahlen auf:

Datei-Gesundheitsscore — ein zusammengesetzter Wert von 0-100 aus Dead Code, Import/Export-Konnektivität, Komplexität und CRAP. Höher bedeutet besser wartbar. Sie können die Projektversion mit fallow health --score abrufen und erhalten eine Buchstabennote dazu.
Risikoscore — stark von CRAP getrieben. Das ist Ihr "was am wahrscheinlichsten explodiert"-Messgerät.
Gesamtzusammenfassungsscore — eine Zahl für den gesamten Durchlauf, damit Sie Projekte untereinander vergleichen oder dasselbe Repo über die Zeit verfolgen können.

Ein Score allein ist allerdings nur eine Eitelkeitsmetrik. Der Abschnitt, der Ihnen tatsächlich sagt, was zu tun ist, kommt als nächstes — und es ist das Cleverste am ganzen Tool.

Der Hotspot-Abschnitt: wo fallow aufhört, ein Linter zu sein

Die meisten Qualitätstools geben Ihnen eine flache Liste von Problemen, sortiert nach Schweregrad. Fallow macht etwas, das ich noch nicht so sauber umgesetzt gesehen habe: Es korreliert Komplexität mit Ihrer Git-Commit-Historie.

Denken Sie darüber nach, was das bedeutet. Eine Funktion kann furchtbar komplex sein, aber wenn niemand sie in zwei Jahren angefasst hat, ist sie eingefroren — riskant zu ändern, aber Sie ändern sie nicht, also lassen Sie sie in Ruhe. Die gefährliche Datei ist die, die sowohl komplex als auch ständig geändert wird. Jeder Commit daran ist ein Würfelwurf, und Sie würfeln wöchentlich.

Diese Schnittmenge — Komplexität × Änderungshäufigkeit — ist der Hotspot. Sie führen es so aus:

# Riskanteste Dateien = Git-Änderungshäufigkeit gekreuzt mit Komplexität
npx fallow health --hotspots

Die Hotspot-Liste ist Ihre Refactoring-Prioritätswarteschlange, sortiert danach, wo Aufräumen die beste Rendite auf Ihre Zeit bringt. Sie können sogar Ownership- und Drift-Signale einbeziehen (--hotspots --ownership), um Bus-Faktor-Risiko zu sehen — Dateien, die nur eine Person versteht.

Das ist der Abschnitt, den ich jetzt zuerst prüfe. Nicht "was ist falsch", sondern "was ist falsch und teuer und wird angefasst." Das ist eine fundamental bessere Frage, und es ist die, die einen Bericht in einen Plan verwandelt.

Wenn Sie lieber ein Team beauftragen möchten, das eine KI-lastige Codebase für Sie auditiert und refaktoriert, statt die Tools selbst zu lernen — genau diese Art von Aufräum-Pipeline zu bauen ist die Art von Auftrag, die ich annehme — aber ehrlich gesagt macht fallow den DIY-Weg jetzt für die meisten Teams realistisch.

Fallow in einen echten Workflow einbinden

Ein Bericht, den man einmal liest und vergisst, ist wertlos. Der Grund, warum fallow bei mir hängen blieb, ist, dass es an vier Stellen lebt, an denen ich tatsächlich arbeite. Dies knüpft direkt an den agentischen Entwicklungslebenszyklus an, über den ich zuvor geschrieben habe — Qualitäts-Gates müssen sich von "gelegentlichem menschlichem Review" zu "kontinuierlich, automatisiert, maschinenlesbar" verschieben, wenn Agenten den Großteil des Codes schreiben.

1. Die CLI, gefiltert auf eine Sache zur Zeit

Ein vollständiger Bericht ist bei einem Legacy-Repo überwältigend. Also grenzen Sie ein. Wollen Sie nur Dead Code? Nur Gesundheit und Komplexität? Geben Sie einen Metrikfilter mit und fallow zeigt Ihnen diesen Ausschnitt und nichts anderes:

npx fallow dead-code   # nur unbenutzte Dateien, Exports, Deps
npx fallow dupes       # nur Duplikation
npx fallow health      # Komplexität, Scores, Hotspots

Ich nehme mir eine Kategorie pro Sitzung vor. Allen Dead Code am Montag bereinigen. Die schlimmsten Clone Families am Dienstag angehen. Das verhindert, dass sich die Arbeit endlos anfühlt.

2. Die VS Code-Erweiterung: Verfall, unterstrichen

Die fallow VS Code-Erweiterung führt die Analyse live über einen Language Server durch. Sie bekommen eine Seitenleiste mit Warnungen und Fehlern, gruppiert nach Typ, und — der Teil, den ich mag — Inline-Indikatoren direkt im Editor. Unbenutzte Dateien und Exports werden markiert. Duplizierte Zeilen bekommen Wellenlinien-Unterstreichungen, sodass Sie das Kopieren-und-Einfügen sehen, während Sie durch den Code scrollen. Es zeigt sogar Referenzzähler über CodeLens an, sodass Sie auf einen Blick wissen, wie viele Dinge einen bestimmten Export tatsächlich nutzen.

Duplikation im Editor markiert zu sehen, während man den Code liest, trifft anders als es in einem Bericht zu lesen. Es ist der Unterschied zwischen einem Arztbrief und einem Spiegel.

3. Der KI-Agent-Skill: selbstüberprüfender Code

Das ist der, der wirklich mein mentales Modell verändert hat, und er verdient seinen eigenen Abschnitt. Scrollen Sie nach unten — aber zuerst das letzte Workflow-Element.

4. CI/CD: das Qualitäts-Gate vor dem Mergen

Fallow wird mit einem vorgefertigten GitHub Actions Workflow (und GitLab CI-Unterstützung) ausgeliefert, der bei jedem Push und PR läuft. Es postet einen Markdown-Kommentar direkt im Pull Request, der zusammenfasst, was sich geändert hat, und es kann ein Qualitäts-Gate erzwingen — den Build fehlschlagen lassen, wenn der Gesundheitsscore unter einen Schwellenwert fällt:

# PR fehlschlagen lassen, wenn die Projektgesundheit unter 70 fällt
- run: npx fallow health --min-score 70

Sie wählen, ob Befunde blockierend (inline, muss behoben werden) oder beratend (ein Kommentar, der informiert, ohne zu blockieren) sind. Ein Hinweis aus der Dokumentation, den man kennen sollte: GitHub Actions setzt checkout standardmäßig auf fetch-depth: 1, was Git-Historie-basierte Baselines bricht. Setzen Sie fetch-depth: 0, wenn Sie gegen ein langlebiges Baseline-Tag vergleichen. Ich habe zwanzig Minuten damit verloren, bevor ich das Kleingedruckte las — betrachten Sie dies als Ihre Abkürzung.

Das Killer-CI-Feature ist allerdings der Branch-Vergleich. Statt Ihr gesamtes Repo bei jedem PR zu auditieren — was Sie mit bereits bestehenden Problemen überflutet, die heute niemand beheben wird — kann fallow Ihren Feature-Branch mit main vergleichen und nur die neuen oder geänderten Probleme melden, die Ihr Branch eingeführt hat. Das ist die richtige Analyseeinheit für einen PR. Sie sind nicht für die gesamte Geschichte der Codebase verantwortlich. Sie sind verantwortlich für das, was Sie (oder Ihr Agent) gerade hinzugefügt haben. Inkrementell, fair, und es hält das Signal sauber.

Der Agent-Skill: KI ihre eigenen Hausaufgaben korrekt benoten lassen

Hier wird es wirklich interessant, und hier hört fallow auf, "ein besserer Linter" zu sein, und wird zu etwas, von dem ich glaube, dass es mehr agentische Stacks kopieren werden.

Es gibt ein Begleit-Repo, fallow-skills, das ein Agent-Skill-Modul über npx installiert. Es bringt einem KI-Agenten — Claude Code, Cursor, Codex, Gemini CLI, über 30 davon — bei, wie er fallow selbst aufrufen und den strukturierten JSON-Output lesen kann.

Halten Sie inne bei dem, was das ermöglicht. Der Agent, der den schlampigen Code geschrieben hat, kann jetzt ein deterministisches Tool ausführen, das die Schlampigkeit aufspürt, maschinenlesbare Befunde zurückbekommen und seinen eigenen Output korrigieren, bevor er Sie jemals erreicht. Jedes Problem in fallows JSON enthält ein actions-Array mit einem auto_fixable-Flag — sodass der Agent nicht nur weiß, was falsch ist, sondern ob es automatisch repariert werden kann.

Sie können es direkt fragen. Ich habe buchstäblich in Claude Code getippt: "Führe fallow aus und sag mir, welche fünf Dateien ich zuerst refaktorieren sollte." Es führt die Hotspot-Analyse aus, parst das JSON und kommt mit einer geordneten, begründeten Antwort zurück, die auf echten geparsten Daten basiert — keine Bauchgefühl-basierte Vermutung über den eigenen Code. Diese Unterscheidung ist alles. Der Agent räsoniert nicht mehr über seinen Output; er misst ihn.

Das schließt die Schleife, die seit dem Aufkommen von KI-Codierung gebrochen war. Das Ding, das den Verfall produziert, hat jetzt ein deterministisches Instrument, um den Verfall zu erkennen und zu entfernen, eigenständig, in derselben Sitzung. Wenn Sie Agent-Workflows bauen, sind Skills der Mechanismus, der diese Art von Selbstkorrektur komponierbar macht — fallow-skills ist eines der saubereren Praxisbeispiele, die ich gesehen habe.

Der JSON-Output ist nicht nur für Agenten. Jedes CI-Skript kann ihn parsen und programmatisch darauf reagieren. Strukturiert, typisiert, deterministisch — das Gegenteil davon, ein LLM zu bitten, einen Diff mit bloßem Auge zu begutachten.

Konfiguration: False Positives eliminieren, bevor sie Ihr Vertrauen zerstören

Ein statischer Analyzer ist nur nützlich, wenn Sie ihm vertrauen, und Vertrauen stirbt in dem Moment, in dem er über Dinge schreit, die Sie absichtlich getan haben. Fallow gibt Ihnen echte Notausgänge. Initialisieren Sie eine Konfiguration in Ihrem Projekt-Root:

npx fallow init

Das erstellt eine Konfigurationsdatei, die Sie im Laufe der Zeit anpassen. (Ein ehrlicher Hinweis: Die Dokumentation verweist auf verschiedene Konfigurationsformate — JSON über etwas wie .fallowrc.json und eine TOML-Option über fallow init --toml. Der genaue Dateiname hängt von Ihrer Version ab, also prüfen Sie, was init tatsächlich in Ihrem Setup ablegt, statt irgendeinem Blogpost-Dateinamen zu vertrauen, einschließlich diesem.) So konfiguriere ich es:

Ignorieren Sie generierte und absichtlich duplizierte Pfade. Ich habe einen /src/data/productinfo-Ordner voller generierter Kartendefinitionen — jeder Eintrag sieht dupliziert aus, weil sie dazu gedacht sind, einheitlich zu sein. Diesen Pfad zu ignorieren eliminierte einen großen Teil des Rauschens. Dasselbe für Tests: ein **/tests/**-Glob, weil Testdateien Setup absichtlich duplizieren, und das ist in Ordnung.

Wählen Sie Ihren Duplikationsmodus bewusst. Standard Mild Mode für eine ruhige Baseline; wechseln Sie zu Semantic Mode, wenn Sie gezielt nach den variabelumbenannten Klonen jagen wollen, die LLMs gerne produzieren.

Verwenden Sie Inline-Overrides für einmalige Ausnahmen:

// fallow-ignore  -> deaktiviert fallow für diese ganze Datei
// fallow-ignore-next-line  -> überspringt nur die nächste Zeile
export const publicApiShim = whatever // fallow-ignore-next-line

Das letzte ist perfekt für einen Export, von dem Sie wissen, dass er intern ungenutzt ist, weil er eine öffentliche API-Oberfläche ist. Sie erkennen es an, fallow hört auf zu nörgeln, und der Bericht bleibt vertrauenswürdig. Ein Bericht, dem Sie vertrauen, ist ein Bericht, nach dem Sie tatsächlich handeln — das ist das ganze Spiel.

Der Auto-Fix: 20 Probleme weg in einem Befehl

Probleme zu lesen ist eine Sache. Sie von Hand zu beheben ist der Teil, den alle überspringen. Fallows fix-Befehl erledigt die mechanische Arbeit automatisch — unbenutzte Exports entfernen, Dead Code bereinigen, den Import/Export-Graphen aktualisieren, damit nach einer Löschung nichts baumelt.

Führen Sie immer zuerst einen Dry-Run durch:

npx fallow fix --dry-run   # jede Änderung vorschauen, nichts anfassen
npx fallow fix             # die sicheren, mechanischen Fixes anwenden

Bei einem meiner Durchläufe löste es 20 Probleme in einem einzigen Durchgang — hauptsächlich tote Exports und verwaiste Imports, die mühsame Arbeit, die ich nie manuell aufgeräumt hätte. Es versucht nicht, eine 1.500-Zeilen-Funktion automatisch zu refaktorieren oder eine Clone Family zusammenzuführen; das erfordert menschliches Urteilsvermögen über die richtige Abstraktion, und fallow hat recht, nicht zu raten. Es fixt, was sicher ist, und überlässt die Architekturentscheidungen Ihnen. Diese Zurückhaltung ist genau das, was man von einem Auto-Fixer will.

Wo fallow zu kurz greift (der ehrliche Teil)

Ich werde nicht so tun, als wäre dieses Tool Magie, denn das ist es nicht, und Sie würden mich ohnehin beim ersten Durchlauf ertappen.

Es ist nur TypeScript und JavaScript. Wenn Ihr Stack Python oder Go ist, ist dies heute nicht Ihr Tool.

Die statische Schicht weiß nicht, was tatsächlich ausgeführt wird. Ein Stück "toter" Code könnte über Reflection, einen dynamischen Import oder eine string-basierte Route aufgerufen werden, der der Parser nicht folgen kann. Genau dafür existiert die kostenpflichtige Runtime-Schicht — und deshalb sollten Sie vor dem Löschen prüfen, statt blind der Unused-Code-Liste zu vertrauen.

Semantic Duplication Mode produziert False Positives. Zwei tatsächlich unterschiedliche Funktionen, die zufällig dieselbe Form haben, werden markiert. Sie werden Zeit mit Triagieren verbringen und auf die Ignorierregeln zurückgreifen. Das ist der Preis dafür, die subtilen Klone zu fangen — es gibt kein kostenloses Mittagessen.

Und es wird Ihre Architektur nicht reparieren. Es sagt Ihnen, dass eine Funktion ein 1.500-Zeilen-, 115-Zweige-Hotspot ist. Es wird Ihnen nicht sagen, wie man sie richtig zerlegt. Dieses Urteil liegt noch immer bei Ihnen. Fallow richtet die Taschenlampe; Sie müssen immer noch das Zimmer aufräumen.

Nichts davon ist ein Dealbreaker. Es ist die normale Form eines scharfen Werkzeugs: Es macht eine Kategorie von Dingen außergewöhnlich gut und hält sich von Arbeit fern, die es nicht sicher erledigen kann. Ich bevorzuge das gegenüber einem Tool, das mit Zuversicht meinen Code in etwas subtil Kaputtes auto-refaktoriert.

Was sich änderte, nachdem ich anfing, es auszuführen

Ich werde Ihnen keine erfundene "Bugs um 47% reduziert"-Zahl nennen, weil ich keine habe und auch sonst niemand, der behauptet, eine zu haben. Was ich Ihnen sagen kann, ist, was sich tatsächlich in meiner Arbeitsweise verändert hat.

Ich hörte auf, "es läuft" als Definition von "es ist fertig" zu vertrauen. Agent-Output bekommt jetzt einen fallow-Durchlauf, bevor ich ihn lese, genauso wie ich Tests laufen lassen würde. Die Hotspot-Liste wurde mein tatsächliches Refactoring-Backlog statt eines vagen Schuldgefühls bezüglich "der unordentlichen Dateien." Und in CI bedeutet das Branch-Vergleichs-Gate, dass der vibecoded PR eines Teamkollegen nicht stillschweigend 200 Zeilen duplizierten Logik in die Codebase werfen kann, ohne dass ein Kommentar im PR erscheint — das Gespräch findet vor dem Mergen statt, und das ist der einzige Zeitpunkt, an dem es günstig ist.

Das realistische Ergebnis, das Sie erwarten sollten: nicht null Schulden, sondern sichtbare, priorisierte, schrumpfende Schulden. Sie werden Ihre fünf schlimmsten Dateien namentlich kennen. Sie fangen neuen Verfall beim PR ab, statt ihn drei Sprints später zu entdecken. Für ein kostenloses statisches Tool, das sich mit npx installiert, ist das eine bemerkenswerte Rendite.

Die größere Verschiebung ist mental. Sobald eine KI den Großteil Ihres Codes schreibt, verschiebt sich Ihre Aufgabe von Autor zu Redakteur und Qualitäts-Gate. Fallow ist eines der ersten Tools, das nativ für diese Aufgabe gebaut wurde — deterministisch, schnell und gleichermaßen nutzbar von Ihnen wie vom Agenten selbst.

Also hier ist meine Herausforderung für die nächsten 24 Stunden: Richten Sie npx fallow auf das KI-lastige Repo, auf das Sie am stolzesten sind. Das, von dem Sie sicher sind, dass es sauber ist. Lesen Sie zuerst den Duplikationsabschnitt. Ich wette, Sie finden mindestens eine Clone Family, von der Sie keine Ahnung hatten, dass sie existiert — und wenn Sie sie einmal sehen, können Sie sie nicht mehr entsehen. Genau das ist der Punkt.

Häufig gestellte Fragen

Ist fallow kostenlos nutzbar?

Ja — fallows gesamte statische Intelligenzschicht ist kostenlos und Open Source und deckt Dead Code, Duplikation, Komplexität, Hotspots und Architekturanalyse ab. Es gibt eine optionale kostenpflichtige Runtime-Schicht, die Produktionsverkehrsnachweise für Hot-Path-Review und Cold-Path-Löschung hinzufügt, aber die kostenlose statische Schicht ist der Ort des alltäglichen Nutzens. Führen Sie es mit npx fallow aus, kein Konto erforderlich.

Wie unterscheidet sich fallow von ESLint?

Fallow zielt auf Wartbarkeitsprobleme in Ihrer gesamten Codebase ab — Duplikation, Dead Code, Komplexität und Hotspots — während ESLint auf Datei-basierte Stil- und Korrektheitsregeln abzielt. ESLint wird 100 Zeilen, die Sie in vier Dateien kopiert haben, nicht markieren; fallow gruppiert sie in eine Clone Family mit exakten Zeilenbereichen. Sie sind komplementär, keine Konkurrenten. Siehe die Abschnitte über Duplikation und Hotspots oben für das, was fallow auffängt, das Lintern entgeht.

Kann fallow Probleme mit KI-generiertem Code automatisch beheben?

Fallows fix-Befehl löst automatisch sichere, mechanische Probleme — unbenutzte Exports entfernen, Dead Code löschen und den Import/Export-Graphen aktualisieren — und ein einziger Durchlauf kann über 20 Probleme bereinigen. Schauen Sie sich immer zuerst eine Vorschau mit npx fallow fix --dry-run an. Es wird bewusst keine riesigen Funktionen auto-refaktorieren oder Duplikate zusammenführen, da diese menschliches Architektururteil erfordern.

Funktioniert fallow mit KI-Agenten wie Claude Code?

Ja — das fallow-skills Modul (installiert über npx) bringt Agenten wie Claude Code, Cursor, Codex und Gemini CLI bei, fallow aufzurufen und seinen strukturierten JSON-Output zu lesen. Dies ermöglicht es einem Agenten, seinen eigenen Code selbst zu überprüfen und automatisch zu korrigieren, bevor er einen PR öffnet. Sie können Dinge fragen wie "welche fünf Dateien sollte ich zuerst refaktorieren?" und erhalten eine datenbasierte Antwort. Siehe den Abschnitt über den Agent-Skill oben für den vollständigen Workflow.

Welche Sprachen unterstützt fallow?

Fallow analysiert ausschließlich TypeScript- und JavaScript-Projekte, mit etwa 95 Framework-Plugins, die automatisch Stacks wie Vite, Next.js, TanStack Query und Tailwind CSS erkennen. Es gibt keine Python- oder Go-Unterstützung in der 2.8x-Releaselinie von Juni 2026. Wenn Ihr Projekt JS/TS ist, konfiguriert es sich beim ersten Durchlauf ohne jegliche Einrichtung selbst.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme aufbauen, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich helfe Ihnen gerne.

Fiverr (Individuallösungen & Integrationen): fiverr.com/s/EgxYmWD
Portfolio: mejba.me
Ramlit Limited (Enterprise-Lösungen): ramlit.com
ColorPark (Design & Branding): colorpark.io
xCyberSecurity (Sicherheitsdienste): xcybersecurity.io