Agents de codage sur de vraies bases de code: ce qu'ils coûtent et où ils échouent

Dans un dépôt vide, un agent sur deux écrit une TODO app en cinq minutes. Dans une base de 200 000 lignes avec 12 ans d'historique, l'image change. La question n'est plus "l'agent sait-il faire?", mais "combien ça nous coûte si on le laisse faire?".

Où les agents de codage livrent aujourd'hui de façon fiable

Trois types de tâches passent mieux avec un agent qu'avec une personne seule:

• Migrations répétitives. Une boucle sur 70 noms de module renommés selon le même schéma est du travail d'agent. Diffs clairs, pas d'hésitation.
• Écrire des tests contre du code existant. Un skill bien spécifié ("écris des tests pour les fonctions exportées dans src/lib/billing.ts") rend 20 tests en dix minutes. Ce qui reste est décidé en revue.
• Recherche de premier secours. "Où vit la logique X?" - les agents avec accès en lecture au dépôt battent toute recherche d'IDE.

Où ils échouent encore

Avec la même franchise: trois domaines restent du travail humain.

1. Décisions d'architecture aux longues conséquences. Quand la réponse est "ça dépend", l'agent invente généralement des arguments.
2. Réglage de performance sans télémétrie. Sans métriques sous les yeux, l'agent devine. Résultat: dix optimisations théoriques, aucune mesurable.
3. Code dans des bases peu documentées. Sans doc, sans tests, sans conventions, l'agent produit des solutions plausibles qui violent des contrats invisibles.

Ce que les tokens coûtent vraiment

Sur des tâches non triviales, nous voyons en moyenne 50 000-200 000 tokens en entrée et 5 000-30 000 en sortie par tâche. Soit entre 5 et 30 euros par développeur et par jour - bien moins avec de bons réglages utilisant le motif Caveman ou des astuces similaires. Ce n'est pas la partie chère. La partie chère, c'est le temps de revue pour des sorties qui n'auraient pas dû exister.

Quatre antipatterns que nous voyons un projet sur deux

• Prompts "big bang". "Refactorise le module XY" rend 800 lignes modifiées que personne ne peut revoir honnêtement.
• Critères de succès manquants. "Fais mieux" n'a pas de condition d'arrêt. Les agents hallucinent d'autres améliorations jusqu'à ce qu'on les arrête.
• Pas de tests dans la boucle. Un agent sans retour de tests se construit sa propre vérité. Avec un test runner dans la boucle, une grande partie des bugs remonte avant la revue.
• Pas de budget de contexte. Chaque tool call tire du contexte. Sans discipline, la fenêtre se remplit de bric-à-brac et l'agent perd le fil.

Un juste milieu pragmatique

Les agents de codage ne remplacent pas le jugement d'ingénierie, mais ils déplacent le levier. Trois mesures suffisent à la plupart des équipes:

1. Un catalogue de skills partagé et versionné (voir notre article sur les skills).
2. Les pull requests restent le seul chemin vers la branche principale - peu importe qui a écrit le diff.
3. Une rétrospective par sprint sur la question: "quelle tâche aurait dû utiliser un agent et ne l'a pas fait - et laquelle n'en avait pas besoin?".

Avec cette discipline, le gain se situe là où les tâches sont clairement délimitées - et il en résulte une séparation nettement plus propre entre "travail d'agent" et "travail humain".