🎙️ La prise de position
Un développeur expose sa conclusion après usage professionnel des LLM. En résumé :
« Les LLM sont bons à rien quand le programme dépasse une complexité. Ils ajoutent des difficultés au lieu d'aider. »
Ils sont utiles pour remplacer Google/Stack Overflow sur du code simple, commenter un code existant ou générer de petits cas de test.
« Mais quand la complexité du logiciel dépasse un certain niveau, ça peut devenir difficile, voire impossible, de générer de bons tests automatiquement. Conclusion : les LLM sont bons pour autre chose, pas pour développer des applications. »
Cette opinion, honnête dans son ressenti personnel, soulève des questions intéressantes sur ce qui est fondé et ce qui est exagéré.
✅ Ce sur quoi la personne a raison
Trois points méritent qu'on s'y arrête — ils reflètent des limites documentées des LLM actuels :
Complexité architecturale
Au-delà d'un certain seuil, les LLM ne comprennent pas l'architecture globale, les dépendances implicites ni les trade-offs système. La littérature confirme que leur performance se dégrade significativement sur des bases de code de taille moyenne à grande.
Tests professionnels difficiles
Les tests couvrent des cas limites, des états du système, des interactions asynchrones — un LLM seul ne peut pas modéliser tout cela de façon fiable. C'est le point le plus juste de l'argumentaire.
Coût de relecture > coût d'écriture
Passer du temps à relire et corriger du code généré prend souvent plus de temps que d'écrire proprement soi-même. Plusieurs études montrent une régression de productivité au-delà de tâches simples.
⚠️ Ce qui est critiquable
Là où la position glisse vers l'exagération, en tombant dans plusieurs pièges cognitifs classiques :
1 Raisonnement binaire
Le « bons à rien » vs « bons pour autre chose » est faux. La réalité est graduelle. Les LLM sont utiles sur des couches d'abstraction précises : squelettes, boilerplate, exploration rapide d'API, reformulation d'erreurs spécifiques. Dire qu'ils ne servent « pas pour développer des applications » revient à dire qu'un marteau ne sert pas à construire — alors qu'il est un outil au sein d'un workflow, pas un substitut au constructeur.
2 Complexité fonctionnelle ≠ complexité technique
Un e-commerce avec 10k lignes bien architecturé n'a pas besoin qu'un LLM comprenne tout pour être utile par endroits. La complexité qui tue les LLM, c'est la complexité émergente — interactions entre modules non prévues — pas le volume brut de code.
3 L'affirmation « impossible »
Dire qu'il est « impossible » de générer de bons tests est exagéré. Des outils comme GitHub Copilot + property-based testing + génération assistée fonctionnent déjà bien en pratique. Ce n'est pas automatique, mais « impossible » ne résiste pas à l'épreuve des équipes qui les utilisent avec succès.
4 Généraliser depuis l'expérience personnelle
La conclusion semble tirée d'une expérience limitée (« pour moi, c'était bon »). Honnête comme position subjective, mais dangereux de l'élever en vérité générale. Les bonnes équipes utilisent les LLM différemment : code reviews augmentées, pair-programming, découverte de solutions — pas « génère-moi l'app entière ».
📊 Synthèse évaluable
| Assertion | Validité |
|---|---|
| LLMs peu utiles au-delà d'un certain seuil de complexité | ✓ Fondé |
| LLMs bons pour recherche et code simple | ✓ Accord |
| Tests automatisés = zone difficile | ✓ Accord |
| "Bons à rien" en développement global | ✗ Exagéré |
| "Impossible" de générer de bons tests | ✗ Trop absolu |
| "Pas pour développer des applications" | ✗ Fausse dichotomie |
Verdict final
La personne décrit correctement les limites actuelles des LLM, mais tombe dans un piège classique : voir des limitations techniques comme des frontières absolues plutôt que des problèmes de workflow à résoudre.
Les LLM ne remplacent pas le développeur — mais le meilleur développeur utilise des LLM mieux que celui qui les rejette systématiquement. La différence ne réside pas dans le volume de code, mais dans l'intelligence du prompt, la capacité à découper un problème complexe en sous-tâches que le modèle peut gérer efficacement.