Comment Coinbase a déployé l'IA auprès de 1 000+ ingénieurs

Comment Coinbase a ancré l’IA dans une organisation de 1 000 ingénieurs

La plupart des grandes organisations d’ingénierie testent des outils IA, observent un bref pic d’adoption, puis voient celle-ci stagner. Chintan Turakhia, Senior Director of Engineering chez Coinbase, est passé exactement par ce creux de désillusion — et en est ressorti avec un playbook qui a vraiment fonctionné. Dans cette conversation avec Claire Bell sur How I AI, il détaille les tactiques concrètes qui ont généré une adoption durable.

Sur pourquoi l’adoption ne tient pas : “The company tried to adopt other AI tools and we saw this uptick in adoption. People opened it up, checked the box, did kind of like a hello world thing, but it didn’t stick. My biggest thing is, how do I make this damn thing stick?” (L’entreprise a essayé d’adopter d’autres outils IA et on a vu un pic d’adoption. Les gens l’ont ouvert, ont coché la case, fait un truc genre hello world, mais ça n’a pas tenu. Ma grande question, c’est : comment faire en sorte que ce truc s’installe vraiment ?) Le problème ne venait pas des outils — les modèles n’étaient pas encore mûrs fin 2024, et dès qu’un ingénieur décrochait, toute l’équipe abandonnait. Le modèle mental de Turakhia : les modèles fondamentaux s’amélioreront toujours, autant bâtir les réflexes maintenant.

Sur les leaders qui recommencent à coder : Turakhia a passé de janvier à avril 2025 dans Cursor tous les jours, à corriger des bugs personnellement, à ouvrir des PR, et à montrer aux ingénieurs ce qui était possible. La pire chose qu’un leader puisse faire, c’est de décréter l’adoption de l’IA depuis une salle de réunion. “I do think that it’s really important when you’re doing this organizational transformation that you have a single person with incredible conviction at the leadership level who is also hands on the metal.” (Je pense vraiment qu’il est essentiel, dans cette transformation organisationnelle, d’avoir une seule personne avec une conviction absolue au niveau du leadership, qui soit aussi les mains dans le cambouis.) Il a commencé par les tâches ingrates — tests unitaires, linting, commandes git — le travail épuisant que personne ne veut faire.

Sur les PR speedruns : Le moment de bascule a été un événement chronométré : chaque ingénieur prend un bug trivial ou un changement de texte et ouvre une PR avec Cursor. En 15 minutes, 100 ingénieurs ont soumis 70 PR. Ils ont mis à genoux l’infrastructure de GitHub. Puis ils sont passés à l’échelle de l’entreprise : 800 ingénieurs, 400 PR en 30 minutes. « C’était vraiment une mort aux points de situation, vive le fait de construire. »

Sur mesurer ce qui compte : Turakhia se focalise sur une seule métrique : le temps entre le ticket et le moment où le changement atteint l’utilisateur. Cela englobe la priorisation, le développement, la revue et le déploiement. Le temps de cycle de revue des PR est passé de 150 heures en moyenne à environ 15 heures — une amélioration par 10. L’objectif : quelqu’un donne un retour, et le correctif est livré avant la fin de l’appel.

Sur Cloudbot — leur agent interne : Coinbase a construit un bot Slack maison qui enchaîne les tickets Linear, des MCPs (Datadog, Sentry, Amplitude, Snowflake) et plusieurs bases de code. Le flux de travail : capturer le retour utilisateur via audio → le LLM extrait les bugs → crée un ticket Linear → l’agent génère une PR → lien direct vers la branche Cursor → QR code pour les tests mobiles. Un soir, Turakhia a lancé 200 corrections de bugs depuis l’outil de feedback en un seul batch.

Sur le rôle de « super builder » : Turakhia a inventé un nouveau rôle : le super builder. Sa mission la plus importante est de créer d’autres super builders. Ce sont les personnes qui pilotent les outils IA, construisent des agents internes et accélèrent tout le monde autour d’eux. Son conseil : être parmi les trois personnes les plus expertes en IA de votre organisation d’ingénierie est l’un des meilleurs paris de carrière que vous puissiez faire en ce moment.

Sur la disparition des frictions de coordination : “My calendar is empty. Almost empty. And the reason why is because the coordination overhead of prioritizing, changing the roadmap — no, you just do things.” (Mon agenda est vide. Presque vide. Et la raison, c’est que la charge de coordination pour prioriser, changer la roadmap — non, vous faites juste les choses.) Les leaders écrivent plus de code. Les équipes sautent les débats de sprint planning parce que les cycles retour-correction se mesurent en minutes, pas en sprints.

6 enseignements du playbook d’adoption IA de Coinbase

• Un leader convaincu les mains dans le cambouis — L’adoption requiert un champion opérationnel qui code tous les jours, pas un décret venu d’en haut
• Commencer par les tâches ingrates — Tests unitaires, linting, commandes git — supprimer le travail épuisant en premier, et les ingénieurs adhèrent
• Les PR speedruns créent des percées — Les événements chronométrés où tout le monde livre en même temps ancrent la conviction et révèlent les limites d’infrastructure
• Revues de PR 10x plus rapides — Le temps de cycle est passé de 150 heures à 15 heures en compressant tout le pipeline retour-livraison
• Les agents internes surpassent les outils externes — Cloudbot enchaîne Linear, Slack et des MCPs pour aller du retour utilisateur à la PR fusionnée de façon autonome
• Le « super builder » comme trajectoire de carrière — La personne qui rend tous les autres plus productifs avec l’IA est l’embauche la plus précieuse en ce moment

Ce que cela signifie pour les organisations d’ingénierie qui adoptent l’IA

L’histoire de Coinbase est significative parce qu’il s’agit d’un vrai cas à l’échelle — pas une startup de 5 personnes, mais 1 000+ ingénieurs dans une entreprise cotée en bourse avec des exigences sérieuses en matière de sécurité et de conformité. Le playbook est reproductible : commencer avec un leader convaincu qui code, cibler les tâches ingrates en premier, créer des victoires visibles via des speedruns, construire des agents internes là où les outils externes ne peuvent pas aller, et mesurer la seule métrique qui compte — le temps du retour à l’utilisateur. Les organisations qui maîtrisent cela ne livrent pas seulement plus vite. Elles changent fondamentalement ce qui est possible avec leurs effectifs existants.