You didn’t create more bugs, you just found them faster

Estimated reading time: 8 minutes

Key takeaways:

• You compressed the building part, not the fixing part. Eight weeks of work delivered in one week also means eight weeks of bugs turning up.
• Pausing feature work to fix quality is a symptom. It usually means you don’t have a handle on your investment balance.
• Code review isn’t the only bottleneck. Product decisions are the other one, and clearing it means engineers picking up product sense and product managers getting comfortable building.

---

A lot of engineering leaders I talk to are having some version of the same experience right now. The AI tooling is working, and it’s exciting. Teams are shipping things in days that used to take weeks. At the same time, everything feels like it’s falling apart – more bugs than they’ve ever had, more incidents, and engineers who are busier and more stressed.

If that’s you, it might honestly be more of an arithmetic problem than a quality one.

Where the 8 weeks of bugs come from

Work that used to take eight weeks can now take one, and you tend to focus on that number.

However, what you compressed was the time it took to build and ship the thing. The bugs are still there, and instead of surfacing gradually across eight weeks, they all turn up in the week after you ship.

It may well be more of them than before, too. Pull requests have indeed gotten a lot bigger – across a sample of 1,500 engineering organizations in Swarmia, median batch size roughly doubled between early 2025 and early 2026 – and bigger changes tend to break in more places.

So in hindsight, the number you should have committed to was one week of building plus however long it takes to fix eight weeks of bugs arriving at once. Which is still a very good trade against eight weeks, in my opinion. Many of those bugs were never going to surface before production anyway, however long you spent on the implementation.

Nothing has gone wrong here, but if nobody planned for that second week, it won’t look that way from outside engineering.

Pausing is a symptom

The knee-jerk reaction for many leaders when quality slips is to stop the line, pause feature work, clean everything up, and start again. Sometimes that’s right. If reliability has got bad enough, carrying on as normal because you’ve decided pauses are bad would be silly.

The problem is when pausing is the only way quality work ever gets funded. If the only two options you can see are shipping features and fixing the system, you’ve been treating quality as something that happens when there’s slack, and there’s never slack.

Holding a high bar on what you’re building now isn’t the thing under discussion. That shouldn’t be up for negotiation, however far behind you are. Fixing what’s already broken is different, and it competes for capacity like anything else. So try to decide the ratio out loud, something like: half our capacity goes to fixing the root causes this quarter, and we’ll still take on the most critical feature work.

The difficult parts are still difficult

It’s so quick to do the easy parts now, but the difficult parts are still pretty difficult – working out what to build, judging whether a change fits the system you’ve already got rather than adding a fifth way to do the same thing, knowing which bits of the product people rely on.

Which also makes it very tempting to slip into a mode where you generate something, it compiles, the tests pass, and you throw it over the wall to your colleagues without thinking deeply enough about it.

Some of what’s missing is context an agent has no way to reach. Why does a service have that one strange piece of logic? Which customer’s integration breaks if you change something that looks insignificant? Or a decision your team made three years ago after an incident, which works fine and nobody has had a reason to revisit.

You’re never going to document all of that in advance, because half the problem is that nobody remembers the context exists until they run into it. When you do run into it, write it down.

Instruction files and repository rules are easy mode. You can step it up a level by, for example, building the habit of writing architecture notes that record why something is the way it is when you discover that the reason is important.

Every improvement you make there helps every engineer and every agent on the team. If you spend two hours today steering an agent around some awkward corner of your system, write it up as an agent skill so your colleague doesn’t spend the same two hours tomorrow.

The bottleneck you can see: code review

More code means more code reviews, and there’s pressure to drop them or wave things through with review agents to keep the pace. Plenty of teams are already trying it, with mixed results.

Review is one of the few places where a person who understands the system can make a judgment call that tools still can’t. Is this the right change to make? Does it compose well with the rest of the system, and are the tradeoffs ones your team wants to live with?

That doesn’t mean asking people to review several times more code. Let the bots handle the specific risk areas (like database migrations, security patterns, and architectural consistency) so your engineers can spend their attention higher up. Linters got us past a whole category of style argument years ago. Now AI review can move the conversation from “did you handle this null check?” to “is this the right data model to use?”

If review is where the work piles up, that’s also where your delivery speed is decided. So build your review capacity instead of abandoning it, mostly by getting the things that don’t need human judgment out of the way.

The one you can’t: product decisions

If your product managers have to make every small decision about where a feature goes and how it should work, they become the constraint. Engineering can now generate several times the volume of work that needs product input, and there’s no version of this where one PM keeps up by working harder. It has to move in both directions.

Engineers need enough product sense to make most of those calls themselves. That means understanding who the customer is, what problem this solves, and what the tradeoffs are – knowledge that used to be “a PM thing.”

Product managers need to get comfortable building, full stop. Prototyping with AI is often the quickest way to work out what the thing should be: make a rough version, put it in front of somebody, and learn from that rather than trying to specify the whole thing first. It’s a different job from writing tickets, but it suits the world we live in. The PMs I see doing well right now flex between both modes depending on what the work needs.

How to tell if things are actually getting worse

Bug and incident counts are harder to analyze when you’re shipping more, because you’d expect both to rise with volume. So watch change fail rate and recovery time too: are individual changes actually failing more often, and how quickly do you get back on your feet when they do?

On the throughput side, a metric I’ve been seeing a bit recently – Microsoft’s engineering team uses it internally – is pull requests per incident. Basically: how much work did you get out the door for each disruption you caused? I wouldn’t watch that one (or any other metric) on its own. 

If your pull requests get twice as big, you can improve the number without necessarily improving much else. Watching it alongside batch size and your KTLO (keeping-the-lights-on) share is more useful. If maintenance work is growing faster than your throughput, you’re producing code faster than you’re producing quality.

I’d also add deployment confidence, which most teams don’t track at all because it isn’t a number you can pull from git and put on a dashboard. Does your team feel comfortable shipping? If engineers dread deployments, or avoid shipping on a Friday, your quality infrastructure isn’t providing the safety net it’s supposed to. That costs you speed as well as quality, because people who don’t trust the safety net ship less often.

If you only do one thing after reading this, ask your engineers whether they’re comfortable shipping, and if not, why not. It costs nothing, and it’ll often tell you what to look at before the dashboard does.

You simply find things out faster now

The practices that produce good software are basically the same ones that produced it a decade ago, and most of them are unglamorous enough that nobody gives conference talks about them anymore.

You use code review as an engineering conversation instead of a checkpoint, and you write tests as you go rather than afterwards.

You pair on the work where being wrong is expensive, and you spend some extra time on the design before somebody builds the wrong thing.

You give technical debt a predictable share of your capacity, because the technical debt project that has to compete with feature work will lose that game every single time.

What’s changed is the speed. Skip any of this and you used to get away with it for a couple of months. Now, you find out in the second week.

That’s uncomfortable, sure, but I still think it’s a pretty good deal.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.