AI adoption isn’t the same as AI usage

Every engineering org has the same chart these days: seat activations up, token spend up, some slide bragging about 80% weekly active usage. Then you sit in that team's planning meeting and nothing about how they actually build software is different. That gap, according to a piece from Webflow published on The New Stack, is the real problem, and most adoption metrics are built in a way that hides it rather than exposes it.

The argument leans hard on Goodhart's Law. Token spend just means someone typed into a box. Pull request counts mean commits landed. "Percentage of code written by AI" means an autocomplete got accepted. None of that tells you the work got better. The comparison drawn is to teams gaming test coverage with assertions like expect(true).toBe(true) — the line goes green, the number looks good, and nothing was actually tested. AI usage metrics, the piece argues, have the exact same failure mode: tell a team usage is a performance signal and usage climbs within a week, proving only that people can read incentives.

The piece breaks "adoption" into three tiers that get lumped together but aren't remotely equal. Tier one is someone tweaking their own workflow — using AI for commit messages or getting oriented in code — which is real but fragile, and evaporates the moment a deadline hits and people fall back to what they know works. Tier two is someone permanently handing off a recurring task, no longer doing it themselves but checking a workflow's output instead; this survives pressure because reverting would just create more work. Tier three, the rare one, is the team deciding as a group that a process now runs differently, writing it down, and enforcing it regardless of anyone's individual enthusiasm. Only tier three survives turnover and a rough quarter, and most organizations never get past tier one.

Webflow's own example of a tier-three change: treating prompts as shared, versioned artifacts stored in the repo with an owner and review process, instead of scattered personal scratch files that got lost every time someone switched machines. It didn't need new tooling — just a decision that this category of thing was worth maintaining.

The piece also flags a specific trap with agentic workflows: leverage is front-loaded. Getting from blank page to a plausible draft is much faster now, but going from plausible draft to something correct and shippable isn't faster at all, and that's still the engineer's job. So people fire off five tasks at once, feel productive, and then get buried reviewing five things they didn't write — serializing on their own attention rather than parallelizing anything. Weeks later that shows up as a usage dip that gets misread as a training problem rather than a work-shape problem.

The recommended fixes are deliberately unglamorous: permanently kill one recurring manual job per person rather than running endless trials, make exactly one team norm official in writing each quarter, and stop reporting usage numbers upward — report the outcome the usage was supposed to produce instead, even in quarters where that number looks worse.