100 % du code écrit par des agents : six mois sur une refonte greenfield

---

Depuis mars, mon équipe construit Solstice, une plateforme greenfield partie d'une page blanche. En quatre mois, on a moins écrit du code qu'on n'a réécrit notre façon d'en produire : un cadrage par service, des agents qui tiennent chacun leur périmètre, un point de contrôle qui rend son verdict avant qu'un humain ne lise le diff. C'est cette méthode que je viens raconter — comment elle s'est mise en place, et ce qu'elle a produit.

Il y a six mois, j'écrivais des prédictions depuis l'intérieur de cette équipe, sans presque rien d'externe pour les appuyer. Aujourd'hui, les études sont sorties, et elles confirment les paris.

L'escalier des six mois

Le paradigme n'est pas arrivé d'un coup. Il a monté marche par marche : un modèle de pointe toutes les quelques semaines, chacun un peu plus autonome que le précédent. Et en dessous, le discours commercial a glissé de la puissance brute vers la fiabilité.

Reprenons la chronologie, de gauche à droite :

• Janvier. METR met à jour sa recherche Time Horizon : la durée de tâche qu'un agent termine une fois sur deux double désormais tous les quatre mois environ, contre sept auparavant. Oubliez le chiffre exact — c'est la forme qui compte, et la forme monte, vite.
• Février. Opus 4.6 sort le 5. Trois semaines plus tard, OpenAI arrête de publier ses scores SWE-bench Verified : le benchmark « ne mesure plus les capacités de pointe », et à l'audit, la majorité d'un échantillon de tâches échouées avait en réalité des tests cassés. Le benchmark que tout le monde citait vient d'être enterré par un de ceux qui le citaient.
• Avril. Deux sorties dans la même semaine : Opus 4.7 le 16, GPT-5.5 le 23 — six semaines après GPT-5.4, et OpenAI s'en vante. Et l'argument de vente d'Opus 4.7 n'est pas la puissance. C'est la rigueur : le modèle conçoit ses propres étapes de vérification avant de déclarer une tâche terminée. L'auto-contrôle est devenu une fonctionnalité qu'on achète.
• Mai. Opus 4.8 le 28. Anthropic affirme qu'il laisse passer quatre fois moins de défauts dans son propre code que 4.7 — un chiffre d'éditeur, certes, mais le choix du chiffre dit tout : plus personne ne vend de la génération, on vend du contrôle. Et avec lui, les « dynamic workflows » de Claude Code : un script rejouable qui répartit le travail sur jusqu'à mille agents par exécution, une quinzaine à la fois, sans noyer le contexte du modèle. Ma méthode de panel de personas, devenue un produit. Le même mois, le protocole MCP passe stateless — une flotte d'agents, c'est désormais un problème de load-balancer, pas une démo.
• Juin. Fable 5 le 9, Sonnet 5 le 30 — la cadence ne ralentit pas. Pendant ce temps, la revue de code reçoit enfin ses chiffres. J'y viens.
• Juillet. GPT-5.6 le 9, et la plus grande étude en entreprise du semestre : un beau chiffre de débit, avec une étiquette d'avertissement collée dessus. Puis, le 16 — le lendemain du gel de ces compteurs —, Moonshot sort Kimi K3 : 2 800 milliards de paramètres, une fenêtre de contexte d'un million de tokens, des poids ouverts, et une variante Swarm Max conçue exprès pour faire tourner des agents en parallèle. Sur ses propres benchmarks, il se hisse au niveau de la frontière propriétaire ; prenez les scores avec les pincettes d'usage, mais c'est la direction qui compte — la capacité de pointe passe en open-weight, et se façonne pour les flottes.

Voilà pour les marches. Regardez maintenant la ligne pointillée sous l'escalier — le gain réellement mesuré sur le code que la plupart d'entre nous maintiennent. Elle bouge à peine. Tout cet article tient dans la distance entre les deux.

Le terrain : Solstice, quatre mois au compteur

Cette série cite « mon équipe » depuis six mois sans jamais ouvrir les compteurs. Corrigeons ça aussi. Depuis mars, mon quotidien a un nom de code : Solstice* — une plateforme greenfield, premier commit le 10 mars, qui fusionne deux suites produit santé historiques dans une seule base de code TypeScript neuve. Quatre mois plus tard : une trentaine de microservices backend, une poignée de micro-frontends, environ 600 000 lignes réparties sur quelque 5 000 fichiers. Du greenfield avec une réserve qui mérite d'être nommée — le code est neuf, le domaine ne l'est pas. De la santé régulée, des données patients, et deux suites legacy de contrats implicites à honorer.

Il faut raconter d'où vient ce projet, parce que sa naissance est le meilleur exemple du semestre. La gestion administrative du patient et le parcours patient tournaient sur deux socles historiques — l'un dans un langage de quatrième génération propriétaire des années 90, l'autre dans une stack de l'ère du client lourd : des technologies où chaque évolution réglementaire se bat contre le code, et où recruter est devenu une cause perdue. Le dilemme refactor-contre-rewrite traînait sur la table depuis des années, et il penchait toujours du même côté : une refonte, c'était trop cher, trop risqué, une double exploitation à financer. L'IA agentique a renversé l'arbitrage début 2026 — vélocité démultipliée, un écran prototypé en heures plutôt qu'en semaines et validé avec le métier avant toute ligne de code de production, la conformité codifiée en garde-fous CI bloquants : identitovigilance, accessibilité, auditabilité. Le coût et le risque de la refonte se sont effondrés ensemble. Solstice n'est pas un projet qui utilise des agents. C'est un projet qui n'existerait pas sans eux.

Le socle choisi dit la même chose : des micro-frontends React derrière un design system, des microservices Fastify/TypeScript, PostgreSQL partout, FHIR R4 comme modèle de données pivot, Docker, OpenTelemetry, CI/CD GitHub Actions. Rien d'exotique — et c'est délibéré. Une stack que les modèles connaissent par cœur est une stack sur laquelle les agents tournent à pleine vitesse.

« Choisir une technologie, c'est désormais une décision de recrutement pour vos agents autant que pour vos humains. »

Voici les compteurs, arrêtés au 15 juillet :

• ~4 500 commits en quatre mois — environ 35 par jour. Près de 1 000 pull requests, 120 et quelques versions taguées, plus de 500 déploiements. Le pic de mai — près de 1 800 commits — n'est pas une anomalie : c'est le mois où la réécriture du frontend s'est exécutée comme un pipeline.
• Une réécriture complète, en vol. Un architecture decision record a acté l'abandon de Vue pour React. Quatre mois plus tard : plus de 300 fichiers .tsx, zéro .vue restant. Ce genre de migration, avant, c'était un projet d'un an avec son propre comité de pilotage. Là, c'est un chantier d'agents mené sur des centaines de fichiers, borné par les tests, fusionné par des humains.
• L'infrastructure d'autonomie. Une cinquantaine d'architecture decision records, une quarantaine de CLAUDE.md — un par service et micro-frontend —, une quarantaine de skills, quelque 250 documents. Près d'une ligne de Markdown pour cinq lignes de code. C'est le contexte qu'on injecte aux agents pour qu'ils tiennent un périmètre sans nous. On ne documente plus seulement pour les humains. On documente pour les flottes.
• La taxe, rendue exécutable. Plus de 600 fichiers de test, une vingtaine de specs E2E sur les parcours critiques, et un point de contrôle qui rend un verdict PASS/FAIL avant même qu'une PR existe. La taxe de vérification que cette série n'arrête pas de nommer n'est plus un concept de billet de blog — c'est un binaire dans la CI.

Et le fait qui compte le plus, dit sans détour : ce code est écrit à 100 % par des agents. Pas « assisté », pas « autocomplété » — écrit. Plus aucun humain de ce projet ne tape de code de production — et l'affirmation ne repose pas sur la confiance mais sur le workflow : chaque changement entre dans le dépôt par une PR ouverte par un agent. Les signatures de commits portent pourtant des noms humains, parce qu'une signature ne dit plus qui a écrit le changement ; elle dit qui l'a spécifié, qui a orchestré la flotte et qui a vérifié le résultat.

« En 2026, une signature de commit est une chaîne de responsabilité, et non plus une signature d'auteur. »

Diagnostic contre arithmétique, comme toujours : ces chiffres mesurent du débit, pas de la valeur — la métrique dont Microsoft nous prévient qu'elle gonfle — et ce sont des chiffres greenfield, le terrain où la recherche de Stanford accorde déjà 30 à 40 % aux agents. Je revendique de la vélocité sur une base de code jeune, rien de plus. L'intéressant n'est pas le compteur brut. C'est ce qu'il a fallu construire pour y arriver.

Quatre mois pour redéfinir la méthode

Parce que rien de cette vélocité n'est venu d'un modèle devenu plus malin tout seul. Une équipe d'une vingtaine de personnes n'y arrive pas en achetant des licences. On a réécrit la méthode morceau par morceau, tout en livrant. Voici ce qui a réellement changé chez nous entre mars et juillet.

Le besoin d'abord, le prototype en heures. L'ancienne méthode spécifiait pendant des semaines avant que quiconque ne code. La nouvelle inverse l'ordre : immersion terrain, parcours co-conçus avec le métier, puis un prototype fonctionnel produit en heures par les agents — et mis devant les utilisateurs avant d'industrialiser quoi que ce soit. On ne débat plus sur des maquettes. On tranche sur du cliquable.

Tout ce qui se décide s'écrit, parce que tout ce qui s'écrit devient du contexte. Une cinquantaine d'architecture decision records en quatre mois, un cadrage par service, un glossaire du domaine, une quarantaine de skills pour les gestes répétés. La documentation a changé de nature : ce n'est plus un livrable qui vieillit, c'est le carburant des flottes. Une décision mal écrite, c'est une flotte qui code à côté. Près d'une ligne de Markdown pour cinq lignes de code — le meilleur investissement du projet.

La machine dit non avant que l'humain ne lise. Le point de contrôle rend un verdict PASS ou FAIL avant même qu'une PR existe ; la revue humaine ne commence que quand la machine a dit oui. Et l'architecture elle-même sert la méthode : les microservices et les micro-frontends sont des périmètres bornés qu'un agent peut tenir seul, sans marcher sur le travail des autres.

L'outillage s'entretient lui-même. La CI qui se répare, les specs E2E générées puis maintenues sur les parcours critiques, les cadrages tenus à jour par les agents mêmes qui les consomment. Le temps d'outillage était un impôt. C'est devenu des intérêts composés.

Et le rituel humain qui porte tout : le partage de pratiques. Presque chaque semaine, l'équipe s'assoit pour partager ce qu'elle a appris du travail avec les agents — une quinzaine de comptes-rendus en quatre mois. Ce qui marche devient un skill. Ce qui engage l'architecture devient un decision record. C'est la boucle d'apprentissage la plus rapide que j'aie vue dans ma carrière, et elle ne doit rien aux modèles.

Et cette vélocité a une échéance, pas seulement un compteur : un premier MVP de préadmission déployé en octobre 2026, le workflow complet début 2027, la couverture intégrale du périmètre legacy en 2028. Deux ans pour remplacer deux socles historiques. Avant les agents, personne n'aurait signé ce planning — c'est précisément pour ça que la refonte n'avait jamais été lancée.

Le bulletin de notes

Quatre paris, six mois de données. Voici la copie corrigée.

Le pari (mars–mai)	Note	Pourquoi
Le SDLC est mort	Tient, amendé	La cérémonie est morte ; un point de contrôle est né. Le processus n'a pas rétréci — son centre de gravité est passé de l'écriture à la revue.
L'IA est un amplificateur	Confirmé	Débit en hausse en surface, coûts qualité qui se composent en dessous. Le MIT : 95 % des pilotes d'IA générative sans impact mesurable sur le P&L — chiffre contesté ; gardez la direction, pas la décimale. L'outil amplifie le système autour — exactement le pari, et la lecture posée dans mon article sur DORA.
Il existe une taxe de vérification	Confirmé, chiffré	Temps de revue et attente en file en forte hausse (Faros, LinearB) ; délégation complète encore l'exception — 0 à 20 % des tâches selon les études ; l'auto-contrôle désormais vendu comme fonctionnalité.
Le codeur devient ingénieur	Confirmé	Le travail de pointe du semestre, c'est l'orchestration — écrire le harnais, câbler les outils, noter les agents. Pas taper de la syntaxe.

Le plafond que personne ne vous vend

Si la remontée se fait attendre, ce n'est pas que les modèles manquent d'intelligence. C'est de l'arithmétique. Un agent fiable à 95 % à chaque étape termine une tâche de vingt étapes un peu plus d'une fois sur trois. Une tâche de cinquante étapes ? Sept fois sur cent. Les erreurs se multiplient entre elles, l'autonomie longue s'effondre bien en dessous de la démo, et la seule chose entre cet effondrement et votre branche de production s'appelle la vérification. Les travaux sur le « context rot » montrent le même phénomène côté mémoire : passé quelques centaines de milliers de tokens, les modèles se dégradent en silence.

Et puis un coût est apparu qu'aucun de mes paris de mars n'avait prévu : la sécurité. L'injection de prompt se discute maintenant comme une propriété permanente des agents, pas comme un bug en attente de correctif. Des CVE sévères ont touché les outils que nous utilisons tous les jours. Anthropic a même révélé qu'un groupe lié à un État avait détourné des instances de Claude Code pour de l'espionnage quasi autonome. La cérémonie du SDLC est bien morte — ce qui naît à sa place, c'est une discipline : provenance, sandboxing, vérification d'agents. Ce n'est pas un démenti de la série. C'est le point de contrôle que l'ancien processus aurait dû être depuis le début.

Ce qu'on délègue en juillet

La question pratique qu'on me pose partout : concrètement, qu'est-ce qu'un agent fait seul en juillet 2026 qu'il ne faisait pas en janvier ? Réponse depuis Solstice, périmètre par périmètre.

En janvier, un agent complétait une fonction et rédigeait un test si on le lui demandait poliment. La PR d'agent était une démo qu'on montrait, pas un flux qu'on vivait.

En avril-mai, avec l'auto-vérification puis les flottes de sous-agents, on est passé de déléguer une fonction à déléguer un chantier entier : notre réécriture React s'est faite comme ça — un pipeline d'agents sur des centaines de fichiers, chaque lot borné par les tests existants, un humain à la fusion. Les ~1 800 commits de mai, c'est ça, rendu visible.

En juillet, voilà ce qui part seul, sur notre dépôt, sans qu'un humain écrive une ligne :

1. La PR de périmètre borné, de bout en bout. Ticket → branche → code → tests → verdict de vérification → PR ouverte. L'humain n'apparaît qu'à la revue. Condition non négociable : le périmètre a son CLAUDE.md, ses skills, et le point de contrôle donne son feu vert.
2. La CI qui se répare elle-même. Collisions de noms de conteneurs, environnements de déploiement qui dérivent : les agents corrigent désormais leur propre tuyauterie. Impensable en janvier — personne n'aurait laissé un agent approcher le pipeline.
3. Les specs E2E sur les parcours critiques. Du front jusqu'au back, générées puis maintenues. Une vingtaine aujourd'hui, et sans doute bien plus dans quelques semaines ou mois.
4. La documentation d'où part le code. C'est plutôt l'inverse : la doc vient d'abord. Elle naît des ateliers et des sachants, captée depuis les transcriptions, puis transformée en cadrages, en ADR, en CLAUDE.md par service — et c'est elle qui cadre le code que les agents écrivent ensuite. La doc n'est plus une trace laissée après coup ; c'est la source dont tout part.

Et ce qui ne part toujours pas seul, même en juillet : l'architecture — les quelque cinquante ADR sont des décisions d'humains, à commencer par celles qui bornent ce que les agents ont le droit de toucher. Le masquage de l'identifiant patient sur nos écrans est passé par une enveloppe ADR avant qu'une seule ligne écrite par un agent ne l'approche. La barre que la fusion doit franchir, toujours — le clic, lui, s'automatise déjà. Et le découpage lui-même : c'est l'humain qui trace les périmètres, jamais l'agent qui s'en attribue un.

« L'autonomie ne se décrète pas au niveau du modèle. Elle s'équipe, périmètre par périmètre — un cadrage, des skills, un point de contrôle qui sait dire non. »

C'est ma lecture du semestre, vue du terrain : chaque marche de l'escalier ne rend pas l'agent plus intelligent, elle élargit ce qu'on ose lui confier. Une fonction en janvier, un chantier en mai, un flux en juillet — la vitesse à laquelle grossit ce périmètre, voilà la vraie mesure de l'autonomie. Pas les benchmarks.

L'échelle que quelqu'un a enfin chiffrée

À mi-chemin de ce billet, Boris Cherny — l'auteur de Claude Code — a publié une échelle qui met des chiffres sur ce que j'appelle depuis le début « l'unité de délégation qui s'élargit ». Cinq échelons, comptés en agents par ingénieur : bloqué (0), assisté (un agent, une paire supervisée), parallèle (une dizaine, un orchestrateur qui saute d'un worktree à l'autre), autonomie supervisée (une centaine, un manager de managers), IA-native (mille et plus, on pilote à la seule intention). C'est la carte la plus nette que j'aie lue de cette montée — et, venant d'un éditeur, chaque échelon arrive avec un produit vissé dessus. Gardez l'échelle. Oubliez le catalogue.

Parce que ce qu'il faut garder, c'est la thèse, et c'est celle autour de laquelle cette série tourne depuis six mois : les tokens ne vous font pas monter. Les mots de Cherny : pour atteindre l'échelon suivant, il faut « trouver et démonter le prochain lot de goulots d'étranglement, et construire le prochain lot de garde-fous ». C'est notre taxe de vérification transformée en échelle à gravir — chaque échelon s'achète avec un garde-fou, pas avec un budget plus gros. Il livre même le test de valeur que je cherche à tâtons depuis des mois : un tableau de bord d'usage mesure l'activité, pas le retour ; la vraie question, c'est de savoir si vous auriez dépensé ces heures d'ingénierie de toute façon, et ce qu'elles auraient coûté en heures-homme. Voilà une règle que je peux enfin poser sur Solstice.

Alors je réponds à sa question de clôture — où en est votre équipe ? Échelon deux, honnêtement : l'orchestrateur, cinq à dix agents à la fois, chacun sur son périmètre, un humain qui relit des diffs finaux plutôt que des frappes clavier. Sur les périmètres balisés où le point de contrôle a gagné notre confiance, on mord sur l'échelon trois — du travail qui se déclenche seul, de la maintenance qui attendait un après-midi libre et qui tourne désormais en fond, précisément là où Cherny situe le vrai gain : l'équipe cesse d'éteindre des incendies et construit des choses hors de portée jusque-là. On est très loin du sommet à mille agents, et je me méfie de quiconque prétend y être : c'est là que l'échelle cesse d'être un modèle de maturité pour devenir une diapo de feuille de route.

La phrase de son billet que je soulignerais est la plus humble : « il n'y a pas un seul bon chemin à travers les étapes ». Le piège qu'il nomme — faire grossir le nombre d'agents avant que la boucle ait gagné la confiance — c'est exactement le danger que cette série répète, écrit cette fois depuis le côté éditeur de la table. Même point de contrôle, même taxe ; on l'aborde juste par les deux bouts.

Ce qui reste aux humains

Comme dans chaque article de cette série, la liste honnête. Six mois de progrès ne nous ont déchargés de rien de ce qui suit.

Définir ce que « sûr à fusionner » veut dire. C'est la taxe, et elle n'a pas baissé — elle a grossi, et elle est passée en tête du pipeline. Sur notre dépôt, le point de contrôle dit « non » avant même qu'un humain ne lise le diff. Le clic de fusion lui-même est le prochain à disparaître : à mesure que s'empilent les contrôles automatisés et les garde-fous, les PR fusionneront bientôt seules dès que le point de contrôle est au vert. Ce qui reste humain, ce n'est pas le clic — c'est de fixer la barre que le contrôle applique. Ce jugement, c'est le métier maintenant.

Garder les gens. Klarna — la fintech qui avait remplacé à grand bruit une bonne partie de son support par de l'IA — a passé l'année à reconstruire discrètement la capacité humaine qu'elle avait coupée, après une chute de qualité. L'argument financier n'a pas changé : la valeur s'est déplacée vers les humains capables de spécifier, d'orchestrer et de vérifier des flottes d'agents. Licenciez-les, et vous supprimez votre propre retour sur investissement — juste là où la taxe mord le plus fort. Dans mon équipe, sur ces six mois, l'effectif a encore grandi. Personne n'a été remplacé par une machine.

Que faire lundi matin

Si vous dirigez une équipe et voulez tirer quelque chose de concret de ce point d'étape :

1. Budgétez la capacité de revue, pas seulement les licences. Si vos agents livrent plus de PR, quelqu'un relit plus de PR. Dotez et mesurez cette capacité avant de passer la génération à l'échelle, sinon la file d'attente devient votre vrai goulot.
2. Documentez pour les agents, pas seulement pour les humains. Un cadrage par service, un skill par geste répété, un glossaire du domaine. L'investissement le moins spectaculaire du semestre, et le plus rentable : chez nous, près d'une ligne de Markdown pour cinq lignes de code — et c'est elle qui rend la délégation possible.
3. Mesurez votre propre gain net sur de vrais tickets. Pas des démos greenfield — le code legacy que vous maintenez vraiment, reprise et revue déduites. Ce chiffre est le vôtre, et c'est le seul qui n'appartienne pas à un éditeur.
4. Gardez les lots petits. Le calcul d'erreur composée est impitoyable : des exécutions d'agent courtes avec des jalons de validation humaine battent une héroïque délégation de cinquante étapes, à tous les coups. Concevez pour la vérification, pas pour le théâtre de l'autonomie.
5. Traitez la sécurité des agents comme de la sécurité de production. Injection de prompt, permissions d'outils, provenance. Si un agent peut lancer une commande, supposez qu'une entrée hostile le peut aussi. Sandboxez en conséquence.
6. Enterrez vos benchmarks morts. Si OpenAI a lâché SWE-bench Verified, votre diapo interne « le modèle obtient X » est probablement périmée aussi. Faites confiance à la tendance et à votre propre dépôt — à rien de ce qui vient d'un classement.

Où en est la série

Il y a six mois, je prédisais depuis l'intérieur d'une équipe. Aujourd'hui, les modèles vérifient leur propre travail, les flottes sont devenues de l'infrastructure, et mon propre dépôt montre ce que quatre mois de développement en font sur une base de code jeune quand la méthode suit. Mes quatre paris sortent tous renforcés. Les agents ont gagné de l'horizon, pas une laisse plus courte. La portée est là. La fiabilité à cette portée se construit — version après version chez les éditeurs, contrôle après contrôle chez nous — et pour l'instant, ce travail est à nous.

Le prochain rendez-vous s'écrit tout seul : le jour où on confiera aux agents plus gros qu'un flux — quelque chose que j'hésite encore à nommer — je ressortirai ce bulletin. D'ici là : posez les rails, tenez le point de contrôle, et comptez vos propres chiffres.

Lire la suite de la série : Le SDLC est mort — pourquoi le processus a toujours été du gaspillage. Coder n'a jamais été le métier — ce que devient l'ingénieur quand la syntaxe disparaît. L'IA est devenue un réflexe d'équipe — à quoi ressemble une équipe IA-native un mardi. DORA vient de confirmer ce que mon équipe a déjà vécu — le rapport qui a mis des chiffres sur ce qu'on vivait déjà. Encore un prompt — la facture personnelle qui accompagne ce verdict professionnel. Le backlog n'a jamais été le métier — ce que ce basculement fait au rôle produit. La doctrine se capitalise. Les modèles, non. — pourquoi remplacer huit modèles en six mois n'a rien coûté. Les tests passent. Il ne se passe rien. — le défaut sans symptôme, et ce qui l'attrape à la place de la lecture.

---

Sources

• METR — Measuring AI Ability to Complete Long Tasks (Time Horizon 1.1) : le doublement de l'horizon de tâche à 50 % de fiabilité, environ tous les quatre mois.
• METR — Impact of Early-2025 AI on Experienced Open-Source Developer Productivity : l'essai randomisé qui a mesuré un ralentissement de 19 % malgré une accélération ressentie de 20 %.
• OpenAI — Why we no longer evaluate SWE-bench Verified : le retrait du benchmark, contamination et tests cassés.
• Stanford — Software Engineering Productivity (Denisov-Blanch) : le gradient greenfield-vs-brownfield, cité par DORA.
• DORA — The ROI of AI-assisted Software Development (2026) : le cadre de l'amplificateur, la taxe d'instabilité, le chiffre ≤10 % sur du brownfield.
• Faros AI — The Acceleration Whiplash (2026) : les deltas de télémétrie de delivery (temps de revue, incidents, bugs) — ce ne sont pas les chiffres de DORA.
• LinearB — 2026 Software Engineering Benchmarks : acceptation des PR IA 32,7 % vs 84,4 %, et l'attente en file 5,3× des PR agentiques.
• Murphy-Hill et al. — Adoption and Impact of Command-Line AI Coding Agents (Microsoft, 2026) : les ~24 % de PR fusionnées en plus, et l'aveu « une PR fusionnée n'est pas la valeur ».
• Model Context Protocol — sortie 2026 : le cœur stateless qui a transformé les flottes d'agents en infrastructure.
• Claude Code — Dynamic Workflows : la répartition déterministe sur jusqu'à 1 000 agents par exécution (~16 en parallèle).
• Boris Cherny — Steps of AI Adoption (16 juillet 2026) : l'échelle à cinq échelons — bloqué, assisté, parallèle, autonomie supervisée, IA-native — comptée en agents par ingénieur (~1 à ~1 000+), et la thèse selon laquelle on monte en démontant le prochain goulot d'étranglement et en construisant le prochain garde-fou, pas en dépensant des tokens. Une grille de lecture d'éditeur, catalogue produit compris — gardez l'échelle, écartez les références.
• Solstice* — télémétrie interne du dépôt (commits, PR, déploiements, tests, ADR), instantané au 15 juillet 2026, et rationnel produit interne (arbitrage de refonte, feuille de route 2026→2028). Pas de lien : c'est une base de code privée, et « Solstice » est un nom de code fictif — le projet réel, ses produits et ses technologies legacy sont anonymisés. Des chiffres de débit, pas de valeur — à lire avec le même scepticisme que ceux d'un éditeur.