Extension ESLint pour les erreurs de code IA

Et si votre acolyte IA au codage sabotait en douce votre appli avec des bugs qui ne se révèlent qu’en production ?

C’est le cauchemar à l’origine d’eslint-plugin-llm-core. Imaginez : vous roulez avec votre LLM, vous enchaînez les features. Tests au vert. Revue OK. Paf — jour du déploiement, tout part en vrille avec des promesses non résolues et des erreurs avalées. Je l’ai vu. Le créateur aussi, après avoir autopsié 500 ratés de code généré par IA.

Et le twist électrisant : il n’a pas juste râlé. Il a forgé eslint-plugin-llm-core, une extension ESLint ultra-ciblée avec 20 règles taillées pour les faiblesses typiques des LLM. Pas des bonnes pratiques de mamie. Celles-ci visent pile les patterns que les LLM déconnent systématiquement.

Regardez.

Async/await massacré dans les callbacks d’array. Blocs catch vides qui dévorent les erreurs comme des bonbons. Nids imbriqués qui puent le “callback hell 2.0”. C’est comme si l’IA avait pris les arêtes les plus vives de JavaScript pour les jongler les yeux bandés.

Pourquoi ? Les LLM excellent en syntaxe et chemins heureux — ce sont des machines à patterns sur stéroïdes. Edges, cohérence, crasse du réel ? Ils hallucinent des API, zappent les nulls, inventent des magic numbers. Les études le confirment : 40 % de blocs manquants, 20 % de lectures foireuses, 15 % d’aveugle aux cas limites.

Pourquoi le code IA explose-t-il en production ?

Voyez les LLM comme des stagiaires zélés. Génies des tutos, paumés sur le terrain.

Ils cartonnnent aux unit tests parce que ça mocke le bordel. En prod ? Données imprévisibles qui déferlent — nulls, timeouts, pannes partielles. Le code IA s’écroule.

Prenez ce classique :

const results = items.map(async (item) => { return await fetchItem(item); });

Ça a l’air clean, non ? Votre assistant IA l’a pondu. Tests OK. Code review validé.

Puis la prod frappe, et results est un array de Promises — pas les valeurs attendues.

La règle no-async-array-callbacks d’eslint-plugin-llm-core la flaire direct : “57:27 error Avoid passing async functions to array methods llm-core/no-async-array-callbacks. This pattern returns an array of Promises, not the resolved values. Consider using Promise.all() or a for…of loop instead.”

Pédagogique, hein ? Pas juste “corrige” — ça explique, pour que même votre IA progresse au prochain coup.

Ou les catch vides :

try { await processData(data); } catch (e) { // TODO: handle error }

“63:11 error Empty catch block silently swallows errors.” Boum. Éliminé.

Et l’imbrication ? L’IA empile des if comme en 99. La règle prefer-early-return les aplatit : pas de data, on sort tôt. Propre, lisible, blindé.

Pas du buzz. Du minage de patterns sur du carnage réel — études empiriques, 333 bugs, 558 snippets pourris. Les angles morts de l’IA, codifiés.

eslint-plugin-llm-core va-t-il faire de l’IA votre nouveau lead dev ?

Réponse courte : plus proche que vous croyez.

Souvenons-nous de JSLint au début des 2000. JavaScript, c’était le far west des quirks de navigateurs et code de cowboys. Le linter de Crockford a dompté la bête, pavant la voie au web dev moderne. eslint-plugin-llm-core ? C’est le JSLint de l’ère IA.

Ma prédiction osée — et l’info que l’original zappe : ce plugin passe l’IA du statut “assistant” à “co-pilote qu’on laisse sans surveillance”. Entraînez votre LLM sur ses messages d’erreur dans les prompts, et regardez la qualité exploser. Des diffs prêts pour la prod dès le jour 1. Fini le baby-sitting de Copilot ou Claude.

Vérif corporate : ok, typescript-eslint pour les règles TS. Mais c’est pur TypeScript, obsédé par les specs. Ça ? Affûté pour la guerre IA. Les deux ensemble — comme beurre de cacahuète et chocolat.

Installation ? Ultra-simple.

``` npm install -D eslint-pl