Fallow: de ESLint voor problemen met AI-gegenereerde code

Fallow: De ESLint voor problemen met AI-gegenereerde code

Afgelopen maand heb ik een feature uitgerold die Claude Code bijna volledig zelfstandig had geschreven. Het werkte. Tests slaagden. De PR werd gemerged. Ik voelde me er een week lang geweldig over.

Toen ging ik terug om een kleine wijziging aan te brengen en vond drie kopieën van exact dezelfde audio-extractielogica in hetzelfde bestand. Andere variabelenamen, identiek gedrag. Een geëxporteerde functie genaamd extractAllAudio die nergens in de codebase werd geïmporteerd. Een dev-only dependency die in de productie-dependencies stond. Niets ervan brak iets. Alles was verval, stilletjes oplopend.

Dat is het vuile geheim van snel AI-coderen: de code werkt, dus je stopt met kijken. En het hulpmiddel waar je normaal naar zou grijpen — ESLint — vangt hier niets van op. ESLint vertelt je over een ontbrekende puntkomma. Het zegt niets over het blok van 100 regels dat je inmiddels in vier routes hebt gekopieerd.

Dus toen ik fallow vond, een gratis codekwaliteitstool voor AI-gegenereerde code die specifiek is gebouwd voor de onderhoudbaarheidsproblemen die AI-codeertools introduceren, maakte ik een middag vrij en richtte het op mijn rommeligste repo. Wat het aan het licht bracht, veranderde hoe ik agentoutput beoordeel. Laat me je precies laten zien wat het vond — en waar het zijn plek verdiende in mijn workflow, en waar niet.

Waarom AI-gegenereerde code op manieren verrot die ESLint nooit ziet

Dit is het punt over een LLM die code schrijft: het heeft geen geheugen van wat het vier bestanden geleden schreef. Het optimaliseert voor deze prompt, nu, werkende output produceren. Onderhoudaarheid over de hele codebase zit simpelweg niet in zijn verliesfunctie.

Dat produceert drie specifieke faalpatronen, keer op keer, in zowel handmatig als AI-gecodeerde projecten — hoewel het veel erger is wanneer een agent het typen doet.

Duplicatie. Het model heeft dezelfde logica op twee plekken nodig, dus schrijft het die twee keer. Dan een derde keer. Het extraheert geen gedeelde helper omdat extraheren vereist dat je de hele codebase in het werkgeheugen houdt, en dat doet het niet. Ik heb 100+ identieke regels gezien die herhaald werden in één enkel bestand. ESLint haalt hier de schouders over op. De code is geldig.

Opgeblazenheid en complexiteit. Vraag een agent om "alle randgevallen af te handelen" en dat zal het doen — door condities te stapelen in lussen in condities totdat een enkele functie 1.500 regels telt en niemand, mens noch machine, het in zijn hoofd kan houden. Elke tak is correct. Het geheel is een moeras.

Dood gewicht. Ongebruikte bestanden. Geëxporteerde functies die niets importeert. Dependencies die voor één experiment zijn binnengehaald en nooit verwijderd. Agents creëren voortdurend scaffolding en ruimen zelden achter zichzelf op, omdat opruimen niet de taak was.

En de wrede ironie? AI-tools zijn slecht in het detecteren van hun eigen verval. Vraag Claude of Cursor "is er duplicatie in dit bestand?" en je krijgt een zelfverzekerd, plausibel, vaak fout antwoord. Het is een probabilistische gok over zijn eigen output. Wat je eigenlijk nodig hebt is iets deterministisch — iets dat de code parseert in plaats van erover te redeneren.

Dat is het gat dat fallow vult. En de manier waarop het dat doet is het interessante deel.

Wat fallow eigenlijk is (en waarom Rust er hier toe doet)

Fallow is codebase-intelligentie voor TypeScript en JavaScript, volledig gebouwd in Rust. Het team erachter — de fallow-rs organisatie op GitHub — beschrijft het als het consolideren van een hele reeks statische analysetools in één sub-seconde binary. Begin juni 2026 zit het op de 2.8x-releaselijn, met bijna dagelijks updates.

Het model splitst netjes in tweeën:

• Statische intelligentie — volledig gratis, open source. Dit analyseert de structuur van je code: dead code, duplicatie, circulaire afhankelijkheden, complexiteit, architectuurgrenzen. Dit is het deel dat ik gebruik en waar dit hele artikel over gaat.
• Runtime-intelligentie — een optionele betaalde laag die hot-path review en cold-path verwijderingsbewijs toevoegt op basis van daadwerkelijk productieverkeer. Het vertelt je welke "dead" code echt dood is op basis van wat er in productie draait. Nuttig voor grote teams die verwijderingsbeslissingen nemen. Ik heb er niet voor betaald, en ik wil daar eerlijk over zijn: ik beoordeel de gratis statische laag, want daar zit de dagelijkse waarde.

Je hoeft niets te installeren om het te proberen. Eén commando:

# Voer een volledige analyse uit op de huidige repo, zonder installatie
npx fallow

Bij de eerste uitvoering detecteert fallow automatisch je stack. Op mijn Vite + TanStack Query-project laadde het plugins voor Vite, TanStack Query en Tailwind CSS zonder dat ik iets hoefde te configureren — het wordt geleverd met ongeveer 95 framework-plugins en schakelt de juiste in op basis van je package.json. Het plaatst ook een .fallow cache-directory zodat volgende uitvoeringen snel zijn.

Waarom doet Rust ertoe? Omdat snelheid gedrag verandert. Een linter die 40 seconden duurt, wordt één keer per week gedraaid. Een linter die klaar is voordat je je hand van het toetsenbord hebt gehaald, wordt bij elke opslag gedraaid, in elke PR, door elke agent in een loop. Sub-seconde analyse is wat fallow bruikbaar maakt binnen een agentische workflow, wat — zo zal ik later betogen — waar het echt krachtig wordt.

Maar eerst het rapport. Want de eerste keer dat je een fallow-rapport over AI-geschreven code leest, is het een beetje confronterend.

Een fallow-rapport lezen: de vier secties die ertoe doen

Toen ik het uitvoerde, viel de output uiteen in duidelijke categorieën. Ik loop ze door zoals ik ze las, ergste overtreders eerst.

Dead code: de dingen die je vergat dat je schreef

Deze sectie vindt drie dingen, en AI-workflows genereren alle drie in volume:

• Ongebruikte bestanden — modules die niets importeert. Agent-scaffolding die nooit is aangesloten.
• Ongebruikte exports — die extractAllAudio die ik noemde. Geëxporteerd, publiek ogend, door niets geïmporteerd. Fallow markeert het met de exacte locatie.
• Ongebruikte dependencies — en deze is verraderlijk. Het ving een testbibliotheek op die in productie-dependencies stond terwijl het in devDependencies had moeten staan. Dat is niet alleen rommel; het zijn bytes die zonder reden naar gebruikers worden verzonden.

Dead code is de makkelijke winst. Het is ook de categorie waar fallow's auto-fix uitblinkt, daar kom ik op terug.

Duplicatie: de belangrijkste sectie, punt uit

Dit is degene waar ik het meest om geef, en het is waar AI-code op zijn slechtst is. Fallow rapporteert duplicatie met specifieke regelbereiken — niet "er is ergens wat duplicatie" maar "regels 412-518 hier komen overeen met regels 1.090-1.196 daar." Concreet. Actiegerecht.

De feature die me deed opveren was clone families: in plaats van 40 paarsgewijze duplicatwaarschuwingen te dumpen, groepeert het terugkerende patronen in families. Dus een stuk logica dat de agent in vijf route-handlers heeft geplakt verschijnt als één familie met vijf leden, niet tien lawaaierige paren. Die groepering is het verschil tussen een rapport waar je naar handelt en een rapport dat je sluit.

Duplicatie draait in twee modi, en het verschil is belangrijk:

• Mild mode (de standaard) vangt duplicaten op waarbij de variabelenamen identiek zijn. Conservatief, weinig false positives.
• Semantic mode vangt duplicaten op waarbij de logica hetzelfde is maar variabelenamen verschillen — precies het soort ding dat een LLM produceert wanneer het dezelfde functie herschrijft met steeds iets andere namen. Strikter, grondiger, meer ruis.

Voor een AI-zware codebase is semantic mode degene die je wilt, omdat variabelenaam-drift de handtekening van de LLM is. Meer over het wisselen van modi hieronder.

Complexiteit: de gezondheidscheck die niemand uitvoert

Deze sectie is een check-up voor functies die uit de hand zijn gelopen. Vier getallen doen het werk:

• Functiegrootte — markeert de monsters. Ik had er eentje die richting 1.500 regels ging.
• Cyclomatische complexiteit — het aantal onafhankelijke takken door een functie. Een lezing van 115 takken betekent 115 afzonderlijke paden. In de praktijk niet te testen.
• Cognitieve belasting — hoe moeilijk de code is om als mens te volgen, met een zware weging voor geneste lussen en condities. Een geneste puinhoop kan 133 scoren, zelfs als de cyclomatische complexiteit er slechts slecht uitziet.
• CRAP-score — Change Risk Anti-Patterns. Dit is de slimme. Het combineert complexiteit met testdekking. Een complexe functie die goed getest is scoort laag — je kunt hem veilig wijzigen. Een complexe functie zonder tests scoort meedogenloos hoog, omdat het wijzigen ervan een gok is. CRAP is het getal dat je vertelt waar het echte gevaar zit.

Die laatste metriek veranderde hoe ik over technische schuld denk. Het is niet "deze functie is complex." Het is "deze functie is complex en niets vangt me op als ik hem breek." Dat zijn compleet verschillende niveaus van urgentie.

De scores: gezondheid, risico, en degene die je werk voor je rangschikt

Fallow rolt alles op in een paar samengestelde getallen:

• Bestandsgezondheidsscore — een samengesteld getal van 0-100 voor dead code, import/export-connectiviteit, complexiteit en CRAP. Hoger is beter onderhoudbaar. Je kunt de projectversie ophalen met fallow health --score en krijgt er een lettercijfer bij.
• Risicoscore — sterk gedreven door CRAP. Dit is je "wat gaat het meest waarschijnlijk ontploffen"-meter.
• Totale samenvattingsscore — één getal voor de hele uitvoering, zodat je projecten met elkaar kunt vergelijken of dezelfde repo in de tijd kunt volgen.

Een score op zichzelf is echter slechts een ijdelheidsgetal. De sectie die je daadwerkelijk vertelt wat je moet doen is de volgende — en het is het slimste onderdeel van de tool.

De hotspot-sectie: waar fallow stopt met een linter zijn

De meeste kwaliteitstools geven je een platte lijst met problemen gesorteerd op ernst. Fallow doet iets dat ik niet eerder zo schoon heb zien gedaan: het correleert complexiteit met je git-commitgeschiedenis.

Denk na over wat dat betekent. Een functie kan verschrikkelijk complex zijn, maar als niemand hem in twee jaar heeft aangeraakt, is hij bevroren — riskant om te wijzigen, maar je wijzigt hem niet, dus laat hem met rust. Het gevaarlijke bestand is het bestand dat zowel complex als voortdurend gewijzigd is. Elke commit eraan is een worp met de dobbelsteen, en je gooit wekelijks.

Die kruising — complexiteit × verloop — is de hotspot. Je voert het als volgt uit:

# Riskantste bestanden = git-verloop gekruist met complexiteit
npx fallow health --hotspots

De hotspot-lijst is je refactoring-prioriteitswachtrij, gesorteerd op waar opruimen het beste rendement oplevert op je tijd. Je kunt zelfs eigenaarschap en drift-signalen meenemen (--hotspots --ownership) om bus-factor-risico te zien — bestanden die slechts één persoon begrijpt.

Dit is de sectie die ik nu als eerste check. Niet "wat is er mis" maar "wat is er mis en duur en wordt aangeraakt." Dat is een fundamenteel betere vraag, en het is degene die een rapport in een plan verandert.

Als je liever hebt dat een team een AI-zware codebase voor je auditeert en refactort in plaats van de tooling zelf te leren, het bouwen van dit soort opruimpipeline is precies het soort opdracht dat ik aanneem — maar eerlijk gezegd maakt fallow het doe-het-zelf-pad nu realistisch voor de meeste teams.

Fallow in een echte workflow plaatsen

Een rapport dat je één keer leest en vergeet is waardeloos. De reden dat fallow bij mij bleef hangen is dat het op vier plekken leeft waar ik daadwerkelijk werk. Dit sluit direct aan op de agentische ontwikkellevenscyclus waar ik eerder over schreef — kwaliteitspoorten moeten verschuiven van "af en toe menselijke review" naar "continu, geautomatiseerd, machineleesbaar" wanneer agents het meeste van de code schrijven.

1. De CLI, gefilterd op één ding tegelijk

Een volledig rapport is overweldigend op een legacy repo. Dus verklein je het. Wil je alleen dead code? Alleen gezondheid en complexiteit? Geef een metriekfilter mee en fallow toont je die plak en niets anders:

npx fallow dead-code   # alleen ongebruikte bestanden, exports, deps
npx fallow dupes       # alleen duplicatie
npx fallow health      # complexiteit, scores, hotspots

Ik pak één categorie per sessie aan. Alle dead code opruimen op maandag. De ergste clone families aanpakken op dinsdag. Het voorkomt dat het werk oneindig aanvoelt.

2. De VS Code-extensie: verval, onderstreept

De fallow VS Code-extensie voert de analyse live uit via een taalserver. Je krijgt een zijbalk met waarschuwingen en fouten gegroepeerd per type, en — het deel dat ik leuk vind — inline-indicatoren recht in de editor. Ongebruikte bestanden en exports worden gemarkeerd. Gedupliceerde regels krijgen golvende onderstrepingen, zodat je het kopiëren-en-plakken ziet terwijl je erdoorheen scrollt. Het toont zelfs referentietellingen via CodeLens, zodat je in één oogopslag weet hoeveel dingen een bepaalde export daadwerkelijk gebruiken.

Duplicatie gemarkeerd zien in de editor, terwijl je de code leest, raakt anders dan het lezen in een rapport. Het is het verschil tussen een doktersbrief en een spiegel.

3. De AI-agentskill: zelf-reviewende code

Dit is degene die echt mijn mentale model veranderde, en het verdient zijn eigen sectie. Scroll naar beneden — maar eerst het laatste workflow-onderdeel.

4. CI/CD: de kwaliteitspoort vóór het mergen

Fallow wordt geleverd met een voorgebouwde GitHub Actions workflow (en GitLab CI-ondersteuning) die bij elke push en PR draait. Het plaatst een markdown-commentaar direct in het pull request met een samenvatting van wat er is veranderd, en het kan een kwaliteitspoort afdwingen — de build laten falen als de gezondheidsscore onder een drempel zakt:

# Laat de PR falen als de projectgezondheid onder 70 zakt
- run: npx fallow health --min-score 70

Je kiest of bevindingen blokkerend (inline, moet-worden-opgelost) of adviserend (een opmerking die informeert zonder te blokkeren) zijn. Een kanttekening uit de documentatie die het weten waard is: GitHub Actions zet checkout standaard op fetch-depth: 1, wat git-geschiedenisgebaseerde baselines breekt. Stel fetch-depth: 0 in als je vergelijkt met een langlevende baseline-tag. Ik verloor twintig minuten hieraan voordat ik de kleine lettertjes las, dus beschouw dit als je shortcut.

De killer CI-feature is echter branchvergelijking. In plaats van je hele repo te auditen bij elke PR — wat je overspoelt met bestaande problemen die niemand vandaag gaat oplossen — kan fallow je feature-branch vergelijken met main en alleen de nieuwe of gewijzigde problemen rapporteren die jouw branch heeft geïntroduceerd. Dat is de juiste analyse-eenheid voor een PR. Je bent niet verantwoordelijk voor de hele geschiedenis van de codebase. Je bent verantwoordelijk voor wat jij (of je agent) zojuist hebt toegevoegd. Incrementeel, eerlijk, en het houdt het signaal schoon.

De agentskill: AI zijn eigen huiswerk laten nakijken — correct

Hier wordt het echt interessant, en hier stopt fallow met "een betere linter" zijn en wordt het iets waarvan ik denk dat meer agentische stacks het zullen kopiëren.

Er is een begeleidende repo, fallow-skills, die een agentskillmodule installeert via npx. Het leert een AI-agent — Claude Code, Cursor, Codex, Gemini CLI, meer dan 30 ervan — hoe fallow zelf aan te roepen en de gestructureerde JSON-output te lezen.

Sta stil bij wat dat mogelijk maakt. De agent die de slordige code schreef kan nu een deterministisch hulpmiddel uitvoeren dat de slordigheid opspoort, machineleesbare bevindingen terugkrijgen, en zijn eigen output corrigeren voordat het jou ooit bereikt. Elk probleem in fallow's JSON bevat een actions-array met een auto_fixable-vlag — zodat de agent niet alleen weet wat er mis is, maar of het automatisch te repareren is.

Je kunt het direct vragen. Ik heb letterlijk in Claude Code getypt: "Voer fallow uit en vertel me welke vijf bestanden ik als eerste moet refactoren." Het voert de hotspot-analyse uit, parseert de JSON, en komt terug met een gerangschikt, beredeneerd antwoord gegrond in echte geparseerde data — geen vibes-gebaseerde gok over zijn eigen code. Dat onderscheid is alles. De agent redeneert niet meer over zijn output; hij meet het.

Dit sluit de lus die gebroken is geweest sinds AI-codering op gang kwam. Het ding dat het verval produceert heeft nu een deterministisch instrument om het verval te detecteren en te verwijderen, zelfstandig, in dezelfde sessie. Als je agentworkflows bouwt, zijn skills het mechanisme dat dit soort zelfcorrectie composeerbaar maakt — fallow-skills is een van de schonere praktijkvoorbeelden die ik heb gezien.

De JSON-output is niet alleen voor agents. Elk CI-script kan het parsen en er programmatisch naar handelen. Gestructureerd, getypeerd, deterministisch — het tegenovergestelde van een LLM vragen om een diff met het blote oog te beoordelen.

Configuratie: false positives elimineren voordat ze je vertrouwen doden

Een statische analyzer is alleen nuttig als je hem vertrouwt, en vertrouwen sterft op het moment dat hij schreeuwt over dingen die je met opzet deed. Fallow geeft je echte nooduitgangen. Initialiseer een configuratie in je project-root:

npx fallow init

Dat scaffoldt een configuratiebestand dat je in de loop van de tijd afstelt. (Een eerlijke opmerking: de documentatie verwijst naar een paar configuratieformaten — JSON via iets als .fallowrc.json en een TOML-optie via fallow init --toml. De exacte bestandsnaam hangt af van je versie, dus controleer wat init daadwerkelijk plaatst in jouw setup in plaats van een blogpost-bestandsnaam te vertrouwen, inclusief deze.) Zo configureer ik het:

Negeer gegenereerde en bewust-gedupliceerde paden. Ik heb een /src/data/productinfo-map vol gegenereerde kaartdefinities — elke entry ziet er gedupliceerd uit omdat ze bedoeld zijn om uniform te zijn. Die map negeren sneed een groot stuk ruis weg. Hetzelfde voor tests: een **/tests/** glob, omdat testbestanden opzettelijk setup dupliceren en dat prima is.

Kies je duplicatiemodus bewust. Standaard mild mode voor een rustige baseline; schakel naar semantic mode wanneer je specifiek wilt jagen op de variabel-hernoemde klonen die LLM's graag produceren.

Gebruik inline overrides voor de eenmalige uitzonderingen:

// fallow-ignore  -> schakelt fallow uit voor dit hele bestand
// fallow-ignore-next-line  -> slaat alleen de volgende regel over
export const publicApiShim = whatever // fallow-ignore-next-line

Die laatste is perfect voor een export waarvan je weet dat die intern ongebruikt is omdat het een publiek API-oppervlak is. Je erkent het, fallow stopt met zeuren, en het rapport blijft betrouwbaar. Een rapport dat je vertrouwt is een rapport waar je daadwerkelijk naar handelt — dat is het hele spel.

De auto-fix: 20 problemen weg in één commando

Problemen lezen is één ding. Ze met de hand oplossen is het deel dat iedereen overslaat. Fallow's fix-commando handelt het mechanische werk automatisch af — ongebruikte exports verwijderen, dead code opruimen, de import/export-graaf bijwerken zodat er niets bengelt na een verwijdering.

Draai altijd eerst een dry-run:

npx fallow fix --dry-run   # bekijk elke wijziging, raak niets aan
npx fallow fix             # pas de veilige, mechanische fixes toe

Bij een van mijn uitvoeringen loste het 20 problemen op in één keer — voornamelijk dode exports en verweesde imports, het saaie werk dat ik nooit handmatig had opgeruimd. Het probeert niet automatisch een functie van 1.500 regels te refactoren of een clone family samen te voegen; dat vereist menselijk oordeel over de juiste abstractie, en fallow heeft gelijk om niet te gokken. Het fixt wat veilig is en laat de architectuurbeslissingen aan jou over. Die terughoudendheid is precies wat je wilt van een auto-fixer.

Waar fallow tekortschiet (het eerlijke deel)

Ik ga niet doen alsof deze tool magie is, want dat is het niet, en je zou me toch betrappen de eerste keer dat je het draait.

Het is alleen TypeScript en JavaScript. Als je stack Python of Go is, is dit vandaag niet jouw tool.

De statische laag weet niet wat er daadwerkelijk draait. Een stuk "dead" code kan worden aangeroepen via reflectie, een dynamische import, of een op strings gebaseerde route die de parser niet kan volgen. Dat is letterlijk waarvoor de betaalde runtime-laag bestaat — en het is waarom je moet reviewen voordat je verwijdert, niet blindelings de ongebruikte-codelijst moet vertrouwen.

Semantic duplication mode produceert false positives. Twee werkelijk verschillende functies die toevallig dezelfde vorm delen worden gemarkeerd. Je zult tijd besteden aan triageren, en je zult leunen op die negeerregels. Dat is de prijs van het vangen van de subtiele klonen — er bestaat geen gratis lunch.

En het zal je architectuur niet fixen. Het vertelt je dat een functie een hotspot is van 1.500 regels met 115 takken. Het zal je niet vertellen wat de juiste manier is om het te ontleden. Dat oordeel is nog steeds van jou. Fallow richt de zaklamp; jij moet nog steeds de kamer opruimen.

Niets daarvan is een dealbreaker. Het is de normale vorm van een scherp hulpmiddel: het doet één categorie dingen uitzonderlijk goed en blijft weg van werk dat het niet veilig kan doen. Ik heb liever dat dan een tool die met vertrouwen mijn code auto-refactort naar iets dat subtiel kapot is.

Wat er veranderde nadat ik het begon te draaien

Ik ga je geen nep-"bugs met 47% verminderd"-getal geven, omdat ik dat niet heb en niemand die zegt dat wel te hebben het ook heeft. Wat ik je kan vertellen is wat er daadwerkelijk verschoof in hoe ik werk.

Ik stopte met "het draait" als definitie van "het is af" te vertrouwen. Agentoutput krijgt nu een fallow-pass voordat ik het lees, op dezelfde manier als ik tests zou draaien. De hotspot-lijst werd mijn daadwerkelijke refactoring-backlog in plaats van een vaag schuldgevoel over "de rommelige bestanden." En in CI betekent de branchvergelijkingspoort dat de vibecoded PR van een teamgenoot niet stilletjes 200 regels gedupliceerde logica in de codebase kan dumpen zonder dat er een opmerking op de PR verschijnt — het gesprek vindt plaats vóór het mergen, en dat is het enige moment waarop het goedkoop is.

Het realistische resultaat dat je mag verwachten: niet nul schuld, maar zichtbare, gerangschikte, krimpende schuld. Je zult je vijf slechtste bestanden bij naam kennen. Je vangt nieuwe verrotting op bij de PR in plaats van het drie sprints later te ontdekken. Voor een gratis statische tool die je installeert met npx, is dat een opmerkelijk rendement.

De grotere verschuiving is mentaal. Zodra een AI het grootste deel van je code schrijft, verschuift je taak van auteur naar redacteur en kwaliteitspoort. Fallow is een van de eerste tools die native voor die taak is gebouwd — deterministisch, snel, en even bruikbaar door jou als door de agent zelf.

Dus hier is mijn uitdaging voor de komende 24 uur: richt npx fallow op de AI-zware repo waar je het meest trots op bent. Degene waarvan je zeker bent dat hij schoon is. Lees eerst de duplicatiesectie. Ik durf te wedden dat je minstens één clone family vindt waarvan je geen idee had dat die bestond — en als je hem eenmaal ziet, kun je hem niet meer onzien. Dat is precies het punt.

Veelgestelde vragen

Is fallow gratis te gebruiken?

Ja — fallow's volledige statische intelligentielaag is gratis en open source, en dekt dead code, duplicatie, complexiteit, hotspots en architectuuranalyse. Er is een optionele betaalde runtime-laag die productieverkeersbewijs toevoegt voor hot-path review en cold-path verwijdering, maar de gratis statische laag is waar de dagelijkse waarde zit. Draai het met npx fallow, geen account nodig.

Hoe verschilt fallow van ESLint?

Fallow richt zich op onderhoudbaarheidsproblemen in je hele codebase — duplicatie, dead code, complexiteit en hotspots — terwijl ESLint zich richt op per-bestand stijl- en correctheidsregels. ESLint zal geen 100 regels markeren die je in vier bestanden hebt gekopieerd; fallow groepeert ze in een clone family met exacte regelbereiken. Ze zijn complementair, geen concurrenten. Zie de secties over duplicatie en hotspots hierboven voor wat fallow vangt dat linters missen.

Kan fallow problemen met AI-gegenereerde code automatisch fixen?

Fallow's fix-commando lost automatisch veilige, mechanische problemen op — ongebruikte exports verwijderen, dead code wissen, en de import/export-graaf bijwerken — en een enkele uitvoering kan 20+ problemen opruimen. Bekijk altijd eerst een preview met npx fallow fix --dry-run. Het zal bewust geen gigantische functies auto-refactoren of duplicaten samenvoegen, omdat die menselijk architecturaal oordeel vereisen.

Werkt fallow met AI-agents zoals Claude Code?

Ja — de fallow-skills module (geïnstalleerd via npx) leert agents zoals Claude Code, Cursor, Codex en Gemini CLI om fallow aan te roepen en de gestructureerde JSON-output te lezen. Dit stelt een agent in staat om zijn eigen code te self-reviewen en automatisch te corrigeren voordat hij een PR opent. Je kunt dingen vragen als "welke vijf bestanden moet ik als eerste refactoren?" en krijgt een op data gebaseerd antwoord. Zie de sectie over de agentskill hierboven voor de volledige workflow.

Welke talen ondersteunt fallow?

Fallow analyseert alleen TypeScript- en JavaScript-projecten, met ongeveer 95 framework-plugins die automatisch stacks detecteren zoals Vite, Next.js, TanStack Query en Tailwind CSS. Er is geen Python- of Go-ondersteuning in de 2.8x-releaselijn van juni 2026. Als je project JS/TS is, configureert het zichzelf bij de eerste uitvoering zonder enige setup.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerkoplossingen & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io