Pourquoi vos prompts ne peuvent pas arrêter le « slop » de l'IA
Les prompts seuls ne sauveront pas votre base de code des déchets générés par l'IA. Les agents IA ignorent ou contournent fréquemment les normes de codage que vous définissez minutieusement dans vos instructions, permettant à du code de faible qualité, ou « slop », de se glisser dans vos projets. Il est facile pour les agents de ne pas tenir compte des règles des prompts, introduisant des incohérences et des problèmes potentiels qui minent la qualité du code.
Ce « slop » n'est généralement pas un bug qui interrompt immédiatement la compilation. Il s'agit plutôt de code à faible preuve, comme un transtypage non sécurisé, qui érode la type safety au fil du temps. Le code compile parfaitement, mais il crée des bugs subtils et difficiles à tracer qui apparaissent beaucoup plus tard, transformant des oublis mineurs en casse-têtes de débogage majeurs.
Prenons un exemple classique : vous récupérez des données depuis une API JSON, incluant un champ createdAt qui arrive sous forme de chaîne de caractères. Votre agent IA pourrait le convertir directement en objet Date, bien que JSON n'ait pas de type Date natif. Le code compile sans plainte parce que vous avez explicitement dit à TypeScript de vous faire confiance. Mais cela crée une bombe à retardement, prête à faire planter votre application dès que quelqu'un tente d'effectuer une opération Date sur cette chaîne, qui reste une chaîne.
Un gardien plus rapide et plus strict pour le code
Oubliez l'espoir que vos agents IA suivent par magie vos directives de codage. Découvrez plutôt anti-slop : une collection de règles strictes conçues pour Oxlint. Ce linter, écrit en Rust, affiche une vitesse incroyable, s'exécutant 50 à 100 fois plus vite qu'ESLint. Ce type de performance est crucial pour des boucles de rétroaction rapides, permettant aux développeurs comme aux agents de voir les problèmes de code presque instantanément.
Contrairement à la nature probabiliste du prompt engineering, le linting est entièrement déterministe. Il agit comme un échec critique, signalant immédiatement tout modèle de code que votre équipe a explicitement banni. Ce n'est pas une suggestion que votre IA pourrait prendre en compte ; c'est une barrière de qualité non négociable, garantissant que le « slop » ne peut pas se faufiler dans votre base de code.
La vraie puissance d'anti-slop réside dans sa personnalisation. Vous n'avez pas besoin d'adopter chaque règle du package. Les équipes peuvent sélectionner méticuleusement les règles spécifiques qui s'alignent parfaitement avec leurs normes de codage existantes, créant un mécanisme d'application automatisé et hautement personnalisé. Il s'agit de construire un système robuste et prévisible pour la qualité, et non simplement d'ajouter plus de prompts au problème.
Transformer les erreurs de linter en leçons pour l'IA
La véritable innovation avec anti-slop n'est pas seulement sa vitesse ; c'est la qualité pure de ses messages d'erreur. Oubliez la sortie TypeScript généralement cryptique qui laisse les développeurs perplexes, se demandant ce qui a mal tourné. Ce linter vous indique précisément pourquoi votre code généré par l'IA est problématique et, surtout, comment le corriger. Il offre des idées directes et exploitables au lieu de plaintes vagues.
Ce retour descriptif transforme les messages d'erreur en « juicy data » incroyables pour un agent IA. Au lieu d'un simple succès/échec, le linter évolue en un enseignant puissant, guidant l'agent pour comprendre et réparer ses propres erreurs. Cela modifie considérablement son rôle, passant d'un simple vérificateur de code à une boucle de rétroaction intelligente et auto-améliorée, économisant d'innombrables heures de débogage manuel.
Le agentic workflow devient remarquablement efficace :
- Un agent IA produit son code initial.
- anti-slop s'exécute, signalant instantanément tout problème.
- L'agent analyse ensuite le message d'erreur détaillé, qui inclut des instructions spécifiques.
- Enfin, l'agent répare le code en se basant sur ces directives précises, ce qui permet d'obtenir un résultat de meilleure qualité. Ce processus itératif empêche les modèles à faible niveau de preuve d'atteindre la production. Pour une liste complète de ces règles arbitraires, consultez le dépôt GitHub - dmmulroy/anti-slop: Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Des mauvaises habitudes au code à toute épreuve
La mise en œuvre des règles anti-slop modifie fondamentalement votre approche du développement. Au lieu de réagir aux bugs une fois qu'ils se manifestent, vous empêchez de manière proactive les modèles de faible qualité qui les provoquent. Ce linter détecte le code problématique à la source, comme une chain type assertion dangereuse qui écarte des preuves de typage critiques. Par exemple, convertir une réponse API en unknown puis en User peut masquer le fait que createdAt pourrait être une chaîne de caractères et non une date, introduisant un bug latent avant même la compilation.
Au-delà de la prévention, anti-slop formalise les normes de codage de votre équipe. Il établit un ensemble de règles lisibles par machine et applicables, économisant un temps de revue humaine précieux sur des problèmes courants mais critiques. Cela signifie que vous n'avez pas besoin d'un humain pour signaler des éléments tels que des fonctions retournant unknown ou d'autres modèles TypeScript à faible niveau de preuve. Le linter les signale, expliquant pourquoi ils sont problématiques et comment les corriger, par exemple en analysant les entrées non fiables à leur frontière.
Intégrez anti-slop dans votre CI/CD pipeline ou dans une boucle de développement locale, et vous pourrez systématiquement 'anti-sloper' l'ensemble de votre base de code. Cela garantit que les contributions humaines et celles de l'IA répondent systématiquement à un niveau de qualité et de preuve plus élevé. Les agents IA, en particulier, apprennent à produire un code à toute épreuve en se corrigeant grâce aux retours clairs et exploitables du linter, créant ainsi un système véritablement robuste et maintenable.
Foire aux questions
Qu'est-ce qu'Anti-slop ?
Anti-slop est un ensemble de règles de linting arbitraires pour Oxlint, un linter JavaScript/TypeScript haute performance. Il est conçu pour rejeter les modèles de code à faible niveau de preuve et à faible signal souvent produits par les agents IA.
Comment Anti-slop améliore-t-il le code généré par l'IA ?
Il crée une boucle de rétroaction. Un agent IA génère du code, le linter s'exécute et fournit des erreurs très descriptives sur les raisons pour lesquelles un modèle est mauvais et comment le corriger. L'agent utilise ensuite ce retour pour réparer le code, améliorant la qualité de manière déterministe.
Anti-slop remplace-t-il ESLint ?
Anti-slop fournit des règles qui s'exécutent sur Oxlint, un linter qui peut être utilisé parallèlement ou comme une alternative beaucoup plus rapide à ESLint. Oxlint est évalué comme étant 50 à 100 fois plus rapide qu'ESLint.
Quel type de modèles de code Anti-slop détecte-t-il ?
Il détecte le code qui peut compiler mais qui est considéré comme un 'code smell'. Les exemples incluent les assertions de type en chaîne (par exemple, as unknown as User), les fonctions avec des paramètres ou des types de retour inconnus, et d'autres modèles à faible niveau de preuve qui écartent la sécurité du typage.