Speed Isn’t Productivity: Why AI Makes the Hard Work Invisible
Friday musings from the uncomfortable edge of LLM efficiency.
Over the last year, I’ve found myself circling the same unease in different conversations, with different people, in different contexts. It comes up when talking about large language models, about agents, about productivity, and inevitably about security. On the surface, everything feels faster. And yet, I’m not convinced we’re actually getting more done. What I think is happening is more subtle, and potentially more dangerous.
Speed Isn’t Productivity
The 80/20 Trap of LLMs
We all know the 80/20 rule, even if we don’t always define it consistently. Roughly speaking, 80% of the visible work often takes 20% of the time, while the remaining 20% of the work consumes the other 80% of the effort. LLMs are astonishingly good at compressing that first part.
First drafts. Boilerplate code. Initial reports. Scaffolding. The shell of a house. Suddenly, what used to take days takes hours or minutes, and that feels like productivity. But here’s the problem:
that first 80% was never the hard part.
When an LLM produces a draft in minutes, it hasn’t removed the work of finalization. It’s simply pushed it downstream, and this is the hidden cost of making things easier. In some cases, it’s made it harder, because the process of doing the work was also how we learned the landscape, spotted the edge cases, and developed judgment. So, we normalize the numbers and say:
“Look, we’re five times faster.”
But what we’ve actually done is make the easy 80% almost free, while making the hard 20% dangerously invisible, and invisible work is the easiest work to ignore. That’s how a quality deficit starts to form.
Quality Is the Real Bottleneck
Security, Finalization, and Artificial Indolence
Quality work is cognitively hard and deeply unglamorous. Security. Testing. Reconciliation. Documentation. Explanation. The final pass where you ask, “Is this actually right?” Humans have always avoided this work when they could. And LLMs trained on human behavior, inherit that same indolence.
I see this all the time when I’m doing what I half-jokingly call “vibe science.” I’ll brainstorm ideas with a model, explore references, sketch arguments. It’s powerful and creative. But when I ask it to do something genuinely tedious, like working through a full analytic gradient instead of jumping to a numerical shortcut, it behaves like a grumpy graduate student.
“Do we really need to do that?”
That’s not super intelligence. That’s super-indolence. What’s fascinating is that the model often seems to be reasoning based on how painful a task would be for a human, not on what it could do cheaply as a machine. It has an embedded sense of task difficulty, and it avoids the hard parts unless you force it not to.
I learned the importance of this kind of work long before AI. As a teenager, I worked for an accountant who insisted that the books had to reconcile exactly. Not “close enough.” If the last two digits didn’t match, something was wrong. And every time I thought he was being pedantic, pulling on that thread revealed a real problem.
Later, working offshore as an engineer, the most important part of the job happened after everyone was exhausted, sitting down to finalize the report, annotate it properly, and explain anything that went wrong. That’s the work that separates something that looks done from something that is done.
Security failures are quality failures. Finalization is where professional judgment lives, and skipped quality doesn’t disappear, it compounds. What we often call “slow” work is simply the work that actually matters.
Small Omissions Become Big Failures
From L4 Errors to Q4 Outcomes
At Amazon, I used to describe a particular class of problem as an “L4 to Q4 issue.” An L4 is a junior engineer. Q4 is your fourth-quarter results. An L4 to Q4 problem is when a small, perfectly understandable mistake made low in the system only becomes visible when it shows up in the company’s financials. By the time you notice it, it’s far too late to fix cheaply. This isn’t about blame. Junior engineers will make mistakes, and that’s normal. What matters is whether the system is designed to catch those mistakes early.
Here’s the uncomfortable parallel: LLMs currently behave a lot like junior engineers. They’re fast. They’re confident. They’re often right. And when they’re wrong, the error can propagate silently, especially if we’ve stripped away the quality checks in the name of efficiency.
AI scales output, yes, but it also scales mistakes. If leadership incentives focus only on visible speed, more code, more features, more throughput, while quality work is deferred or handed off to “someone else,” the gap widens. And by the time the consequences show up, security incidents, insurance premiums, regulatory scrutiny, or missed quarters, then organization has already taken on more debt than it can repay.
This isn’t an individual failure; it’s a systems failure. And it’s why guardrails can’t be bolted on at the end. They must be embedded into how we build, from the moment of creation.
The Real Opportunity
Now, I’m not saying this means we should slow down or reject LLMs. Quite the opposite. The real opportunity is to use them to make quality work cheaper earlier, to integrate testing, security, review, and documentation into the same moment we generate the first draft. If we do that, we don’t just move faster; we move better. But if we confuse speed with productivity, we risk building a thousand beautifully rendered shells, houses that look complete, until someone tries to live in them. By then, the cost of fixing what we skipped may already be existential, and that’s the part we need to reckon with now, not in Q4.
