Amazon's spokesperson told NPR that their in-house AI tools "help engineers move faster, ship more secure code, and spend less time on busywork." Through surveys, "engineers tell us these tools help them save time and feel more productive."
Feel more productive. That phrasing is doing a lot of work.
Because when you actually talk to engineers—not in official surveys but in honest conversations—you get a very different picture. One where AI might help with specific tasks, but the overall productivity gains are murky at best.
An engineer at Amazon, speaking anonymously, was more direct: skepticism about AI coding tools is widespread, and not everyone is convinced they're actually helping.
So who's right? The company saying AI is transforming productivity, or the engineers saying they're not seeing it?
Plot twist: they're both right, which is exactly the problem.
The "Feel" vs. Reality Gap
Here's what I think is happening: AI coding tools make you feel more productive without necessarily making you actually more productive.
It's like the difference between feeling busy and being effective. They're correlated, but not the same thing.
When you use Cursor or GitHub Copilot, code appears almost instantly. That feels like progress. Your lines-of-code metric goes up. Your commits per day increase. All the activity metrics spike.
But activity isn't the same as delivery. Writing code fast isn't the same as shipping features fast. And feeling productive isn't the same as being productive.
The METR study I wrote about before found developers were 19% slower with AI, even though they were convinced they were faster. That's not a measurement problem. That's a perception problem.
The Mandates Make It Worse
What really caught my attention in the NPR piece: Amazon doesn't mandate AI use.
But elsewhere in the tech industry? Less flexible.
The Information reported that two engineers were fired from an AI startup for not using AI coding tools enough. Not for poor performance. Not for missing deadlines. For insufficient tool usage.
Meta's internal memo called for "5X productivity" gains through AI. Which sounds great until you realize that's not a suggestion—it's an expectation. And if you're not achieving it, well, good luck in the next performance review.
Y Combinator, the influential startup incubator, has apparently shifted focus so heavily toward AI that founders are noticing. As one engineer put it after leaving his job: he was "floored by how much [YC] has gone from supporting different kinds of technologies to focusing solely on AI."
When AI usage becomes a performance metric rather than a productivity tool, everyone has an incentive to overstate its benefits. Because admitting "actually, this makes me slower" could get you labeled as resistant to change or not technically sophisticated enough.
The Trust Problem
A Google survey of software engineers showed that while AI use is nearly universal, about half "somewhat" trusted AI's responses, and 30% chose "a little" or "not at all."
Think about that. Engineers are using tools they don't fully trust because... they feel like they should? Because their company expects it? Because everyone else is?
That's not how good engineering works.
You don't use tools you don't trust. Unless those tools are no longer really optional, in which case you use them and just hope for the best.
The "Workslop" Problem
There's a new term that perfectly captures what's happening: workslop.
It describes output that's technically work but of questionable value—AI-generated code that compiles but might not be maintainable, documents that exist but don't communicate clearly, tests that pass but don't actually verify correctness.
One engineer described a colleague who was "very gung ho about AI coding and thought he could get this very complicated project done very, very quickly."
Spoiler: he couldn't. But he generated a LOT of code trying. Code that someone else then had to read, understand, and probably rewrite.
That's workslop. It creates more work for teammates while making the original person feel productive. The worst of both worlds.
The Real Use Cases vs. The Hype
Here's where I think AI coding tools actually help:
Boilerplate and templates - If you're writing the same pattern for the 50th time, AI can do it. Great!
Syntax in unfamiliar languages - Need to write Python but you're a JavaScript dev? AI can help bridge that gap.
Test generation - Writing unit tests is tedious. AI is decent at it.
Quick throwaway scripts - Need to process some data once? Perfect AI use case.
But for complex features? Architectural decisions? Debugging weird production issues? Reviewing someone else's code? AI is somewhere between "marginally helpful" and "actively makes this harder."
Yet the marketing from companies would have you believe AI is revolutionizing all of software development, all the time, for all use cases.
The Measurement Theater
Companies keep pointing to metrics that look good on paper:
- "Engineers complete 26% more tasks!" (Are they the right tasks? Are they done well?)
- "Code commits increased 13.5%!" (Is more code better? Or is it workslop?)
- "Compilation frequency up 38.4%!" (Does compiling more often mean you're iterating productively or just trying more things?)
None of these metrics actually measure what we care about: are we shipping better software faster?
It's like measuring restaurant quality by counting how many dishes the kitchen produces. A bad restaurant can have high output. A good restaurant focuses on what they serve, not just how much.
But companies need to justify their AI investments, so they cherry-pick metrics that make AI look good.
What Engineers Actually Tell Me
Off the record, engineers are way more honest than official company statements:
"I use it for stuff I'd normally copy from Stack Overflow anyway."
"It helps me remember syntax, but I still have to think through the logic."
"Sometimes it's faster. Sometimes I spend longer debugging its suggestions than writing it myself would have taken."
"My team's using it because we're being measured on adoption, not because it's genuinely helping."
"I feel guilty when I don't use it, like I'm not keeping up with technology."
That last one is particularly telling. The pressure isn't coming from "this tool is amazing, I want to use it!" It's coming from "everyone says this is the future, so I better use it or risk being left behind."
The Uncomfortable Middle Ground
Here's my actual take: AI coding assistants are useful for specific things, oversold in general, and being mandated in ways that distort their actual utility.
If you're experienced and you know exactly when to use AI and when to ignore it? Great, you're probably getting genuine productivity gains for certain tasks.
If you're less experienced and using AI as a crutch instead of learning patterns? You're probably creating technical debt while your metrics look good.
If your company is mandating AI usage and measuring adoption? You're incentivizing people to use it even when it doesn't help, creating workslop and teaching people to ignore their own judgment.
The technology is fine. The deployment and expectations around it are the problem.
What Actually Needs to Happen
Companies need to:
-
Stop measuring AI usage as a metric. Measure outcomes, not tool adoption.
-
Be honest about limitations. AI is good at some things, bad at others. Acknowledge that.
-
Trust engineers' judgment. If someone says AI makes them slower on a specific task, believe them.
-
Reward good code, not just fast code. Maintainability, clarity, and correctness matter more than velocity.
-
Make AI optional for real. Not "optional but everyone knows you should be using it."
Engineers need to:
-
Be honest about whether it's helping. Don't fake productivity to look good.
-
Use it strategically, not universally. It's a tool, not a religion.
-
Push back on bad metrics. If your company measures AI usage, explain why that's counterproductive.
-
Document what works. Share real use cases where AI genuinely helped, so others can learn.
My Frustrated Bottom Line
The gap between what companies claim about AI coding tools and what engineers actually experience is huge and getting bigger.
Companies have incentives to overstate benefits (justifying massive investments).
Engineers have incentives to conform to expectations (keeping their jobs).
The truth gets lost somewhere in the middle.
Amazon's spokesperson saying engineers "feel more productive" while an Amazon engineer says there's widespread skepticism perfectly captures this disconnect.
Both things are true. Engineers feel more productive (because AI gives instant feedback and makes activity metrics look good). But they're also skeptical (because they're not sure it's actually making them better at their jobs).
Until we can have honest conversations about what AI actually does well versus what it doesn't, we're just going to keep layering hype on top of reality until nobody knows what's actually true anymore.
And that benefits nobody. Not companies who waste money on tools that don't help. Not engineers who are pressured to use tools that slow them down. Not users who get software that was optimized for velocity metrics instead of quality.
Maybe we could all just... be more honest? Acknowledge that AI coding tools are useful for specific things but not a silver bullet?
Radical idea, I know. But it sure would beat the current situation where companies lie about productivity gains and engineers lie about how much the tools are helping because everyone's afraid of looking behind the curve.
The tools are fine. The dishonesty is the problem. Let's fix that instead of pretending everything is great when clearly it isn't.