A while back I wrote about the four lenses of productivity. Here’s how each one has moved now that everyone builds with AI.
A couple of years ago I wrote about the four lenses of productivity. The idea comes from a research-based framework, and the DX team has written about it too. The short version is that productivity is not one thing. It shows up at four levels, stacked on top of each other:
- Individual
- Team
- Organization
- Market
Here’s how each one has moved now that AI is everywhere. AI poured almost everything into the first lens, individual productivity, which happens to be the one that matters least.
You give a team AI and every engineer gets faster. You can see it happening. Everyone ships code quicker than last year, everyone feels more productive, and they are. Then you look at how long an idea takes to reach a customer, and it hasn’t moved much at all.
The engineers got faster. The company didn’t.
Level one: your engineers got faster. That was the easy one
This is the lens everyone stares at, because it is the easiest to see. AI made every developer quicker at writing code, and around 90% of engineers use it daily now, so this isn’t an adoption story. Everyone is already in.
A study in July 2025 put this to the test. Experienced developers used AI on real tasks and expected it to make them about 24% faster, but when they were timed they came out 19% slower. They felt faster while they were measurably slower, and they had no idea. So even at the lens we care about most, what people feel and what happened are two different things.
Level two: a fast team isn’t just a pile of fast people
Go up a level. A team doesn’t get faster because everyone on it is fast. It gets faster when someone is always watching for what’s blocking everyone else.
This is where glue work lives, and it was undervalued long before AI showed up. On most teams the person who matters most is the one making sure the communication, the planning, the feedback and the risk-watching keep happening. They may not write the most code in a given week, but they are the reason the code that does get written adds up to something. Most companies have not thought about the glue part yet.
On one team I saw two strong engineers both raising PRs quickly, both pleased with how much they were getting through, and neither reviewing the other’s work. Two fast people had built a bigger pile of code that nobody had looked at. When everyone optimizes their own output and nothing else, the team can get slower, because the work still has to come together somewhere and nobody is minding that spot.
Level three: the weeks are hiding in the org
Coding was rarely the slowest part of the delivery cycle. AI made that part faster without touching what was making releases slow.
This is the lens almost nobody measures, and it’s where the weeks go. It is also the level your customers feel, because it’s where the work finally reaches them.
Think about everything that happens between a ticket getting created and the customer having the thing in their hands. The approvals, the environments, the handoffs from one team to the next. That is the real delivery timeline, and the coding is a small slice of it.
At many places, a 20-minute change takes 11 days to go live, because of the quality gates between merged and done. It is easy to call a team like that slow, but they were the opposite. Companies add gates one at a time, each one after something broke, and every gate is a scar from an incident. Scars leave fear, fear makes you cautious, and that caution turns into more gates. Enough of them pile up and they become the bottleneck.
This isn’t one team’s problem. The wider data says the same. DORA’s 2024 research found that as AI adoption rose 25%, delivery throughput slipped about 1.5%. The best teams in DORA’s data ship on demand, with a change live in under a day, while the slowest take one to six months. The difference between them is the delivery system around the code. Typing speed has little to do with it.
Level four: did any of it reach the market?
The top lens is the market, the value your work delivers to customers and everyone who depends on it. It asks whether the thing you shipped was worth shipping at all, because you can move fast through the three levels below it and still pour that speed into features nobody wanted.
AI makes this lens harder to get right. When building gets cheap, teams build more, and a lot of what they build is stuff nobody asked for.
There is a cost here that is easy to miss. When teams bring in AI and stop watching their change-failure rate, it tends to creep up 30 to 60% over the first few months, so some of the speed you think you gained is bugs you haven’t found yet. A feature that breaks in production delivered no value at all. It only looked like it did for a while.
Why AI landed on the wrong lens
Because the first lens is the one with clean numbers. Commits, pull requests, story points, lines of code. All of them measure a single engineer at a desk. The metrics we lean on are the ones that are easy to count, and whether they track anything that matters is a separate question. AI walked straight into that habit. We aimed it at the productivity we could measure, got a real win there, and now we are wondering why the company didn’t move. We have done this before, with lines of code, tickets closed, code coverage, commit count. History is full of metrics that stuck around for one reason, they were easy to count.
First, find where a change stalls
AI has mostly finished with the first lens. The other three are where your attention goes now, and the way in is the same for all of them. Before you add more AI, study your DORA and DevEx metrics and find the step that adds the most delay on a change’s way to the customer.
Is it a PR nobody has reviewed, a ticket parked in the same Jira status for three days, or a change blocked behind an environment that isn’t ready? Or is it rework, because screens got generated faster than anyone could check them against the business rules and the product requirements?
Wherever it is, that stalled time is your real delivery time, and most of it has nothing to do with how fast anyone writes code.
Back in 2011, right after going public, LinkedIn froze all feature work for about two months, rebuilt how they shipped, and went from deploying once every two weeks to three times a day. Your version can be smaller. You don’t need a full freeze, only an honest look at the steps that add the delay, and the will to cut that waste, with AI or without it.
AI is a robot, and your company is the road
In a few US cities, little robots roll down the sidewalk and drop food at your door. The wheeled robot shows up and dinner arrives.
Put that same robot on a street in a lot of other countries and it won’t get far. The obstacles are part of it, but the deeper reason is that the US spent 60 years getting the roads right. Sidewalks slope down to meet the road with no sudden drop, drivers stop at red lights, and at a stop sign, which is only a sign and not even a light, people still come to a full stop before moving on. Sixty years of small things done right let a robot deliver your dinner. Drop that same robot onto roads with years of technical debt and you get a wasted meal and a wrecked robot.
AI is that robot. It’s the new thing you are rolling into the company, and if you run it on top of your old practices, the same broken handoffs and approval mazes and stale docs, it won’t give you the efficiency or the savings you are after. Everything you’ve been doing since day one has to be in good enough shape for the robot to run on.
So before you count how many seats of AI to buy, or how many people to hand it to, look at your own roads. Find the steps where a change stalls on its way to a customer, and fix those first. The robot only delivers if the roads are right.
