The Review Gauntlet
Every review gate your team runs exists for a reason. Most of those reasons are the same reason: direction was unclear when the work started.
I heard a sharp observation recently (h/t Jack Hanlon at Meta): you have an F1 car going down a street with stop signs every 100 feet and wondering why it isn't faster.
He described the gauntlet that code passes through in most mature product organizations on its way from complete to in users' hands. Strategy reviews, product reviews, design reviews. engineering reviews, privacy, legal, accessibility, comms, experimentation setup and approval, experimentation results review, and on and on.
Each gate was created in response to something that went wrong. A feature shipped that violated a privacy policy. Or a design shipped that broke accessibility. An experiment launched without proper controls. Real incidents, real consequences, real reasons for the gate to exist.
The answer is obviously not to kill them all.
But they were designed for a world where writing the code was the bottleneck, where getting it right before shipping was critical because rewriting was expensive. That world is gone. When code for some features takes hours to write, the review cycle is now 95% of the timeline. The critical path changed but the calendar didn't.
That framing is accurate. But the F1 car metaphor implies the fix is faster stop signs. Better review tooling. Automated checks. AI-assisted privacy reviews. Make each gate faster and the car moves faster overall.
That helps at the margins. The deeper question is why each gate catches what it catches.
Strategy review catches misalignment between the feature and organizational priorities. This means the team built something that didn't match what leadership intended. The direction was vague enough that the engineering team's interpretation diverged from strategy.
Design review catches intent gaps. The feature works but the experience doesn't match what the PM envisioned. The spec described functionality but not interaction. The developer filled in the UX decisions the same way agents do: based on patterns, not intent.
Engineering review catches confusion about requirements. The code works but handles edge cases differently than intended. The spec said "handle errors gracefully" and two engineers had different ideas about what gracefully means.
Privacy review catches data handling assumptions. The feature collects or processes data in ways the spec didn't address. Because the spec was about functionality, not data flow. The engineer made reasonable assumptions that happened to be wrong.
Every one of these gates compensates for the same upstream failure: the brief wasn't clear enough when work started.
When direction is vague, decisions get made downstream. Each gate exists to catch those decisions before they ship. The more vague the direction, the more decisions get pushed downstream, the more gates catch issues, the longer the gauntlet takes.
It compounds. A vague brief produces a PR that's 80% right. The remaining 20% gets caught across multiple review gates. Strategy sends it back for rescoping. Design sends it back for UX changes. Privacy sends it back for a data flow review. Each round trip adds days. Each reviewer needs context. Each context assembly is its own cost.
Now multiply this by every feature in flight. Five features, each making three round trips through different gates. The engineering team spends more time responding to review feedback than building. The reviewers spend more time reviewing than doing their own work. The PM spends more time in review conversations than setting direction for the next feature.
The gauntlet consumes the attention of everyone it touches. And the more code we push (and the more lines per push), the worse the gauntlet gets.
Code was never the scarce resource in large organizations. Alignment was. AI didn't expose a broken review process. It exposed that most software work was never limited by typing speed in the first place.
The review gauntlet is alignment happening at the wrong end of the process. Alignment by correction rather than alignment by direction.
What alignment at the start looks like
Consider what happens when direction is clear before execution begins.
The brief states what the feature does, why it matters, what done looks like, what's explicitly not included, and the main risk. The team aligns on it. The PM's intent survives the translation because the translation happened collaboratively, not as a downstream interpretation.
Strategy review becomes a rubber stamp because the brief was written with strategic context. The reviewer scans it and confirms alignment in minutes, not days (or meetings).
Design review becomes unnecessary as a gate because the designer contributed during brief alignment. The UX intent was captured before anyone opened an IDE. Edge cases got surfaced when they were cheap to address. AI may even have connected those dots.
Engineering review still catches technical issues, but the "that's not what I meant" class of problems disappears. The reviewer isn't second-guessing intent. They're verifying implementation.
Privacy and legal still matter. But when the brief explicitly addresses data handling and constraints, these reviews get shorter. The feature was designed with constraints in mind, not retrofitted to accommodate them.
The gauntlet shrinks. Not because you removed gates, but because each gate has less to catch.
This is what we experienced building with @usehamster. The brief is where alignment happens. By the time a plan generates and an agent starts executing, the team already agreed on direction, scope, constraints, and definition of done. The review stage compresses because the direction stage expanded. And then we ship like demons.
The math
A team with vague direction ships a feature in 3 weeks. The breakdown looks like 2 days of writing the spec, 2 days waiting for review meeting, 3 hours of actual development, 8 days of review cycles across multiple gates and 2 days of revision from review feedback.
A team with clear direction ships the same feature that same day. The breakdown: 15 minutes writing a brief. 30 minutes of team alignment. Plan generation. Agent execution. One review pass that catches technical issues but not intent misalignment. Shipped. Live.
The engineering effort is roughly the same. The review effort collapsed because there was less to catch.
Most organizations invest in faster gates because the gates are visible. You can see the review queue. You can't see the vague brief that filled it.
The answer today isn't a better gauntlet. The teams shipping fastest don't even run one. They aligned at the brief and the gates had nothing left to catch.
Hamster's completely free during early access. DM me if you'd like to try it. You'll love it.