On clôture cette série avec la question qui récolte le plus d'avis style LinkedIn : vers où va le développement agentique ?

La plupart de ce que je lis là-dessus est soit dithyrambique (« l'IA aura écrit tout le code d'ici 2027 ») soit balayant (« ça va plafonner et tout ira bien »). Les deux passent à côté.

Voici ma lecture posée après un an à faire tourner Claude Code sur de vraies codebases — sur quoi je parierais, sur quoi je ne parierais pas, et la ligne au-delà de laquelle je deviens sceptique du hype.

Sur quoi je parierais

1. Le multi-agent devient ambient

Aujourd'hui vous appelez les sub-agents explicitement. D'ici fin 2026, le dispatch se fait automatiquement : vous énoncez l'objectif, l'orchestrateur choisit le bon spécialiste, lance le pipeline, vous remet un diff.

Niveau de pari : haut. La plomberie existe déjà ; il manque le travail UX.

2. Le contexte « codebase-aware » prend un ordre de grandeur

Aujourd'hui Claude Code lit les fichiers nécessaires au runtime. La prochaine itération est la mémoire persistante de la codebase : un index vectoriel de votre code que l'agent interroge avant de lire quoi que ce soit. Ça existe déjà en recherche ; c'est un problème de déploiement, pas de science.

Implication : les prompts raccourcissent. Vous arrêtez de dire « regarde lib/cache.ts ». L'agent sait déjà.

3. Les hooks deviennent la CI de l'équipe

Le système de hooks de l'article 11 est un aperçu de la suite. Sous 18 mois, votre .claude/hooks/ ressemblera plus à .github/workflows/ qu'à des scripts personnels. Le déterminisme autour de l'agent sera l'endroit où vit la culture d'ingénierie de l'équipe.

4. Les « personas d'agent » deviennent un concept de recrutement

Ça sonne dystopique ; suivez-moi. Quand code-reviewer.md est versionné dans git et revu en PR, vous commencez à le traiter comme un coéquipier — versionné, owned, évalué. Les offres d'emploi listeront « vous co-écrirez la persona d'agent reviewer de l'équipe » comme elles listent « vous owniez notre infra ».

Ce n'est pas l'agent qui remplace l'ingénieur. C'est l'expertise de l'ingénieur qui se codifie et s'amortit.

Sur quoi je ne parierais PAS

1. « Les agents remplacent les ingénieurs » d'ici 2027

Le titre est faux à deux niveaux.

D'abord, un agent sans humain dans la boucle sur les actions irréversibles n'est pas une feature ; c'est une responsabilité. Le rayon d'explosion d'automatiser git push sur main est supérieur à n'importe quel gain de productivité.

Ensuite, ce que les ingénieurs font réellement — design, goût, communication, décider quoi construire — c'est exactement ce sur quoi les agents sont les pires. Le marché de l'ingénieur ne rétrécit pas. Il change de forme.

2. La démo « tout faire depuis un seul méga-prompt »

Vous en voyez chaque semaine sur Twitter. Quelqu'un montre un agent qui construit un SaaS en 15 minutes. C'est une démo. Ce n'est pas un workflow.

Les vraies codebases ont :

• Des contraintes qui ne sont pas dans le prompt.
• Des stakeholders avec des opinions.
• Du code existant qui ne suit pas les patterns préférés de l'agent.
• Des coûts de l'erreur.

Une démo de SaaS en 15 minutes, c'est ce à quoi contourner tout cela ressemble. Ne calquez pas votre travail là-dessus.

3. La « PR factory entièrement autonome »

Je suis haussier sur le pattern PR factory de l'article 7. Je suis baissier sur sa version entièrement autonome — c'est-à-dire sans humain entre l'intention et le merge.

La raison est simple : quelqu'un doit owner le jugement. « Est-ce le bon design ? » « Faut-il retarder pour la revue sécurité ? » « Est-ce cohérent avec la roadmap ? » Ces décisions ne se délèguent pas. Elles sont le travail.

La ligne où je deviens sceptique

Quand on me dit que les agents vont « planifier », « ressentir » ou « comprendre » — c'est là que j'arrête de hocher la tête.

Ce que les agents actuels (Claude Code inclus) font extraordinairement bien :

• Pattern-match contre une vaste base de code antérieure.
• Exécuter des boucles structurées.
• Résumer de longs contextes.
• Traduire des objectifs en commandes quand les contraintes sont explicites.

Ce qu'ils ne font pas, et pour quoi il n'y a aucune raison d'ingénierie de présumer qu'ils le feront bientôt :

• Tenir une théorie de ce à quoi sert la codebase.
• Pousser back contre une mauvaise décision produit.
• Dire « non, on ne devrait pas construire ça ».

Une formulation plus honnête de l'avenir proche du coding agentique :

La compétence qui compose

Si je devais choisir une seule compétence dans laquelle investir pour 2026 en tant qu'ingénieur en exercice :

Spécifier les problèmes assez précisément pour qu'un agent puisse les résoudre.

C'est le prompt en quatre parties de l'article 3. C'est CLAUDE.md. C'est .claude/agents/code-reviewer.md. C'est le bloc rules, le schéma de sortie, les contre-exemples.

Ce n'est pas du « prompt engineering » au sens chat-avec-l'IA. C'est de l'ingénierie de spécification — la même compétence qui a toujours séparé les seniors des juniors, mais avec un plafond de levier plus haut que jamais.

Les ingénieurs qui livrent cette compétence se multiplient avec l'agent. Ceux qui ne le font pas auront du mal à expliquer pourquoi leurs PR prennent une semaine.

Comment garder cette série utile

Vous avez fini 12 articles. Voici ce que je ferais cette semaine :

1. Choisissez un ticket sur votre projet courant et livrez-le avec le prompt en quatre parties + l'agent code-reviewer. Un seul.
2. Committez .claude/CLAUDE.md, même si ça fait 10 lignes.
3. Ajoutez deux sub-agents : code-reviewer et test-writer. Volez les templates de l'article 5.
4. Lancez /compact une fois. Prenez le réflexe.
5. Repérez ce qui paraît lourd. C'est votre prochaine commande custom.

Six étapes. Deux heures. La composition commence dès le jour un.

Pour clore

J'ai ouvert cette série par une attaque délibérément cinglante : la plupart des développeurs utilisent le mauvais outil IA pour le mauvais job. Douze articles plus tard, la reformulation plus honnête est :

La plupart des développeurs utilisent les outils IA à 5 % de leur levier parce que personne ne leur a appris à quoi ressemblent 100 %.

Cet écart se referme à l'instant où vous traitez Claude Code comme de l'infrastructure : .claude/ partagé, sub-agents bornés, hooks déterministes, template de prompt en quatre parties, piste d'audit.

Faites ça pendant un trimestre. Regardez les chiffres de vélocité. Décidez vous-même si c'était du hype.

Je parie que non.

---

Cela clôture Claude Code Mastery. La série recevra de petits updates au fil de l'évolution de l'outillage — gardez cette page en favoris. Si vous voulez parler de la façon de déployer ça sur votre codebase, je fais des consultations : voir le lien dans le footer.