Any process that requires someone’s approval before work can proceed creates a structural power asymmetry. The approver can always say no, and the burden of proof is always on the person seeking approval. When this asymmetry is exploited — consciously or not — the approval gate becomes a weapon. The following antipatterns are drawn from code review but apply to any gatekeeping process: editorial review, design critique, legal sign-off, procurement approval.
The danger of each pattern is that it is indistinguishable from legitimate diligence. The gatekeeper can always claim they are “just being thorough.”
The Patterns
Death of a Thousand Round Trips
Read just far enough to find one nitpick. Stop. Wait for the fix. Read a little further. Find another nitpick you could have mentioned the first time. Stop. Wait again. Each round trip costs a day. The work evolves as slowly as possible while the reviewer technically “responded promptly to every revision.”
This is sabotage by procedure: the reviewer is following the process correctly — responding to each version, raising legitimate issues. The dysfunction is serial where parallel was possible, and no rule requires parallel feedback.
The Ransom Note
The submitter needs this specific change badly. The reviewer does not. The asymmetry creates leverage: approve the change only after the submitter does unrelated work that benefits the reviewer. The hostage is the submitter’s urgency.
The Double Team
Two reviewers make incompatible demands. Each directs feedback at the submitter, never at the other reviewer. The submitter ping-pongs between contradictory requirements until they give up. The reviewers avoid direct conflict with each other by using the submitter as a buffer.
This is the triangulation trap in organizational form: instead of resolving disagreement directly, both parties force a third party to absorb the cost of their conflict.
The Guessing Game
Criticize the solution on vague grounds — “design principles,” “future compatibility,” “architectural concerns” — without specifying what an acceptable solution would look like. The submitter guesses, implements something different, and gets that rejected too. The reviewer never commits to a position, so they can never be wrong.
This is the high-status move of judging without producing: the reviewer maintains authority by staying in evaluation mode while the submitter exhausts themselves generating options.
Priority Inversion
Spend the first passes on trivial issues — variable names, comment typos. Wait for all those to be fixed, then reveal a fundamental architectural problem that requires rewriting the sections you just made them polish. The message is: your time is not valued.
The Late-Breaking Design Review
A large piece of work is half-committed. The reviewer was not consulted on the original design — or was, and lost the argument. Now they hold a minor but blocking change hostage until the entire prior design is rejustified. They transform a tactical review into a strategic veto.
The Catch-22
If the change is one large patch, it is “too hard to review — split it up.” If it is many small patches, “these don’t make sense on their own — combine them.” Any tradeoff can be weaponized: readable code has “unacceptable performance”; optimized code is “unmaintainable.” The reviewer wins by pivoting between two legitimate concerns, making it impossible to satisfy both simultaneously.
The Flip Flop
Suddenly object to a pattern you have approved three times before. When the submitter points out the inconsistency, respond: “You’re right, those should be changed too.” Do not volunteer to change them yourself. With luck, the submitter interprets this as an instruction to retroactively fix all prior instances — free labor, purchased with a sudden change of taste.
Review Theater
The process gives the illusion of detecting and resolving errors without any evidence of its effectiveness. Reviews happen, comments are left, approvals are granted — but the ceremony has no measurable relationship to quality. The process exists because it looks like quality control, and looking like quality control is sufficient for organizational comfort. Actual quality is unmeasured because measuring it would risk exposing the theater.
Why These Persist
Each antipattern works because the gatekeeper has plausible deniability. Thoroughness looks the same whether it is driven by quality or by power. The CIA sabotage manual identified this exact dynamic: the most effective sabotage is indistinguishable from conscientiousness. Plausible deniability is the same currency that powers CYA culture — the gatekeeper and the ass-coverer are the same archetype in different costumes, both trading real judgment for safety from the downside.
The firefighter trap compounds it: when the organization already lacks senior engineers who could push back on bad reviews, junior submitters have no authority to challenge the gatekeeper. Their only option is compliance — which teaches them that voice is futile, accelerating the voice atrophy that destroys the team.
The dead-sea-effect is the long-term outcome: the engineers who care most about doing good work are the least willing to tolerate weaponized review. They evaporate. The residue — those who have learned to appease gatekeepers rather than build good software — become the next generation of reviewers.
Common Misread
The dimwit take is “code review is broken — just ship without review.”
The midwit take is “these are just interpersonal issues — set clearer review guidelines.”
The better take is that approval gates create structural incentives for gatekeeping, and no amount of process documentation prevents power dynamics from flowing through the approved channels. The fix is not more rules but accountability for the reviewer’s impact on throughput — measuring not just what was caught but what was blocked, delayed, or killed.
Main Payoff
The patterns are catalogued not to blame individual reviewers but to make the structural dynamic visible. Most gatekeepers do not consciously weaponize their authority. They are doing what the system incentivizes: demonstrating value through criticism rather than through contribution. The approval gate rewards finding problems, not solving them. Once you see this, every gate in every organization — editorial, legal, compliance, procurement — reveals the same patterns.
References:
- Simon Tatham, Code Review Antipatterns