AI has shortened the time, not the problems

It has only made them harder to see

Every new tool arrives with the same promise: do the same things in far less time. With AI, that promise is, for the most part, genuinely kept. Time compresses. What no one tells you is that the problems don’t — they don’t compress along with the time. They move. And they move to exactly the spot where they’re hardest to see.

Let me put it as directly as possible, because it’s the heart of the matter. An error produced in three seconds and accepted without a glance is not one error fewer. It’s an error that surfaces later, weeks later, when fixing it costs more and no one remembers where it came from. AI doesn’t reduce errors. It increases their discovery latency. The difference that matters isn’t between an error made and an error avoided, but between an error made and an error discovered.

“Almost right” is the problem that doesn’t look like a problem

Stack Overflow asked more than 49,000 developers what frustrates them most about AI. The number-one answer, from 66% of respondents, is solutions that are “almost right, but not quite.” The second, at 45%, is that debugging AI-generated code takes more time than expected. And trust in the accuracy of these tools has fallen: only 33% trust them, down from 43% in 2024.

The real problem isn’t the obvious error. That one you see and throw away. The problem is the almost-right. It’s the well-formatted, plausible output that passes a glance and slips into the work. Reviewers lower their guard precisely because the form is in order. The problem doesn’t disappear; it hides behind its own presentability, and the most experienced developers are the most wary. Among those with more than ten years in the trade, only 2.6% trust AI a lot. The better you are at spotting an error, the less you trust it.

There’s one figure, though, that closes the loop better than any other, because it looks to the future, not the present. Stack Overflow asked: in a future where AI could do most of the work, in which cases would you still ask a person for help? The number-one answer, at 75%, is “when I don’t trust the AI’s responses.”

It’s the endpoint of the whole argument. However fast AI becomes, the final judgment on what’s right stays human. Not because AI is useless, but because someone still has to answer for what comes out.

The speed is there. The bill comes downstream

Google’s DORA report is one of the most serious and long-running studies on software development. In the 2025 edition, for the first time, AI adoption shows a positive effect on delivery speed. Teams have learned to use it, and they go faster. In the same report, however, AI adoption continues to correlate negatively with delivery stability.

This is the clearest confirmation of the whole thesis, and it comes from those who promote AI, not those who fear it. The speed is real, the time genuinely shrinks. But the acceleration puts pressure on everything downstream: testing, code review, quality control — and if that part can’t keep up the pace, the extra volume turns into instability. The problem doesn’t disappear because you’re faster, and you only see it if you’ve built the tools to see it.

The debt that piles up is a cost someone pays

GitClear analyzed 211 million lines of code changed between 2020 and 2024, from the repositories of large tech and enterprise companies. The key figure concerns two opposite ways of writing new code.

The first is refactoring, the tidying-up work that reuses existing code and keeps it clean and maintainable. It dropped from 25% of changed lines in 2021 to less than 10% in 2024.

The second is copy-paste. Duplicating blocks of code instead of reusing them in an orderly way. It rose from 8.3% to 12.3% over the same period. And in 2024, for the first time, lines that were simply copy-pasted overtook lines reused in a structured way.

In other words, more and more code is written “as a photocopy” and less and less is tidied up. It’s the sign of producing in a hurry by piling up duplicates, instead of keeping the system clean.

This is the picture of what I call the “kludge.” When producing costs almost nothing, the incentive shifts from writing well to writing fast. Shortcuts, duplicates, and pieces that work today and that someone will have to maintain tomorrow pile up. It’s not a cost you see at delivery. It’s a debt that matures over time and comes due months later, when you have to touch the system and discover that no one knows anymore why that piece was built the way it was.

Where code breaks, and where it stays silent

All these numbers come from the software world for a simple reason: it’s the one place where the problem is measured well. There’s a test that fails, a deploy that breaks, an incident in production. Sooner or later something breaks and makes the error visible.

In my work, data and compliance, that alarm often doesn’t go off. And this is where it becomes more insidious, not less.

An analysis built on faulty tracking, one dimension mistaken for another, a consent misread, a traffic source attributed at random, produces perfectly plausible numbers (remember the “SEO Boom” from my previous article?). Nothing breaks. The chart is clean, the slide is convincing, the decision gets made. The error isn’t visible at that moment; it surfaces when a budget or positioning choice turns out to rest on data that didn’t hold up.

Same story with compliance. A text that looks compliant — a privacy notice, a cookie policy, a processing assessment — passes a glance exactly like almost-right code. The flaw stays invisible until an audit arrives, a challenge, a data subject’s request. At that point you take back all the time you’d saved writing it, with the interest of the risk.

The time you save is a loan, not a gift

Let’s be clear: the conclusion isn’t “use AI less.” That would be shortsighted, and the data itself disproves it, since the speed is real and the advantage is concrete. The right question is another one: what do you do with the time AI gives back to you?

Because that time is a loan. If you cash it in — you deliver faster and change nothing upstream — you’ll very likely have to get ready to pay the interest soon. Errors discovered late, debt to maintain, decisions made on fragile grounds: that’s the price to pay. If you reinvest it instead, and move verification upstream rather than downstream, you keep useful friction where it’s useful, you leave the responsibility of whoever checks explicit — and at that point AI really does accelerate without hiding the bill from you.

It’s a matter of method, and method is our craft. Concretely, for us, it means three things:

• always keep the observed data separate from the interpretation, and verify where it comes from;
• treat data governance not as a formality but as the condition for analyses to hold up;
• prefer a hypothesis you can test over a shortcut that seems to work.

AI is an extraordinary tool for those who keep the discipline of checking what they produce. For those who lose it, it shortens one thing only: the time before they pay the bill.

---

Sources: Stack Overflow Developer Survey 2025 (survey.stackoverflow.co/2025/ai); Google Cloud DORA, State of AI-assisted Software Development 2025 (dora.dev); GitClear, AI Copilot Code Quality 2025 (gitclear.com).