"How could you let this happen?"
I've been in that conversation. On both sides of it, at different points.
It's a versatile question.
The first time I heard it from above, we'd shipped something that shouldn't have shipped in the state it was in. Bugs that a proper code review would have caught. QA that got compressed in the final days because another part of the project ran late and the deadline didn't move.
Nobody decided to skip code review. Nobody said "let's just ship it broken." What happened was simpler and more predictable: the deadline was fixed, the timeline snowballed, and the back of the chain got squeezed. Code review and QA are always at the back of the chain. When time runs out, they're where the time comes from.
Everyone agreed at the start of the project that they mattered. Someone always raises it at the end, too. They're not wrong, but the deadline is rarely swayed by a good point.
I've done the same thing in how I talk about work. For a while, I praised speed without understanding what was being traded to get it. "You turned that around fast." Said with genuine appreciation. Received as instructions.
When I realized it, I tried to correct it.
Refused to let reviews be where the time came from.
Ensured they stayed in the planning estimate.
Made them a line item, not an afterthought.
It held until the next hard deadline, which arrived on schedule. Then the timeline snowballed again, for reasons that had nothing to do with code review, and the question was: what do we compress?
Same answer as always.
Engineers respond to incentives. We already know what happens when quality controls live at the end of a compressed schedule: they get cut. Critical thinking is increasingly vulnerable to the same pressure.
I know, because I've been the person setting those incentives. I didn't mean to. I praised speed.
Timelines were slipping long before anyone knew what a token was, but AI has made the path of least resistance feel productive. When you can offload work and still hit the deadline, it's genuinely hard to argue against in the moment. Especially when the alternative is staying late, losing the argument, and watching the code review get cut at 11pm anyway.
The obvious fix is to hand the review to AI.
Faster than a human.
No one has to stay late.
The process technically still happens.
Except AI reviewing AI-generated code means nobody has actually looked at it. The thing that slips through under pressure isn't always a syntax error. Sometimes it's the change that broke an assumption nobody documented.
Speed pressure keeps building.
People get more depleted.
Exhaustion makes the easiest options more attractive.
The easiest options still hit the deadline.
Speed gets praised.
The loop runs itself, quietly, while everyone's still arguing about who let this happen.
One of the fixes I keep coming back to isn't structural.
Protected reviews.
Line items in the estimate.
I've tried those.
They tend to last until the next deadline, which is to say they don't last.
What I think actually sticks is what gets named. I'm not talking about a process doc. When someone pushes back on a compressed timeline and catches the thing that would have shipped broken, that has to come up in the next 1:1. It needs to be praised and I have to be the one to tell that story.
Process follows incentives. It's never the other way around.
What interests me isn't whether people are making bad choices.
They're humans. I know they are.
It's that the system reliably produces the outcome it claims not to want.
Everyone agrees code review matters... until the deadline, at which point it becomes a philosophical position.
Everyone agrees judgment can't be outsourced... until the velocity report.
And when something breaks, someone inevitably asks the question.
Top comments (0)