The romantic illusion of AI coding tools is that shipping code faster equals building a better product.

In reality, it often just means generating unrecoverable technical debt at a speed no one can keep up with. My team and I fell for this illusion and this is how it happened.

In January 2025, I was Director of Talent Operations for a talent provider.

My job was to find, vet, and onboard engineers for remote roles. One of our largest clients with 16 of our engineers embedded across multiple teams came to us with a simple request.

“Roll out cursor to all our engineers, we want to see 10x productivity from each member of the team”

The expected impact of this were; increased output, shorter iteration cycles and doing more without adding new headcount.

By March, it looked like the exact future everyone had been predicting. Work that used to take four-week sprints was getting done in one or two.

The teams were shipping faster, execution picked up, and the client came back asking for more engineers. At that point, we were convinced we  could scale this to more clients. So, we took what we learned and started talking to other clients about the same setup. 

By June, we added Claude to the toolset our engineers could use. We made it available at no additional cost to clients. We thought if these tools could help strong engineers move faster, then access should not be the bottleneck.

By November/December, when more of the developer communities started adopting Claude code, we were getting a different kind of feedback for our engineers who had been using it since June

Code written with the help of this tool was going through multiple rounds of PR reviews. Review cycles that used to take two days were stretching into weeks before teams were confident enough to merge it.

Production issues were increasing and user-reported bugs were pulling the team away from new feature requests. The same teams that had felt invincible in March were now spending more time checking, correcting, and cleaning up slop from the AI tools.

Velocity quickly dropped below where it was before the adoption of the tools.

That was the first time I stopped looking at AI as an access question. We had increased what any one engineer could produce, but failed to equip them with the right skills, rituals and structure required to keep the output useful, reviewable, and safe inside the product.

At the time, I thought we were looking at a unique problem but the more I paid attention to what was happening elsewhere, the more it looked like the same failure pattern was showing up in different forms across the ecosystem.

What became harder to ignore was the ease of code generation, the quality and reliability of the system those codes were powering. It seemed the faster our engineers generated codes, the faster the quality and reliability of the product dropped. Another inescapable fact was the increasing difficulties of the engineers to probably navigate and solve problems in the codebase.

By February of 2026, a lot more people were reporting similar failure patterns and subsequent studies looking into the effect of AI tool adoption validated these experiences.

A late 2025 study on Cursor adoption by Carnegie Mellon University that gained mainstream popularity in 2026 found a large but temporary increase in project-level development velocity, followed by a persistent rise in static analysis warnings and code complexity.

Another follow-up study by the same team on autonomous coding agents like Claude Code reached a similar conclusion: the velocity gains appeared mainly in teams new to AI, while complexity levels kept rising across contexts.

This negative impact of blind AI adoption on the ability of engineers to solve problems in complex codebases draws warnings from the makers of these tools; 

Dax Schafer, founder and CEO of OpenCode, put it plainly: 

“The default place for our new coding agent abilities to go to is to work on the wrong things. Products are going from good to bad faster than ever.”

Mario Zechner, creator of pi, wrote an extended reflection on the same problem:

“We have basically given up all discipline and agency for a sort of addiction, where your highest goal is to produce the largest amount of code in the shortest amount of time. Consequences be damned.” Give yourself time to think about what you're actually building and why. Allow yourself to say, fuck no, we don't need this.”

This is Jer Crane, the founder of PocketOS, who recently narrated a story of the real-word impact of such blind AI tool Adoption. Claude Code deleted their production database including the volume-level backups through a single API call. 

The task given to the agent was supposed to happen in staging. The agent found a token, guessed wrong about the scope, ran a destructive action, and later admitted in writing that it had violated the safety rules it was given. The damage reached customers who depended on their software to run their businesses.

This incident is extreme, but not the only.

These tools are and will continue to be integral in how we build softwares and products that depend on them going forward. However, te blind adoption of these tools poses a risk most companies and teams will not be able to recover from.

The adoption patterns where the engineer would outsource their thinking and problem solving abilities to AI instead of using them to augment these functions are what leads to the unintended consequence of high code complexity slop increase security vulnerabilities, user dissatisfaction with most software products today.

Why engineers must be able to reason and solve problems in a codebase

Peter Naur, a Computer Scientist in 1985 wrote an essay called “Programming as Theory Building.” In it, he argued that programming is fundamentally about building a theory, a shared mental model of how a system works, why it works that way, and how it should evolve.The source code is merely a written representation of this theory, and like all representations, it’s lossy. Critical knowledge about intent, design decisions, trade-offs, and the reasoning behind architectural choices exists only in the minds of the people who built the system.This is an excerpt from Christian Ekrem’s recent article on why Engineers should not outsource thinking to AI.If your AI adoption strategy is optimising only for speed of code generation, over your ability to solve problems long term, you’re setting yourself up for a world of pain.