Agents développeurs autonomes : jusqu’où les laisser coder ?
Nos agents analysent des dépôts, corrigent des bugs, écrivent des tests et ouvrent des pull requests. La règle qui rend ça sûr : ils ne touchent jamais à la production.
Les agents les plus clivants que nous exploitons sont ceux qui écrivent du code. Ils analysent une flotte de dépôts, priorisent ce qui doit être corrigé, patchent, testent — et ouvrent une pull request comme n’importe quel développeur.
La frontière qui fait que ça marche
Le monde des agents s’arrête à la pull request. Fusionner est un acte humain. Déployer est un acte humain. Ce n’est pas du théâtre de précaution : ça signifie que le rayon d’explosion d’une mauvaise décision d’agent est une PR refusée, pas une panne. Les relecteurs restent dans la boucle exactement là où leur jugement compte.
Ce qu’ils font vraiment bien
- →Le backlog que personne ne prend : mises à jour de dépendances, tests instables, code mort, couverture manquante.
- →Les migrations répétitives appliquées de façon cohérente sur des dizaines de dépôts.
- →Les premiers jets de correctifs quand le motif est connu et le risque faible.
Multipliez ça sur une flotte de dépôts et l’arithmétique devient sérieuse — c’est une part significative des équivalents temps plein que nous mesurons sur nos agents déployés.
Là où les humains restent irremplaçables
L’architecture, les compromis, le nommage, le sens produit — tout ce dont la bonne réponse dépend d’où le code doit aller, pas d’où il est. Notre règle simple : les agents pour le travail qui a un motif, les humains pour le travail qui fixe le motif.