Le débat le plus utile sur l’AI cette semaine ne porte pas sur un nouveau modèle. Il porte sur la raison pour laquelle le même LLM donne à une personne un brouillon utile, à une autre des erreurs sûres d’elles, et à une troisième plus de code que l’équipe ne peut réellement livrer.

Expert guidant des panneaux AI avec listes de contrôle, tests et contexte de travail

Plusieurs discussions montées ensemble sur Hacker News — “LLMs reward expertise”, cognitive debt et AI Productivity Gap — disent la même chose: AI augmente la capacité de production, mais la qualité dépend toujours de l’expertise, de la vérification et de la compréhension du système.

Le prompting n’est pas une formule magique. L’expert sait quel détail change le problème, quel vocabulaire utiliser, où le modèle hallucine, quelle réponse semble plausible mais fausse, et quand arrêter. AI ne supprime pas l’expertise; elle la rend plus visible.

Les débutants gagnent, mais avec limites

AI aide les novices à prototyper, rédiger, explorer et apprendre. La limite apparaît quand la tâche sort du chemin balisé. Il manque vocabulaire, critères de qualité, déploiement, sécurité, maintenance et définition de “terminé”.

La bonne réponse n’est pas d’interdire AI aux juniors. Il faut du scaffolding: exemples, checklists, environnements sûrs, glossaires, evals et mentorat. Avec feedback, AI accélère l’apprentissage. Sans feedback, elle masque les lacunes.

La dette cognitive existe

Quand un agent écrit un gros changement et qu’un humain l’accepte après une revue superficielle, le code existe avant d’être compris. Ankur Sethi propose de retaper ou réécrire manuellement les changements suggérés pour préserver le modèle mental. Le geste n’est pas universel, mais le principe compte: comprendre fait partie du livrable.

Le mode rapide convient aux tâches mécaniques, bornées et testées. Les systèmes centraux, la sécurité, la facturation, les migrations, l’architecture et l’apprentissage exigent un mode qui préserve la compréhension. Le responsable doit expliquer le changement, ses tests, ses risques et son intégration.

La productivité dépend des goulets

Accélérer l’écriture de code ne triple pas la livraison produit. Exigences, design, revue, tests, CI, déploiement, coordination et jugement produit restent des contraintes. AI peut même augmenter le volume à relire.

Les lignes de code, PRs ou tokens sont donc de mauvaises métriques. Il faut mesurer les résultats validés: problèmes clients résolus, cycle de production plus court, moins de défauts, analyses correctes plus rapides, documentation utile.

Les anciennes pratiques reviennent

Le cas de refactoring décrit par Martin Fowler montre que la structure compte. Dans une application de 150 000 lignes écrite par agents, un fichier Rust de 17 155 lignes servait de couche d’accès aux données. Après refactoring, les tokens d’entrée pour un changement représentatif sont passés de 159 564 à 27 360, soit 83% de moins. Mais la stratégie venait d’une guidance humaine.

Pour les équipes non techniques, l’équivalent est l’hygiène du workflow. Sans critères clairs, AI produit plus de confusion: réponses support incohérentes, clauses improvisées, analyses jolies mais fausses.

Checklist pratique

Mesurez le throughput de résultats, pas le volume. Exigez l’ownership humain des décisions finales. Gardez de petits changements. Utilisez les agents pour des tâches bornées et vérifiables. Mettez les hypothèses métier dans des documents, tests, dictionnaires et exemples durables. Créez des evals avant de passer à l’échelle. Suivez la charge de revue et la dette cognitive. Protégez l’apprentissage des juniors.

AI entre dans la phase post-démo. La question n’est plus de savoir si le modèle peut produire. Il le peut. La question est: qui sait lui faire produire la bonne chose, dans le bon contexte, sans dette pour les autres?