Agentic Engineering : comment je délègue des phases de dev entières à Claude Code
Agentic Coding au niveau phase : comment je délègue des phases de dev entières à Claude Code
La première fois qu'une délégation de phase a capoté sur moi, ça s'est fait en silence. Claude était en pleine implémentation, 40 minutes dedans, et j'ai réalisé que le résultat n'avait plus rien à voir avec la spec. Pas une hallucination. Pas un bug. La spec avait simplement dérivé hors de la context window active. Au moment où l'agent a eu besoin de s'y référer, le modèle travaillait à partir d'une reconstruction dégradée de mon intention initiale.
C'est le context rot. Un event de compaction où le LLM perd la spec à mesure que la session grandit, et ce n'est pas un problème de prompt engineering. C'est une propriété structurelle de la façon dont fonctionnent les large language models. Cet incident a complètement changé ma façon d'architecturer mes systèmes d'agentic coding.
Le mental model qui marche vraiment
La plupart des devs qui utilisent Claude Code font de la délégation au niveau task : « écris cette fonction », « fix ce test », « refactore ce composant ». Utile. Mais ce n'est pas de l'agentic engineering.
Le shift (et il m'a fallu plus de temps que je voudrais l'admettre) c'est de task à phase. Une phase est une unité de travail avec un état final défini, des critères de sortie vérifiables par machine, et une context window bornée. Le boulot du dev devient d'écrire le brief. Le boulot de l'agent est de porter la phase.
Des recherches sur les patterns de supervision humaine dans les systèmes agentic ont trouvé quelque chose de contre-intuitif : plus la task est complexe, moins la supervision step-by-step devient tenable. Pas parce que les devs font plus confiance aux agents sur les problèmes durs, mais parce que superviser une phase complexe à cette granularité tue le but même de la délégation. Tu ne peux pas surveiller chaque écriture de fichier dans une implémentation à 40 étapes. Le système doit être conçu pour que tu n'aies pas besoin de le faire.
C'est l'argument empirique pour l'ownership au niveau phase. Pas une philosophie, juste une conséquence de la façon dont le travail agentic complexe se déroule réellement.
Ce que contient vraiment un brief de phase
Un brief de phase, ce n'est pas un ticket Jira. Ce n'est pas une liste de tasks. C'est une description du monde après que la phase est terminée, plus les conditions qu'une machine peut vérifier pour confirmer qu'on est bien arrivé.
Quatre composants, non négociables :
Description de l'état final. À quoi ressemble la codebase quand cette phase est finie ? Pas « implémente l'auth », mais « le module auth exporte signIn, signOut, et refreshToken, tous couverts par des tests d'intégration qui tapent une vraie base de données. »
Critères de sortie vérifiables par machine. TypeScript compile. Les tests passent. Zéro erreur de lint. Ce ne sont pas des nice-to-haves, ce sont les conditions d'arrêt de l'agent. Sans eux, la boucle ne sait pas quand elle a fini.
Contraintes. Ce que l'agent ne doit pas explicitement toucher. Scope d'accès aux fichiers. Quels packages sont déjà installés. Quelles interfaces il ne doit pas casser.
Niveau d'accès. Read-only pour les phases d'exploration. Read-write pour l'implémentation. Les agents d'orchestration reçoivent des rapports structurés des sub-agents, ils n'écrivent pas de fichiers directement.
Dans le pipeline NEXUS-Micro, cette séparation est explicite. Les agents PM produisent une spec structurée ; les agents Dev implémentent à partir de cette spec, scopés à des modules spécifiques ; les agents QA vérifient sans toucher à ce qu'ils valident. Trois rôles, zéro chevauchement.
La spec, c'est ce qui steer l'agent. Une spec tight tourne proprement. Une spec vague coûte des heures de back-and-forth, ou pire, produit un output qui a l'air correct jusqu'à ce qu'il tape l'edge case que tu as oublié de définir.
Tu montes ton propre pipeline de délégation de phase et tu tapes des murs ? Je consulte des équipes d'engineering sur les workflows agentic qui ship vraiment. L'architecture du brief, c'est en général là que ça casse. On en parle.
Les trois modes d'échec en agentic coding
Chaque échec de délégation de phase que j'ai vu remonte au brief, pas au modèle.
Spec drift. La spec change en pleine implémentation, une requirement se clarifie en conversation, un edge case apparaît, une dépendance casse, et il n'y a pas de checkpoint pour updater le brief. L'agent continue de tourner contre une spec qui ne reflète plus l'intention. Fix : traite le brief comme immutable au sein d'une phase. Si la spec doit changer, stoppe la phase, update le brief, redémarre.
Context collapse. C'est le problème de context rot. Les longues sessions dégradent la mémoire de travail du modèle sur la spec. La solution est architecturale : des context windows indépendantes par phase. Pas une seule session où tu refiles tout le projet, mais une context fraîche par phase, avec le brief injecté au départ. Dans mon setup, l'approche Ralph Loop en bash marche mieux que le plugin exactement pour cette raison. Chaque itération prend une window propre. Pas de bleed de session. L'approche plugin introduit un overhead de session qui s'accumule sur les longues runs. Le consensus s'est posé sur des contexts indépendants en bash comme plus fiable que « tourner à l'infini dans une seule session ».
Missing exit criteria. L'agent ne sait pas quand s'arrêter, donc soit il termine trop tôt (implémentation partielle, aucun signal que quelque chose ne va pas), soit il loop à l'infini. Les critères vérifiables par machine sont la condition d'arrêt. Si npm test passe et que TypeScript compile, la phase est finie.
Le pattern Ralph Loop formalise les trois : le Generator produit un output, le Judge valide contre des critères explicites, la boucle termine quand les critères passent. Le détail critique, c'est que le Judge est du tooling externe, pas un prompt d'auto-évaluation. Un agent qui check son propre travail va le trouver acceptable. Ce n'est pas un flaw du modèle ; c'est une propriété prévisible de tout système à qui on demande de se noter lui-même.
Ce que l'agentic coding te demande vraiment
Le output quotidien du dev se déplace presque entièrement sur l'écriture de briefs. Ça ressemble à une rétrogradation. En pratique, c'est l'inverse.
Écrire un brief tight demande de comprendre le problème assez profondément pour décrire l'état final précisément. Tu dois savoir quels critères vérifiables par machine existent. Tu dois anticiper ce dont l'agent aura besoin et ce dont il doit rester éloigné. Tu ne peux pas écrire un bon brief de phase pour un travail que tu ne comprends pas.
Ce qui disparaît : l'implémentation mécanique. Le boilerplate. La quatrième itération du même pattern CRUD. Les generics TypeScript que tu as écrits cent fois. L'agent porte ça. Tu portes l'architecture de ce qui est construit, le graphe des phases, l'ordre des dépendances, les conditions de sortie.
L'erreur que je vois faire les teams, c'est d'essayer de déléguer des phases sans restructurer le projet d'abord. La structure du repo détermine l'essentiel de l'efficacité de l'agent. Du nommage cohérent, des frontières de module logiques, des interfaces propres entre packages, un CLAUDE.md qui donne à l'agent son point d'entrée dans la codebase. Une codebase confuse produit un output confus. Aucune écriture de brief ne fixe un repo où l'agent continue de taper des impasses et de demander des clarifications en boucle.
Le travail est en amont. Structure la codebase. Écris le brief. Définis les critères de sortie. Puis recule et laisse la phase tourner.
La partie dont personne ne parle
Le shift de dev assistée par IA à dev pilotée par IA n'est pas un upgrade d'outil. C'est une restructuration de la façon dont un projet est conçu. Le graphe de dépendances entre phases, les frontières entre ce qu'un agent peut porter et ce qui demande une décision humaine, les critères qui terminent une phase, tout ça doit être conçu explicitement.
La plupart des échecs de délégation de phase ne sont pas des échecs de modèle. Ce sont des échecs de design. Le brief était vague. La context window n'était pas isolée. L'agent QA était dans la même session que l'agent d'implémentation. Les critères de sortie étaient subjectifs.
Le modèle est prêt. La question, c'est de savoir si le pipeline l'est.
J'ouvre quelques slots de consulting pour des teams prêtes à passer de dev assistée par IA à dev pilotée par IA. Si tu veux monter le genre de pipeline décrit ici, on en parle.
Apprenez le workflow agentic coding que j'utilise en production
Comment je structure mes repos, gère le contexte, et fais tourner des agents en production. Écrit pour que vous puissiez faire pareil.