SoylentNews

jelizondo [soylentnews.org] writes:

CIO published a very interesting article [cio.com] about how the use of AI by the best engineers actually is slowing them down, and quite not delivering on the promised speed up of production code:

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 [freethink.com], 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.

[...]

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 [metr.org]. 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.

[...]

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.

According to the 2025 Stack Overflow Developer Survey, the single greatest frustration for developers is dealing with AI solutions [stackoverflow.blog] 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 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.

[...]

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.

[...]

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.

[...]

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.

[...]

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.

[...]

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.

As Brian Kernighan said, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it". And now, a corollary: "If AI is smarter than you, who the hell is going to debug the code?"

Original Submission