Chez Uber, être ingénieur, c’est construire le contexte des agents
Un Distinguished Engineer d’Uber résume son métier : donner le bon contexte aux agents. Ce que montrent leurs outils, et ce que j’en retiens.
Pour Uday Kiran Medisetty, Distinguished Engineer chez Uber, le métier d’ingénieur se résume désormais à une question : comment construire le bon contexte pour que les agents produisent un résultat fiable. Je suis d’accord, et ce qui me frappe dans son témoignage, c’est que la réponse d’Uber repose surtout sur des outils construits bien avant l’arrivée des agents.
Ce qu’il a dit
Uday est l’un des ingénieurs les plus anciens d’Uber et dirige une bonne partie de ses travaux sur les agents IA. Invité du podcast The Pragmatic Engineer, il le formule ainsi :
« En un sens, le travail d’ingénieur se résume à une question : comment construire le bon contexte pour que les agents produisent un résultat fiable ? Il faut devenir vraiment bon en context engineering. »
Il ajoute deux compétences : savoir passer d’une tâche à l’autre, puisqu’on lance plusieurs agents en parallèle, et savoir relire et vérifier ce qu’ils produisent pour ne pas mettre de régression en production.
Chez Uber, les agents sont déjà partout. En mars, Gergely Orosz rapportait que 84 % des développeurs utilisaient des agents, que l’usage de Claude Code était passé de 32 % à 63 % entre décembre et février, et que 11 % des pull requests étaient ouvertes par des agents.
Un outillage qui ne dépend d’aucun agent
Ce que je retiens surtout, c’est AIFX, un outil qui se place au-dessus de Claude Code, Codex et OpenCode : quand un ingénieur change d’outil, ses réglages, ses skills et ses plugins le suivent. Pour les modèles, Uber avait fait le même choix dès 2023 : une passerelle unique, Model Gateway, permet de passer d’Anthropic à OpenAI ou à un modèle ouvert sans tout refaire.
Je fais la même chose à mon échelle. J’utilise Claude Code, OpenCode et Codex, et mon contexte vit dans des fichiers Markdown que les trois savent lire : un AGENTS.md, des notes de projet, des skills. Je ne veux pas qu’un changement d’outil me fasse perdre ce que j’ai mis des mois à écrire. Qu’une entreprise de cette taille arrive à la même règle me conforte dans ce choix.
Le contexte, c’est tout l’environnement
Chez Uber, le contexte va bien au-delà d’un fichier d’instructions. Les agents y ont accès au code, aux services internes via une passerelle MCP, à un dépôt de skills et à un graphe de connaissances sur l’ingénierie. Les tâches simples de la CI, comme le lint et les règles de build, sont même passées du côté de l’agent : il les lance avant d’ouvrir une PR. Uber s’y est résolu après un « code red » sur sa CI, dont les jobs avaient plus que doublé en un an.
J’en suis convaincu aussi. Le contexte d’un agent dépasse largement un AGENTS.md : il comprend les règles, les skills, les tests, les linters, les notes de décisions et l’état du projet. Un agent qui peut lancer les tests et le linter se corrige seul. En général, ma consigne à l’agent tient en une phrase : fais les checks qu’il faut et vérifie que ça marche. Elle ne fonctionne que si ces checks existent.
Uday le dit autrement : tout ce qu’Uber a construit pendant dix ans pour faciliter la vie des ingénieurs facilite aussi celle des agents. Minion, la plateforme créée en 2025 pour faire tourner des agents en tâche de fond, repose sur DevPods, des environnements de développement lancés en 2017. J’en parlais dans un article précédent : les bonnes pratiques servaient déjà à aider le nouvel arrivant, et l’agent est un nouvel arrivant permanent.
La revue de code bloque
Revers de la médaille : Uday reconnaît que la revue de code est devenue un goulot d’étranglement. Toutes les PR sont encore relues par un humain, mais quand un développeur ouvre une PR, une IA l’a déjà relue, des captures ou des vidéos sont jointes si besoin, et un score de risque l’aide à décider combien de temps y consacrer.
Uber ne mesure plus non plus la vitesse des PR : l’indicateur n’a plus de sens quand un agent peut en ouvrir des dizaines. Chaque PR est maintenant classée par type (fonctionnalité, correctif, maintenance, tests ou documentation), et la part des fonctionnalités augmente pendant que celle de la maintenance baisse.
Je ne sais pas si ce classement reflète vraiment la valeur produite. Il a au moins le mérite de regarder ce qui est livré, et pas seulement la quantité de code.
Sources : Uber’s AI infra, from the inside, The Pragmatic Engineer, How Uber uses AI for development, The Pragmatic Engineer. Texte rédigé avec l’aide d’une IA à partir de mes idées, puis relu par moi.