J’ai récemment découvert l’article de Ramp sur la construction de leur propre agent de programmation en arrière-plan, appelé Inspect. C’est un excellent article. Pour l’équipe d’ingénierie de Cartesia, il arrive au bon moment, alors que nous réfléchissons à la façon d’étendre les gains de productivité des agents de programmation à toute l’équipe.
Chez Cartesia, nous avons largement adopté ces agents. Nous utilisons Claude Code, Cursor, Codex, Copilot, Zed, Conductor et d’autres. Dans nos monorepos, attendez-vous à une revue de Claude Code, Cursor BugBot, Vercel Agent et Codex. Leurs retours variés, parfois complémentaires, parfois contradictoires, améliorent concrètement la qualité du code livré. BugBot est actuellement notre préféré :
Cela ne vient pas d’une consigne imposée par la direction. C’est le résultat d’un intérêt spontané pour mieux travailler, plus vite, et automatiser les tâches ennuyeuses autant que possible, associé à la volonté de dépenser ce qu’il faut pour expérimenter.
Ces nombreuses expériences facilitent la comparaison des agents et l’observation des dernières avancées. Les méthodes changent tous les quelques mois.
Mais il semble manquer quelque chose.
Écrire du code semble résolu. L’ingénierie ne l’est pas.
Les modèles de pointe peuvent effectuer des refactorisations complexes et intégrer du code à des points de terminaison très sollicités. On a souvent l’impression qu’ils anticipent les problèmes. Nous avons constaté que des changements simples, comme placer le code dans un monorepo, leur permettent de raisonner entre les composants du système et d’éviter des bugs subtils. Les agents de revue comblent certaines lacunes. Écrire le code n’est plus le principal frein.
Mais programmer et faire de l’ingénierie sont deux choses différentes. Un bon ingénieur ne se contente pas d’ajouter du code à un monorepo. Il pense aux effets de son travail. Il juge si une fonction marche, l’améliore selon les retours réels et continue jusqu’à atteindre les objectifs de l’entreprise.
C’est là que les agents peinent. Nous avons utilisé Opus 4.5 pour supprimer sans risque une fonction de plus de 10 000 lignes :
…mais nous ne pouvons toujours pas lui demander de déterminer si une fonction est adoptée en production puis de l’améliorer, ou de relier une hausse de latence de l’API à une ligne de notre code.
Le vrai frein vient des boucles de retour interrompues
Les agents n’échouent pas parce qu’ils ne savent pas écrire du code, mais parce qu’ils rencontrent des limites pratiques. Opus 4.5 peut écrire le code d’un test A/B, mais ne peut pas consulter PostHog pour voir si l’expérience a réussi, alors il s’arrête. Il peut déployer une correction d’interface, mais pas accéder à l’aperçu Vercel pour vérifier le rendu. Il peut optimiser une requête SQL, mais pas consulter les mesures de production pour confirmer le gain.
Nous voyons ici une occasion d’améliorer leur travail : leur donner, de manière sûre, l’infrastructure nécessaire pour itérer de bout en bout. Accès aux dépôts, à la CI, aux aperçus, aux tableaux de bord internes, aux données PostHog et à tout ce dont ils ont besoin pour juger la réussite et l’échec comme un ingénieur humain.
Cela profite aussi concrètement aux humains. Accélérer la CI ou faciliter le lancement de toute la pile aide les ingénieurs à prendre leurs marques plus vite et à rester productifs.
Améliorer la productivité avec les agents est une fonction stratégique
Les ingénieurs sont souvent trop concentrés sur le problème immédiat pour penser globalement à leur expérience de développement. Suivre les dernières avancées, expérimenter les outils récents et transformer les enseignements en outils internes est un travail à temps plein.
Cette occasion dépasse l’ingénierie. Nous pensons que les mêmes principes d’infrastructure conçue pour l’IA peuvent transformer les processus internes dans toute l’entreprise. Les équipes de mise sur le marché, d’affaires et de vente effectuent beaucoup de tâches répétitives dont l’automatisation pourrait produire des gains importants.
L’écart entre les capacités des agents et l’infrastructure ne se comblera pas seul. Quelqu’un doit concevoir activement l’expérience de développement pour les humains comme pour l’IA.
Nous travaillons à résoudre ce problème et recrutons un ingénieur AI & Developer Acceleration, chargé d’accélérer le travail des IA et des développeurs. En nous rejoignant, vous définirez les méthodes qui permettront aux ingénieurs comme aux non-ingénieurs de passer du problème à la solution avec un minimum d’intervention humaine. Vous pourrez aussi en parler haut et fort publiquement. Contactez-nous !