Engineering teams across industries are shipping the same report this year. Velocity is up across the board, with tickets closing faster and lines of code per sprint doubling or tripling at some organizations. Those are the numbers that make it into quarterly reviews and vendor case studies.
A different set of numbers exists that rarely makes it into any report.
Defect rates have not improved even as output has surged.
Onboarding new engineers to codebases takes longer.
Incident recovery stretches out because the engineer debugging the failure did not write the code that broke.
Something clearly changed in how software gets built. The speed went up. Whether the software got better is a question nobody seems prepared to answer.
A developer named Brett recently published a video, now going viral on YouTube with 9,000 comments and half a million views in 12 days, describing what happened when he used AI coding tools earnestly for over a year. A 20-year veteran of the field, he used the tools under a company mandate, shipped more code than ever, and quit AI entirely, calling it a net harm to his work, his growth, and his mental health. His conclusion is his own. This post is not an endorsement of his position, and it is not a rebuttal. What his experience does is surface a set of questions that most of the industry is actively avoiding.
What Are We Actually Measuring?
Every AI coding vendor dashboard tracks the same throughput inputs, from tokens consumed and tickets closed to lines shipped and time to first commit. These metrics tell you how fast the machine is running, and nothing about whether the machine is producing value.
We keep hearing the same observation from developers across client organizations and public forums. Productivity doubled or tripled, and nothing changed in revenue, customer satisfaction, or product quality. The task count went up, the code volume went up, and the business impact stayed flat. The question worth investigating is what you would need to measure to know whether your team’s experience looks any different.
Most teams have no visibility into the numbers that would actually tell them whether AI adoption is working.
How defect rates shifted after AI adoption.
How long a new engineer needs to become productive in a codebase that an AI authored.
Whether incident recovery takes longer when the debugging engineer has no mental model of the failed code.
Whether the additional features that shipped faster are actually being adopted by users.
Feature bloat is a useful lens here. Software that tries to do everything and becomes impossible to use predates AI by decades, and AWS and Google Cloud Platform are widely cited examples. What AI velocity does is accelerate the rate at which bloat accumulates.
The question every engineering leader should ask is whether any of the additional features that shipped this quarter moved a business metric or just made the changelog longer.
The uncomfortable truth for vendors and adopters alike is that the current measurement framework proves adoption, and adoption alone tells you nothing about whether the software or the business is better for it.
When a Developer Stops Writing Code, What Did the Business Gain?
When an engineering team fully adopts agentic coding, the developer’s role shifts in ways that sound productive on paper. The developer writes training documentation to prevent the AI from repeating mistakes, reviews the volume of code the AI generates each day, and tests the features the agent produces. We have heard management at multiple organizations describe this exact configuration as the developer’s job in the AI era. On a dashboard, it looks like a functioning system.
What that dashboard does not capture is what happens to the developer’s relationship with the codebase over the following months.
Code review at AI output volume becomes an exercise in scanning for obvious failures because thorough review of that quantity is not realistic on a daily cadence.
Over time, the effects compound in predictable ways.
System understanding degrades because nobody on the team wrote the code that changed it.
The ability to explain how a feature works without consulting the AI erodes gradually.
Care for code quality declines when the person accountable for it had no hand in building it.
These effects accumulate across engagements where agentic coding was adopted without a defined ownership model, and the cumulative result is a team whose skill trajectory has flattened during a period when it should have been growing.
There is a deeper observation underneath those symptoms. Software that people value, the kind that feels considered and well built, carries a quality that is difficult to quantify but easy to recognize. That quality comes from proximity between the people building the software and the decisions embedded in the code. When that proximity disappears, the software may ship faster, but the thing that made it worth using starts to erode.
If your senior engineers cannot explain how a critical system works because an AI wrote it 6 months ago and 4 releases have been stacked on top since, how long does incident recovery take? If your engineers at the mid level have spent a year supervising agents and have not solved a hard problem directly in that time, what has happened to their capability trajectory? If your codebase is growing at 3 times the previous rate and your team’s understanding of it is shrinking, is that codebase an asset or a liability?
It is bad for developers, software, and business when there is no ownership model defining what the human is responsible for knowing, understanding, and being able to explain. The absence of a governance framework created that vacuum.
Is “Use AI or Be Left Behind” a Strategy or a Panic Response?
The adoption sequence that tends to produce the worst outcomes follows a pattern that developers have documented openly, in r/ExperiencedDevs threads, Hacker News discussions, and a Slashdot thread that drew over 120 comments from working engineers. Leadership attends a conference or reads a report where someone with financial investment in AI sells them on how LLMs will revolutionize knowledge work within months. That leads to a company mandate to adopt AI tools or be left behind. The mandate lands on engineering teams that may already have data points suggesting caution, teams that tried autocomplete features and found them distracting, or watched a colleague spend hours debugging an issue caused by an AI that fabricated a nonexistent version of a software library. Those data points get overridden by the mandate.
When engineers try the tools earnestly under that mandate, the initial experience often feels magical. The output is genuinely impressive. That feeling of magic is itself worth examining. It is the feeling that overrides earlier red flags, suspends critical evaluation, and makes governance feel like unnecessary friction.
Nobody builds a review framework for something that feels like magic.
The question for engineering leaders is specific.
Did your team adopt AI coding tools because a structured evaluation showed measurable benefit to your codebase, team composition, and delivery model? Or did someone attend a keynote, get excited, and issue a mandate?
This dynamic appears at client organizations regularly. The teams that adopted AI tools through a deliberate process with defined boundaries are extracting value from them. The teams that adopted because someone said “we have to” are producing the symptoms described throughout this post, using the same technology and arriving at entirely different outcomes.
The Acceptance Trap
There is a behavioral dynamic in AI coding tools that rarely gets discussed in engineering conversations. These models are architecturally optimized to produce output that gets accepted.
Context
What “optimized for acceptance” looks like
Chat interface
Agreeable, validating responses that never push back
Coding harness
Code that compiles, passes the existing test suite, and looks reasonable on first read
The problem is that “accepted on first pass” and “correct” are not the same standard. Code produced by an AI can look completely clean on the surface and still:
Satisfy ticket requirements, pass CI, and merge cleanly, then introduce a coupling that makes the next 3 features harder to build.
Implement a data access approach that works at current load and fails at 10 times that load.
Handle the happy path flawlessly with no concept of the edge case your domain experts would catch because they have spent years thinking about the problem.
The acceptance rate of AI code in most teams is alarmingly high. The review bar has shifted without anyone noticing. When a human teammate submits a pull request, reviewers engage critically because they expect variation in quality and look for judgment calls. When an AI produces code that looks clean and passes tests, a different heuristic takes over, one where the output looks right, appears to work, and gets merged without the same interrogation.
This is a trust calibration problem, and it accumulates over time.
Every unchallenged merge reinforces the behavior, the team’s threshold for scrutiny drops a little further, and the codebase absorbs decisions nobody interrogated.
Then 6 months later, when something breaks in production, the debugging engineer is reading code that no human on the team ever fully reasoned through.
The question for engineering leaders is concrete. What is your team’s rejection rate on AI code? If it is near zero, your review process has been quietly disabled by convenience. Rebuilding that discipline once a codebase has grown past the point of casual review is a distinct engineering effort with its own scope and cost, well beyond what a stricter PR template can address.
Capability Debt
Technical debt is a concept every engineering leader understands. You take a shortcut now and you pay for it later with interest. A parallel concept is emerging in teams that use AI coding tools heavily, and nobody has given it a useful name yet.
Call it capability debt.
A developer writing on DEV Community captured the mechanism precisely. He could review code the AI generated fluently, spot mistakes, discuss architecture. When asked to write an HTTP handler from scratch, he froze. Recognition and production had split apart without him noticing. The title of his post says it plainly: “I Could Review It. I Couldn’t Write It.”
Capability debt accumulates when your engineering team’s ability to solve problems independently degrades because team members have spent months supervising an agent and have not done the hard work themselves. It stays invisible on every dashboard. Velocity looks fine, sprint burndowns look fine, the team is shipping, and the collective reasoning capacity the team is actually paid for is quietly declining.
This debt comes due the moment the team faces a problem that requires deep contextual reasoning. A production incident with no obvious cause, where the debugging engineer has no mental model of the code that failed, is the clearest example. The team discovers in that moment what it can do independently versus what it could do with a subscription running.
In those moments, you learn what your team can actually do on its own versus what your team plus a subscription could do together. If those numbers are far apart, you have accumulated a capability debt that will cost far more to repay than the velocity it purchased.
AI coding tools demonstrably make teams faster in many contexts. The question for engineering leaders is whether the way your team uses them is building capability or borrowing against it. Most teams have no framework for answering that question because nobody is measuring it.
The Costs That Do Not Appear on Your Invoice
The conversation about AI adoption cost also extends beyond engineering quality into the broader cost of AI infrastructure, from the water consumed per prompt and data centers that negatively affect local communities and waterways to hardware supply chain strain that drives up costs for components and consumer electronics. The AI buildout is absorbing resources at a scale most users never see because the cost is abstracted away from the point of use.
These are not engineering questions, and this post will not attempt to answer them definitively. We raise them because any honest conversation about AI adoption cost has to acknowledge they exist. Most frameworks for evaluating AI tool adoption measure subscription cost, time saved, and output volume, leaving the externalized costs of the underlying infrastructure entirely unaccounted for.
“It is cheaper and faster” is an incomplete cost analysis if it only counts the line items on your invoice.
What Happens When the Tool Goes Away?
If an AI coding tool goes down for an extended period, a team that has relied on it heavily for months faces a specific problem. Skills have atrophied and mental models of the codebase have degraded, leaving a team that was 3 times more productive unable to operate at baseline until the service comes back.
This is a dependency risk that most organizations have not stress tested. The single point of failure problem is well understood in engineering management, where losing 1 developer who holds all the context exposes the entire team. Teams that use AI coding tools heavily have created a new variant of this problem where the critical dependency is a subscription service whose pricing, model behavior, and availability can change without notice.
Tool unavailability is the obvious scenario. The subtler risk is model behavior drift. The AI coding tool your team calibrated its workflow around 6 months ago may not behave the same way today, and the review shortcuts your team developed based on predictable AI output may no longer hold because you tuned your process to 1 version of the model and the model moved.
If your AI coding tool became unavailable for 2 weeks, what would your team’s throughput look like? If the answer is “dramatically lower than before we adopted AI,” you have not augmented your team. You have created a dependency.
When Your Best Engineers Feel Coerced
There is a specific signal that tells you an AI adoption strategy has gone wrong, and it has nothing to do with code quality metrics or velocity dashboards. The signal is when your most experienced engineers describe feeling forced.
Brett, whose video and blog post sparked this piece, is a clear example. He is a developer with 20 years of experience who used AI tools in earnest for over a year before deciding they were net negative for his work, his growth, and his mental health. He describes feeling disillusioned and purposeless, weighed down by depression, confusion, and guilt about his role in the system. He describes existential dread about whether software engineering will exist as a career and considered leaving the field entirely. His decision to stop using AI carries potential career consequences he openly acknowledges, and he says he is willing to accept them.
The fact that a skilled, experienced engineer feels this level of risk in choosing not to use a tool tells you something important about how this conversation is being conducted across the industry.
When adoption is mandate driven (“use AI or be left behind”), it optimizes for compliance. Two things follow, both of them expensive.
Engineers who comply and disagree will use the tools carelessly, review output superficially, and disengage from the quality of what ships.
Engineers who refuse will leave or be pushed out, taking institutional knowledge and domain expertise with them.
The alternative is adoption that is evidence driven. Define where AI tools add measurable value in your specific workflow. Define where they do not. Let your most experienced engineers participate in drawing that boundary because they have the context to draw it well. Measure outcomes, not compliance.
Brett chose to walk away entirely. He went back to personal projects, built a game engine, wrote a book on game development, and coded by hand. He says the effect was immediate, that he reconnected with the craft and remembered he liked coding and was good at it. He wants to return to creating educational programming resources for people who want to learn the craft directly. That is a valid choice for him. It is also a loss for any organization that pushed a veteran engineer to the point where quitting the tools felt like the only option.
The teams getting the most value from AI coding tools, in our experience, are the ones where experienced engineers had the autonomy to integrate the tools into their workflow on their own terms, keep what worked, and discard what did not. If your adoption model makes a 20-year veteran feel like they have to choose between their professional judgment and their employment, the model is broken. The velocity numbers do not change that.
The Question Underneath All the Questions
Every symptom discussed in this post, skill atrophy, codebases nobody can explain, apathy toward work that used to matter, roles redefined around supervising an agent, existential dread among experienced engineers, measurement frameworks that count velocity and miss value entirely, traces back to 1 root cause. Organizations adopted a powerful tool without defining who owns what the tool produces.
Our observation, from working with teams across industries navigating this transition, is that the symptoms above are predictable outcomes of unmanaged adoption. The diagnosis determines what you do next.
The answer starts with defining what the human owns and what the AI drafts, and measuring outcomes as the primary signal.
The question underneath all the specific questions in this piece is simple. Does your team own what it ships? Does the team, the humans on it, understand what they are shipping, why it works, how it fails, and what to do when it breaks?
If the answer is yes, the tool is working for you. If the answer is no, the tool is working in place of you. And that is a different thing entirely.
Every team navigating AI adoption hits the same inflection point. The dashboards look healthy, the tickets are closing, and something still feels off. If your engineering organization is shipping more but struggling to explain what it owns, a structured evaluation of your adoption model can surface where the gaps are before they compound.
Pushker is the founder of Clixlogix. Give him a messy operation and he finds the leverage point, then builds the fix himself. He works at the edge of what AI can actually do inside a business, and writes about what he finds there.
DM Us
