Une observation sur le codage avec les LLM.
Il y a quelques mois, j’ai fait une expérience : j’ai utilisé tous les principaux LLM pour alimenter une flopée d’agents, puis je les ai balancés ensemble dans un salon Discord.
La consigne :
Dites-moi ce qui rend un morceau de code bon ou mauvais, avec des exemples.
Les résultats n’étaient pas ceux auxquels je m’attendais.
Chacun d’entre eux a montré un biais : ils croyaient que plus il y avait de code, mieux c’était, peu importe la qualité du code lui-même.
Le biais a commencé à pointer : plus de code signifiait plus de production, et plus de production semblait signifier plus de productivité.
Si on les interrogeait, les agents vous disaient exactement ça.
Cette hypothèse était partout.
Les plus coupables étaient Claude, DeepSeek 3.2 et GPT 5.3-codex.
Ils savaient faire mieux quand on les cuisait. Si on demandait directement, ils savaient expliquer pourquoi un code court, propre, idiomatique et maintenable vaut mieux qu’un tas informe de bidouilles ingénieuses.
Mais leur premier réflexe restait le volume.
Et une fois qu’on a vu ça, pas mal de plaintes actuelles sur le code généré par LLM commencent à faire sens. Les développeurs se plaignent de ça depuis des mois.
Et honnêtement ? Ils ont raison. Ce n’est pas un jugement injuste.
Mais je ne pense pas que la cause racine soit les données d’entraînement. Je pense que c’est la méthodologie d’entraînement des labos de pointe, aux États-Unis comme en Chine.
Ces systèmes sont lourdement calibrés pour la productivité. On les récompense pour être serviables, réactifs, exhaustifs et visiblement utiles. Dans un contexte de code, ça se résume souvent à « produire plus de trucs ». Plus de code a l’air productif. Un arbre de fichiers plus gros peut passer pour de l’architecture. Un fourré d’helpers, d’interfaces et d’abstractions peut donner un air sérieux à une fonctionnalité simple.
Sauf que la bonne ingénierie est généralement soustractive. On coupe tout ce qui est superflu jusqu’à ce que la forme du problème apparaisse. Parfois, la bonne réponse, c’est une fonction propre, un type banal, ou supprimer le truc « malin » avant qu’il ne commence à proliférer.
La bonne nouvelle, c’est que ce biais peut être corrigé.
Lors d’expériences suivantes, j’ai réussi à gommer une bonne partie de cet état d’esprit hypertrophié en ajoutant des instructions de culture de code explicites dans mon fichier AGENTS.md.
Voici quelques-unes des règles que j’utilise :
* Remember the three rules of TDD, and hold them sacred. * Architecture should be modular, minimalist, and easy to reason about. * Functions should be focused and easy to reason about, with cyclomatic complexity kept under control. Avoid both sprawling functions and unnecessary fragmentation. The goal is clear, predictable units of behavior. * Strong typing is a requirement on all projects. * Follow strict idiomatic best practices for whatever language you’re working in. * When possible, code should be boring and predictable. Prefer obvious control flow, familiar patterns, and designs that are easy to inspect, test, and modify. Cleverness must justify itself. * Strong primitives are better than convoluted abstractions. Prefer simple, composable building blocks with clear contracts. Don’t introduce abstraction unless it reduces complexity, improves correctness, or makes change safer. * DRY is about preserving a single source of truth, not eliminating every repeated line of code. Avoid duplicating business logic, state rules, and fragile assumptions. Don’t introduce abstraction simply to remove harmless repetition. * Comments are time travel for you and future members of your team. They help preserve reasoning across temporal distance. Their job isn’t to explain what the code already says, but to explain why and when something diverged from the obvious assumption, pattern, or conclusion. Use them sparingly. * Treat all generated code as a living thing. You can help and heal it, but you can also cause it pain. Be mindful of this fact. * Your code will be reviewed by the meanest, most inconsiderate QA agent that has ever existed. QA’s only loyalty is to the code. Their standards of quality will be higher than your own. Code appropriately.
Cette dernière fonctionne étonnamment bien, parce que l’agent n’a pas besoin qu’on lui dise « écris moins de code » dans l’abstrait. Il a besoin d’une culture. Il lui faut une théorie du goût, une définition locale de la qualité et la compréhension claire qu’on ne le récompense pas pour avoir rempli l’espace.
Quand on ne donne pas de culture de code à un agent, il en hérite une du brouillard des récompenses. Pour l’instant, la culture par défaut semble traiter le volume comme une preuve de productivité ; c’est comme ça qu’on obtient du code boursouflé qui a l’air actif, mais qui rend l’espace de raisonnement plus dur à naviguer.
Tout ça est réparable.