# AI Is a Multiplier, Not a Metric URL: https://danylovorvul.com/blog/ai-is-a-multiplier-not-a-metric/ Author: Danylo Vorvul Date: 2026-05-19 Tags: engineering, tooling Description: Tokens are a billing metric. They belong on the finance dashboard, not the engineering one. Someone at a big-tech company is being measured this quarter on how many tokens they burn. I wish I were exaggerating. The internal pressure exists. Adoption targets get set, and the easiest thing to count is consumption — calls made, tokens spent, sessions opened. So that's what becomes the KPI. The engineer who genuinely closed a tricky bug with a five-minute Claude session looks worse, on the dashboard, than the one who fed every README into the model and printed back what was already there. We've spent fifty years arguing about how to measure software productivity. It's a tricky thing. We have working frames now — DORA at the team level, [SPACE →](https://queue.acm.org/detail.cfm?id=3454124) at the personal level — and the conversation has matured. Then AI shows up, and the first metric an enterprise reaches for is *tokens burned*. That isn't a productivity metric. It's an activity metric. They are not the same thing. ## What SPACE got right [SPACE →](https://queue.acm.org/detail.cfm?id=3454124) (Satisfaction, Performance, Activity, Communication, Efficiency) is one of the few productivity frames I trust, mostly because of what it refuses to do. It doesn't pick a single number and call it productivity. It triangulates. Activity is one fifth of the picture; you also need Performance, and Performance is the outcome of the system, not a count of its motions. A team can be very busy and produce nothing. SPACE makes that visible. The problem is that SPACE was built for a world where Activity at least correlated with Performance. PRs merged, commits landed, reviews given — they were noisy proxies, but they pointed in roughly the right direction. AI has decoupled them. With Claude or Cursor, you can ship a Linux kernel of LOC per week and produce nothing of value. Activity now actively misleads. ## The second axis So you measure productivity on one axis. Fine. What goes on the other? This is where most companies stop thinking and pick "AI usage." That's wrong, but it's wrong in a specific way worth naming. AI usage measured as token count or session frequency is the same mistake as measuring engineering productivity by lines of code. It counts the motion, not the multiplier. The right second axis is **AI-SDLC adoption** — depth of integration into the delivery flow. Not "do you use AI" but "where, with what validation, with what reusable artefacts left behind." A power user who fires off a thousand prompts a week and ships no Skills, no SOPs, no validated context is not a power user. They're a high-volume single-player. A senior who uses AI sparingly but turns every solved problem into a reusable Skill is moving the org further than the prompt-blaster ever will. Score that adoption on a 0–4 scale, plot it against SPACE-derived productivity, and you get a quadrant map. ## The four quadrants **High productivity · low adoption** Strong senior who hasn't onboarded to AI yet. Don't break their flow; extract their patterns into Skills others can use; route AI at the parts they don't enjoy — docs, tests, review context. **High productivity · high adoption** Target state. AI augments delivery, handoffs drop, Skills compound, the next engineer onboards faster because the last engineer left context behind. **Low productivity · low adoption** No traction, no output. Training, pairing, simple Skills, SOPs for repeated work. **Low productivity · high adoption** The risky one. Heavy AI use that isn't converting. Big PRs, rework, regressions, no validation, no reusable artefacts. A token-burn KPI sends your whole engineering org here. The bottom-right quadrant is dangerous precisely because, without the productivity axis, it looks identical to the top-right. Both read as "heavy AI users." A token-counter cannot tell them apart. A token-counter actively *manufactures* the bottom-right quadrant by rewarding the behaviour that produces it. ## AI is a multiplier Here's the part that should settle the strategy debate. AI doesn't make you a different engineer. It makes you a more-of-whatever-you-already-are engineer. If you're a solid 1x engineer and AI gives you a 30% lift, you're a 1.3x engineer. If you're a 10x engineer and AI gives you the same 30% lift, you're a 13x engineer. The multiplier is the same. The base is what changes. This is why the high-adoption-high-productivity quadrant is the only one worth aiming at. You don't get there by forcing adoption on a low-productivity baseline — you get higher-volume mediocrity. You get there by raising the baseline and then layering adoption on top. Push the adoption axis alone and you're multiplying noise. ## Where this fails in the wild I've heard versions of this story from inside a few large clouds, AWS being the loudest. Adoption gets pushed top-down as a strategic priority. Engineers get measured on AI activity. The dashboard goes up and to the right. Senior engineers — the people whose productivity was already high — find their workflow degraded by mandated tooling and start working around it. Junior engineers learn to *perform* AI usage rather than use it. The org slides from the top-right quadrant into the bottom-right one, and the dashboard keeps celebrating. This is the predictable failure mode of measuring one axis. You will optimise the axis you measure. If the axis is activity, you will get activity. If the axis is adoption divorced from outcome, you will get adoption divorced from outcome — louder, faster, and at greater inference cost. ## What to measure instead Pick a productivity frame you trust — SPACE works. Build an adoption frame that measures depth, not noise. Plot the two. Look at the quadrants. Move engineers from where they are toward the top-right, but never by sacrificing the axis you weren't measuring. Tokens are a billing metric. They belong on the finance dashboard, not the engineering one.