Productivity Delusion: Token Maxing Won’t Save You

We have all seen the claims: AGI or ASI is less than five years away, one-person billion-dollar companies are around the corner, and AI will unlock near-infinite productivity, but that picture is incomplete.

Frontier models are genuinely impressive. They can write code, summarize documents, generate prototypes, and automate pieces of work that used to take hours or days. But there is a growing gap between what these systems can demo and what they can reliably deliver inside real organizations. I call that gap productivity delusion.

Productivity delusion is the belief that because AI can generate a lot of output very quickly, it is therefore creating equivalent business value. It assumes that more tokens, more code, and more agent activity automatically mean more productivity. In practice, that is often false.

You could reasonably ask: who am I to talk about this? Aren’t tech CEOs already doing enough of that?

Fair question.

A lot of the productivity narrative today is being driven by people whose job is to raise capital, set direction, attract talent, and keep markets excited. That naturally pushes them toward optimism. In some cases, it pushes them toward exaggeration. That is part of the role.

My perspective is different. I work with organizations trying to adopt this technology in the real world. My job often involves helping leaders move from curiosity to implementation. And yes, in the short term, it is in my interest when more companies buy into the AI wave. However, unmanaged expectations come with a cost.

For companies without very deep pockets, blindly chasing “token maxing” or “vibe maxing” can become an expensive trap. They start believing that velocity alone will save them. They mistake generated output for durable capability. Eventually, they discover that the promised gains do not show up where they actually matter: reliability, security, maintainability, coordination, and decision quality.

How we got here

With tools like Claude Code, Codex, Gemini CLI, and similar systems, code is becoming easier to produce than ever before. Someone with decent language skills can describe a product idea and get a functional prototype, sometimes even a usable MVP, in minutes.

On the surface, this looks like a massive productivity breakthrough. To be fair, in some contexts, it is.

A non-technical founder no longer needs to wait weeks to test an idea. A small team can explore more product directions faster. Engineers can offload repetitive work. For prototyping, scaffolding, refactoring, and boilerplate, these tools are already incredibly useful.

But the leap from “AI can generate code quickly” to claims that engineers are now 100x more productive is where delusion begins.

A prototype is not a product. A demo is not a system. And generated code is not the same as software that can survive production, because software engineering is far more than generating code.

The hard part of software has never been typing characters into a file. The hard part is deciding what should be built, why it should be built, how it should behave under stress, and how it can evolve safely over time.

That is why there is such a big disconnect right now between people who are obsessed with the tech and people who have spent years building reliable products.

One group sees someone “vibe code” a new product line in a day. The other sees a 100,000-line enterprise codebase, a fragile dependency chain, regulatory requirements, security constraints, and the very real risk that one careless fix creates a production incident, which is why the same capabilities that look like a breakthrough in one setting can seem far less convincing in another.

To be clear, I am not arguing that current models are useless or that AI will not improve productivity. I am an optimist. I have built with this technology for years, and I expect to keep building with it.

The problem is not AI itself. The problem is the lazy assumption that productivity rises in proportion to token usage, when in practice the real constraints are judgment, coordination, reliability, and decision quality.

A system can generate thousands of lines of code and still create negative value if that code increases review burden, introduces security risk, duplicates existing logic, or makes the system harder to reason about. Many engineers are already feeling this pain. They are tired of “vibe PRs” that nobody seriously reviews but everyone is somehow expected to trust.

A lot of people imagine the future like this: if LLMs are cheap replicas of humans, then eventually a company will just replace 1,000 employees with 1,000 AI agents. But that framing misunderstands where the real constraint sits. Even if future agents become much more reliable, closer to competent digital workers than autocomplete on steroids, you still do not automatically get a functioning 1,000-person company, because the limiting factor in most organizations is not raw code production but coordination. The hardest part is often getting people to agree on the right thing to do: what should be built, what should be prioritized, which tradeoffs are worth making, which risks are acceptable, what success actually looks like, and who remains accountable when the answer is ambiguous.

Anyone who has sat in a room with 20 stakeholders knows that the problem is rarely “not enough output.” The problem is communication, collaboration, and alignment. Scale that to 100 or 1,000 people and the issue becomes even more obvious.

Now add another complication: today’s models often converge toward similar answers. They are very good at producing plausible consensus. They are much less reliable at producing genuinely independent judgment. You can think of this as a kind of diversity collapse: when many agents trained on similar data and optimized toward similar reward signals keep generating variations of the same acceptable opinion.

That matters because organizations do not just need speed. They need disagreement, creativity, judgment, and the ability to spot the one important signal hidden inside a sea of polished nonsense.

Creativity is subjective. Originality is difficult to measure. The best idea in the room is often not the most statistically average one, and it is usually not the one that sounds safest on first pass. In a world flooded with AI-generated output, the scarce skill may become the ability to separate signal from noise, not the ability to generate more noise faster.

Engineers’ Concerns

I have spoken to engineers across fintech, health tech, and other domains. Most of them are excited by what these tools can do. They use them. They benefit from them. They are not anti-AI.

What frustrates them is something else: people with no experience building or maintaining production systems suddenly acting as if software is now trivial. This attitude creates bad incentives and worse decisions.

I have heard people say things like: “Agent-generated code shouldn’t even be reviewed by humans” or “Just keep prompting the model until it fixes the bug.” Anyone who has spent time debugging real systems knows how reckless that sounds.

AI-assisted coding can be powerful. But using it without careful review is how you get subtle failures, security issues, broken abstractions, and operational messes that cost far more to fix later.

The real danger is not that AI writes bad code sometimes. The real danger is that organizations start lowering their standards because the output looks impressive.

What’s Next

I do not know whether AGI or ASI arrives in five years or ten. I am not confident in anyone’s timeline.

What I am confident about is this: we are entering a period where agents will become much more common, and adoption will rise significantly from today’s levels. A lot of tasks will be automated. A lot of new products will be built. And a lot of new opportunities will emerge from the problems those systems create. However, for this future to be useful, we need to stop confusing activity with progress.

The conversation has to move beyond token counts, beyond demo velocity, and beyond executive hype. The real challenge now is bridging the gap between C-level enthusiasm and the people doing the hard work of making products secure, reliable, maintainable, and worth using.

Code generation is improving quickly, but reliable software has never been just a code generation problem. If we keep pretending otherwise, we will reward output over judgment, noise over signal, and eventually push away the engineers who have spent decades building the stable systems we all depend on.