Detailed Report
Coinbase faced an existential challenge: transform its self-custody wallet into a full-blown consumer social application, the Base App, within a brutal six-to-nine-month timeline. With previous AI coding tool attempts having failed, AI was no longer a luxury but a necessary force multiplier to compete with established social media giants.
Chintan Turakhia, Senior Director of Engineering at Coinbase, stepped into this high-pressure environment with a radical approach to AI adoption, aiming to embed AI into the workflow of 1,000 engineers.
Overcoming Past Failures
Coinbase's initial attempts at AI adoption, such as with GitHub Copilot, had faltered. Engineers would try the tools once or twice, find them unhelpful for immediate, complex tasks, and then dismiss them. This created a 'trough of sorrow' where skepticism spread, and the crucial workflow integration, or 'stickiness,' was missing.
'Leader-on-the-Metal': A New Leadership Paradigm
Turakhia believed that true transformation couldn't be decreed from an executive meeting. It required a 'single person with incredible conviction at the leadership level who is also hands on the metal.' He embodied this by personally coding, fixing bugs, and submitting pull requests within an AI-native IDE like Cursor from January through April 2025.
This deliberate, public demonstration allowed him to experience friction points and 'holy shit' moments firsthand, building credibility and showing engineers, rather than just telling them, what was possible. His conviction was that foundational models would inevitably improve, and the organization needed to build the muscle memory and workflows *now*.
The 'PR Speed Run': A Cultural Reset
Recognizing that simply providing tools wasn't enough, Turakhia orchestrated a 'PR speed run' to create a shock to the system. The first event involved 100 engineers, tasked with fixing a trivial bug or copy change using AI tools and submitting a pull request within 15 minutes. The result was 70 PRs submitted, which intentionally overloaded and *broke Coinbase's internal GitHub infrastructure*.
The trivial nature of the tasks was key, lowering the barrier to entry and removing the fear of failure. This created a shared, immediate success experience, forcing a large group of engineers to engage with AI tools in a fun, competitive, low-stakes environment. The broken GitHub was seen not as a failure, but as a positive sign of overwhelming engagement and validation of the velocity AI could unlock.
Buoyed by this success, they scaled the experiment to 800 engineers, resulting in 400 PRs submitted in just 30 minutes. This shattered lingering skepticism, creating social proof and a sense of inevitability around AI adoption.
Reframing AI: Eliminating 'Toil'
Turakhia strategically framed AI's purpose not as a replacement for engineers, but as a tool to free them from 'toil' – the mundane, repetitive tasks developers universally despise. This included writing unit tests, linting code, or remembering obscure git commands.
The message was clear: 'The best way to get to an engineer is just give them the tools so they stop doing the shit work and so they can build the stuff they love.' This approach bypassed natural resistance, transforming the narrative from 'you must use AI' to 'here is a tool to make your life easier,' making AI an ally rather than a threat.
Measuring True Impact: Beyond Vanity Metrics
Coinbase actively discouraged traditional AI adoption metrics like 'lines of code generated by AI' or 'percentage of engineers using Copilot,' labeling them 'vanity metrics.' Turakhia argued these could be misleading and distract from the real goal.
Instead, their single 'north star' metric was the total end-to-end time from ticket creation to the moment a change was live for the user (cycle time). This holistic measure of velocity encompassed the entire development lifecycle. The result was an astonishing 10x improvement in PR review cycle time, plummeting from 150 hours to 15 hours. The ambition became: if a user provides feedback on a call, the fix should be shipped before the call ends.
AI for AI: Optimizing Adoption with Data
In a meta move, Turakhia used AI itself (Cursor) to analyze his team's AI adoption data. This allowed him to cluster users into cohorts (light, casual, power) and identify specific behaviors of power users. He then prompted the AI to generate tailored playbooks with actionable guidance for each cohort, complete with motivational slogans like 'Stop typing. Start shipping.' This data-driven, AI-assisted approach provided personalized and scalable coaching, using AI to make more engineers better at using AI.
Building the 'Intelligent Machine': Internal AI Agents
Beyond off-the-shelf tools, Coinbase invested in building its own internal AI agents. A standout example is 'Cloudbot,' a custom Slack bot deeply integrated with internal systems like Linear, Datadog, and Sentry. This agent can transcribe user feedback from audio, extract bug details, automatically create a ticket in Linear, and even generate a pull request with a proposed fix, deep-linking to the code branch in Cursor.
This level of automation compresses the entire feedback-to-ship pipeline from days or weeks into mere minutes. Turakhia mentioned kicking off 200 bug fixes from user feedback in a single batch one night using this system, fundamentally transforming their operational workflow.
The 'Super Builder': Evolving Engineering Roles
To support this shift, Coinbase created a new role: the 'super builder.' Their primary job is to create *more* super builders by driving AI tooling adoption and building sophisticated internal agents like Cloudbot. This signifies a formal recognition that a significant portion of engineering effort must be dedicated to building the 'intelligent machine' that makes *all* other engineers more productive.
This shift redefines engineering productivity, placing a premium on strategic thinking, prompting, problem decomposition, and critical evaluation of AI-generated work, heralding a new era of human-AI collaboration.
Security and Quality Guardrails
Operating in a regulated industry like financial technology, Coinbase prioritized security and code quality. They partnered closely with security and privacy teams to develop a 'repository sensitivity matrix,' establishing clear criteria for AI tool usage on specific codebases. The core principle is that AI doesn't ship bugs; humans misuse or misinterpret its output, so guardrails mitigate human risk.
Measures include 'identity-aware controls' to ensure AI systems only access relevant information and using AI to monitor employee activities, including code reviews, as part of internal security protocols.
The 'Death of Coordination'
One profound, and perhaps unexpected, consequence of this AI-driven acceleration is the 'death of coordination.' The traditional friction points of software development—endless meetings for prioritization, roadmap debates, status updates—begin to dissolve. When the cost and time to fix a bug or ship a small feature drops to near zero, the need for extensive debate diminishes. Turakhia notes that the organization's default mode shifts from 'planning to build' to simply 'building,' transforming a meeting-heavy culture into a shipping-heavy one.
Repeatability and Nuance
While Coinbase's playbook offers a compelling blueprint, its universal repeatability is an open question. Turakhia's personal 'leader-on-the-metal' immersion was undeniably crucial for building credibility and momentum, a level of engagement difficult to scale across all leaders in a massive organization. The success appears to be a unique combination of a top-down mandate from CEO Brian Armstrong, making AI tools mandatory, and Turakhia's bottom-up, hands-on implementation that won over engineers. The external pressure of rewriting the wallet also provided a powerful catalyst that other organizations might lack, suggesting it's a blueprint, but not a one-size-fits-all solution.
Full Transcript
HostOkay, so imagine this: you're an engineering director at a major tech company. You've got a thousand engineers, and your CEO just dropped a bombshell – you need to completely rewrite a core product, a self-custody wallet, into a full-blown consumer social app, and you have six to nine months to do it. Oh, and your previous attempts at using AI coding tools? They failed. Miserably.
ExpertAnd into this pressure cooker steps Chintan Turakhia, the Senior Director of Engineering at Coinbase. His team isn't just going to *try* AI again. They’re going to gamify its adoption so aggressively that they actually *break their own GitHub infrastructure*.
HostWait, they *broke GitHub*? As in, their internal GitHub? With a "PR speed run" that had 100 engineers submitting 70 pull requests in 15 minutes?
ExpertThat's right. They intentionally overloaded it, in a move that the report describes as a "death to status updates, long live building moment." It’s an almost unbelievably chaotic, yet entirely deliberate, tactic to force a cultural reset. And it worked.
HostThat detail about intentionally breaking GitHub just to prove a point about AI adoption is wild. But let's rewind a bit. The report frames this entire initiative around an existential "adapt or die" moment for Coinbase. What exactly was the mandate that put them in such a high-stakes position?
ExpertWell, the core of it was an incredibly ambitious project: transforming their self-custody wallet into what they called the Base App—a consumer social application. Think about it: they're trying to compete with established social media giants that have tens of thousands of engineers and a decade-long head start. The timeline for this rewrite was brutal, only six to nine months. So, AI wasn't just a nice-to-have; it was positioned as a necessary force multiplier to even have a prayer of achieving this monumental task.
HostAnd yet, their previous attempts at AI adoption, like with GitHub Copilot, had essentially flamed out. The report calls it a "trough of sorrow." What went wrong the first time, and why did engineers just bounce off these tools?
ExpertThe report highlights a common pattern. Engineers would try it, "open it up, check the box, did kind of like a hello world thing," as Turakhia put it. But it didn't stick. They’d use it once or twice, find it unhelpful for their immediate, complex tasks, and then dismiss it entirely. That skepticism would spread, creating a cultural barrier. The tools were there, but the workflow integration, the "stickiness," was missing. It was a classic case of tooling without true adoption.
HostSo, how do you counter that deep-seated skepticism? The report emphasizes Turakhia's conviction and what he called "leader-on-the-metal." That phrase really jumps out. What did that mean in practice for him?
ExpertIt was a complete repudiation of the idea that AI adoption could be decreed from an executive meeting room. Turakhia believed that true transformation required a "single person with incredible conviction at the leadership level who is also hands on the metal." And he embodied that himself. From January through April 2025, he essentially transformed his own role. He wasn't just managing; he was personally coding, fixing bugs, submitting pull requests, all within an AI-native IDE like Cursor.
HostSo he was literally in the trenches, experiencing the tools firsthand, rather than just telling his team to use them?
ExpertExactly. It was a deliberate, public demonstration. He wanted to "show the engineers, not just tell." By personally experiencing the friction points and, crucially, the "holy shit" moments of using these tools, he built credibility. He could genuinely understand what was needed to make the adoption "stick" because he was feeling it himself. His core belief, as the report notes, was that foundational models would inevitably improve, so the organization needed to build the muscle memory and workflows *now*. It was about preparing for an inevitable future.
HostThat makes so much sense. It’s hard to argue with a leader who’s already done the thing he’s asking you to do. But even with that kind of leadership, changing ingrained habits across a thousand engineers is a huge undertaking. How did they actually break through that institutional inertia and turn skepticism into widespread engagement? This is where the "PR speed run" comes in, right?
ExpertAbsolutely. This was the cultural reset button. Turakhia realized that simply providing tools wasn't enough; they needed a shock to the system. The first "PR speed run" involved 100 engineers. The challenge was deceptively simple: pick a trivial bug or a copy change, use AI tools—specifically Cursor—to fix it, and submit a pull request within 15 minutes.
HostAnd the result was 70 PRs submitted in 15 minutes, which then broke their GitHub infrastructure. That's a fascinating side effect. What was the intention behind making it so low-stakes, almost trivial?
ExpertThe trivial nature of the tasks was key. It wasn’t about writing perfect code or solving complex problems. It was about lowering the barrier to entry, removing the fear of failure, and creating a shared, immediate success experience. The report emphasizes that it was a "death to status updates, long live building moment" from a journalistic and cultural standpoint. It forced a large group of engineers to simultaneously engage with the AI tools in a fun, competitive, and low-stakes environment. And the fact that they *broke GitHub* wasn't a failure; it was seen as a positive sign of overwhelming engagement. It validated the sheer velocity these tools could unlock.
HostSo, they essentially manufactured a "holy shit" moment that a top-down mandate could never achieve. And then they scaled it?
ExpertImmediately. Buoyed by the initial success, they scaled the experiment to 800 engineers. This time, 400 PRs were submitted in just 30 minutes. This wasn't just momentum; it was undeniable proof that something profound was happening. It shattered any lingering skepticism. The "speed run" created social proof and a sense of inevitability around AI adoption, turning engineers from passive observers into active participants. It showed, rather than told, what was possible.
HostI can imagine the buzz in the office after that. It sounds like they created a positive feedback loop. But it wasn't just about forcing adoption; the report also highlights a very strategic framing of AI's purpose: eliminating "toil." Why was that such a crucial aspect of their pitch?
ExpertThis was brilliant, frankly. Turakhia understood that engineers are naturally resistant to being told what to do, especially if it feels like their core creative work is being devalued or replaced. So, the pitch wasn't about replacing them; it was about freeing them. The initial focus was squarely on eradicating "toil"—those soul-crushing, mundane tasks that every developer universally despises. Things like writing unit tests, linting code, remembering obscure git commands, or other repetitive, low-value activities.
HostAh, the "shit work," as the report quotes Turakhia. Making AI the assistant that handles the chores, so engineers can focus on the fun stuff.
ExpertExactly. His message was clear: "The best way to get to an engineer is just give them the tools so they stop doing the shit work and so they can build the stuff they love." This approach bypassed the natural resistance. The "aha" moment for many engineers wasn't just that AI could write code, but that it could automate the entire PR process. They realized they would "never need to remember git status, git rebase... why is anyone doing this anymore?" It transformed the narrative from "you must use AI" to "here is a tool to make your life easier," which, as it turns out, is far more persuasive. It makes AI an ally, not a threat.
HostThat's a masterclass in change management, really. But once you get engineers using these tools, how do you measure if it’s actually working? The report mentions they actively *discouraged* traditional AI adoption metrics. That's counter-intuitive, isn't it?
ExpertIt really is. Most companies would immediately jump to "lines of code generated by AI" or "percentage of engineers using Copilot." But Turakhia explicitly called those "vanity metrics." He argued they could be misleading, incentivize superficial engagement, and lead to teams spending "endless hours coming up with new metrics to measure AI adoption to go tell finance that it's worth the money." He saw it as a distraction from the real goal.
HostSo what *was* the real goal, and what was their "north star" metric instead?
ExpertTheir single "north star" was the total end-to-end time from ticket creation to the moment that change was live for the user. This is often called "lead time for changes" or "cycle time." It encompasses the entire development lifecycle: prioritization, coding, code review, deployment, and release. By focusing on this holistic measure of velocity, they weren't just tracking AI usage; they were tracking its *impact* on their ability to ship value. They knew that if AI was truly effective, it would shorten that entire cycle, not just one part of it. The report notes they did track token usage as a general proxy for experimentation, but the primary measure of success was always the impact on shipping speed.
HostAnd the result of that focus on end-to-end velocity? The report states a 10x improvement in PR review cycle time. From 150 hours to 15 hours. That's not just an improvement; that's a fundamental shift.
ExpertIt's an astonishing result. It fundamentally transformed their development process. The ambition became: if a user provides feedback on a call, the fix should be shipped before the call ends. That 10x reduction isn't just a number; it's a proof point that demonstrates tangible, undeniable value to the entire organization. It moves beyond theoretical gains into real-world impact.
HostAnd in a perfectly meta move, the report says Turakhia even used AI to analyze his own team's AI adoption data. That’s next-level. How did that work?
ExpertIndeed. He recognized that simply rolling out tools wasn't enough; they needed to understand the nuances of usage to make it stick. He used Cursor, the AI tool itself, to ingest and analyze the team's adoption data. This allowed him to cluster users into cohorts—light users, casual users, power users—and identify the specific behaviors and workflows that separated the power users from the rest.
HostAnd then what did he do with that analysis? Did he just present it in a report?
ExpertNo, he went further. He prompted the AI to *generate* a tailored playbook with specific, actionable guidance for each cohort to help them level up their skills. The AI even generated motivational slogans, like "Stop typing. Start shipping." This data-driven, AI-assisted approach to driving adoption allowed for personalized and scalable coaching. It turned raw usage data into a concrete plan for organizational improvement, essentially using AI to make more engineers better at using AI. It's a self-improving system.
HostSo, they've got off-the-shelf tools, they've got this incredible adoption strategy, and they're measuring the right things. But the report goes on to describe how Coinbase took it a step further by building their *own* internal AI agents. This isn't just about using existing tools, it's about building an "intelligent machine" themselves. Can you elaborate on these internal agents?
ExpertThis is where it gets really powerful. One of the standout examples is a custom Slack bot named "Cloudbot." This agent is deeply integrated into Coinbase’s internal systems—their issue tracking with Linear, monitoring platforms like Datadog and Sentry. Imagine this: a user gives verbal feedback during a call. An AI model transcribes that audio, extracts the key details of a bug or feature request, and automatically creates a ticket in Linear.
HostAnd Cloudbot doesn't stop there, does it?
ExpertNo, it doesn't. From that Linear ticket, another agent can generate a pull request with a proposed fix, and then deep-link directly to the specific code branch in Cursor, ready for a developer to review and test. Turakhia even mentioned kicking off 200 bug fixes from user feedback in a single batch one night using this system. This level of automation compresses the entire feedback-to-ship pipeline from days or weeks into mere minutes. It’s a complete transformation of their operational workflow.
HostThat's incredible. It sounds like they're not just automating tasks, but entire processes. And to support this, the report mentions they created a completely new role: the "super builder." What does a "super builder" do, and what does this signify for the future of engineering roles?
ExpertThe "super builder" role is a fascinating development. Turakhia defines their most important job as creating *more* super builders. These are the engineers tasked with driving AI tooling adoption, building these sophisticated internal agents like Cloudbot, and acting as force multipliers across the organization. It’s a formal recognition that in the age of AI, a significant portion of engineering effort needs to be dedicated to building the "intelligent machine" that makes *all* other engineers more productive.
HostSo it's not just about building products; it's about building the *tools that build the products*. And the report even suggests becoming one of the top AI-proficient engineers in an organization is one of the best career moves right now.
ExpertAbsolutely. It points to a potential bifurcation in engineering. One class of engineer will focus on building and maintaining the AI infrastructure and agents themselves—the "intelligent machine." The other, larger group will leverage these tools to build products at an unprecedented velocity. This shift redefines engineering productivity, placing a premium on strategic thinking, prompting, problem decomposition, and critical evaluation of AI-generated work. It really heralds a new era of human-AI collaboration.
HostThis level of acceleration and automation, especially in a financial technology company like Coinbase, immediately raises red flags for me around security and code quality. How do they manage that inherent risk when they're moving at such an incredible pace?
ExpertThat's a critical question, and the report addresses it directly. Coinbase partnered closely with their security and privacy teams to develop a "repository sensitivity matrix." This framework establishes clear criteria that must be met before AI tools can be used on a particular codebase, ensuring that safety and quality standards are upheld. The core principle here is that AI itself doesn't ship bugs; it's humans who misuse or misinterpret its output. So, the guardrails are designed to mitigate that human risk.
HostAnd are there any specific measures they put in place to enforce those guardrails?
ExpertYes. Coinbase's CISO, for example, emphasized the need for "identity-aware controls," ensuring AI systems only access information relevant to a specific user to prevent data breaches. They also use AI to monitor employee activities, including code reviews, as part of their internal security protocols. It’s a multi-layered approach to ensure that speed doesn't compromise security or compliance in such a regulated industry.
HostOkay, so they've got this whole system going. But one of the most profound and perhaps unexpected consequences, according to the report, is the "death of coordination." Turakhia claims his own calendar is "almost empty." How does AI lead to less coordination overhead?
ExpertIt's quite revolutionary. The traditional friction points of software development—endless meetings for prioritization, roadmap debates, status updates—they begin to dissolve. When the cost and time to fix a bug or ship a small feature drops to near zero, the need for extensive debate about what to build and when simply diminishes. Turakhia says, "the coordination overhead of prioritizing, changing the roadmap — no, you just do things." The organization's default mode shifts from "planning to build" to simply "building." It's a fundamental change from a meeting-heavy culture to a shipping-heavy one.
HostThat's a dream for a lot of engineers, I imagine. But this whole Coinbase playbook, with Turakhia's "leader on the metal" approach, the gamification, the immense project pressure… is it repeatable? Is this a universal solution for enterprise AI adoption, or is it a unique outcome of a very specific leader in a very specific moment?
ExpertThat's the journalist's question, isn't it? The report acknowledges that. Turakhia's personal, hands-on immersion was undeniably crucial for building credibility and momentum. But, as you said, that level of engagement from a senior director is hard to scale across a massive organization with many leaders. The success at Coinbase seems to be a combination of a top-down mandate from CEO Brian Armstrong, making AI tools mandatory, and Turakhia's bottom-up, hands-on implementation that actually won over the engineers. The external pressure of rewriting the wallet also provided a powerful catalyst that other organizations might lack. So, it's an open question whether these exact tactics would be as effective in a more stable, business-as-usual environment. It certainly provides a blueprint, but perhaps not a one-size-fits-all solution.
HostFascinating. So, what are the key takeaways for our listeners from this deep dive into Coinbase's AI adoption strategy?
ExpertFirst, true AI adoption requires radical leadership. The "leader-on-the-metal" approach, as exemplified by Turakhia, is incredibly powerful for building credibility and overcoming initial skepticism. Second, reframe AI from a mandate to a relief. By focusing on eliminating "toil" and mundane tasks, you make AI an ally to engineers, rather than a threat.
HostAnd third, prioritize impact over vanity metrics. Ditching metrics like "lines of code generated by AI" in favor of holistic measures like "lead time for changes" ensures you're optimizing for real business value and velocity.
ExpertExactly. Fourth, think beyond off-the-shelf tools. Building bespoke internal AI agents, like Cloudbot, can automate entire workflows and create exponential efficiencies unique to your organization. And finally, recognize the evolving role of the engineer. The future isn't just about writing code; it's about prompting, managing, and verifying AI output, leading to new archetypes like the "super builder."
HostIt's a compelling vision. As we wrap up, I'm left wondering: if AI can dissolve coordination overhead to this extent, what does that mean for the very structure of engineering organizations in the coming years? And for individual engineers, beyond becoming "super builders," how do we ensure that creativity and human ingenuity remain central when so much of the routine is automated?
