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.

Blog post cover image
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 :
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).
⚠️ 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 :
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.

▸ 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.

Does this resonate with your team?

Let's talk about how Atypical Consulting can help you move forward.

Contact me