Contexte et portée de l'IA en génie logiciel
L’article souligne que les agents d’intelligence artificielle peuvent automatiser une partie importante de l’implémentation et assister les activités d’analyse, de conception et de test. Cette capacité ne supprime toutefois pas la responsabilité humaine de déterminer ce qui doit être construit et de juger la suffisance des preuves d’acceptation. L’auteur insiste sur le fait que remplacer le développeur qui « tape du code » serait une simplification abusive, car la chaîne de décision reste indispensable.
Gestion durable des décisions d'architecture
Pour éviter que les décisions architecturales ne se perdent dans une conversation éphémère, l’auteur propose de les consigner dans un fichier PROJECT_GUIDE.md. Ce document doit contenir le but du produit, le périmètre actuel, les exclusions explicites, les frontières du système et les raisons des choix d’architecture, ainsi que les attentes de qualité et les commandes de vérification. L’article cite le rapport d’Anthropic sur les agents à long terme, qui montre que les fenêtres de contexte limitées entraînent des problèmes de continuité et que la compaction des sessions peut effacer les conditions de décision. En reliant explicitement le guide aux instructions du projet, on garantit que l’agent le charge lorsqu’il exécute une tâche.
Vérification contrôlée des artefacts générés
L’auteur décrit une chaîne de vérification locale composée d’un formateur, d’un compilateur et d’une suite de tests ciblés. Chaque commande répond à une question précise : le formateur assure le respect des conventions, le compilateur valide les règles de type, les tests confirment le comportement attendu. L’exemple du « écran de recherche mobile » montre comment définir des cas d’acceptation (résultat correspondant, état vide, restauration complète, protection contre l’écrasement de résultats asynchrones) avant l’implémentation. Le texte rappelle la discussion de Simon Willison (juin 2025) sur le « context engineering », qui recommande de sélectionner délibérément les informations fournies à chaque étape du modèle.
Limites et bonnes pratiques
Les sorties d’un agent restent probabilistes ; un test qui passe ne garantit pas que le bon problème a été résolu. L’article met en garde contre les vérifications trop larges, comme un test qui ne contrôle que la présence d’un résultat sans vérifier son exactitude. Il souligne également que les hooks locaux facilitent la détection précoce d’erreurs, mais ne remplacent pas les politiques de protection côté serveur. Enfin, l’ingénieur doit toujours interpréter les preuves, décider d’accepter, de réviser ou de rejeter le livrable, et documenter les raisons de chaque décision pour préserver la traçabilité.
