The AI productivity trap: Why your best engineers are getting slower

We’ve all heard the pitch. By now, it’s practically background noise in every tech conference: AI coding is solved. We are told that large language models (LLMs) will soon write 80% of all code, leaving human engineers to merely supervise the output.

For a CIO, this narrative is quite seductive. It promises a massive drop in the cost of software production while increasing the engineering speed. It suggests that the bottleneck of writing code is about to vanish.

But as someone who spends his days building mission-critical financial infrastructure and autonomous agent platforms, I have to be the bearer of bad news: it’s not working out that way. At least, not for your best engineers.

The deployment of AI copilots into the workflows of experienced engineers isn’t producing the frictionless acceleration promised in the brochures. Instead, I’m seeing the emergence of a productivity trap — a hidden tax on velocity that is disproportionately hitting your most valuable technical talent.

I’m not saying this because I’m skeptical of the tech. I am an AI optimist and I build AI systems for a living. But we need to be honest about the data. For complex, high-stakes engineering tasks, AI tools are currently making experienced developers slower.

The hidden tax on speed

For the first few years of the generative AI boom, we operated on vibes. We had anecdotal evidence and vendor-sponsored studies claiming massive productivity gains. And for junior developers working on simple tasks, those gains were real. If you just need a basic react component for a login button, using AI feels like a miracle.

But we got a reality check in mid-2025. A randomized controlled trial by METR (Model Evaluation & Threat Research) analyzed the impact on senior engineering talent. Unlike previous studies that used toy problems, this one watched experienced developers working on their own mature codebases — the kind of messy, complex legacy systems that actually power your business.

The results were stark. When experienced developers used AI tools to complete real-world maintenance tasks, they took 19% longer than when they worked without them.

How can a tool that generates code instantly result in a net loss of time?

It comes down to what I call the illusion of velocity. In the study, developers felt faster. They predicted the AI would save them huge amounts of time. Even after they finished — and were objectively recorded as being slower — they still believed the AI had been a timesaver.

The AI gives you a dopamine hit. Text appears on the screen at superhuman speed and the blank page problem vanishes. But the engineer’s role has shifted from being a creator to being a reviewer and that is where the trap snaps shut.

The almost-right valley of death

The core of the problem is that AI is really good at being almost right.

According to the 2025 Stack Overflow Developer Survey, the single greatest frustration for developers is dealing with AI solutions that look correct but are slightly wrong. Nearly half of developers explicitly stated that debugging AI-generated code takes more time than writing it themselves.

In software engineering, blatantly broken code is fine. The compiler screams, the app crashes upon launch, the red squiggly lines appear. You know it’s wrong immediately.

Almost-right code is insidious. It compiles. It runs. It passes the basic unit tests. But it contains subtle logical flaws or edge-case failures that aren’t immediately obvious.

When I write code from scratch, I am doing forward-engineering. I build a mental model of the logic. I know why every variable exists. If a bug appears, I can trace my own steps back to the error.

When I use an AI, I am forced into reverse-engineering. I get a block of code I didn’t write. I have to read it, decipher the intent of the model and then map that intent against the requirements of my system.

I saw this firsthand when building financial systems for enterprise logistics. The logic required to calculate net revenue was sophisticated with bespoke business rules. If I asked an LLM to generate the billing code, it would give me something that looked mathematically perfect. It would sum the line items correctly.

But it would inevitably miss a crucial, unstated context — perhaps that empty miles are billed at a different rate only when the carrier is part of a specific dedicated program. Finding that omission in 100 lines of AI-generated code is exponentially harder than writing the 100 lines myself. I spend more time debunking the AI’s plausible hallucinations than I would have spent just doing the work.

Context rot and flow state

There is also the cost of context switching. Deep work, or flow state, is the essence of high-level engineering. It takes time to load the context of a distributed system into your brain.

AI tools, in their current chat-based forms, encourage a fragmented workflow. You stop coding, you prompt the bot, you wait, you review, you reject, you re-prompt. The flow is gone.

Worse, as you try to fix the AI’s errors by feeding it more code snippets, you encounter context rot. The model gets distracted by irrelevant details and starts producing bloated, off-target code. The senior engineer ends up acting as a glorified editor for a very fast, very confident intern who doesn’t understand the history of the company.

Changing the game plan

So, if the current copilot model is a trap for your best talent, what do we do? We certainly don’t ban AI. That would be like banning calculators because you sometimes hit the wrong button.

We need to move from AI-assisted coding to AI-enabled architecture. The goal isn’t to make your senior engineers type faster, but to enable them to build systems that are robust enough to handle the chaos of AI-generated code.

From reviewer to architect

The popular 80/20 split — where AI does 80% of the work and humans do the 20% — is misleading. It implies the human part is just a finishing touch. In reality, that 20% is 100% of the value. It’s the architecture, the security model and the business logic.

To escape the productivity trap, you need to direct your engineering leaders to focus entirely on this human 20%.

My own work has shifted away from writing features and toward defining the physics of our codebase. When I was at Uber, I spent a huge amount of time migrating our systems to use strict types and schemas.

By enforcing strict rules, I effectively created a guardrail system. If we use AI in that environment, the AI is forced to write compliant code. If it hallucinates a field that doesn’t exist, the compiler immediately rejects it.

This is the strategic shift. The role of the senior engineer is to build the compiler for the AI. They need to create the schemas, the type systems and the automated rules that constrain what the AI can do.

This transforms the almost-right problem. Instead of me manually reviewing code to find errors, the system rejects the code automatically if it doesn’t fit the architecture. I stop being a reviewer and start being a legislator.

How to lead the change

For a CIO, this requires a change in management strategy. You can’t just buy Cursor subscriptions and expect your velocity and stability metrics to go up.

First, you have to stop measuring output. The most dangerous thing you can do right now is measure productivity by lines of code (LOC) or commits per day. In an AI world, those metrics are easily gamed and completely divorced from value.

You need to measure outcomes. If a senior engineer spends a month writing zero code but designing a schema that prevents 100% of a type of production bug, that is a massive win. You have to reward the prevention of work, not just the completion of it.

Second, you need to invest in your context engine. AI struggles when it lacks context. Your senior engineers should be tasked with building internal developer platforms (IDPs) that expose your codebase in a structured way. A clean, strictly typed codebase is the prerequisite for effective AI adoption.

Finally, you need to redefine what you look for in a senior engineer. The skill of knowing syntax is depreciating rapidly. The skill of system verification is skyrocketing in value.

You want engineers who talk about schematics, type safety and architecture. Ask them to build the guardrails that constrain the AI, rather than just chatting with it.

The AI productivity trap is real, but it’s not inevitable. It’s a symptom of applying a new technology using an old workflow. The path forward is rigorous, architectural and deeply human. It requires us to value the design and the constraint-setting as the true core of engineering.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?