Saturday, June 27, 2026
J'ai automatisé 100% du dev d'un repo avec des agents Claude. J'ai cramé ma limite hebdo en moins d'une journée.
Pendant 19 heures, je n'ai pas écrit une ligne de code. Pas ouvert un seul fichier. Pas reviewé une seule PR à la main.
J'ai lancé une boucle, et une flotte d'agents Claude a développé mon projet à ma place : ~120 merges verts, du brainstorming jusqu'au merge, en passant par la spec, l'implémentation, la code review et le CI.
Le résultat technique est bluffant. La facture, elle, pose une vraie question : est-ce que ce mode de développement est réellement scalable aujourd'hui ?
Spoiler : j'en doute. Et c'est tout l'objet de cet article.
▸ Le setup : 4 skills et une boucle
Le repo, c'est Koine, un langage dédié (DSL) pour le Domain-Driven Design, qui compile des fichiers .koi en C# et TypeScript idiomatiques.
Pour automatiser son développement, j'ai écrit 4 skills Claude qui s'enchaînent :
1.
create-issue : crée une issue avec un plan en 3 phases (brainstorming, specs, plan d'implémentation), puis fait le triage et pose les labels.2.
implement-issue : implémente l'issue, applique une code review automatique, et remonte même les bugs non liés à l'issue qu'il croise au passage.3.
merge-pr : attend que le CI soit vert, applique les corrections nécessaires, merge, et ouvre des issues de follow-up si besoin.4.
auto-dev : une simple boucle qui orchestre les trois autres, en maintenant 3 agents en parallèle.C'est exactement la philosophie que défendait récemment le créateur de Claude Code : ne plus chatter, ne plus écrire de code à la main, ne même plus écrire de skills, mais abstraire le travail dans des boucles. J'ai voulu le tester à l'échelle d'un vrai repo. Ça marche. Vraiment bien.
Puis j'ai regardé les chiffres.
▸ La facture : 120 sessions, 5,07 milliards de tokens
J'ai agrégé tous les transcripts du run complet : l'orchestrateur plus 119 sessions worker tournant en parallèle dans des panes tmux séparés (26 juin 15:11 au 27 juin 10:26).
120 sessions (1 orchestrateur plus 119 workers)
5,07 milliards de tokens
27 566 turns assistant
≈ 12 042 $ d'équivalent API Opus
≈ 100 $ par merge
⚠️ Précision importante : ces montants sont des équivalents au prix public de l'API Opus, calculés à partir des tokens sur disque. Sur un abonnement Max/Pro, mon coût marginal réel était de ~0 $ (l'usage est inclus, borné par des rate limits, pas facturé au token). Le chiffre en dollars n'est donc pas une facture, c'est un signal de scalabilité : il dit OÙ vont les tokens.
Et c'est là que ça devient intéressant.
▸ 83% du coût, c'est du contexte. Pas du travail.
La question qu'on se pose tous : « ça coûte cher parce que ça génère beaucoup de code, non ? »
Faux. Le poste dominant, et de loin, c'est le cache read (la relecture du contexte). Le reste se répartit ainsi :
Cache write (établir le contexte) : 61%
Output (le code réellement généré) : 22%
Input : 16%
96,5% des tokens consommés sont du cache read. Autrement dit : à chacun des 27 566 turns, chaque agent relit l'intégralité de son contexte. Dans une longue boucle agentique, tu ne paies pas pour la réflexion ou le code produit, tu paies pour : volume de contexte × nombre de turns.
Mon orchestrateur, à lui seul, a relu 1,5 milliard de tokens de contexte sur un marathon de 2 950 turns, parce qu'il traînait une TaskList de 380 entrées réinjectée à presque chaque appel d'outil. Du pur gaspillage de cache, multiplié par 2 950.
C'est ça, le vrai enjeu de scalabilité. Et on en parle encore trop peu.
▸ Les leviers (contre-intuitifs)
Les providers comme Anthropic offrent aujourd'hui un volume de tokens énorme pour ~200 €/mois. Ça paraît illimité. Sauf que je n'ai automatisé qu'un seul repo, et j'ai flingué ma limite hebdomadaire en moins d'une journée.
Le mode « un agent Opus, full reasoning, en boucle infinie » ne passe tout simplement pas à l'échelle, pas à cause du code généré, mais à cause de la re-transmission redondante du contexte.
1. Tiering de modèles : la plupart des tâches étaient mécaniques (un guard sur une ligne, de la doc, une régénération de snapshot). Le cache read est 5× moins cher sur Sonnet, 15× sur Haiku. Router la flotte de workers vers Sonnet/Haiku et réserver Opus à l'orchestration ferait passer le run de ~12k$ à ~4-5k$ équivalent (≈ 7k$ d'économie), sans perte de qualité notable. De loin le plus gros gain.
2. Réduire le contexte par turn : ne pas accumuler d'état inutile, compacter régulièrement l'orchestrateur plutôt qu'une session sans fin.
3. Des unités de travail plus grosses : regrouper les issues sœurs dans un seul worker amortit le coût d'établissement du contexte (140M tokens de cache write, soit 22% du total).
4. Moins d'attente active sur le CI : un worker qui poll un CI lent se réveille en boucle, et chaque réveil relit son contexte.
▸ La vraie question, et la suite
On nous vend l'agent autonome qui code pendant qu'on dort. Techniquement, c'est déjà là. Je l'ai fait tourner, ça produit du code mergé et reviewé.
Mais l'économie sous-jacente n'est pas encore mûre pour ce mode « brute force ». Tant que ~80% du coût est de la re-transmission de contexte plutôt que du travail réel, la scalabilité n'est pas une question de modèle plus intelligent, c'est une question d'ingénierie du contexte et de tiering.
L'avenir du dev autonome ne sera pas « le meilleur modèle en boucle ». Ce sera « le bon modèle, au bon turn, avec le contexte minimal ».
Et là, je n'ai fait tourner que 3 agents en parallèle, sur 1 seul repo. Projetez ça : dans peu de temps, on déclarera probablement une dizaine d'agents sur une dizaine de repos, en parallèle. Multipliez la facture de contexte par cet ordre de grandeur, et la scalabilité ne devient plus théorique, elle devient le facteur limitant numéro un.
C'est le chantier que j'attaque la semaine prochaine : une nouvelle boucle qui tourne sur Sonnet plutôt qu'Opus, et qui évite la relecture de cache autant que possible. J'écrirai un second article une fois les bons réglages trouvés.
D'ici là, je suis vraiment preneur de vos retours : vous avez déjà laissé tourner des agents en autonomie sur un vrai projet ? Sur combien de repos en parallèle ? Et surtout, comment avez-vous géré le coût et les limites ?
Repo et skills en open source : le repo Koine et les 4 skills.