How I AIHow Coinbase scaled AI to 1,000+ engineers | Chintan Turakhia
CHAPTERS
- 0:00 – 4:12
Scaling AI adoption to 1,000+ engineers: why it’s “adapt or die”
Claire and Chintan frame the core skepticism: can a large, high-performing engineering org actually get durable value from AI? Chintan sets the bar—Coinbase has 1,000+ engineers—and explains the real challenge isn’t initial trials, but making adoption stick.
- •AI at scale is possible, but requires urgency and intent
- •Coinbase scale: 1,000+ engineers
- •Early adoption often looks like “hello world” experimentation that fades
- •The central question: how to make usage persistent and meaningful
- 4:12 – 5:42
Rewriting the product under extreme timelines—and why AI became the accelerant
Chintan explains the context that forced experimentation: a major rewrite from a self-custody wallet into a consumer social app, with a six-to-nine month delivery window. The combination of a smaller team and a massive competitive goal pushed them to seek velocity multipliers.
- •Large rewrite: wallet → consumer social app using crypto
- •React Native architecture decisions needed rethinking
- •Aggressive deadline (6–9 months) vs competitors with huge head starts
- •AI explored primarily as a way to accelerate engineering throughput
- 5:42 – 7:14
The early tool “trough of sorrow”: models weren’t ready, engineers wrote it off
Chintan recounts trying Cursor early when it felt underpowered, creating quick skepticism among engineers. He connects this to prior company attempts (e.g., Copilot) that spiked briefly but failed to sustain usage.
- •Early Cursor experience felt weak due to model capability limits
- •Engineers rapidly discard tools after a poor first impression
- •Prior AI tool rollouts saw initial uptake but low retention
- •Mental model: models will improve—teams need reps like going to the gym
- 7:14 – 9:57
Leadership conviction + hands-on coding: “show engineers, don’t decree”
Both discuss that organizational change requires a credible leader who actively uses the tools and can demonstrate real workflows. Chintan emphasizes that mandating AI use doesn’t work; leaders must model usage and translate failures into actionable tactics.
- •Transformation needs a high-conviction, hands-on leader
- •Demonstrations beat mandates (“I decree you must use AI” fails)
- •Leaders must learn the tool deeply to guide engineers effectively
- •AI helped pull engineering leaders back toward coding and away from meetings
- 9:57 – 11:33
Start with toil: unit tests, linting, and “create draft PR” workflow wins
Chintan shares the practical wedge: eliminate soul-sucking work first to earn trust. He describes Cursor rules and a key aha moment—using AI to generate draft PRs and reduce friction in routine Git workflows.
- •Target early wins where engineers feel pain: tests, linting, small papercuts
- •Use Cursor rules to standardize and amplify helpful behaviors
- •Aha: “create a draft PR” removes tedious Git ceremony
- •Cultural shift: no prestige in memorizing Git commands—optimize for shipping
- 11:33 – 12:03
Making wins visible: the ‘cursor-wins’ channel (and wins + losses)
They discuss lightweight internal virality: engineers posting tangible outcomes builds social proof. Claire adds the value of sharing failures too, so teammates can suggest rules, prompts, and fixes.
- •Dedicated Slack channel turns individual wins into collective momentum
- •Social proof drives adoption faster than top-down directives
- •Posting failures accelerates learning (“wins and losses”)
- •Small, frequent demonstrations keep the tool in daily conversation
- 12:03 – 16:42
The PR Speed Run: a 15-minute ritual that flipped adoption behavior
Chintan describes a live event where everyone ships something trivial via Cursor, producing dozens of PRs rapidly. The experience created a “death to status updates, long live building” moment, later scaled to company-wide adoption.
- •PR Speed Run concept: everyone creates a small PR immediately
- •First run: ~100 participants, ~70 PRs in ~15 minutes
- •Company-wide run: ~800 engineers, ~300–400 PRs in 30 minutes
- •Pressure testing even revealed infrastructure limits (broke GitHub)
- 16:42 – 20:03
What to measure: compressing time from ticket → user impact (not vanity AI metrics)
Chintan rejects metrics like “AI lines of code” and focuses on end-to-end cycle time: from ticket creation to user-facing change. He highlights improvements in PR review time and the compounding impact of faster iteration loops.
- •AI is an accelerant, not a headcount replacement
- •North Star metric: time from ticket to change landing for users
- •Improve PR review time (example: ~150 hours → ~15 hours)
- •Faster cycles unlock faster customer feedback loops and product iteration
- 20:03 – 27:33
Demo: analyzing Cursor adoption with Cursor—cohorts, dashboards, and playbooks
Chintan demonstrates downloading Cursor admin analytics CSVs and using Cursor itself to find usage clusters and produce scripts and dashboards. The goal is to identify power-user patterns and turn insights into actionable guidance for each cohort.
- •Use Cursor analytics CSV export as the raw dataset
- •Cluster users by behavior (agent-heavy, tab-heavy, balanced, minimal)
- •Generate reusable Python scripts + simple HTML dashboards
- •Convert analysis into guidance and internal playbooks to replicate power users
- 27:33 – 36:52
Operationalizing the insights: from CSV → visuals → Slack-ready guidance
They emphasize the managerial superpower: rapidly transforming messy metrics into clear narratives for teams and leadership. The demo outputs cohort guidance, “motivational” adoption tips, and shows how managers can distribute distilled takeaways via Slack.
- •Managers can do once-onerous analytics without pulling an IC
- •Turn deep analysis into communications artifacts (e.g., Slack posts)
- •Practical adoption advice: agent mode for everything, better prompting, iterate
- •Fun/novel outputs can increase engagement and learning velocity
- 36:52 – 43:12
Demo: real-time feedback-to-feature—audio capture → LLM triage → Linear ticket → PR
Chintan shows a workflow that captures spoken feedback, extracts bugs, and creates Linear tickets automatically. From there, a Slack bot can generate a PR, drastically reducing the lag between user feedback and an actionable code change.
- •Replace manual bug bash notes and ticket transcription with automated capture
- •LLM extracts bug statements and suggests clear titles and journeys
- •One-click creation of Linear tickets from structured summaries
- •Immediate handoff to an agent to start PR creation from the ticket context
- 43:12 – 47:09
Why build an internal Slack bot: security constraints, virality, and ‘context as the fuel’
Chintan explains building an in-house agent (“Claude Bot”) due to internal requirements and to embed workflows where engineers already work—Slack. The bot pulls context from Linear and uses MCP integrations to access systems like Datadog, Sentry, Amplitude, and internal databases across codebases.
- •Internal agent built to meet security/compliance constraints
- •‘Super builder’ role: create more super builders by enabling others
- •Slack as the distribution channel—public workflows go viral internally
- •Linear as the source of truth for context; MCPs connect to observability/data tools
- 47:09 – 55:24
Driving org-wide AI adoption: practical advice + personal workflow (wine menu taste modeling)
Claire and Chintan close with career and adoption advice—be among the most AI-capable people in your org, reduce friction via existing platforms, and don’t fear building internal agents. Chintan shares personal use cases, including extracting preferences from wine notes and choosing bottles from a menu based on taste profile.
- •Career advice: become a top AI practitioner inside your engineering org
- •If you can’t use cloud agents, building internal agents is feasible with SDKs
- •Personal productivity: turn photos/emails into structured actions (calendar invites)
- •Taste modeling: infer wine preferences from notes and recommend menu picks/value
- 55:24 – 58:57
Lightning round and wrap: fewer meetings, more code, and prompting ‘tough love’
In the final minutes, Chintan explains how AI changed his time allocation—his calendar is nearly empty and he codes more. He also shares a pragmatic prompting style for when models go off-track, then plugs the Base App launch and hiring needs.
- •AI reduces coordination overhead; meetings drop dramatically
- •Leaders can contribute more directly in code and technical problem-solving
- •Prompting style: clarify, correct, and escalate when the model isn’t listening
- •Closing: Base App launch, hiring super builders and engineers, where to find him
