À l’ère où l’on ne lit plus le code, que doivent lire les ingénieurs ?

Utiliser l’IA réduit l’apprentissage ?

• Étude d’Anthropic : les développeurs ayant terminé des tâches de programmation avec l’IA ont obtenu des scores de quiz inférieurs de 17 %
• Le point clé n’est pas « utiliser l’IA réduit l’apprentissage », mais le fait qu’en utilisant la même IA, les résultats divergeaient radicalement selon la manière de s’en servir
• Ceux qui ont confié le code en entier à l’IA → ont terminé le plus vite, mais ont le moins appris
• Ceux qui ont seulement posé des questions sur les concepts et codé eux-mêmes → ont eu plus d’erreurs, mais des scores de quiz nettement supérieurs

De l’ère où l’on lit le code à celle où l’on donne des instructions

• Ben Shoemaker : « Je ne lis plus le code ligne par ligne. Je lis les specs, les tests et l’architecture. » → une nouvelle approche appelée harness engineering
• Équipe Codex d’OpenAI : trois ingénieurs ont créé un million de lignes de code uniquement avec des agents et livré un produit utilisé par des centaines de personnes. Ce dans quoi ils ont investi, ce n’était pas le code, mais la documentation, les linters et l’infrastructure de test
• Evan Armstrong : la génération de code est devenue une commodité, mais la « couche de contexte » qui gouverne le code en production n’est pas devenue une commodité
• Steve Yegge : « L’ère du hand-coding est terminée. » Il propose 8 niveaux d’adoption de l’IA — à partir du niveau 4, on ne regarde plus les diff, et au niveau 8, on construit directement son propre orchestrateur d’agents

Le jeu de la ligne d’arrivée et le jeu des intérêts composés

• Kent Beck : derrière le développement fondé sur les specs se cache l’hypothèse du « jeu de la ligne d’arrivée » (une fois X atteint, c’est terminé)
• En réalité, le développement logiciel est un « jeu d’intérêts composés » — l’architecture d’aujourd’hui ouvre ou ferme des possibilités pour dans six mois
• « On ne gagne pas un jeu d’intérêts composés avec un meilleur AGENTS.md » — l’essentiel est de concevoir un système qui s’accumule de manière composée

L’IA est un miroir

• Jeremy Utley (Stanford) : « Elle aide à être paresseux pour celui qui veut être paresseux, et à être plus affûté pour celui qui veut gagner en acuité »
• Si l’on a un background en TDD/DDD, on peut guider l’IA dans ce sens ; si l’on se contente de dire « fais-le », on obtient un code mal structuré. Ce n’est pas que l’IA soit stupide : si je ne prête pas attention à quelque chose, l’IA n’y prêtera pas attention non plus
• Recherche de Berkeley : l’IA a permis à des non-développeurs de coder, mais au final les ingénieurs ont dû passer plus de temps à relire et corriger le code IA de leurs collègues
• « Effet Dracula » — quand on fait du vibe coding à pleine vitesse, le temps réellement productif plafonne à trois heures par jour

Alors, comment l’utiliser ?

• « N’exigez pas de l’IA la bonne réponse : dialoguez avec elle. » Au lieu de poser des questions à l’IA, faites en sorte que l’IA vous pose des questions
• Recommandation de la saisie vocale — taper au clavier met en « mode mots-clés », la voix fait basculer en « mode conversation »
• Context engineering : si AGENTS.md explicite les raisons des choix d’architecture, les conventions et le vocabulaire métier, l’IA produit un code cohérent
• Kent Beck : « Investissez autant dans les futures possibilités que dans les features »

Ce qui ne change pas

• La nécessité de lire chaque ligne de code diminue, mais la capacité à savoir le lire est devenue encore plus importante
• Quand tous les tests passent mais que le produit se comporte bizarrement, quand l’IA dit « aucun problème » alors qu’il y a un bug — il arrive toujours un moment où il faut lire soi-même
• Savoir lire mais ne pas lire, et ne pas savoir lire du tout, ce sont deux choses complètement différentes
• Devenir quelqu’un qui a quelque chose à refléter dans le miroir — voilà l’essence du métier d’ingénieur à notre époque