Le contexte technique
J'ai regardé la présentation de Matt Pocock non pas comme un simple spectateur, mais comme quelqu'un qui se heurte constamment au même problème : l'implémentation de l'IA dans le développement échoue non pas à cause du modèle, mais à cause du processus. Et c'est là que son ensemble de techniques met vraiment le doigt sur le problème.
La première chose que j'ai notée, c'est l'utilisation de /grill-me avant le Plan Mode. Essentiellement, je ne vois pas cela comme un « prompt secret », mais comme un mode de validation stricte de la tâche. Je constate souvent que les assistants de code sont trop prompts à accepter, pour ensuite propager des hypothèses incorrectes tout au long du processus.
/grill-me est efficace car il force l'IA à argumenter, à trouver des failles et à clarifier les contraintes et les cas limites avant de commencer à écrire un plan ou du code. Pour le développement en conditions réelles, c'est moins coûteux que de devoir corriger plus tard une implémentation joliment formatée mais défectueuse.
Le deuxième point fort qui m'a fait hocher la tête presque automatiquement, c'est le TDD comme strict minimum. Pas comme une idéologie pour l'idéologie, mais comme une assurance contre les fantaisies du modèle. Si je force l'assistant à formaliser d'abord le comportement avec un test, il « crée » moins et respecte mieux le contrat.
Un autre modèle utile discuté était /domain-model. La description ressemble à un résumé concis du modèle de domaine, accumulant les connaissances dans CONTEXT.md et des ADR. J'aime cette approche pour sa retenue : pas de sanctuaire DDD énorme, mais un enregistrement des décisions pour que la passe suivante de l'IA ne commence pas avec une amnésie.
Et oui, je ne considérerais pas non plus /improve-codebase-architecture comme un bouton magique. C'est plutôt un moyen de guider l'assistant dans une revue architecturale, mais je ne confierais toujours pas entièrement la conception des interfaces à une machine. Plus l'interface est simple, moins le modèle a de chances de l'« optimiser » en un monstre.
L'impact sur le business et l'automatisation
Pour les équipes, la conclusion pratique ici est très terre-à-terre. Les gagnants sont ceux qui construisent l'automatisation avec l'IA autour de vérifications, de tests et d'un contexte explicite. Les perdants sont ceux qui demandent de « faire joli » et s'étonnent ensuite de la complexité superflue.
Le deuxième effet que je constate chez les clients est une économie sur les remaniements. Lorsque le modèle de domaine et les décisions architecturales sont documentés de manière concise, l'intégration de l'IA dans le pipeline devient plus stable : moins d'explications répétées, moins de dérive des décisions entre les itérations.
Et la conclusion principale ne me semble pas du tout alarmante pour les développeurs. Non, cela ne ressemble pas à « l'IA va remplacer tout le monde ». Cela ressemble à un amplificateur pour ceux qui savent poser des limites, pas à un substitut à la pensée d'ingénieur.
Si votre équipe écrit déjà du code avec Claude, Cursor ou des outils similaires, mais que les résultats varient d'excellents à étranges, je commencerais par des garde-fous comme ceux-ci. Et si vous voulez intégrer cela dans un flux de travail approprié sans improvisation, chez Nahornyi AI Lab, nous aidons à structurer l'automatisation par IA pour que l'entreprise obtienne une vélocité prévisible, et non une nouvelle source de chaos.