Why Developers Disagree About AI Productivity

I think we're frequently talking past each other about AI coding tools.

• One group reports transformative productivity gains, often claiming 2-5x improvements
• Another group finds minimal impact, seeing AI tools as marginally helpful at best

My suspicion is these two groups are using "productivity" to mean completely different things: "I can implement 5x more code changes" vs "I generate 5x more business value." Both experiences are real, but they're not the same thing.

There's always been a threshold in software development: above it, code changes are worth the effort; below it, they sit in backlog purgatory. AI tools lower implementation costs, moving that threshold down so more backlog items become viable.

The "5x productivity" crowd is excited about this expanded scope, while skeptics correctly note that the highest-value work hasn't fundamentally changed.

Definition 1: Implementation Efficiency

Developers in this group define productivity as "the volume of intended code changes I can implement per unit time."

When I say "code change," I mean a discrete improvement not total lines of code. You've got the current code and you want to do something differently. With AI coding tools, it's much easier to exert your will on these individual improvements.

These engineers have always maintained a mental backlog of improvements they'd like to make: better error handling, comprehensive documentation, cleaner abstractions, stronger type checking, additional validation, more thorough test coverage. But the economics rarely justified spending time on many of these improvements.

If our developer gets the important stuff done by 2pm instead of 5pm, what do they do next? These developers say "of course!", "now I have free time to make some of those lower-value changes."

For these developers, AI tools fundamentally change the equation. The implementation cost for these improvements has dropped dramatically, allowing them to act on more items from their mental backlog. When they say "I'm 5x more productive with AI," they mean "I can implement 5x more of the changes I've always wanted to make."

Definition 2: Business Impact Efficiency

Developers in this group define productivity as "the business value I can generate per unit time."

These engineers have deeply internalized the economic constraints of software development. They've trained themselves to focus primarily on changes with the highest business leverage. They often intentionally defer lower-ROI improvements regardless of how technically desirable or interesting they might be.

If our developer gets the important stuff done by 2pm instead of 5pm, what do they do next? These developers think, "I already did all the highest-impact things I know about. How is an AI tool going to give me something as good or better than the work I already prioritized?" When they look at their remaining options, they see the same low-value changes they already decided against earlier because they weren't impactful enough.

For these developers, AI tools don't fundamentally change the economic equation. While implementation speed increases, they were already focusing on the highest-value work. When they hear others claim "I'm 5x more productive with AI," they check business metrics and think, "If you were really 5x more productive, wouldn't we be seeing much larger profit impacts?"

The Word Processor Parallel

This situation parallels the introduction of word processors to the publishing industry:

• Individual authors immediately saw word processors as revolutionary. They could edit, rearrange, and experiment freely without retyping entire manuscripts. Their definition of productivity - words refined per day - either by getting to the quality bar quicker, or reaching an even higher bar each day.

• Publishers, measuring productivity by sales and market impact, were less impressed. If an author produced the same category of book aimed at the same audience, the fact they wrote it more efficiently didn't necessarily change business outcomes. A publisher needs books that bring in new readers, new dollars. Telling the publisher we can now fight over the same old pool of revenue twice as fast is not interesting.

Different Measures, Different Conclusions

Both groups are measuring real phenomena, just different ones:

• Implementation efficiency genuinely has increased for many developers
• Business impact efficiency might not have changed as dramatically

What Else?

But maybe that's the wrong way to think about it. Maybe AI agents can make strategic decisions if you build the right environment for them: good instructions, relevant context through tools, workflows as building blocks.

Where are the stories about AI reading your sales and customer support Slack channels and messaging you pssst, here's a better change to make today than stupid CSV exports.

They're not building agent environments or having design conversations. They're asking for implementation help after they've already decided what to build. So of course they only see implementation speed improvements.

It's not really surprising that strategic data isn't readily available in the right format for AI agents. There wasn't a need for sales conversations, customer support tickets, and usage analytics to be structured for AI decision-making before. There are a lot of unknowns to figure out, so building those systems will take time.

Meanwhile, the code editing use case was already half-built. IDEs already had autocomplete suggestions and snippets. You just needed to plug an LLM into that existing product experience. Of course that's where we're seeing results first.

My Two Cents

My experience has been straightforward: I ask the AI to make code changes, it helps me write them faster, but nothing fundamentally changes about my work. It's the same tasks, just quicker implementation.

But maybe your experience is different. I'm genuinely curious:

• Has your thinking process changed? Are you solving different problems now?
• Are you delivering business outcomes that weren't possible before?
• Has it changed what you choose to work on, not just how quickly you work?

If you're having an experience beyond "I can make more code changes now," that's what I want to hear about.