How I AI: Chintan Turakhia’s Playbook for AI Adoption at Coinbase

In this episode of How I AI, Coinbase engineering leader Chintan Turakhia demonstrates how he studies Cursor usage, shortens the path from user feedback to a proposed code change, and uses visible team experiments to spread AI practices across a large engineering organization.

Coinbase has more than a thousand engineers. Chintan's group was also rebuilding Coinbase Wallet as a consumer social app on a six-to-nine-month timeline. He began by using the tools himself, sharing concrete wins, and reducing friction for engineers who wanted to try them.

The demonstrations include an adoption-analysis prototype built from sample Cursor data, an internal feedback and coding-agent workflow, and a personal ChatGPT project for wine recommendations. Each one turns existing context into a smaller decision surface.

Measure behavior before prescribing adoption

The data-driven AI adoption workflow includes the cohort prompt, dashboard output, and the review questions needed before turning usage patterns into a team program.

Earlier tool rollouts produced a burst of experimentation that did not last. Chintan wanted a more useful view than license activation, so he explored how different usage patterns might translate into coaching for engineers.

Start with the fields the tool actually exposes

Cursor's admin interface can export a CSV with fields such as `accepted_lines`, `chat_lines`, and `chat_lines_deleted`. For the episode demonstration, Chintan used invented sample rows that followed the real schema rather than exposing employee-level production data.

Look for patterns, not a single adoption score

Chintan loaded the sample CSV into Cursor and asked the agent to propose a cohort analysis. He used Claude Opus High in plan mode so he could inspect the approach before allowing it to build the analysis.

I want to understand the usage of Cursor. I already know we have light users all the way to power users. What are the natural clusters of usage? Can you find them across the team? What is the best way to cohort them?

The plan considered volume, agent use, tab completion, model preference, acceptance rate, and feature breadth. It proposed a reusable Python script, enriched CSV output, and a small HTML dashboard.

Turn the analysis into coaching hypotheses

After Chintan approved the plan, the agent wrote the Python analysis and produced a simple HTML view. The percentages, names, and user counts visible in the demo were sample results, not measurements of Coinbase employees.

The sample analysis grouped behavior into patterns such as:

• Agent-heavy users: People who rely on the chat agent for larger tasks.
• Tab-heavy users: People who prefer inline completion and tighter control.
• Balanced users: People who use both agent and tab-completion workflows.
• Minimal or inactive users: People with little activity in the sample.

Chintan then asked the agent to translate the cohort model into explicit next steps:

Based on the data, generate guidance for each user cohort on what they should do to advance and graduate to a super user. I am looking for explicit guidance, effectively like I wanna turn this into some type of playbook.

Treat the playbook as a prototype

The model generated a dark-mode HTML playbook with cohort-specific suggestions and slogans such as "Stop typing, start shipping" and "Tab harder." These were prototype coaching ideas generated from sample data, not validated performance recommendations.

The useful pattern is to move from raw usage fields to a hypothesis about behavior, then review that hypothesis with the people who understand the work. The dashboard makes the analysis discussable; it does not establish that more generated code means better engineering.

Shorten the path from feedback to a proposed fix

The feedback-to-pull-request workflow makes each handoff explicit: capture the report, review the issue, identify the repository, and keep the agent's progress visible.

Chintan wanted to reduce the handoffs between a dogfooding session and an engineer investigating a problem. His internal workflow captures feedback, creates a structured Linear issue, and passes that context to a Slack-based agent.

Capture the problem while it is happening

Chintan built a small web app in about half a weekend. During an in-person or remote session, a teammate can record feedback from a phone instead of reconstructing it later from notes.

For the demo, he recorded a sample report about numbers not appearing in a trade form.

Create a reviewable issue from the recording

A language model transcribes and summarizes the recording into a proposed bug report. The person using the tool can review the summary before creating the issue.

The interface then creates a Linear ticket with a suggested title and relevant user-journey tags.

Give the coding agent the approved context

Coinbase built an internal Slack agent called Claude bot. Despite the name, Chintan said it can use multiple underlying models. He triggered its pull-request command with the repository and Linear issue:

Claude bot create pr --repo wallet-mobile --ticket [TICKET_ID]

The internal agent can retrieve context from Linear and other approved company systems, then plan or attempt a change across relevant codebases. Coinbase built it in-house because its security requirements prevented the team from deploying available cloud background agents at the time.

In the recorded demo, the agent began working but the episode did not show a completed pull request. The demonstrated value was the connected handoff from recording to issue to agent, with progress visible in a shared Slack channel.

Build a preference model from your own notes

The same pattern is broken out in the personal AI sommelier workflow: derive the profile from your evidence first, then apply it to a new list.

Chintan also showed a personal version of the same pattern: extract preferences from his own notes, then apply the resulting profile to a new menu.

Extract the preferences you repeatedly reward

Chintan photographed handwritten notes from a champagne tasting, including ratings and comments about particular producers.

He uploaded the images to ChatGPT and asked it to infer a taste profile:

Here are a bunch of champagnes that I tasted, figure out from my notes what my taste preferences are.

The model summarized preferences for low sugar, high acidity, some aging, grower champagne, and certain chalkier styles. Chintan compared the profile with what he already knew and said it was accurate.

Use the profile to narrow a real menu

Chintan then photographed a restaurant wine list and asked for recommendations against the saved profile:

What would I like from this list? What are good values?

ChatGPT returned value picks, splurge options, and bottles to avoid. Chintan recognized at least one recommendation as a wine he had tried and liked. The workflow narrows a long menu using his own evidence; it does not replace checking availability, price, or the judgment of a sommelier.

How Chintan approaches adoption

Chintan argues that adoption comes from showing engineers useful work rather than issuing a mandate. His team created a "Cursor Wins" channel, and he ran a speed-run session in which roughly 100 participants opened about 70 pull requests in 15 minutes. Those were pull requests opened, not a claim that all 70 were merged or shipped.

The recurring design choice is visibility. Usage analysis becomes a dashboard the team can question. Feedback becomes a Linear issue with its source attached. Agent work happens in a shared Slack channel. That visibility helps people learn from one another while keeping review and engineering judgment in the loop.

Across all three examples, Chintan does not ask people to trust an invisible AI process. He creates an artifact they can inspect: a dashboard, a ticket, a Slack thread, or a written preference profile. That artifact gives the next person enough context to challenge the analysis and continue the work.