The code is measurably more duplicated and measurably less maintained than it was before these tools arrived. That is not an opinion about model quality, and it is not an argument that AI does not work. It is what shows up when you measure the output itself, and the mechanism behind it is simple enough to state in a sentence: generation got roughly free, and review did not.
Here is the evidence, in the order it makes sense in, with the caveats that keep it honest.
What does the code itself show?
GitClear analysed 211 million lines of code, and four findings sit together:
- Duplicated blocks are at the highest level ever recorded, up 81% since 2023.
- Refactoring — moving and cleaning code, the thing you only do when you understand a system — is down 70%.
- Cross-file reuse is down 35%.
- Long-term legacy maintenance, the unglamorous work of going back into old code and keeping it alive, is down 74% against 2022.
And the single measurement that captures all four: in 2024, for the first time in the history of the measurement, developers copy-pasted more lines than they moved.
Read separately those are statistics. Read together they describe one thing happening inside a lot of companies right now: code is being produced faster than it has ever been produced, and cared for less than it has ever been cared for.
Why do almost all developers use these tools and almost none trust them?
Because both facts are true and they are measuring different things. In the 2025 Stack Overflow Developer Survey, 84% are using AI tools or planning to, up from 76% the year before. 29% trust that what comes back is accurate. 46% actively distrust it. 3% report high trust.
That gap is where the whole story lives, and the two numbers that explain it are these: 66% say what they get back is "almost right, but not quite", and 45% say they lose significant time debugging code a machine wrote.
Almost-right is the hardest category of error there is. Obviously wrong output gets deleted in four seconds. Almost-right output is the failure mode built to survive review — it compiles, it reads plausibly, it passes the tests that exist, and it is wrong in the three lines that will hurt you in production.
How did everyone end up here?
Not by a decision most developers made. The shape that keeps appearing is that the tools were not adopted from the bottom, they were mandated from the top — and, critically, nobody measured anything. No baseline, no before-and-after, no control group. The tools were rolled out on a belief and then judged by the only thing that was easy to see, which was volume: tickets closed, pull requests merged, lines delivered.
And the first six months genuinely do feel extraordinary. That part is real and any honest account has to say so. More gets done, the backlog moves, the demo lands.
The name for what happens next is older than any of this: automation complacency. When a system works well enough, often enough, people stop watching it — not because they are careless, but because attention is expensive and the system keeps being right. The trap inside that is not that the system fails. It is that by the time it fails, nobody is close enough to catch it.
What did the job actually become?
Supervision. Nobody in this data got replaced — the developers are still employed and the headcount is still there. What changed is the content of the day.
You write a prompt. The agent writes four hundred lines. Now the work starts, because those four hundred lines are your responsibility, your name is on the commit, and you did not write a word of it. So you read it. You hunt for the three lines that will hurt you. You test what it built. You write a file of instructions to stop it making the same mistake next Tuesday. Then you do it again tomorrow, at a volume nobody had to review before, because nobody could produce this much before.
Anyone a year into this recognises the specific moment: the review queue gets longer than the work ever was.
That is the trade. Automation did not take the work away. It converted it into supervision — a different job, which nobody applied for, nobody trained for, and no job title reflects. The same conversion happens outside engineering, in the layer of work that AI cannot take, which is why AI isn't saving you time.
Did anyone measure whether it is actually faster?
Once, properly, and the answer was uncomfortable. METR ran a randomised controlled trial with 16 experienced open-source developers on 246 real issues in repositories they had maintained for years. Before starting, they predicted AI would make them 24% faster. After finishing, they reported it had made them about 20% faster. Measured, they were 19% slower.
Sixteen people is a small study and it does not prove the industry is slower. What it demonstrates does not need a large sample: the people doing this work cannot reliably tell how fast they are going. Every productivity claim made about AI in the last two years — including the ones your own company is making — rests on a self-report from someone with no way to check.
That study, its caveats and its 2026 follow-up get the full treatment in does AI make coding faster. The reason it belongs here is narrower: if perception is unreliable, then volume becomes the only thing anyone can see, and volume is precisely the metric that produced the numbers at the top of this page.
What does it cost the business?
Every line of code a company owns is a liability as much as an asset. It has to be read, updated, secured, tested and eventually understood by somebody who was not there when it was written. That was true before any of this. What changed is the rate at which a company can acquire that liability.
Translate the four measurements into a balance sheet and they read like this. Duplicated code means the same bug lives in nine places. Collapsed refactoring means complexity never gets paid down. Abandoned legacy maintenance means the oldest, most business-critical systems are the ones nobody is touching. None of that shows up this quarter. All of it shows up eventually.
Two independent readings point the same way. Google's DORA research, across roughly 5,000 technology professionals, finds that most organisations are not seeing dramatic end-to-end improvement — speed without stability is accelerated chaos. And MIT's Project NANDA found 95% of enterprise generative-AI pilots delivered no measurable impact on profit and loss.
That last figure gets quoted badly, so be precise about it. It is a survey, not an audit. And what it actually found was not that the models were bad — it was that the tools never entered the workflow they were bought to change. That is a different failure, and a more useful one, because a company can fix it.
The dependency question nobody has been made to answer
Around 90% of developers now use these tools every day, per DORA. So here is the question no engineering leader has answered in public: if the tool went away on Monday — deprecated, priced differently, restricted, or simply down — how much of your product does your team still understand?
That is not a hypothetical about the future. It is a resilience question about right now, and it is the same question every business already learned the hard way about cloud providers, payment processors and single traffic sources. The dependency never announces itself while it is working. It identifies itself the day it stops.
The version here is worse than the cloud version for one specific reason. When your hosting provider goes down, your team still knows how your software works; they are just waiting. When the thing you have outsourced is the understanding itself, there is nothing to wait for.
What does it cost the person?
Distance, first, and it degrades in a specific order. First you stop knowing why a line is written the way it is. Then you stop knowing where the line is. Then you stop knowing what changed this week. The last stage is opening a file in your own project with no memory of it existing.
That is not a moral failure, it is what delegation does — and delegation is usually fine. The difference here is what got delegated. In most work you hand over the parts you already understand. Here, people are handing over the parts they were about to learn. You do not get better at something by getting the answer; you get better by struggling toward it. The difficulty is not a tax on the learning. The difficulty is the learning.
So the honest version is not "AI makes you stupid." Nobody's existing skill evaporates. What stops is the acquisition of the next one — survivable if you already have fifteen years of foundation, a very different proposition two years in. And the door is measurably narrower for the people who would be building that foundation now: Stanford's Digital Economy Lab, working from payroll records covering millions of workers a month, finds employment of 22 to 25 year olds in AI-exposed occupations sitting 19% below where it would have been had it kept pace with less-exposed peers, operating primarily through reduced hiring rather than increased exits. We went through that evidence and its caveats in which jobs are safe from AI.
Put the two together and the question the industry has not begun to answer becomes obvious. The juniors are not being hired, because the tool does what juniors used to do. The people who are hired stop practising, because the tool does the practising part. Every senior engineer currently holding this together learned by doing the work that nobody is doing any more.
Why does ownership matter to code quality?
Because caring is a quality control mechanism, not a feeling. People form attachment to what they had to struggle to make — the effort is where the caring comes from, which is why the wobbly shelf you built survives three house moves and the good one from the shop does not.
When the machine produces the result, something in that relationship changes, and people describe it as caring less. That matters commercially rather than emotionally: caring is the thing that makes a person go back and fix the ugly part nobody asked about. Take it out of the pipeline and the software gets worse in a way no test suite will ever catch.
So — is AI making code worse?
The code is worse on the measures we have, and the model is not the reason. The industry picked a metric, output, and got exactly what it measured. What it did not measure went somewhere: the understanding of how the system works, the ability to operate when the tool is down, and the reason a person spent twenty years getting good at this in the first place.
None of those appear on a dashboard. They appear eighteen months later, as a codebase nobody can explain and a team that has not done anything hard in two years.
Which sets up the test coming for every company on this road, and it is not whether the tool works. It works. It is whether the company still works without it. And the same discipline that answers that question is the one that catches an agent optimising the score instead of the task — reward hacking is the sharpest example of what happens when you measure the proxy and stop opening the work.
Ninety percent of developers use this every day. Twenty-nine percent trust it. That gap has to close from one side or the other, and everybody in this is about to find out which.
