A bug ships with a new feature, and the proposed response is to schedule a retro. On paper that’s the right instinct. In practice, you often know how it will go.

You’ll gather, agree the process should have caught it, write an action item nobody owns, and ship the next bug the same way. A ceremony where a fix should be.

But the retro isn’t really the problem. It’s the last link in a chain of rituals that all share the same flaw.

The review that doesn’t review

Start with the pull request. The flow is supposed to be a safeguard: you write code, someone with judgment reads it, they catch what you missed.

What often happens instead is that the author opens a PR and waits for a thumbs up, and the reviewer, busy, trusting, and buried under their own pile, skims it and approves.

Nobody really read it. The green check says otherwise.

It gets worse when there’s friction. A review comes back with real questions and no approval, and the author routes the PR to a second reviewer who will say yes.

Not to address the concern. To get past it. The objection wasn’t resolved, it was outvoted by an audience of one.

Of course problems slip through. That isn’t a flaw in the process. It’s the process working exactly as configured.

Tested is not done

Then there’s the word “tested,” which does a lot of quiet lying.

Someone says a feature is ready and means QA ran it and it passed. Someone else says it’s not ready and means it isn’t safe in front of real users at real scale.

Both are telling the truth. They’re just using “ready” to mean two different things.

Passing QA tells you the thing does what the ticket said on a good day. It doesn’t tell you what happens under load, with malformed input, at 3am when a dependency is down.

Tested is a floor. Production-ready is a much higher ceiling. Pretending the floor is the ceiling is how you ship the bug you then schedule a retro about.

The common thread

Look at the three together: the rubber-stamp review, the QA-equals-done handoff, and the retro that resolves nothing. They run on one mechanism.

Each takes responsibility and spreads it thin enough that no single person is left holding it. The reviewer trusted the author. The author trusted QA. QA tested what they were handed.

The retro belongs to everyone, which means it belongs to no one. By the time the bug reaches a customer you can trace a dozen hands it passed through.

And not one that would say “that was mine.”

Put your name on it

A friend made a joke that stuck with me. He said that when he commits code written with an AI, he always tags it: authored by him, co-authored by the model.

It’s funny because it’s a tiny ceremony of its own. It’s also exactly right, and not because of the AI part.

The point is the signature. Putting your name on something changes how you treat it. You read the diff differently when the commit will say you wrote it.

You think harder about “ready” when ready is your word on the line.

And he added the part that matters most: this was true long before AI. The model didn’t invent the accountability gap. We had it when humans wrote every line by hand.

AI just made it easier to ship code nobody feels they own, and faster, which means the durable fix was never going to be a tool. It’s a name.

So I’ve stopped trusting the green checks on their own. Tested, reviewed, approved, retro’d. None of them mean much without someone behind them willing to say, out loud, this one’s mine.

That’s the part of the quality process actually worth keeping. The rest is ceremony.