4 gates every PR passes through.

4 gates every PR passes through. We've only automated 2.

Gate 1. Does the code work.
Gate 2. Is the code clean.
Gate 3. Will it break in production.
Gate 4. Will it spike the bill, cloud or model.

All good, merge. Not all good, don't merge.

Gates 1 and 2 are solved. Like this:

CI runs the tests.
Linters and now LLM reviewers handle the second one, and honestly they do it better than most of us humans do. Especially if it's 5pm on a Friday. :-)

Gates 3 and 4 are where it falls apart. Like this:

The standard answer is load testing and staging.
I've built those environments for a few teams and I'll say the quiet part: they run after the merge, on a schedule, against data that doesn't look like production. By the time they flag something, the commit is buried under 40 others and nobody can point at the one that did it.

So....

Gate 3 becomes an incident!

Gate 4 becomes a finance meeting in month 2!

That was survivable when a team shipped 15 PRs a week.

At 100s of PRs a week, with a lot of them model-authored, it isn't survivable.

The gate didn't get weaker.

The volume went up and the gate stayed exactly where it was.

What gates 3 and 4 actually need is the same shape as gates 1 and 2.

Automatic.
On the diff.
Blocking. Before the merge, not after.

Nobody would ship without CI.

We ship without this every day.

I've spent a while now convinced that's the wrong tradeoff, and I've stopped just complaining about it.