Fallow : l'ESLint pour les problèmes de code généré par l'IA

Fallow : L'ESLint pour les problèmes du code généré par IA

Le mois dernier, j'ai livré une fonctionnalité que Claude Code a écrite presque entièrement tout seul. Ça fonctionnait. Les tests passaient. La PR a été mergée. Je me suis senti bien pendant environ une semaine.

Puis je suis revenu pour faire une petite modification et j'ai trouvé trois copies de la même logique d'extraction audio dans le même fichier. Des noms de variables différents, un comportement identique. Une fonction exportée appelée extractAllAudio que rien dans la codebase n'importait. Une dépendance dev installée dans les dependencies de production. Rien de tout cela ne cassait quoi que ce soit. Tout cela était de la détérioration, s'accumulant silencieusement.

C'est le secret inavouable du codage rapide avec l'IA : le code fonctionne, alors vous arrêtez de regarder. Et l'outil vers lequel vous vous tourneriez normalement — ESLint — ne détecte rien de tout cela. ESLint vous signale un point-virgule manquant. Il ne dit rien sur le bloc de 100 lignes que vous avez copié-collé dans quatre routes.

Alors quand j'ai trouvé fallow, un outil gratuit de qualité de code généré par IA en ligne de commande, construit spécifiquement pour les défauts de maintenabilité que les outils de codage IA introduisent, j'ai libéré un après-midi et je l'ai pointé sur mon dépôt le plus désordonné. Ce qu'il a révélé a changé ma façon de vérifier la sortie des agents. Laissez-moi vous montrer exactement ce qu'il a trouvé — et où il a gagné sa place dans mon workflow versus où il ne l'a pas fait.

Pourquoi le code généré par IA se détériore de façons qu'ESLint ne voit jamais

Voici le problème quand un LLM écrit du code : il n'a aucune mémoire de ce qu'il a écrit quatre fichiers plus tôt. Il optimise pour ce prompt, maintenant, produire une sortie fonctionnelle. La maintenabilité à travers toute la codebase n'est tout simplement pas dans sa fonction de perte.

Cela produit trois modes de défaillance spécifiques, encore et encore, dans les projets codés à la main comme dans les projets vibecoded — bien que ce soit bien pire quand un agent fait la saisie.

Duplication. Le modèle a besoin de la même logique dans deux endroits, alors il l'écrit deux fois. Puis une troisième fois. Il n'extrait pas un helper partagé parce qu'extraire nécessite de garder toute la codebase en mémoire de travail, et il ne le fait pas. J'ai vu plus de 100 lignes identiques répétées dans un seul fichier. ESLint hausse les épaules. Le code est valide.

Surcharge et complexité. Demandez à un agent de "gérer tous les cas limites" et il le fera — en empilant des conditionnels dans des boucles dans des conditionnels jusqu'à ce qu'une seule fonction fasse 1 500 lignes et que personne, humain ou machine, ne puisse la garder en tête. Chaque branche est correcte. L'ensemble est un marécage.

Poids mort. Fichiers inutilisés. Fonctions exportées que rien n'importe. Dépendances ajoutées pour une expérience et jamais supprimées. Les agents créent du scaffolding constamment et nettoient rarement après, parce que le nettoyage n'était pas la tâche.

Et la cruelle ironie ? Les outils d'IA sont mauvais pour détecter leur propre détérioration. Demandez à Claude ou Cursor "y a-t-il de la duplication dans ce fichier ?" et vous obtiendrez une réponse confiante, plausible et fréquemment incorrecte. C'est une estimation probabiliste sur sa propre sortie. Ce dont vous avez réellement besoin, c'est quelque chose de déterministe — quelque chose qui analyse le code au lieu de raisonner dessus.

C'est le vide que fallow comble. Et la façon dont il le comble est la partie intéressante.

Ce qu'est réellement fallow (et pourquoi Rust compte ici)

Fallow est de l'intelligence de codebase pour TypeScript et JavaScript, entièrement construit en Rust. L'équipe derrière — l'organisation fallow-rs sur GitHub — le décrit comme la consolidation de tout un ensemble d'outils d'analyse statique en un seul binaire qui s'exécute en moins d'une seconde. Début juin 2026, il est sur la ligne de versions 2.8x, avec des mises à jour presque quotidiennes.

Le modèle se divise clairement en deux :

• Intelligence statique — entièrement gratuite et open source. Elle analyse la structure de votre code : dead code, duplication, dépendances circulaires, complexité, limites d'architecture. C'est la partie que j'utilise et dont parle tout cet article.
• Intelligence runtime — une couche payante optionnelle qui ajoute l'examen des chemins chauds et les preuves de suppression des chemins froids basées sur le trafic réel de production. Elle vous dit quel code "mort" est réellement mort en fonction de ce qui s'exécute en production. Utile pour les grandes équipes prenant des décisions de suppression. Je n'ai pas payé pour elle, et je veux être honnête : j'évalue la couche statique gratuite, là où réside la valeur quotidienne.

Vous n'avez rien à installer pour l'essayer. Une seule commande :

# Exécutez une analyse complète sur le repo actuel, sans rien installer
npx fallow

À la première exécution, fallow auto-détecte votre stack. Sur mon projet Vite + TanStack Query, il a chargé les plugins pour Vite, TanStack Query et Tailwind CSS sans que je configure quoi que ce soit — il est livré avec environ 95 plugins de framework et branche les bons en fonction de votre package.json. Il crée également un répertoire de cache .fallow pour que les exécutions suivantes soient rapides.

Pourquoi Rust compte ? Parce que la vitesse change le comportement. Un linter qui prend 40 secondes est exécuté une fois par semaine. Un linter qui termine avant que vous ayez bougé la main du clavier est exécuté à chaque sauvegarde, dans chaque PR, par chaque agent en boucle. L'analyse en moins d'une seconde est ce qui rend fallow viable dans un workflow agentique, ce qui — je le soutiendrai plus tard — est là où il devient véritablement puissant.

Mais d'abord, le rapport. Parce que la première fois que vous lisez un rapport fallow sur du code écrit par l'IA, c'est un peu humiliant.

Lire un rapport fallow : les quatre sections qui comptent

Quand je l'ai exécuté, la sortie s'est divisée en catégories claires. Je vais parcourir chacune de la façon dont je les ai lues, en commençant par le pire contrevenant.

Dead code : ce que vous avez oublié avoir écrit

Cette section trouve trois choses, et les workflows IA les génèrent toutes les trois en volume :

• Fichiers inutilisés — modules que rien n'importe. Du scaffolding d'agents qui n'a jamais été connecté.
• Exports inutilisés — ce extractAllAudio que j'ai mentionné. Exporté, d'apparence publique, importé par rien. Fallow le signale avec l'emplacement exact.
• Dépendances inutilisées — et celle-ci est sournoise. Il a détecté une bibliothèque de tests installée dans les dependencies de production qui aurait dû être dans devDependencies. Ce n'est pas juste du désordre ; ce sont des octets envoyés aux utilisateurs sans raison.

Le dead code est la victoire facile. C'est aussi la catégorie où l'auto-correction de fallow brille, ce que j'aborderai plus loin.

Duplication : la section la plus importante, point final

C'est celle qui m'importe le plus, et c'est là où le code IA est à son pire. Fallow rapporte la duplication avec des plages de lignes spécifiques — pas "il y a de la duplication quelque part" mais "les lignes 412-518 ici correspondent aux lignes 1 090-1 196 là-bas." Concret. Actionnable.

La fonctionnalité qui m'a fait dresser l'oreille, ce sont les clone families : au lieu de déverser 40 avertissements de doublons par paires, il regroupe les modèles récurrents en familles. Ainsi, une logique que l'agent a collée dans cinq gestionnaires de route apparaît comme une famille avec cinq membres, pas dix paires bruyantes. Ce regroupement est la différence entre un rapport sur lequel vous agissez et un rapport que vous fermez.

La duplication fonctionne dans deux modes, et la différence compte :

• Mode mild (par défaut) détecte les doublons où les noms de variables sont identiques. Conservateur, peu de faux positifs.
• Mode sémantique détecte les doublons où la logique est la même mais les noms de variables diffèrent — exactement le genre de chose qu'un LLM produit quand il réécrit la même fonction avec des noms légèrement différents à chaque fois. Plus strict, plus complet, plus de bruit.

Pour une codebase avec beaucoup d'IA, le mode sémantique est celui que vous voulez, parce que la dérive des noms de variables est la signature du LLM. Plus de détails sur le changement de mode ci-dessous.

Complexité : le bilan de santé que personne n'exécute

Cette section est un check-up pour les fonctions qui ont grandi hors de contrôle. Quatre chiffres font le travail :

• Taille de la fonction — signale les monstres. J'en avais une approchant les 1 500 lignes.
• Complexité cyclomatique — le nombre de branches indépendantes à travers une fonction. Une lecture de 115 branches signifie 115 chemins distincts. Impossible à tester en pratique.
• Charge cognitive — à quel point il est difficile pour un humain de suivre le code, en pondérant fortement les boucles et conditionnels imbriqués. Un fouillis imbriqué peut atteindre 133 même si la complexité cyclomatique semble simplement mauvaise.
• Score CRAP — Change Risk Anti-Patterns (Patrons Anti-Risque de Changement). C'est le malin. Il combine la complexité avec la couverture de tests. Une fonction complexe bien testée obtient un score bas — vous pouvez la modifier en toute sécurité. Une fonction complexe sans tests obtient un score brutalement élevé, parce que la modifier est un coup de dés. CRAP est le chiffre qui vous dit où se trouve le vrai danger.

Cette dernière métrique a reformulé ma façon de penser la dette technique. Ce n'est pas "cette fonction est complexe." C'est "cette fonction est complexe et rien ne me rattrapera quand je la casserai." Ce sont des niveaux d'urgence complètement différents.

Les scores : santé, risque, et celui qui classe votre travail pour vous

Fallow résume tout en quelques chiffres composites :

• Score de santé du fichier — un composite de 0-100 de dead code, connectivité import/export, complexité et CRAP. Plus haut est plus maintenable. Vous pouvez obtenir la version au niveau du projet avec fallow health --score et obtenir une note en lettre avec.
• Score de risque — fortement influencé par CRAP. C'est votre indicateur de "ce qui a le plus de chances d'exploser".
• Score de synthèse global — un nombre pour toute l'exécution, pour que vous puissiez comparer les projets entre eux ou suivre le même dépôt au fil du temps.

Un score en soi n'est qu'une métrique de vanité. La section qui vous dit réellement quoi faire est la suivante — et c'est la chose la plus intelligente de l'outil.

La section hotspots : là où fallow cesse d'être un linter

La plupart des outils de qualité vous donnent une liste plate de problèmes triés par sévérité. Fallow fait quelque chose que je n'ai pas vu fait aussi proprement : il corrèle la complexité avec votre historique de commits git.

Pensez à ce que cela signifie. Une fonction peut être horriblement complexe mais si personne ne l'a touchée depuis deux ans, elle est gelée — risqué de la modifier, mais vous ne la modifiez pas, alors laissez-la tranquille. Le fichier dangereux est celui qui est à la fois complexe et modifié constamment. Chaque commit dessus est un coup de dés, et vous jouez chaque semaine.

Cette intersection — complexité × fréquence de changements — c'est le hotspot. Vous l'exécutez comme ceci :

# Fichiers les plus risqués = fréquence de changements git croisée avec la complexité
npx fallow health --hotspots

La liste de hotspots est votre file de priorité de refactoring, triée par où le nettoyage donne le meilleur retour sur votre temps. Vous pouvez même ajouter des signaux de propriété et de dérive (--hotspots --ownership) pour voir le risque de bus factor — des fichiers qu'une seule personne comprend.

C'est la section que je consulte en premier maintenant. Pas "qu'est-ce qui ne va pas" mais "qu'est-ce qui ne va pas et coûte cher et est en cours de modification." C'est une question fondamentalement meilleure, et c'est celle qui transforme un rapport en plan.

Si vous préférez qu'une équipe audite et refactorise une codebase avec beaucoup d'IA pour vous plutôt que d'apprendre l'outillage vous-même, construire ce type de pipeline de nettoyage est exactement le genre de mission que j'accepte — mais honnêtement, fallow rend le chemin DIY réaliste pour la plupart des équipes maintenant.

Intégrer fallow dans un vrai workflow

Un rapport que vous lisez une fois et oubliez ne vaut rien. La raison pour laquelle fallow est resté pour moi, c'est qu'il vit dans quatre endroits où je travaille réellement. Cela se connecte directement au cycle de vie de développement agentique dont j'ai parlé avant — les portes de qualité doivent passer de "revue humaine occasionnelle" à "continue, automatisée, lisible par les machines" quand les agents écrivent la majorité du code.

1. La CLI, filtrée sur une chose à la fois

Un rapport complet est écrasant sur un dépôt legacy. Alors vous le réduisez. Vous ne voulez que le dead code ? Juste la santé et la complexité ? Passez un filtre de métrique et fallow vous montre cette tranche et rien d'autre :

npx fallow dead-code   # uniquement fichiers, exports et dépendances inutilisés
npx fallow dupes       # uniquement la duplication
npx fallow health      # complexité, scores, hotspots

J'attaque une catégorie par séance. J'élimine tout le dead code le lundi. J'attaque les pires clone families le mardi. Ça empêche le travail de sembler infini.

2. L'extension VS Code : la détérioration, soulignée

L'extension fallow pour VS Code exécute l'analyse en direct via un serveur de langage. Vous obtenez une barre latérale avec les avertissements et erreurs regroupés par type, et — la partie que j'aime — des indicateurs en ligne directement dans l'éditeur. Les fichiers inutilisés et les exports inutilisés sont marqués. Les lignes dupliquées obtiennent des soulignements ondulés, pour que vous voyiez le copier-coller en parcourant le code. Il affiche même le nombre de références via CodeLens, pour que vous sachiez d'un coup d'œil combien de choses utilisent réellement un export donné.

Voir la duplication surlignée dans l'éditeur, pendant que vous lisez le code, frappe différemment que la lire dans un rapport. C'est la différence entre une note du médecin et un miroir.

3. La skill de l'agent IA : du code qui s'auto-vérifie

C'est celle qui a véritablement changé mon modèle mental, et elle mérite sa propre section. Sautez plus bas — mais d'abord, la dernière pièce du workflow.

4. CI/CD : la porte de qualité avant le merge

Fallow inclut un workflow pré-construit pour GitHub Actions (et un support GitLab CI) qui s'exécute à chaque push et PR. Il poste un commentaire en markdown directement dans la pull request résumant ce qui a changé, et il peut imposer une porte de qualité — faire échouer le build si le score de santé tombe en dessous d'un seuil :

# Fait échouer la PR si la santé du projet tombe en dessous de 70
- run: npx fallow health --min-score 70

Vous choisissez si les résultats sont bloquants (inline, correction obligatoire) ou consultatifs (un commentaire qui informe sans bloquer). Un avertissement de la documentation qui vaut la peine d'être connu : GitHub Actions fait checkout avec fetch-depth: 1 par défaut, ce qui casse les baselines basées sur l'historique git. Configurez fetch-depth: 0 si vous comparez avec un tag baseline de longue durée. J'ai perdu vingt minutes là-dessus avant de lire les petits caractères, alors considérez ceci comme votre raccourci.

La fonctionnalité phare du CI, cependant, c'est la comparaison de branches. Au lieu d'auditer tout votre dépôt à chaque PR — ce qui vous inonde de problèmes pré-existants que personne ne va corriger aujourd'hui — fallow peut comparer votre branche de fonctionnalité contre main et rapporter uniquement les problèmes nouveaux ou modifiés que votre branche a introduits. C'est la bonne unité d'analyse pour une PR. Vous n'êtes pas responsable de toute l'histoire de la codebase. Vous êtes responsable de ce que vous (ou votre agent) venez d'ajouter. Incrémental, juste, et ça garde le signal propre.

La skill de l'agent : laisser l'IA noter son propre devoir — correctement

C'est ici que ça devient vraiment intéressant, et où fallow cesse d'être "un linter amélioré" et devient quelque chose que je pense que davantage de stacks agentiques vont copier.

Il y a un dépôt compagnon, fallow-skills, qui installe un module de skill pour agents via npx. Il enseigne à un agent IA — Claude Code, Cursor, Codex, Gemini CLI, plus de 30 d'entre eux — comment invoquer fallow lui-même et lire la sortie JSON structurée.

Arrêtez-vous sur ce que cela permet. L'agent qui a écrit le code bâclé peut maintenant exécuter un outil déterministe qui détecte le bâclage, recevoir des résultats lisibles par machine, et corriger sa propre sortie avant qu'elle ne vous parvienne. Chaque problème dans le JSON de fallow porte un tableau actions avec un flag auto_fixable — donc l'agent sait non seulement ce qui ne va pas mais s'il peut le corriger automatiquement.

Vous pouvez le demander directement. J'ai littéralement tapé dans Claude Code : "Lance fallow et dis-moi quels sont les cinq fichiers que je devrais refactorer en premier." Il exécute l'analyse de hotspots, analyse le JSON et revient avec une réponse classée et raisonnée basée sur de vraies données analysées — pas une estimation basée sur des vibes à propos de son propre code. Cette distinction est capitale. L'agent ne raisonne plus sur sa sortie ; il la mesure.

Cela ferme la boucle qui est cassée depuis que le codage IA a décollé. La chose qui produit la détérioration dispose maintenant d'un instrument déterministe pour détecter et supprimer la détérioration, par elle-même, dans la même session. Si vous construisez des workflows d'agents, les skills sont le mécanisme qui rend ce type d'auto-correction composable — fallow-skills est l'un des exemples du monde réel les plus propres que j'ai vus.

La sortie JSON n'est pas que pour les agents, non plus. N'importe quel script CI peut l'analyser et agir dessus programmatiquement. Structurée, typée, déterministe — l'opposé de demander à un LLM d'examiner un diff à vue d'œil.

Configuration : éliminer les faux positifs avant qu'ils ne tuent votre confiance

Un analyseur statique n'est utile que si vous lui faites confiance, et la confiance meurt dès qu'il crie sur des choses que vous avez faites exprès. Fallow vous donne de vraies soupapes de sécurité. Initialisez une configuration à la racine de votre projet :

npx fallow init

Cela génère un fichier de configuration que vous affinez avec le temps. (Une note honnête : la documentation référence quelques formats de configuration — JSON via quelque chose comme .fallowrc.json et une option TOML via fallow init --toml. Le nom exact du fichier dépend de votre version, alors vérifiez ce que init génère réellement sur votre setup plutôt que de faire confiance au nom de fichier de n'importe quel article de blog, y compris celui-ci.) Voici comment je le configure :

Ignorez les chemins générés et de duplication intentionnelle. J'ai un dossier /src/data/productinfo rempli de définitions de cartes générées — chaque entrée semble dupliquée parce qu'elles sont conçues pour être uniformes. Ignorer ce chemin a éliminé une énorme quantité de bruit. Pareil pour les tests : un glob **/tests/**, parce que les fichiers de test dupliquent la configuration exprès et c'est très bien.

Choisissez votre mode de duplication délibérément. Mode mild par défaut pour une baseline tranquille ; passez en mode sémantique quand vous voulez spécifiquement chasser les clones avec variables renommées que les LLMs adorent produire.

Utilisez des overrides inline pour les exceptions ponctuelles :

// fallow-ignore  -> désactive fallow pour tout ce fichier
// fallow-ignore-next-line  -> saute juste la prochaine ligne
export const publicApiShim = whatever // fallow-ignore-next-line

Ce dernier est parfait pour un export que vous savez inutilisé en interne parce que c'est une surface d'API publique. Vous le reconnaissez, fallow arrête de vous harceler, et le rapport reste fiable. Un rapport auquel vous faites confiance est un rapport sur lequel vous agirez vraiment — c'est tout le jeu.

L'auto-correction : 20 problèmes éliminés en une commande

Lire les problèmes, c'est une chose. Les corriger à la main, c'est la partie que tout le monde zappe. La commande fix de fallow gère le mécanique automatiquement — supprimant les exports inutilisés, nettoyant le dead code, mettant à jour le graphe import/export pour que rien ne pende après une suppression.

Faites toujours un dry-run d'abord :

npx fallow fix --dry-run   # prévisualisez chaque changement, ne touchez à rien
npx fallow fix             # appliquez les corrections mécaniques et sûres

Lors d'une de mes exécutions, il a résolu 20 problèmes en une seule passe — principalement des exports morts et des imports orphelins, le fastidieux que je n'aurais jamais nettoyé manuellement. Il ne tente pas d'auto-refactorer une fonction de 1 500 lignes ou de fusionner une clone family ; cela nécessite un jugement humain sur la bonne abstraction, et fallow a raison de ne pas deviner. Il corrige ce qui est sûr et laisse les décisions architecturales pour vous. Cette retenue est exactement ce que vous voulez d'un auto-correcteur.

Là où fallow montre ses limites (la partie honnête)

Je ne vais pas prétendre que cet outil est magique, parce qu'il ne l'est pas, et vous me prendriez en flagrant délit la première fois que vous l'exécuteriez.

Il est uniquement TypeScript et JavaScript. Si votre stack est Python ou Go, ce n'est pas votre outil aujourd'hui.

La couche statique ne sait pas ce qui s'exécute réellement. Un morceau de code "mort" pourrait être invoqué par réflexion, un import dynamique ou une route basée sur des chaînes que le parser ne peut pas suivre. C'est littéralement pour cela que la couche runtime payante existe — et c'est pourquoi vous devriez vérifier avant de supprimer, pas faire aveuglément confiance à la liste de code inutilisé.

Le mode de duplication sémantique produit des faux positifs. Deux fonctions véritablement différentes qui partagent une forme seront signalées. Vous passerez du temps à trier et vous vous appuierez sur ces règles d'ignore. C'est le coût pour détecter les clones subtils — il n'y a pas de repas gratuit.

Et il ne réparera pas votre architecture. Il vous dit qu'une fonction est un hotspot de 1 500 lignes avec 115 branches. Il ne vous dira pas la bonne façon de la décomposer. Ce jugement est toujours le vôtre. Fallow pointe la lampe torche ; c'est toujours à vous de nettoyer la pièce.

Rien de tout cela n'est rédhibitoire. C'est la forme normale d'un outil affûté : il fait une catégorie de choses exceptionnellement et reste en dehors du travail qu'il ne peut pas faire en toute sécurité. Je préfère cela à un outil qui auto-refactorise mon code avec assurance en quelque chose de subtilement cassé.

Ce qui a changé après que j'ai commencé à l'exécuter

Je ne vais pas vous citer un faux "a réduit les bugs de 47 %" parce que je n'ai pas ce chiffre et personne qui vous dit qu'il l'a ne l'a non plus. Ce que je peux vous dire, c'est ce qui a réellement changé dans ma façon de travailler.

J'ai arrêté de faire confiance à "ça marche" comme définition de "c'est terminé." La sortie de l'agent reçoit maintenant une passe fallow avant que je la lise, de la même façon que je lancerais les tests. La liste de hotspots est devenue mon vrai backlog de refactoring au lieu d'un vague sentiment de culpabilité concernant "les fichiers en désordre." Et dans le CI, la porte de comparaison de branches signifie que la PR vibecoded d'un collègue ne peut pas silencieusement déverser 200 lignes de logique dupliquée dans la codebase sans qu'un commentaire apparaisse sur la PR — la conversation a lieu avant le merge, ce qui est le seul moment où elle est peu coûteuse.

Le résultat réaliste que vous devriez attendre : pas zéro dette, mais une dette visible, classée et en diminution. Vous connaîtrez vos cinq pires fichiers par nom. Vous attraperez la nouvelle détérioration dans la PR au lieu de la découvrir trois sprints plus tard. Pour un outil statique gratuit qui s'installe avec npx, c'est un retour remarquable.

Le plus grand changement est mental. Une fois qu'une IA écrit la majorité de votre code, votre travail passe d'auteur à éditeur et porte de qualité. Fallow est l'un des premiers outils construits nativement pour ce travail — déterministe, rapide et également utilisable par vous et par l'agent lui-même.

Alors voici mon défi pour les prochaines 24 heures : pointez npx fallow sur le dépôt avec beaucoup d'IA dont vous êtes le plus fier. Celui dont vous êtes sûr qu'il est propre. Lisez la section duplication en premier. Je parierais que vous trouvez au moins une clone family dont vous ignoriez l'existence — et une fois que vous la verrez, vous ne pourrez plus ne pas la voir. C'est exactement le but.

Questions Fréquentes

Fallow est-il gratuit ?

Oui — toute la couche d'intelligence statique de fallow est gratuite et open source, couvrant le dead code, la duplication, la complexité, les hotspots et l'analyse d'architecture. Il existe une couche runtime payante optionnelle qui ajoute des preuves de trafic de production pour l'examen des chemins chauds et la suppression des chemins froids, mais la couche statique gratuite est là où réside la valeur quotidienne. Exécutez-le avec npx fallow, aucun compte requis.

En quoi fallow est-il différent d'ESLint ?

Fallow cible les défauts de maintenabilité à travers toute votre codebase — duplication, dead code, complexité et hotspots — tandis qu'ESLint cible les règles de style et de correction par fichier. ESLint ne signalera pas 100 lignes que vous avez copiées-collées dans quatre fichiers ; fallow les regroupe en une clone family avec des plages de lignes exactes. Ils sont complémentaires, pas concurrents. Consultez les sections duplication et hotspots ci-dessus pour voir ce que fallow détecte et que les linters manquent.

Fallow peut-il auto-corriger les problèmes de code généré par IA ?

La commande fix de fallow auto-résout les problèmes mécaniques et sûrs — supprimant les exports inutilisés, effaçant le dead code et mettant à jour le graphe import/export — et une seule exécution peut régler plus de 20 problèmes. Prévisualisez toujours avec npx fallow fix --dry-run d'abord. Il ne tente délibérément pas d'auto-refactorer les fonctions géantes ni de fusionner les doublons, car ceux-ci nécessitent un jugement architectural humain.

Fallow fonctionne-t-il avec des agents IA comme Claude Code ?

Oui — le module fallow-skills (installé via npx) enseigne aux agents comme Claude Code, Cursor, Codex et Gemini CLI à invoquer fallow et lire sa sortie JSON structurée. Cela permet à un agent de s'auto-vérifier et d'auto-corriger son propre code avant d'ouvrir une PR. Vous pouvez demander des choses comme "quels sont les cinq fichiers que je devrais refactorer en premier ?" et obtenir une réponse basée sur les données. Consultez la section skill de l'agent ci-dessus pour le workflow complet.

Quels langages fallow supporte-t-il ?

Fallow analyse uniquement les projets TypeScript et JavaScript, avec environ 95 plugins de framework qui auto-détectent les stacks comme Vite, Next.js, TanStack Query et Tailwind CSS. Il n'y a pas de support pour Python ou Go dans la ligne de versions 2.8x en juin 2026. Si votre projet est JS/TS, il se configure tout seul à la première exécution sans aucune préparation.

Travaillons Ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (développements sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprises) : ramlit.com
• ColorPark (design et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io