Le goulot a bougé : Comment les équipes tech restent rapides quand les agents écrivent le code

Le codage a cessé d’être l’étape lente. À travers quatre talks récents, le même pattern apparaît : les agents peuvent rédiger des changements rapidement, et les équipes s’enlisent ensuite sur la qualité, la revue, la confiance et la vérification.

Ce n’est pas le même argument que d’automatiser toute une entreprise, ou qu’une seule boucle de vérification à l’intérieur d’un produit de codage. Il s’agit de la façon dont une équipe reste rapide une fois que les agents écrivent déjà la plupart des diffs.

Où le temps passe réellement

Les agents non supervisés empirent le codebase avec le temps. Dexter Horthy, sur Beyond Coding et encore à la Agentic AI Foundation, passe en revue SlopCodeBench : les modèles reçoivent une app greenfield, puis une séquence de fonctionnalités, sans le problème entier d’avance. Les tests qui échouent montent. Les meilleurs modèles scorent encore dans le milieu des teens. Son avertissement est pratique : ne misez pas le codebase sur l’espoir que le modèle de l’année prochaine le nettoiera. Visez 2-4x, pas 100x. Faites moins de choses en parallèle, et gardez un humain dans la boucle recherche-design-plan pour tout ce qui change l’architecture.

Le processus de revue est souvent plus lent que le modèle. Dario Hamidi d’Amp, aussi sur Beyond Coding, dit que l’équipe ship en production environ 50 fois par jour, et le changement qui rend cela possible n’est pas l’agent. C’est d’abandonner les pull requests et les feature branches. Il argumente que même une équipe qui n’utilise pas l’IA peut gagner en productivité à deux chiffres en mergeant sur trunk, parce que les gens vérifient alors leur propre travail au lieu d’attendre dans une file construite pour des inconnus. La contrainte correspondante est la confiance : construisez des environnements où les agents ne peuvent pas « jongler avec des couteaux », avec des credentials de courte durée et des permissions que vous approuveriez réellement.

La vérification ne scale pas avec la génération. Prompt to Production d’IBM met le nouveau goulot en une phrase : la vérification humaine à l’échelle de l’IA. La planification, l’impact et les preuves comptent plus que la première ligne de code, parce qu’un vrai changement touche aussi les tests, la config, les pipelines et le monitoring. Un article IBM lié sur IDE vs CLI fait le même point du côté toolchain : la friction est de coordonner le travail autour du code, pas de le taper.

Les specs et les evals sont l’interface de l’équipe. Guillermo Rauch, dans l’interview de David Ondrej, décrit un workflow agentique construit sur l’essai de nombreux modèles, des evals personnels et d’entreprise, et des agents qui peuvent revoir une app ou shipper une fonction à partir d’une instruction courte. Le bit utile pour une équipe n’est pas le setup célébrité. C’est un eval partagé pour que « quel modèle cette semaine » ne devienne pas un argument privé.

Que changer lundi

Divisez le travail. Les petits changements réversibles peuvent aller à un agent en arrière-plan. Tout ce qui change une abstraction reste dans un passage recherche-design-plan avec un humain.
Arrêtez de mesurer la vitesse par les tokens ou les agents parallèles. Mesurez les deploys qui n’ont pas soulevé d’incidents, et gardez une priorité en vol.
Déplacez la revue à gauche. Les auto-checks et un environnement de confiance battent une longue file de PR. Si vous abandonnez les pull requests, dites ce qui les remplace : trunk, tests, et quelqu’un qui lit encore le diff.
Écrivez des règles anti-slop que l’agent peut voir : patterns que vous ne mergerez pas, et un endroit pour que le feedback utilisateur réentre dans l’usine.
Traitez la vérification comme la ressource rare. Planifiez les preuves (tests, flags, un court check manuel) avant de demander à l’agent d’implémenter.

Les équipes qui deviennent plus rapides ne sont pas celles avec le plus d’agents qui tournent la nuit. Ce sont celles qui ont remarqué que le goulot avait bougé, et qui ont staffé cette étape.