Contexte technique
Je suis entièrement d'accord avec la formule brainstorm → spec → plan → implementation. Lorsque je fais une implémentation d'IA dans un développement réel, je ne demande presque jamais à Claude d'écrire toute la fonctionnalité d'un seul coup. À ce stade, le modèle ne comprend pas encore les limites de la tâche et commence à imaginer l'architecture à ma place.
D'abord, je l'utilise comme un collecteur de contexte. Je lui donne l'objectif de la fonctionnalité, des morceaux de l'architecture actuelle, les contraintes, les contrats d'API, les points litigieux et je lui demande de me retourner cela sous forme synthétique : ce qu'il a compris, ce qui manque, où sont les risques. Cette étape à elle seule évite la moitié des décisions étranges.
Ensuite, je ne me lance pas directement dans le code. Je demande une spécification (spec) : ce que nous changeons exactement, quels sont les non-objectifs, les critères d'acceptation, les cas limites, quels modules seront affectés. Si la spécification semble fragile, une nouvelle session n'aidera pas, car le problème n'est pas la fenêtre de contexte, mais le fait que la tâche n'est pas encore bien définie.
Après cela, je lui demande de développer la spec en un plan. Pas un plan abstrait du genre « faire le backend, puis le frontend », mais une véritable décomposition d'ingénierie : ordre des étapes, dépendances, fichiers, tests, migrations, risques de rollback. C'est seulement à partir de ce plan que je lance l'implémentation, généralement par petits morceaux.
J'ouvre souvent une nouvelle session, mais pas magiquement « pour générer du code », mais pour fixer une phase de travail propre. Dans une nouvelle session, je transmets la spec et le plan déjà épurés, ainsi que le contexte de code nécessaire. C'est bien mieux que de traîner un long va-et-vient où se mêlent idées, réfutations et impasses.
La délégation fonctionne aussi, mais pas en remplacement de la réflexion. Je peux demander à Claude de rassembler séparément les inconnues, de proposer une structure de spec, de vérifier les failles du plan. C'est-à-dire que je délègue des sous-tâches, pas la responsabilité de la solution d'ingénierie.
Impact sur l'entreprise et l'automatisation
En pratique, il y a trois avantages. Premièrement : moins de code inutile qu'il faudra jeter plus tard. Deuxièmement : il est plus facile d'estimer les délais, car le plan est déjà décomposé en étapes réelles. Troisièmement : il est plus facile de construire une automatisation avec l'IA dans une équipe où plusieurs personnes et assistants travaillent sur la même fonctionnalité.
Les équipes qui ont un contexte coûteux y gagnent : héritage, intégrations, logique non standard. Celles qui demandent encore au modèle de « créer un système complet » en une seule invite et s'étonnent ensuite que tout s'effondre lors de la revue sont perdantes.
Chez Nahornyi AI Lab, je résous précisément ce genre de problèmes pour les clients : je transforme un développement chaotique en un pipeline gérable où l'AI automation accélère les livraisons au lieu de créer de nouveaux risques. Si vos fonctionnalités sont noyées dans le contexte, examinons votre processus et construisons un schéma d'AI integration qui éliminera réellement le travail manuel superflu.