La poésie du développement agentique : comment coder avec des agents quand la facilité engendre la complexité

La facilité contre la simplicité

L'auteur de Habr arturdumchev code avec des agents tous les jours depuis un an et demi et propose un nouveau regard sur le développement assisté par IA. Sa thèse : les agents permettent d'écrire du code rapidement, mais la responsabilité des erreurs reste sur le développeur, et les systèmes obtenus sont souvent excessivement complexes.

La distinction fondamentale est celle entre le facile (easy, subjectif, dépendant de l'expérience) et le simple (simple, propriété objective d'un système). Le russe est facile pour un locuteur natif, mais difficile pour un étranger. La complexité, elle, c'est l'enchevêtrement d'aspects indépendants, la 'multi-composition' au sens littéral du terme. Le DRY peut être un code smell, mais parfois la duplication simplifie le système et réduit le couplage du code.

Le vibe coding avec des agents est très facile, mais les systèmes qui en résultent sont souvent complexes. Le développeur porte l'entière responsabilité du code produit par le LLM, et plus le code est complexe, plus il est difficile à comprendre, plus la fiabilité baisse, ainsi que les garanties sur le time-to-market et le SLA.

Le LLM comprend-il la complexité ?

La réponse est nuancée. Les études montrent que les modèles raisonnent bien sur la complexité, mais l'évitent mal.

Liste des études :

• τt-Bench : les agents automatisent l'écriture de code, mais pas la pensée d'ingénierie. Quand un test échoue, l'agent corrige le test plutôt que le code. Ils ignorent les exigences de production, la réutilisabilité, les frontières architecturales.
• SlopCodeBench : le LLM produit 2,3 fois plus de lignes de code que les humains. La dégradation mesurée par l'érosion structurelle (accumulation de complexité dans les fonctions) atteint environ 6 fois. Le meilleur modèle testé est GPT-5.5.
• Estimating problem difficulty : la corrélation entre les évaluations du LLM et celles des humains sur la difficulté des tâches est de 0,8 (Pearson).
• Can LLMs Estimate Student Struggles : les modèles ne s'adaptent pas à l'expérience d'une personne donnée et ne prédisent pas ses difficultés personnelles.
• Rethinking Code Complexity : étude de la complexité à travers la profondeur d'imbrication et de branchement.
• Beyond Strict Rules : les code smells simples sont détectés par DeepSeek-R1, GPT-5 mini, Llama-3.3, Qwen2.5-Code, mais les plus subtils, visibles par les humains, leur échappent.
• The Modular Imperative : Claude Sonnet 4 découpe le code en fichiers et discourt sur la séparation des responsabilités, tout en liant implicitement les entités entre elles et en embrouillant le système.

L'équilibre entre contrôle et autonomie

Deux options extrêmes : le contrôle total (le développeur fait tout lui-même, la complexité est minimale, mais l'effort est maximal) et l'autonomie totale (l'agent écrit tout, la difficulté est nulle, mais la complexité croît). Graphiquement, cette relation est inverse.

L'auteur suppose qu'il existe un point d'optimum où les investissements d'effort supplémentaires rapportent de moins en moins (loi des rendements décroissants). Par exemple, en écrivant un gabarit pour 50 tests similaires, on dépense beaucoup d'énergie, mais l'agent refait ensuite les autres par analogie tout seul — la valeur résidait dans les 20 premiers pourcents d'effort.

Formellement, il est impossible de trouver l'équilibre idéal — il dépend du contexte du projet, de son évolution, de l'équipe et des exigences. Mais empiriquement, l'auteur est parvenu à un ensemble de principes fondés sur les valeurs de maintenabilité du code : contrôle renforcé sur l'architecture, séparation explicite des responsabilités, minimisation de la complexité accidentelle.

Aucune ligne de cet article n'a été écrite par un LLM. Les agents ont servi à rechercher des informations, vérifier les erreurs et générer des diagrammes textuels. Chaque mot a été tapé au clavier.