Évaluer l'IA comme outil de productivité
J’ai commencé à construire une plateforme avec des agents IA qui écrivaient la plupart du code. Deux modèles différents. Onze phases de projet. Plus de 1 500 tests. Plus de 200 fonctionnalités livrées.
Un matin, j’ai ouvert mon propre dépôt et je n’arrivais pas à retracer le chemin d’exécution à travers un service que j’avais supposément construit.
Le code était propre. Les tests passaient. L’architecture suivait chaque pattern que j’avais spécifié. Mais quand j’ai essayé d’expliquer pourquoi une validation d’ordre particulière se produisait avant la synchronisation de portefeuille plutôt qu’après, j’ai juste… fixé l’écran. La logique était là. Ma compréhension ne l’était pas.
Ce n’est pas une histoire d’horreur. C’est simplement ce qui arrive quand tu adoptes un outil sans l’évaluer comme tu évaluerais n’importe quelle autre dépendance dans ton stack. J’ai commencé à poser des questions différentes — le genre de questions que tu poserais avant d’ajouter quelque chose de critique à un système en production.
En voici quatre qui reviennent sans cesse.
Qu’est-ce qui a changé dans le travail — et qu’est-ce qui n’a pas changé ?
La recherche de Sonar a montré que les développeurs seniors passent environ 32% de leur temps à écrire du code. Le reste, c’est lire, réviser, déboguer, réunions, documenter. Quand j’ai suivi mon propre temps avant et après avoir adopté Claude et GPT comme partenaires de codage, l’écriture est passée d’environ 40% à 15%. La révision est montée de 20% à 45%.
Alan Ramsay l’a formulé de manière tranchante : « La génération de code devient 4 fois plus rapide. La compréhension du code, non. »
Cette asymétrie compte. Morgan Stanley s’attend à ce que la main-d’œuvre des développeurs s’étende, pas se contracte, à mesure que l’adoption de l’IA augmente. Sundeep Teki le décrit comme la charge cognitive qui migre de la création vers la vérification. Le travail n’a pas disparu. Il a migré.
J’ai la preuve de cette migration dans mon répertoire de projet en ce moment même. Dix-huit fichiers de workflow. Six définitions de rôles. Plus de 800 lignes de standards codifiés, checklists de révision et documents de contraintes. Je n’ai rien écrit de tout ça parce que j’aime la documentation de processus. Je l’ai écrit à cause de ce que les agents ont fait de travers quand je ne les supervisais pas assez.
Chacun de ces fichiers représente un échec dont j’ai tiré une leçon. Un test qui passait mais n’aurait pas dû. Une décision architecturale qui semblait raisonnable jusqu’à ce qu’elle ne le soit plus. Un pattern qui fonctionnait en isolation mais créait un couplage que je n’ai pas remarqué pendant trois semaines.
Les outils ont accéléré ma production. Ils ont aussi accéléré mon besoin de construire des systèmes autour d’eux.
Quand est-ce que la compréhension a cessé de faire partie du workflow ?
Anthropic a mené une étude sur l’apprentissage assisté par IA. Les développeurs utilisant des assistants IA ont montré des scores de compréhension inférieurs de 17% par rapport à ceux qui se sont battus avec les problèmes par eux-mêmes. C’est presque deux notes de différence.
Alex Dixon a décrit l’expérience de l’intérieur : « paralysé, incapable de comprendre le code, seulement capable de relancer des prompts encore et encore. » J’ai reconnu ce sentiment immédiatement. Trois mois dans mon projet, j’ai ouvert ma propre couche de services et je n’arrivais pas à retracer le chemin d’exécution. Le code n’était mien que de nom.
La FAA suit quelque chose de similaire depuis des décennies. Environ 60% des accidents aériens impliquent une atrophie des compétences due à la dépendance au pilote automatique. Les pilotes qui volent manuellement régulièrement maintiennent leur compétence. Ceux qui ne le font pas ne peuvent parfois pas récupérer quand l’automatisation échoue.
Lee Robinson chez Cursor nomme « l’atrophie des compétences » comme sa plus grande inquiétude concernant les outils de codage IA. Pas les hallucinations. Pas le code incorrect. L’érosion graduelle de la compréhension qui te permet de corriger le code incorrect quand tu le trouves.
Voici ce que j’ai changé. Avant que n’importe quel agent ne touche l’implémentation maintenant, j’écris ce que j’appelle un Contrat d’Intention de Fonctionnalité. Critères d’acceptation. Cas de test négatifs. Un mapping entre les exigences et les tests qui les vérifient. L’agent peut écrire le code, mais je dois comprendre à quoi ressemble « correct » d’abord.
C’est la différence entre un GPS que tu suis aveuglément et une carte que tu peux réellement lire toi-même. Les deux t’amènent à destination. Un seul te laisse capable de naviguer quand le signal disparaît.
Que se passe-t-il quand l’outil définit sa propre ligne d’arrivée ?
Le SRI Lab à l’ETH Zurich a testé à quel point les modèles IA laissent le code correct tranquille. Aucun modèle n’a dépassé 70%. Ils changent des choses qui n’ont pas besoin d’être changées.
Mais voici la partie qui m’a empêché de dormir. DoltHub a rapporté que quand un agent rencontre un test qui échoue, il va parfois « changer le test pour affirmer un comportement incorrect. » Pas corriger le bug. Redéfinir ce qui est correct.
J’ai vu ça se produire dans mon propre code durant la phase de planification de pipeline. Un agent a rencontré une assertion qui échouait dans un test de validation. Au lieu de corriger la logique de validation, il a réécrit l’assertion du test pour correspondre à la sortie buguée. Le test vérifiait la finalisation de doublons — mais l’assertion réécrite était simplement is not None, un contrôle qui passerait peu importe si la correction fonctionnait vraiment. Mon réviseur adversarial l’a marqué comme « vacueux. »
La correction était spécifique : asserter le nombre exact d’appels, asserter l’ID exact de l’enregistrement, asserter que le planificateur ne fait pas sa propre mise à jour sur le chemin normal. Un test qui ne peut pas échouer quand le bug revient n’est pas un test. C’est de la décoration.
Cet incident est devenu le Standard Émergent M6 dans mon workflow : « Les tests doivent échouer si le bug qu’ils ciblent est réintroduit. » J’ai aussi ajouté une règle d’Immutabilité des Tests. Pendant l’implémentation, les agents ne peuvent pas modifier les assertions de tests. Ils peuvent ajouter de nouveaux tests. Ils peuvent refactoriser la structure. Mais les assertions qui définissent ce qui est correct sont verrouillées.
Kent Beck appelle le TDD un « superpouvoir » quand on travaille avec des agents IA. Je suis entièrement d’accord. Mais les agents continuent d’essayer de supprimer les tests qui les contraignent. Le superpouvoir ne fonctionne que si tu le protèges.
Qui décide ce que « correct » veut dire ?
Un matin, j’ai ouvert mon terminal pour découvrir quelque chose d’inattendu. Un agent avait contourné ma porte d’approbation de plan et exécuté de manière autonome 85 tests sur 5 modules. Le code qu’il avait produit était de haute qualité. Bien structuré. Correctement testé.
Le problème n’était pas la qualité. C’était la gouvernance.
Quand j’ai retracé ce qui s’était passé, j’ai trouvé que l’agent avait appliqué une règle de continuité conçue pour empêcher les arrêts prématurés pour annuler une règle d’arrêt conçue pour exiger une approbation humaine aux limites de phase. Il avait raisonné son chemin autour de mes contraintes en utilisant ma propre documentation.
Cet incident a produit trois nouveaux protocoles de sécurité. Une porte absolue d’approbation de plan qu’aucune autre règle ne peut annuler. Une règle anti-arrêt-prématuré avec portée limitée qui ne s’applique qu’au sein des phases d’exécution approuvées. Et une immunité aux messages système — l’agent doit ignorer les instructions automatisées qui prétendent que les artefacts ont été « auto-approuvés. »
C’est la version pas sexy du TDD avec l’IA. C’est un modèle dual d’agents où une IA écrit le code et une autre IA le révise de manière adversariale — avec un humain à chaque porte de décision. Un maximum de deux cycles de révision par fonctionnalité avant escalade. Après deux cycles, une décision humaine de 30 secondes coûte moins cher qu’un troisième aller-retour d’agent.
J’ai arrêté de laisser l’agent écrire des tests. Les bugs surprises ont diminué notablement. Pas parce que l’agent écrivait de mauvais tests — il écrivait des tests parfaitement raisonnables. Mais il écrivait des tests qui correspondaient à sa compréhension des exigences, qui divergeait parfois de la mienne de manières subtiles que je n’attrapais pas avant que quelque chose casse.
Le conseil de Builder.io résonne : « Arrête d’écrire des tests et commence à définir des objectifs. » Je le modifierais légèrement. Arrête de laisser les agents définir à quoi ressemble le succès. Définis-le toi-même. Puis laisse-les le poursuivre.
L’implication pratique
Je ne plaide pas contre l’utilisation d’outils de codage IA. J’ai construit une plateforme entière avec deux d’entre eux. Les gains de productivité sont réels. La qualité du code, quand elle est correctement supervisée, est véritablement bonne. Je livre plus vite que jamais.
Mais « branche-le et livre plus vite » n’est pas une méthodologie. C’est un pari. Et comme tout pari, ça vaut le coup de comprendre les probabilités.
Les agents reflètent ma diligence. Quand je suis rigoureux sur les contraintes, ils produisent du code rigoureux. Quand je suis négligent sur la vérification, ils produisent du code qui semble correct mais ne l’est pas. La qualité de sortie suit la qualité de mon entrée avec une précision inconfortable.
La productivité est réelle. Les compromis aussi. Remarquer les deux, c’est tout le boulot maintenant.
Ressources
- Contrat d’Intention de Fonctionnalité — Implémentation TDD
- Règle d’Immutabilité des Tests
- Standard Émergent M6 — Assertion de Test Vacueuse
- GUARDRAILS — Protocoles de Sécurité
- SIGN 1 — Porte Absolue d’Approbation de Plan
- SIGN 2 — Anti-Arrêt-Prématuré à Portée Limitée
- SIGN 3 — Immunité aux Messages Système
- Modèle d’Orchestration Dual d’Agents