Coinbase AI Adoption: Measuring Usage vs Business Value

Every day we are flooded with information about AI: news, warnings, success stories, deployment frameworks, risk assessments, debates about agents, and an endless stream of advice about what to do and what to avoid, arriving from almost every direction at once, like an avalanche that now reaches every organisation.

And yet, looking closely at how most organisations actually approach AI adoption, the conversation tends to follow a surprisingly similar shape. On one side are companies still working out the benefits, how to use it, or how to adopt it properly; on the other you have organisations where progress is communicated through rollout numbers, dashboards are built to track activity, and leadership conversations grow steadily more confident simply because there is visible data on the screen, until at some point nobody asks the harder question: is this actually creating value?

That is one of the reasons I chose Coinbase as the case to examine here, because the data is publicly available and leadership openly described how the adoption was managed and what it was producing. And honestly, real examples also help us see what other industries are doing, draw out lessons, and understand what transfers to our own organisation.

This is, at its core, what happens when an organisation measures one thing well, and another barely at all.

The case: Coinbase

By early 2026, Coinbase was reporting that more than half its code was written by AI and around 60% of support tickets were handled by AI systems, the visible result of a push that, in 2025, had turned AI adoption into an explicit organisational priority, with engineers required to onboard onto tools like Cursor, Copilot, and Claude and leadership pressing for pace to the point of asking why every engineer could not simply onboard by the end of the week.

Those are clear numbers, and they are also, almost entirely, numbers about adoption: how much the tools are used. What proves far harder to find, across everything the company reported publicly, is an equivalent number about impact, one that would show whether the code is better, whether support resolves issues more effectively, whether the savings are real.

And this reaches well beyond Coinbase: it is what tends to happen in almost any organisation adopting AI under pressure, and what tends to stay out of view while it does.

Why AI adoption is easier to measure than AI impact

Adoption gives you a number right away. You can count the engineers onboarded this week, the share of code generated this month, and the figure is there the moment you ask: traceable, aggregable, easy to put in front of a leadership team.

Impact works differently. Knowing whether the code is better takes baselines, quality criteria, time, and sustained observation, and those instruments tend to arrive later, built well after adoption is already moving.

So the two are measured on different clocks:

• Adoption: usage rates, onboarding levels, tickets processed.
• Impact: output quality, value generated, effect on productivity and risk.

Under pressure, an organisation needs signals of progress, and adoption is the signal available, so it stands in for impact by default rather than by decision.

There is a logic underneath this. Coinbase has long held that action produces information: you move, you watch what happens, you adjust. Under that view, the metric already in hand takes the place of the one that action has not yet had time to build, and an activity number with no impact number beside it can be read as evidence of success.

There is a name for this. As the image above lays out, when a measure becomes a target it stops being a good measure, the pattern Goodhart's law describes, so the number that once tracked adoption usefully becomes the thing teams optimise for, and the signal drifts from what it was meant to capture.

This shows up in another place too: how the company decides. For a product bet like USDC, judgement is spread wide, and a single sponsor can carry an idea forward without consensus. For AI adoption, the company moved the other way, setting one expectation and pressing for pace. The same organisation distributes judgement in one domain and centralises it in another, which tells you something about how it reads each one.

You see it again in the balance between risk and value. The riskiest systems get careful, differentiated control, while the question of where AI actually creates value is handled with far less of that same precision. Risk is instrumented. Value, so far, is mostly counted.

The full case study traces all of this across every function Coinbase reported on: code, support, compliance, and decision-making.

What the metrics leave out of view

Once you start looking for the impact number, you notice how much stays outside the frame.

The reported figures cover volume, while the quality of the generated code stays out of view, whether it carries more or fewer defects, whether rework went up or down, whether incidents in production changed. Support, in turn, is reported as coverage, the share of tickets handled by AI, rather than as satisfaction or resolution, and the cost of adoption stays off the ledger too, from onboarding time to review hours to licences.

We hear a lot about the tools and little from the people using them: engineers appear as onboarding rates, support users as processed volume, and the reviewers checking AI-generated code as a control mechanism, with little record of how that workload grew.

That last one carries an assumption worth surfacing: that human review will hold as a safeguard. Yet as the volume of generated code rises, so does the volume waiting to be reviewed, and if review capacity grows more slowly, the safeguard thins out gradually, without any single moment that announces it.

Here is the question this opens, and it is the one that matters most: a system built to measure, reward, and report adoption knows whether adoption happened. If the quality of what was shipped slipped slowly over six months, would that same system notice? The dashboard would stay green while usage kept climbing.

The case study maps these blind spots in full, one function at a time.

There is always more than one way to adopt

The route Coinbase took, moving fast, tracking usage, and guarding its riskiest systems, is just one option among several. Seeing the others is where the case stops being a story about one company and becomes something you can use.

There are other ways to go. An organisation could keep that same pace but build the impact metrics alongside it, so usage and value grow together. It could move quickly where the value is easy to verify, and more slowly where it is harder to see. Or it could wait for proof of value before scaling at all, letting evidence earn the expansion.

Every one of these paths gains something and gives something up. Going fast means living with less certainty; waiting for certainty means giving up speed; adjusting route by route brings coherence but a harder story to tell. Which path an organisation takes tends to show what it values most, whether or not anyone said so out loud.

The case study lays out four routes in full, showing for each one what it optimises, what it puts at risk, and the conditions it needs to work.

Turn the questions on yourself

It is tempting to close a case like this with a verdict, but that would miss what makes it useful.

Coinbase moved decisively under real competitive pressure, built genuine capability, and protected itself where the risks were most visible. What the case shows is something subtler and far more common: that even a capable organisation, moving fast for good reasons, can end up measuring with precision what is easiest to observe, while what will finally decide whether the bet paid off stays harder to see.

That is why it reads better as a mirror than as a warning, since the questions it raises point away from Coinbase and towards your own organisation:

• When you report on your AI adoption, are you reporting activity, or impact?
• If the quality of what you ship dropped slowly over six months, would any number you track today show it?
• Where does your ability to measure value actually live, and does it reach the decisions that matter, or stay in the corner where it was built?

Most organisations adopting AI already hold the first number, so the harder and more honest work is building the second, and being willing to look at it. And for organisations still weighing whether to start, these same questions can guide where to begin, showing what to put in place before adoption gets ahead of understanding.

---

This article draws on a longer case study of Coinbase's AI adoption, which develops the structural analysis in full, maps the blind spots function by function, and lays out four routes an organisation can take under pressure, with what each one optimises, risks, and needs to work.