Why No Manager Ever Says 'Let's Just Fix Bugs' · Issue #179

Opening

Dear reader, last week I read a developer’s post describing a string of small disasters. His banking app demanded facial recognition three separate times just to confirm a payment. A Slack window popped up late, stole focus, and a command he was typing into his terminal got fired off into a group chat instead. A refrigerator warranty claim failed at the very last step, after he’d filled out a long form. His car’s infotainment system now reboots itself mid-drive, ever since the last update.

One detail he added stuck with me. Months earlier, the PM of the team that redesigned that car’s operating system had posted on LinkedIn celebrating what a great job they’d done. The user who fights with that product every single day can’t help but keep thinking of that post.

It’s rare for the builders’ self-congratulation and the users’ lived experience to diverge this sharply. Let me give you the conclusion up front: AI has largely solved the problem of “code can’t be written fast enough.” What it hasn’t touched is the problem that “nobody rewards the person who fixes things.” And the better the tools get, the wider that gap grows.

Throughput Really Did Go Up

Let’s get one thing straight first: this isn’t a story about “AI ruined everything.” Speed genuinely did improve.

Google’s DORA team surveyed roughly 5,000 tech workers worldwide for its 2025 report and found that 90% of respondents were using AI in their work, with a median usage time of 2 hours a day. And unlike the 2024 survey, this year’s data showed that higher AI adoption correlated with higher software delivery throughput and better product performance, together. That suggests teams are actually learning where and how to use these tools.

There’s individual-level data pointing the same direction. GitClear, which analyzes code-change histories, reported in January 2026 that the developers who used AI the most produced 4 to 10 times more output than non-users. But there’s an honest caveat attached: much of that gap predates AI entirely — it reflects differences in individual skill that were already there. When you compare the same person’s output to their own past performance, the speed gain was closer to 25%. This reads less like “AI made people better” and more like “the people who were already good picked up AI first.”

The problem is a different finding sitting right next to that one in the same DORA report: higher AI adoption also came with higher delivery instability¹. That means more unplanned deployments triggered by outages and failures. DORA sums up the combination this way: AI is an amplifier. It grows the strengths of organizations that were already running well, and it grows the flaws of organizations that were already creaking, in equal measure.

What Vanished Wasn’t Code — It Was Habits

So what exactly is being amplified? A follow-up study GitClear released in 2026 gets quite specific about this. It tracked 623,000,000 code changes from 2023 through 2026, broken down into eight signals. The direction is consistent across all of them.

The most striking finding is the disappearance of refactoring². The share of all changed lines classified as “moved code” — meaning existing code that was cleaned up and rearranged — fell from 21% in 2022 to 3.8% as of 2026. Over the same period, the share of copy-pasted code rose from 9.4% to 15.7%. Back in 2022, developers chose to clean up code twice as often as they chose to paste it; now pasting dominates by roughly a 5-to-1 margin. This isn’t just a shift in preference — the direction reversed completely.

The rest of the numbers tell the same story. Duplicate blocks — five or more identical lines repeated verbatim — rose 81% versus 2023, the highest level ever recorded. The frequency with which newly written code calls other functions in the existing codebase dropped 35%, meaning new code increasingly sits isolated in its own file, disconnected from the rest of the codebase. The share of work devoted to reopening old code untouched for more than a year — to clean it up or retire it — fell from 1.7% to 0.46%, a 74% decline.

It’s easy to see why this matters if you picture a single duplicate block. If a five-line block is scattered across ten places, whoever fixes one of them automatically inherits the burden of tracking down the other nine and deciding “does this one need to change too?” — including in files and domains they’ve never touched. It’s a structure where the 30 seconds someone saves today gets repaid, half a day at a time, by someone else three years from now.

GitClear calls this the “maintainability gap.” The report sums up the core issue this way: the problem isn’t that AI writes bad code — it’s that today’s default workflow is built to produce one happy path, one passing test, one closed ticket. Whatever is visible and gets closed immediately gets rewarded; whatever is invisible and gets deferred quietly accrues a tax.

So Why Does Nobody Fix It?

This is where the real question shows up. The tools have gotten this good — so why doesn’t anyone pay down this debt? The developer I quoted earlier wrote the answer as an imaginary line from a hypothetical presentation:

“This quarter, we won’t ship any new features and we have no redesign planned. We will focus solely on fixing bugs.”

How many organizations could actually put that sentence on a quarterly planning slide? I’ve almost never seen one. The reason is simple: new features come with a demo, a story to present, a sentence you can drop into a performance review. Stabilization, when it succeeds, shows up as “nothing happened.” The evidence of a job well done exists only in the form of an absence.

bug So this looks like a technical problem, but it’s really a measurement and incentive problem. Throughput shows up on a dashboard in real time; maintainability arrives as an invoice three years later. If a manager can only see one of the two, which one they end up managing is already decided.

In Korea, this distortion isn’t confined to individual company culture — it’s written directly into the industry’s pricing. I’m talking about the public-sector software maintenance rate³. In a 2017 meeting of the Government Policy Coordination Council on Major State Affairs (Gukjeong Hyeonan Jeomgeom Jojeong Hoeui), the government confirmed it would raise the rate from roughly 15% to 20% by 2022, to close the gap with foreign software (around 22%). But according to the 2019 industry survey by the Software Policy & Research Institute (SPRi), 29.8% of responding firms were still being paid a rate below 10%. The private-sector average was 14.2%, meaning the public sector was actually paying less. The practice of fully compensating for building something while discounting the cost of fixing it has been on the books, in writing, for decades.

The consequences accumulate quietly. At its March 2026 briefing on digital and IT affairs, Korea’s Financial Supervisory Service (FSS) noted that many recent incidents stemmed not from sophisticated hacking techniques but from a failure to follow basic security principles and internal controls. The diagnosis is that the cause of failure is the basics, not the cutting edge. And the basics are, by definition, the one thing nobody ever gets praised for.

These Numbers Deserve Scrutiny Too

If you’ve read this far and concluded “so AI was the problem after all,” that’s premature. We need to look at the limits of this evidence too.

First, GitClear is not a neutral observer. It’s a company that sells tools for measuring code quality and developer productivity. A conclusion that quality metrics are getting worse happens to align neatly with that company’s business interests. A large dataset and a neutral interpretation are two different things.

Much of the DORA survey is self-reported, too, and what it observed is correlation. This data alone can’t tell us whether teams that use AI heavily become unstable, or whether teams that already move fast and loose are simply the same teams that adopt AI first.

The most interesting case is the once-widely-cited METR study. In a July 2025 release, 16 experienced developers were randomly assigned⁴ to 246 real tasks, and the finding was that completion took 19% longer when using AI. But in February 2026, METR itself revised the experimental design. The reason: developers who stood to gain the most from AI were disproportionately reluctant to be assigned to the “no AI” condition — a selection bias — and once the team corrected for that, using data from re-participants, the estimate flipped to AI making developers 18% faster. In short, the research team itself walked the finding back to something close to “we honestly don’t yet know whether AI increases productivity.”

One finding survives this revision, though: the gap between perception and the clock. Before the study began, participants expected to be 24% faster; after it ended, they still felt they’d been 20% faster. Whichever way the actual measurement goes, the conclusion holds that people cannot accurately gauge changes in their own productivity by feel. And right now, most organizations are adopting tools and planning headcount based on exactly that feeling.

Oz’s Lens

Having built GTM strategy, I’ve sat through more product roadmap meetings than I can count, and the scene where stabilization items get pushed down the priority list repeats almost without exception. What’s interesting is that nobody in the room ever dismisses quality as unimportant. But when it comes time to pick the sentence for the quarterly goals, “we shipped three new features” beats “we reduced outages by 40%” every time. The first sentence has to prove that something didn’t happen; the second just has to be shown.

To add something from my own experience with data: the maxim “what gets measured gets managed” operates in organizations almost like a law of physics. So I don’t think the root cause here is AI. The distortion was already there; AI is simply the mechanism that executes it much faster. When the cost of building a feature drops to a tenth of what it was, a scale that was already tilted toward features tilts even further. Cleaning up and retiring code, by contrast, still demands human judgment and time, which makes it look relatively more expensive.

That’s why I think any organization treating this as a question of which tool to pick will largely fail. Whether you use Cursor or Claude Code, if the quarterly plan has no line item for “fixing things,” the outcome is the same. DORA’s own conclusion says exactly the same thing: success with AI adoption is a systems problem, not a tools problem.

I’ll leave one door open, though. The developer who wrote the original post ended not on pessimism but on this hope: while companies pile up debt, an individual developer can now single-handedly build software they never would have dared attempt before. The same tool that creates the debt also hands the person who’s sick of that debt the power to build an alternative.

Closing

Let me sum this up in three lines. Since AI adoption, throughput has gone up, but the habits that keep code alive long-term — refactoring falling to 3.8%, duplicate blocks rising 81% — have retreated across the board. It’s not because AI writes bad code; it’s because closed tickets get rewarded and outages that never happen get nothing. Korea has even carved that distortion into its pricing, in the form of the maintenance rate.

Here’s one thing worth trying this quarter: open up your roadmap and count what percentage is allocated to “fixing and cleaning up.” If it’s close to zero, that’s not a problem with your team — it’s a problem with the plan.

Have you ever seen an organization spend an entire quarter on stabilization instead of new features? I’m especially curious how that decision got approved, and how that team was treated in the review that followed.

💬 Tell me in the comments about an organization that spent a quarter on stabilization. I’ll fold it into a future issue. 📨 If you have a colleague fighting to get a quality line item onto the roadmap, send them this piece.

References & Further Reading

Primary sources

GitClear, “The Maintainability Gap: AI Code Quality in 2026”, 2026. ··· Most of today’s figures come from here. That said, I’d recommend reading it with the awareness that this company sells code-quality measurement tools.
Google Cloud, “2025 State of AI-assisted Software Development (DORA Report)”, Sep. 2025. ··· The key passage is that throughput and instability rise together. The phrase “AI is an amplifier” also comes from here.
Becker, J., Rush, N., Barnes, B. & Rein, D., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, arXiv:2507.09089, Jul. 2025. ··· This is the original source of the 19% figure. I’d strongly recommend reading it alongside the follow-up below.
METR, “We are Changing our Developer Productivity Experiment Design”, Feb. 2026. ··· This is the record of the research team acknowledging its own selection bias and revising the design. The way they publicly amended their own research is worth reading on its own merits.
Software Policy & Research Institute (SPRi), “Public-Sector Software Maintenance Projects Must Close the Budget Blind Spot” (Korean). ··· This piece covers the gap between the maintenance-rate target and reality. A good starting point for understanding Korea’s structural background.

Background

DORA, “Balancing AI tensions: Moving from AI adoption to effective SDLC use”, 2026. ··· This analysis argues that the time AI saves on generation gets reallocated to verification. It connects directly with the third section of today’s issue.
Lawtimes, “Key Takeaways from the 2026 Digital & IT Financial Supervision Briefing” (Korean), Mar. 2026. ··· This lays out the diagnosis behind recent financial-sector incidents. Useful for seeing how regulators view the issue.

Past issues worth reading alongside this one

Why Does the New Fed Chair Talk Like a Startup Founder ··· This issue covered how the narrative “AI productivity is just around the corner” circulates ahead of the actual data. It looks at the same gap from exactly the opposite side of today’s issue.

📝 Glossary

The author, Kwangseob Ahn, is a professor of business administration at Sejong University and lead consultant at OBF (Oswarld Boutique Consulting Firm). He teaches statistics and data analysis, including business data management and business analytics, while leading GTM and AI strategy consulting in the field, designing the seam between technology and business. He has published academic research on a memory architecture for AI dialogue systems (HEMA) and runs Daily Arxiv, a daily curation of global AI papers. He holds a master's from Korea University's Graduate School of Technology Management and a KMBA. He is the author of Homo Brainless: The People Who Outsource Their Thinking.

Footnotes

Delivery instability: How often a team has to push an unplanned deployment after shipping new code, because of an outage or a defect. Unlike speed, it’s a metric users feel immediately. ↩
Refactoring: Reorganizing a program’s code structure without changing what it actually does. It’s less about adding a new room to the house and more about tidying up the stuff that’s already inside it. ↩
Maintenance rate: The percentage applied to a software system’s development cost to set its annual maintenance budget. At a 10% rate, a system that cost ₩100,000,000 to build would carry an annual maintenance cost of ₩10,000,000. ↩
Randomized assignment: Randomly distributing participants or tasks across experimental conditions. It reduces the risk that differences other than the condition itself contaminate the results, giving stronger grounds for causal claims than a simple comparison would. ↩