A zero-bug policy lets you stop managing stocks of defects.

But it isn't enough.

If the team fixes bugs faster without changing the way it builds, it stays stuck in a repair loop. The backlog shrinks, then climbs again. The fires go out, then flare back up. Support catches its breath, then gets swamped again.

The real issue lies upstream.

How do you avoid producing so many bugs in the first place?

You don't cut bugs down with better triage alone. You cut them down by giving ownership to those who ship, by refusing overly vague specifications, by testing earlier, and by giving QA a quality-policy role rather than a catch-up one.

Quality isn't something you delegate after the fact.

Quality belongs to those who ship.

Fixing other people's bugs dilutes ownership

In a lot of teams, the setup looks like this.

A developer works on a feature. They ship it. They move on to something else. Bugs show up. Since they're already busy, someone else picks them up. An available developer. A person on rotation. A technical support team. Sometimes a dedicated bug team.

On paper, this looks efficient. You optimize for availability.

In practice, you dilute ownership.

Whoever introduced the defect doesn't always see the cost of what they shipped. Whoever fixes it has to understand a context they didn't create. The lost time becomes collective, and therefore less visible. And everyone can hide behind a classic line: "I'd already moved on to something else."

This system creates a bad signal.

It implicitly says: you can ship, and if it breaks, someone else will absorb it.

Even if no one puts it that way, the effect is real.

Whoever creates the bug fixes it

The healthiest rule is simple: whoever creates the bug fixes it.

Not because people should be punished.

Not because people should be humiliated.

Because responsibility for the fix has to stay tied to responsibility for the production.

If a developer knows their bugs will come straight back to them, they'll ship differently. They'll test more. They'll review more carefully. They'll avoid pushing a fragile change just to hit a deadline. They'll be less willing to build on top of a strong ambiguity.

It's not a guarantee. But it's a healthy incentive.

Of course, there are exceptions.

The developer may be away. The bug may come from several contributions. The problem may live in legacy code. Responsibility may be shared. Someone else may sometimes be better placed to fix it.

These cases exist.

But they shouldn't become an excuse to abandon the general rule.

In most cases, if a developer created the defect, they should fix it. Even if they've moved on to something important. Even if it disrupts the schedule. Even if it slows down the next feature.

Quality consumes capacity. Hiding it doesn't make it free.

Ownership isn't blame

Here we need to distinguish ownership from a culture of blame.

Giving ownership doesn't mean hunting for a culprit. It doesn't mean publicly naming whoever broke things. It doesn't mean creating a fear of shipping.

A culture of blame destroys quality. People hide problems, downplay defects, avoid taking risks, document to cover themselves, and the team learns more slowly.

Useful ownership is different.

It says: you own what you ship, so you take part in its fix, its lessons, and its improvement.

We're not trying to punish. We're trying to close the loop.

The developer who fixes their own bug understands better what broke. They see where their understanding fell short. They see whether the test was missing. They see whether the spec was vague. They see whether the architecture made the error likely.

That loop is what creates quality.

Developers aren't order-takers

This ownership rests on another idea: developers aren't order-takers.

They aren't there to "crank out code."

They're value creators.

The Product Manager owns the product decisions: why this topic, for which audience, with what impact, at what priority. But developers own the technical quality, the code base, and what they ship.

Everyone has a zone of responsibility.

If the Product Manager makes a bad product trade-off, they have to own it.

If developers ship code that's fragile, poorly tested, poorly understood, or hard to maintain, they have to own that too.

This doesn't mean the responsibilities are isolated. They talk to each other. A good product is built through dialogue between product choices, feasibility, usage, quality, and technical constraints.

But that dialogue shouldn't be used to dissolve responsibility.

An overly vague spec must be refusable

A defect doesn't always come from bad code.

It can come from an incomplete specification, an ambiguous product decision, an unconsidered case, a poorly understood flow.

But that doesn't mean no one is responsible.

If a spec is too vague, developers should be able to refuse to build.

Refusing doesn't mean blocking. It means: the framing isn't clear enough to ship something correct.

It's better to ask for clarification before coding than to build a shaky feature that will later generate bugs, support tickets, rework, and endless discussions.

A responsible developer doesn't just execute an ambiguous request. They seek to understand the expected behavior, the edge cases, the acceptance criteria, the risks, the data, the dependencies.

If they can't understand what they're supposed to ship, they can't guarantee the quality of what they ship.

Product responsibility and technical responsibility meet right there: the Product Manager has to clarify the product decision; developers have to refuse to turn a strong ambiguity into fragile code.

TDD: the what before the how

TDD, Test Driven Development, is a concrete answer to this logic.

Instead of writing the code first and then checking whether it works, you write the test first.

The test describes the what.

The code implements the how.

It's an important distinction. The test formalizes part of the specification: here is the expected behavior, here is what must stay true, here is what must not break.

After that, the code can evolve. It can be refactored. It can interact with new data. Other features can grow up around it. But if the expected behavior is broken, the test breaks.

Ideally, the problem is caught on the developer's machine or in QA, not in production.

TDD doesn't eliminate every bug. It doesn't replace product thinking. It doesn't turn a bad spec into a good product.

But it changes one essential thing: it forces you to make part of the quality verifiable before implementation.

In an organization that wants fewer bugs, that discipline matters.

QA isn't a safety net

QA shouldn't be the place where developers drop off their quality responsibility.

If QA is just a safety net at the end of the chain, it arrives too late. It tests what should have been thought through, clarified, automated, or avoided earlier. It becomes the last line of defense before production, and therefore the place where the organization outsources its defects.

That isn't enough.

QA can play a far more strategic role.

It can define the quality criteria. The testing policies. The shipping standards. The acceptable regression thresholds. The risks to cover. The areas of the product to secure. The tests to automate. The signals that show whether a team is shipping better or worse.

With artificial intelligence and automation, this role becomes even more important.

As with many jobs, AI makes it possible to cut down part of the repetitive operational work in order to focus more on strategy. For QA, that means fewer repetitive manual tests, fewer regressions replayed screen by screen, and more thinking about the quality system.

QA's value shifts.

Less: mechanically redoing the same checks.

More: defining what to check, why, at what level of automation, against which risks, with which criteria.

QA doesn't replace developers' responsibility. It builds the framework in which that responsibility becomes practical, measurable, and sustainable.

Metrics must serve quality

Measuring can be useful.

Rework, for instance, can show that a team keeps going back over the same topics. Cycle time can reveal that reworks are heavily slowing down delivery. Regressions can show that certain areas of the product break too often.

These signals are useful if they serve to improve the system.

They turn toxic if they recreate an administrative obsession.

There's no point spending endless time figuring out whether a defect is a bug, a feature, an improvement, a rework, a QA anomaly, or something else, if that classification doesn't change the decision.

Measurement should shed light.

It shouldn't replace judgment.

The goal stays simple: ship what matters fast, at an acceptable level of quality, and reduce the real pain.

The legacy of the future

Legacy exists.

Every team has to, at some point, work with old code, past decisions, fragile architectures, poorly documented dependencies, choices that maybe made sense yesterday and complicate everything today.

You can't always avoid existing legacy.

But you can avoid manufacturing tomorrow's legacy.

A bug handed off to someone else, a vague spec accepted without discussion, a test never written, a manual regression repeated without automation, a QA used as a final net, code shipped fast but poorly understood: all of that becomes future legacy.

Giving developers ownership doesn't fix everything. But it changes the trajectory.

When whoever ships owns the quality of what they ship, they build differently. When they can refuse an overly ambiguous spec, they avoid turning vagueness into complexity. When TDD formalizes part of the specification, the product becomes more robust. When QA defines a quality policy, the whole system becomes clearer.

Future legacy isn't inevitable.

It's often the result of responsibilities misplaced today.

Conclusion

A team that wants fewer bugs shouldn't just classify them better.

It has to make quality impossible to delegate.

A zero-bug policy deals with the stock of known defects. But delivery quality is what keeps that stock from being recreated. For that to happen, everyone has to hold up their share of the responsibility.

The Product Manager owns the product decisions.

Developers own the technical quality of what they ship.

QA builds the quality framework: criteria, standards, risks, tests, automation.

And the team, collectively, has to refuse the kind of setup where bugs always become someone else's problem.

Ownership doesn't mean blame. It means responsibility for what you produce.

Quality belongs to those who ship, because they are the ones who can build it at the moment it costs the least: before the bug exists.

Further reading

Zero bug: let's stop managing stockpiles of defects Code Centric