@wazir-dev/cli 1.0.0

package/expertise/antipatterns/process/code-review-antipatterns.md

@@ -0,0 +1,656 @@
+# Code Review Anti-Patterns
+
+> Code review is the single most impactful quality practice a team can adopt -- and the single most destructive when done poorly. These anti-patterns cover the ways reviews fail: through negligence, ego, process breakdown, or cultural dysfunction. Each pattern has been observed across organizations from two-person startups to Google-scale engineering teams. A dysfunctional review culture does not just miss bugs -- it erodes trust, demoralizes contributors, and quietly drives your best engineers out the door.
+
+> **Domain:** Process
+> **Anti-patterns covered:** 20
+> **Highest severity:** Critical
+
+## Anti-Patterns
+
+### AP-01: Rubber Stamping
+
+**Also known as:** LGTM-and-Move-On, Drive-Through Approval, Checkbox Review
+**Frequency:** Very Common
+**Severity:** Critical
+**Detection difficulty:** Hard
+
+**What it looks like:**
+
+A PR is opened. Within 90 seconds, it has an approval with a one-word comment: "LGTM." The reviewer did not check out the branch, did not run the code, and may not have scrolled past the first file. The approval exists solely to satisfy a branch protection rule. Chromium's core team sent an internal memo titled "Please don't rubber stamp code reviews" after noticing that approvals were arriving faster than a human could physically read the diff.
+
+**Why reviewers do it:**
+
+Review work is invisible -- there is no dashboard tracking how thoroughly someone reviewed. Teams under delivery pressure treat reviews as a gate to clear, not a quality practice. When a senior engineer submits a PR, juniors assume the code is correct and approve out of deference. A culture of reciprocal rubber stamping develops: "I approve yours quickly, you approve mine quickly." Junior reviewers see that a senior reviewer has approved, so they rubber stamp too -- "Well, I trust the senior reviewer!"
+
+**What goes wrong:**
+
+Bugs that are visible in the diff -- copy-paste errors, missing null checks, hardcoded credentials -- ship to production because nobody actually read the code. A 2015 study by Czerwonka et al. at Microsoft found that reviews where the reviewer spent less than five minutes had a defect detection rate near zero. Rubber-stamped code at Knight Capital contributed to a $440 million loss in 45 minutes when untested deployment code went live. The review log creates a false audit trail suggesting diligence that never occurred. If you are in a culture where untested code gets waved through because someone powerful wanted it merged, you do not have a code review process -- you have theater.
+
+**The fix:**
+
+Require reviewers to leave at least one substantive comment (not "LGTM") before approving. Track review-to-approval time and flag approvals that arrive faster than 2 minutes per 100 lines changed. Rotate review assignments so that no single person is the default reviewer. Make review thoroughness a first-class performance metric alongside code output.
+
+**Detection rule:**
+
+Measure the median time between PR assignment and approval. If median approval time is under 3 minutes for PRs exceeding 100 lines, rubber stamping is systemic. Track the ratio of approvals with zero inline comments -- if it exceeds 40%, reviews are not substantive.
+
+---
+
+### AP-02: Nitpick Focus
+
+**Also known as:** Bikeshedding, Style Police, Missing the Forest for the Trees
+**Frequency:** Very Common
+**Severity:** High
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+A PR introduces a new authentication flow with a subtle race condition in session handling. The review thread contains 14 comments, all about variable naming, brace placement, and whether to use single or double quotes. The race condition ships to production unnoticed. The reviewer spent 45 minutes on the review -- all of it on cosmetic concerns.
+
+**Why reviewers do it:**
+
+Style issues are easy to spot and unambiguous to comment on. Identifying logic errors, security flaws, or architectural problems requires deeper cognitive effort and domain knowledge. Commenting on style feels productive and demonstrates engagement without the vulnerability of being wrong about a substantive issue. Parkinson's Law of Triviality predicts exactly this: groups spend disproportionate time on trivial matters because everyone can have an opinion on them.
+
+**What goes wrong:**
+
+Substantive defects pass through while cosmetic ones are caught. Authors become frustrated because the feedback feels petty relative to the effort they invested. A study published at IEEE SANER 2021 on anti-patterns in modern code review found that superficial reviews focusing on style were strongly correlated with higher post-release defect density. Over time, developers learn that reviews are about style compliance, not quality, and they stop expecting reviews to catch real issues. The team develops a false sense of security: "we do thorough code reviews" -- but the reviews catch nothing that a linter could not.
+
+**The fix:**
+
+Automate all style enforcement with linters and formatters (Prettier, ESLint, Black, gofmt) in pre-commit hooks or CI. Establish a team agreement: if a linter can catch it, a human should not comment on it. Train reviewers to structure feedback in tiers: (1) blocking issues (bugs, security, correctness), (2) design concerns, (3) suggestions, (4) nitpicks -- and require at least one comment in tiers 1-2 before spending time on tier 4.
+
+**Detection rule:**
+
+Categorize review comments over a two-week period. If more than 60% of comments are style/formatting related and less than 10% address logic, design, or security, the team has a nitpick focus problem.
+
+---
+
+### AP-03: Too-Late Review
+
+**Also known as:** Post-Facto Review, Retroactive Approval, Ambush Review
+**Frequency:** Common
+**Severity:** Critical
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+Code is merged to main before review is complete -- or the reviewer raises fundamental architectural objections after the author has invested days of implementation work. In the first case, the developer merges their own PR citing urgency, then asks someone to "take a look when you get a chance." In the second, the reviewer says "This should use event sourcing instead of CRUD" after the author has already built the entire CRUD layer. Either way, the review's value is destroyed by timing.
+
+**Why reviewers do it:**
+
+Teams without strict branch protection allow self-merges. Deployment pressure creates a culture where "ship first, review later" becomes normalized. When reviews are delayed (see AP-20), developers bypass the process out of frustration. In the design-objection variant, there was no design review or RFC process before implementation began, so the reviewer sees the approach for the first time in the PR.
+
+**What goes wrong:**
+
+Review findings after merge are psychologically demoted -- the cost of addressing them now includes a new PR, re-testing, and redeployment, so they are filed as "follow-up" tickets that never get prioritized. Late design objections force the author to discard significant work, collapsing morale. Teams that experience this repeatedly stop proposing new approaches and default to "safe" patterns, killing innovation. The practice undermines the entire review culture: if reviews can be skipped or overruled when inconvenient, they are optional by definition.
+
+**The fix:**
+
+Enable branch protection rules that require at least one approval before merge. Remove direct push access to main/master for all team members, including leads. For genuine emergencies, establish a documented "emergency merge" process that requires post-merge review within 24 hours with a tracking ticket. Institute lightweight design reviews or RFCs before implementation of any non-trivial feature -- a 30-minute design discussion before coding prevents a week of wasted implementation. Encourage early draft/WIP pull requests so reviewers can flag directional issues before the author is invested.
+
+**Detection rule:**
+
+Query your Git hosting platform for PRs merged without approval or PRs where approval was granted after the merge timestamp. Flag review comments that suggest a fundamentally different approach (keywords: "instead of," "should have used," "wrong pattern," "rewrite") on PRs where the author has already pushed more than 3 commits.
+
+---
+
+### AP-04: Huge PRs
+
+**Also known as:** The Monster Diff, Wall of Code, Mega-Merge
+**Frequency:** Very Common
+**Severity:** High
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+A PR appears with 1,200 lines changed across 35 files. The description says "Implement user management module." Reviewers open the diff, scroll through a few files, leave a comment on line 47, and approve -- because nobody has the stamina or context to review 1,200 lines meaningfully. SmartBear's study of Cisco code reviews found that reviewer effectiveness drops dramatically beyond 400 lines, and defect density in reviews approaches zero beyond 1,000 lines.
+
+**Why reviewers do it:**
+
+Developers batch work because creating small, incremental PRs requires more planning and discipline. Feature branches live too long without integration. The team lacks conventions for breaking work into reviewable chunks. Some developers view a large PR as a sign of productivity rather than a review burden.
+
+**What goes wrong:**
+
+Review quality collapses. Google's internal data shows that 90% of their code reviews involve fewer than 10 files, with most changes around 24 lines -- and this is by design, not accident. Large PRs also increase merge conflict risk, make git bisect less useful for debugging, and delay feedback because reviewers procrastinate on intimidating diffs. When a bug is found in a 1,200-line PR, isolating the problematic change is significantly harder than in a 50-line PR. Research confirms that thousand-line pull requests result in measurably more bugs escaping to production.
+
+**The fix:**
+
+Set a soft limit of 400 lines per PR and a hard limit of 800. Break features into vertical slices that each deliver incremental value. Use feature flags to merge incomplete features safely. Require PRs exceeding the soft limit to include a justification in the description. Use stacked PRs (tools like Graphite, ghstack) to keep individual reviews small while maintaining logical grouping.
+
+**Detection rule:**
+
+Track PR size distribution weekly. If the median PR exceeds 300 lines or more than 20% of PRs exceed 500 lines, the team has a large-PR problem. Alert when any single PR exceeds 800 lines changed.
+
+---
+
+### AP-05: No PR Description
+
+**Also known as:** The Blind Review, Context-Free Diff, Title-Only PR
+**Frequency:** Very Common
+**Severity:** Moderate
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+The PR title is "Fix stuff" or "Updates." The description field is empty. The reviewer must reverse-engineer the intent of the change from the diff alone -- guessing at which behavior is intentional and which is accidental. There is no link to a ticket, no explanation of the approach, and no guidance on what to focus on during review.
+
+**Why reviewers do it:**
+
+This is an author anti-pattern that reviewers enable by accepting and approving description-less PRs without pushback. Authors skip descriptions because writing them feels like overhead, especially for changes they consider "obvious." Teams without PR templates have no structural prompt for descriptions.
+
+**What goes wrong:**
+
+Without context, reviewers cannot distinguish intentional design decisions from mistakes. Review quality degrades because the reviewer is simultaneously trying to understand WHAT changed and evaluate WHETHER the change is correct. Months later, when someone runs `git log` to understand why a change was made, the empty description provides no insight. Onboarding developers cannot learn from the team's PR history because it contains no rationale.
+
+**The fix:**
+
+Add a PR template that requires: (1) a link to the ticket/issue, (2) a summary of the approach, (3) testing performed, and (4) any areas where the author wants focused review. Configure CI to fail if the description is empty or matches the default template text. During review, if the description is missing, the first review comment should be: "Please add a description before I review."
+
+**Detection rule:**
+
+Query PRs merged in the last 30 days. If more than 25% have descriptions shorter than 50 characters, the team has a description problem. Track the percentage of PRs with no linked ticket or issue.
+
+---
+
+### AP-06: Blocking on Style Preferences
+
+**Also known as:** Taste-Based Blocking, Personal Preference Paralysis, "I Would Have Done It Differently"
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Moderate
+
+**What it looks like:**
+
+A reviewer marks a PR as "Request Changes" because the author used a for loop instead of a reduce, named a variable `userList` instead of `users`, or chose a ternary over an if-else. The code is correct, readable, tested, and follows team conventions -- the reviewer simply prefers a different style. The PR sits blocked for days while the author and reviewer debate preferences. As one engineering blog put it: "another developer's personal preference isn't a good enough argument."
+
+**Why reviewers do it:**
+
+Experienced developers have strong opinions formed over years of practice. It is psychologically difficult to approve code that differs from how you would write it. Some reviewers conflate "not my style" with "wrong." Without agreed team standards, every preference becomes a potential blocking issue.
+
+**What goes wrong:**
+
+Author morale degrades when correct code is blocked on taste. The review process becomes adversarial rather than collaborative. PR cycle time inflates as authors make changes they disagree with to appease reviewers, then silently revert them in future PRs. Team velocity drops because reviews become negotiations over style rather than evaluations of correctness. Senior developers who habitually block on preference become bottlenecks that the team routes around.
+
+**The fix:**
+
+Establish a written team style guide and agree that anything not in the guide is author's choice. Distinguish between "blocking" (must fix before merge) and "non-blocking" (suggestion, take it or leave it) feedback -- many teams use prefixes like `nit:` or `suggestion:`. Adopt Google's standard of code review: if the code is functional, well-tested, and follows team conventions, approve it even if you would have written it differently.
+
+**Detection rule:**
+
+Track review comments that result in "Request Changes" status. If more than 30% of blocking comments are about style preferences (not correctness, security, or convention violations), blocking standards are too subjective. Monitor PR cycle time -- if PRs with changes-requested take more than 3 days to resolve, preference-blocking may be the cause.
+
+---
+
+### AP-07: Gatekeeping Reviews
+
+**Also known as:** Ego Olympics, The Approval Bottleneck, Review Monarchy
+**Frequency:** Common
+**Severity:** Critical
+**Detection difficulty:** Moderate
+
+**What it looks like:**
+
+One senior developer is the sole required reviewer for all PRs. They reject code that does not match their personal architecture vision, demand rewrites of working solutions, and use reviews as a platform to demonstrate technical superiority. PRs sit in their queue for days. Junior developers learn to write code that appeases this person rather than code that solves the problem well. As research on review power dynamics found: "it feels good to leave a blocking review because it feels like they're single-handedly protecting the quality of the codebase, and it's a way to indulge flexing their own technical knowledge."
+
+**Why reviewers do it:**
+
+Gatekeeping provides a sense of control and importance. Organizations that assign ownership of code review to a single person inadvertently create gatekeepers. The power dynamic is self-reinforcing: because juniors defer to the gatekeeper, the gatekeeper's belief that they are indispensable is confirmed. People with less structural power hesitate to push back against those with more power, even when they are technically correct, and the code review becomes performative.
+
+**What goes wrong:**
+
+The gatekeeper becomes a bottleneck that limits team throughput to their personal review bandwidth. Junior developers stop growing because they optimize for gatekeeper approval rather than engineering quality. Knowledge concentrates in one person, creating a catastrophic bus factor. When the gatekeeper leaves or is unavailable, the team cannot ship. Team members who disagree with the gatekeeper leave the team or the company. The culture becomes one of permission-seeking rather than ownership.
+
+**The fix:**
+
+Require review from any team member, not a specific person. Rotate review assignments using automated tools (GitHub CODEOWNERS with team-level, not individual, ownership). Establish a written escalation process for disagreements so that no single person has unilateral veto power. Make review distribution metrics visible -- if one person is reviewing more than 30% of all PRs, rebalance. Ensure that junior developers also review senior developers' code, normalizing bidirectional feedback.
+
+**Detection rule:**
+
+Analyze review distribution: if one person provides more than 40% of all review approvals, gatekeeping risk is high. Track how often a single reviewer's "Request Changes" blocks a PR for more than 48 hours. Survey the team anonymously: "Do you feel you need a specific person's approval to merge?"
+
+---
+
+### AP-08: Not Reviewing Tests
+
+**Also known as:** Test Blindness, Green-Bar Assumption, "Tests Pass, Ship It"
+**Frequency:** Very Common
+**Severity:** High
+**Detection difficulty:** Hard
+
+**What it looks like:**
+
+The reviewer carefully examines the production code but skips the test files entirely. The tests are treated as validation artifacts -- if CI is green, the tests must be fine. Nobody checks whether the tests actually assert meaningful behavior, whether edge cases are covered, or whether the tests would catch a regression if the production code changed. A test file that asserts `expect(true).toBe(true)` passes CI and passes review.
+
+**Why reviewers do it:**
+
+Test code feels secondary to production code. Reviewing tests requires understanding the intent of the production code deeply enough to evaluate whether the tests validate it. Test files are often long and repetitive, making them tedious to review. Reviewers trust the CI pipeline as a proxy for test quality rather than evaluating the tests themselves.
+
+**What goes wrong:**
+
+Tests that do not test anything meaningful create a false safety net. Code coverage metrics look healthy, but the tests are not actually validating behavior. Ding Yuan et al.'s study "Simple Testing Can Prevent Most Critical Failures" (OSDI 2014) found that the majority of catastrophic failures could have been prevented by simple testing -- yet the tests that existed did not cover the failure paths. When a future change introduces a bug, the tests still pass because they never tested the correct behavior in the first place. The team accumulates "test debt" -- a suite that is expensive to maintain but provides little confidence.
+
+**The fix:**
+
+Review test files with the same rigor as production code. Ask: "If I introduced a bug in the production code, would this test catch it?" Check for edge cases, error paths, and boundary conditions. Look for tests that are tautological (asserting the implementation rather than the behavior). Add mutation testing (Stryker, mutmut, pitest) to CI to measure whether tests actually detect changes in production code.
+
+**Detection rule:**
+
+Track the percentage of review comments on test files vs. production files. If fewer than 15% of review comments address test code, test review is being neglected. Run mutation testing quarterly -- if mutation survival rate exceeds 30%, tests are not catching regressions.
+
+---
+
+### AP-09: Only Reviewing Changed Files
+
+**Also known as:** Tunnel Vision Review, Diff-Only Review, No Context Review
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Hard
+
+**What it looks like:**
+
+The reviewer examines only the lines highlighted in the diff without understanding the surrounding code, the module's responsibilities, or how the changed code interacts with the rest of the system. A function signature change looks fine in isolation but breaks three callers outside the diff. A new utility function duplicates one that already exists two directories away. An API contract change is compatible with the changed client but incompatible with two other clients not shown in the diff.
+
+**Why reviewers do it:**
+
+Modern code review tools center the diff as the primary view. Expanding context requires deliberate effort -- clicking to load surrounding lines, navigating to other files, or checking out the branch locally. When review workload is high, reviewers stay within the diff to minimize time per review. The cognitive load of understanding the broader system is significant, especially for reviewers who are not domain experts in the changed module.
+
+**What goes wrong:**
+
+Integration bugs, contract violations, and behavioral regressions that are invisible in the diff reach production. Duplicate code proliferates because reviewers do not know what already exists outside the changed files. Security vulnerabilities in the interaction between components go undetected. The review catches local errors but misses systemic ones -- which are typically more expensive to fix.
+
+**The fix:**
+
+Encourage reviewers to check out the branch locally for non-trivial changes. Use review tools that show impact analysis -- which callers, dependents, or contracts are affected by the change. Include "areas of concern" in the PR description to guide reviewers toward interactions that matter. For architectural changes, require the author to document impacted components.
+
+**Detection rule:**
+
+Track bugs that escape review and categorize them: if more than 25% of post-merge bugs involve interactions between the changed code and unchanged code, reviewers are not examining context. Monitor whether reviewers ever view files outside the diff -- if review tool analytics show zero non-diff file views, tunnel vision is systemic.
+
+---
+
+### AP-10: Toxic Comments
+
+**Also known as:** Harsh Feedback, Code Shaming, The Personal Attack
+**Frequency:** Common
+**Severity:** Critical
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+Review comments include phrases like "This is terrible," "Did you even think about this?", "Why would anyone write it this way?", or passive-aggressive emoji reactions. The feedback attacks the developer rather than the code. Sarcasm substitutes for constructive guidance. A junior developer's first PR receives 23 dismissive comments and no encouragement. Sandya Sankarram's widely-cited talk "Unlearning Toxic Behaviors in a Code Review Culture" documented how these patterns suppress creativity and drive attrition.
+
+**Why reviewers do it:**
+
+Text-based communication strips tone and body language, making blunt feedback feel harsher than intended. Some reviewers use code review as a status display, demonstrating superiority through criticism. Frustration with repeated mistakes or time pressure leads to short, sharp comments. In some engineering cultures, brutal honesty is valorized and "thick skin" is expected -- a norm that disproportionately excludes underrepresented groups. Some developers pass off personal programming opinions as established fact, using code reviews as an opportunity to show off how clever they are.
+
+**What goes wrong:**
+
+Developers dread submitting PRs and delay them to avoid negative feedback. Psychological safety collapses: team members stop taking risks, proposing novel approaches, or asking questions in reviews. Toxic review culture is a leading driver of engineer attrition -- people leave teams, not codebases. Toxic behaviors during code reviews can be more unproductive than no code reviews at all, because these behaviors stifle the qualities developers need the most: creativity and innovativeness. The team loses the diversity of thought that produces better solutions because only those who can tolerate abuse participate.
+
+**The fix:**
+
+Establish a code review code of conduct. Train reviewers to comment on the code, never the person ("This function could handle the null case" vs. "You forgot to handle nulls"). Use the "yes, and" approach: acknowledge what works before suggesting improvements. Require that every "Request Changes" review includes at least one positive observation. When toxic comments are identified, address them immediately with the reviewer in private -- public correction creates its own toxicity.
+
+**Detection rule:**
+
+Periodically review a sample of review comments for tone. Flag comments containing personal pronouns in negative contexts ("you always," "you never," "you should have"). Run anonymous team surveys quarterly asking whether code reviews feel safe and constructive. Track attrition and exit interview data for mentions of review culture.
+
+---
+
+### AP-11: Drive-By Reviews
+
+**Also known as:** Hit-and-Run Comments, Seagull Review, The Dive-Bomb
+**Frequency:** Common
+**Severity:** Moderate
+**Detection difficulty:** Moderate
+
+**What it looks like:**
+
+A reviewer who is not assigned to the PR drops a single comment -- often a nitpick or a vague concern like "Hmm, not sure about this approach" -- and disappears. They do not respond to follow-up questions, do not review the full PR, and do not approve or reject. Their comment creates uncertainty and blocks progress without adding clarity. The author does not know whether to address the concern or ignore it.
+
+**Why reviewers do it:**
+
+Drive-by reviewing feels like participating without the commitment of a full review. Some developers skim PRs in their feed out of curiosity and leave thoughts without intending to engage further. In open-source projects, drive-by comments from non-maintainers are common and expected -- but in team contexts, they create confusion about who is responsible for the review.
+
+**What goes wrong:**
+
+Unresolved drive-by comments create ambiguity: is this a blocking concern or idle musing? Authors waste time addressing vague feedback from someone who may never return to validate the fix. PR cycle time increases as the author waits for the drive-by reviewer to respond. Multiple drive-by comments from different people can create contradictory guidance without a clear path forward. Review responsibility diffuses -- everyone comments, nobody owns the review.
+
+**The fix:**
+
+Distinguish between assigned reviewers (who are responsible for a thorough review and approval decision) and optional reviewers (whose comments are advisory). If you leave a comment on a PR you are not assigned to, explicitly state whether your comment is blocking or informational. Teams can adopt a convention: unassigned reviewers prefix comments with `[non-blocking]` or `[FYI]`.
+
+**Detection rule:**
+
+Track review comments from non-assigned reviewers that receive no follow-up response from the commenter. If more than 30% of non-assigned reviewer comments go unresolved, drive-by reviewing is a pattern. Monitor PRs with comments but no approval or rejection from the commenter.
+
+---
+
+### AP-12: Syntax-Only Review
+
+**Also known as:** Human Linter, Surface Review, Form Over Function
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Moderate
+
+**What it looks like:**
+
+The reviewer checks that the code compiles, follows naming conventions, and uses the right patterns -- but never evaluates whether the logic is correct. They verify that the function has a return statement but not that it returns the right value. They confirm that error handling exists but not that it handles the right errors. The review is structurally thorough but semantically empty. This is distinct from AP-02 (Nitpick Focus) in that the reviewer genuinely believes they have done a complete review -- they just lack the depth to evaluate logic.
+
+**Why reviewers do it:**
+
+Evaluating syntax and structure is pattern matching -- a low-energy cognitive task. Evaluating logic requires building a mental model of the system's behavior, reasoning about state, and considering edge cases -- high-energy tasks that demand domain knowledge. Reviewers without context in the changed module default to what they can evaluate: form rather than function. Some teams assign reviewers without regard for domain expertise, making logic review impossible.
+
+**What goes wrong:**
+
+Logic bugs, off-by-one errors, race conditions, and incorrect business rule implementations pass review. The team's bug escape rate correlates with the complexity of the logic rather than the complexity of the syntax, because syntax gets caught and logic does not. Over time, the review process optimizes for form -- producing consistently formatted, consistently incorrect code. Microsoft's research found that the primary value of code review is knowledge transfer and shared understanding, not syntax checking -- when reviews stay at the syntax level, this value is lost entirely.
+
+**The fix:**
+
+Assign reviewers who have domain expertise in the changed module. Require reviewers to articulate what the code does in their own words before approving -- if they cannot explain the logic, they have not reviewed it. Include specific review prompts: "Does this handle the case where X is null?", "What happens if Y times out?", "Is the sort order correct for Z?" Supplement human review with static analysis tools that detect logic issues (null dereference, unchecked returns, race conditions).
+
+**Detection rule:**
+
+Categorize escaped bugs by type. If more than 50% of post-merge bugs are logic errors (incorrect conditions, wrong calculations, missing cases) rather than structural errors (missing imports, type mismatches), reviews are syntax-focused. Track whether reviewers ask questions about behavior vs. questions about style.
+
+---
+
+### AP-13: No Automation for Style and Lint
+
+**Also known as:** Manual Style Enforcement, The Human Linter Pipeline, Formatters Are Optional
+**Frequency:** Common
+**Severity:** Moderate
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+The team has a style guide but no automated enforcement. Every PR review includes 5-10 comments about formatting, import ordering, trailing whitespace, and naming conventions. These comments consume reviewer time, delay approvals, and frustrate authors who must make mechanical changes. The same style violations recur because there is no automated feedback loop.
+
+**Why reviewers do it:**
+
+Some teams resist automation because they believe human judgment is needed for all aspects of code quality. Others have not invested the setup time for linters and formatters. In polyglot codebases, configuring tools for every language feels like a large upfront cost. Some developers resist auto-formatters because they want control over their code's appearance.
+
+**What goes wrong:**
+
+Reviewer bandwidth that should be spent on logic and design is consumed by style enforcement. Authors receive a mix of substantive and stylistic feedback, making it harder to prioritize. Style comments feel personal and can trigger defensiveness. The team spends cumulative hours per week on work that a tool could do in milliseconds. Without automation, style enforcement is inconsistent -- different reviewers enforce different rules, and the same reviewer enforces different rules on different days.
+
+**The fix:**
+
+Configure linters (ESLint, Pylint, RuboCop) and formatters (Prettier, Black, gofmt) to run in pre-commit hooks and CI. Make the CI check blocking -- PRs with lint failures cannot be merged. Once automated enforcement is in place, add a team agreement: "Do not comment on anything a linter can catch." This frees reviewer attention for higher-value feedback.
+
+**Detection rule:**
+
+Count the number of review comments per PR that are about formatting or style. If this exceeds 3 per PR on average, automation is missing. Check CI configuration for linter and formatter steps -- if absent, this anti-pattern is guaranteed to be present.
+
+---
+
+### AP-14: Review Ping-Pong
+
+**Also known as:** Endless Iterations, The Infinite Rally, Death by a Thousand Rounds
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+A PR goes through 7 rounds of review. Each round, the reviewer finds new issues they could have mentioned in the first round. The author fixes round 1's comments, only to receive round 2's comments on different lines. The reviewer then spots a third set of issues introduced by the round 2 fixes. Simon Tatham described this as the "death by a thousand cuts" anti-pattern -- a reviewer who stops reading at the first nitpick rather than providing complete feedback in one pass.
+
+**Why reviewers do it:**
+
+Reviewers who find an issue early in the diff stop reading and submit feedback immediately, planning to continue "after the fix." Each round of changes introduces new context the reviewer feels compelled to examine. Some reviewers avoid giving too much feedback at once, fearing it will overwhelm the author -- an admirable intent that backfires by extending the cycle. If the team has not agreed on what "ready for review" means, a PR may be opened half-baked, forcing reviewers to question architecture decisions, test coverage, and formatting all at once -- prime conditions for multiple rounds.
+
+**What goes wrong:**
+
+PR cycle time balloons from hours to days or weeks. Author morale drops as they feel they can never satisfy the reviewer. The PR's diff accumulates fix-on-fix changes that obscure the original intent. Other team members waiting on the PR are blocked. Major changes in the middle of code review basically reset the entire review process. In extreme cases, the author abandons the PR and rewrites it from scratch, wasting all review effort.
+
+**The fix:**
+
+Reviewers should do a complete pass before leaving any comments. Batch all feedback into a single round. If an issue is minor, mark it `nit` and approve anyway -- do not block on nitpicks. Limit review rounds to a maximum of 3; if the PR is not ready after 3 rounds, schedule a synchronous discussion (call or pairing session) to resolve remaining issues. Establish clear expectations for what "ready for review" means so that PRs are not opened prematurely.
+
+**Detection rule:**
+
+Track the number of review rounds per PR. If the median exceeds 2 rounds or more than 15% of PRs take 4+ rounds, ping-pong is occurring. Measure the time between first review comment and final approval -- if this regularly exceeds 3 business days for PRs under 300 lines, the review process is cycling excessively.
+
+---
+
+### AP-15: Ignoring Security Implications
+
+**Also known as:** Security Blindness, "That's AppSec's Problem", Threat-Unaware Review
+**Frequency:** Common
+**Severity:** Critical
+**Detection difficulty:** Hard
+
+**What it looks like:**
+
+A PR adds a new API endpoint that accepts user input and writes it to a database. The review focuses on code structure, test coverage, and error messages -- but nobody asks about input validation, SQL injection, authentication, authorization, or rate limiting. A PR modifies a Terraform configuration to open a security group, and the reviewer checks only that the syntax is valid. OWASP's Secure Code Review Guide emphasizes that security review requires deliberate focus on trust boundaries, data flow, and authentication -- none of which appear in a typical review checklist.
+
+**Why reviewers do it:**
+
+Most developers are not trained in security. Security concerns are invisible unless you are specifically looking for them. Teams assume that security is handled by a dedicated AppSec team, SAST tools, or penetration testing -- review is "just" for functionality. Security review requires understanding threat models and attack vectors, which is specialized knowledge that general-purpose reviewers lack.
+
+**What goes wrong:**
+
+Injection vulnerabilities, broken access control, exposed secrets, and insecure configurations pass through review. These are the OWASP Top 10 categories that dominate real-world breaches. The 2017 Equifax breach exploited an unpatched Apache Struts vulnerability that had a fix available for months -- the kind of dependency issue that a security-aware review process would have flagged. Automated security tools can identify coding errors, but experienced human reviewers are still capable of identifying issues that tools miss, particularly in business logic and authorization flows. The review process provides a false sense of security: "It was code-reviewed" does not mean "It was security-reviewed."
+
+**The fix:**
+
+Add a security checklist to the PR template for changes that touch authentication, authorization, data input, configuration, or infrastructure. Require at least one reviewer with security training for PRs in sensitive areas. Integrate SAST tools (Semgrep, CodeQL, Snyk Code) into CI to catch common vulnerabilities automatically. Conduct periodic threat modeling sessions so that all developers develop security intuition. Treat infrastructure-as-code (Terraform, Kubernetes manifests) as security-sensitive by default.
+
+**Detection rule:**
+
+Audit PRs that touch authentication, authorization, or user input handling. If fewer than 20% of these PRs have review comments addressing security concerns, security review is absent. Track whether SAST tools are integrated into CI -- if not, automated security coverage is zero.
+
+---
+
+### AP-16: Not Reviewing Config and Infrastructure
+
+**Also known as:** Config Blindness, "It's Just YAML", YAML Yolo
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Moderate
+
+**What it looks like:**
+
+A PR includes changes to `docker-compose.yml`, Kubernetes manifests, Terraform files, CI/CD pipeline definitions, or environment configuration. The reviewer examines the application code changes in the PR but skips the infrastructure files entirely -- they are treated as boilerplate that "just works." An open S3 bucket, an overly permissive IAM role, or a missing resource limit passes through unreviewed.
+
+**Why reviewers do it:**
+
+Many application developers lack infrastructure expertise and feel unqualified to review config files. Infrastructure code looks like declarative boilerplate rather than logic, making it seem less important. Review tools often collapse YAML and JSON diffs, making them harder to read. The team may not have established standards for infrastructure code review.
+
+**What goes wrong:**
+
+Misconfigured infrastructure is a leading cause of cloud security incidents. Exposed storage buckets, overpermissive network rules, and missing encryption settings have caused major data breaches. Half of Kubernetes deployments have been characterized as technical debt due to configurations that were copied without understanding, leading to security misconfigurations and resource waste. Resource limits omitted from Kubernetes manifests lead to noisy-neighbor problems and cost overruns. CI/CD pipeline changes that remove security scanning steps weaken the entire quality process. These issues are often invisible until an incident occurs because infrastructure misconfigurations rarely produce immediate errors.
+
+**The fix:**
+
+Treat infrastructure code as first-class code. Assign reviewers with infrastructure expertise to PRs that modify config files. Integrate infrastructure linting tools (tflint, checkov, kube-linter, hadolint) into CI. Establish infrastructure review checklists covering: access controls, encryption, resource limits, network exposure, and secret management. Require that any CI/CD pipeline change is reviewed by at least two people.
+
+**Detection rule:**
+
+Track review comments on infrastructure files vs. application files. If infrastructure files receive zero review comments in more than 50% of PRs that include them, config blindness is present. Run infrastructure scanning tools and compare findings against review comments -- if tools catch issues that reviewers did not mention, human review of infrastructure is insufficient.
+
+---
+
+### AP-17: Seniority Auto-Approval
+
+**Also known as:** Trust-the-Title, The Untouchable's Code, Hierarchy-Driven Review
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Hard
+
+**What it looks like:**
+
+When a staff engineer or tech lead submits a PR, it receives instant approval with minimal scrutiny. Junior reviewers assume the code is correct because of the author's seniority and feel uncomfortable pushing back. The same code from a junior developer would receive 15 comments; from the senior, it receives "LGTM" in under a minute. Authority bias -- the documented tendency to attribute greater accuracy to authority figures -- drives this pattern even when reviewers notice potential issues.
+
+**Why reviewers do it:**
+
+Questioning a senior engineer's code feels socially risky. Junior developers fear being wrong and looking foolish. There is a genuine statistical likelihood that senior engineers produce fewer bugs, which makes deference seem rational. Seniors may have earned trust through a track record of quality -- but trust should adjust review depth, not eliminate review. Some organizations create explicit review exemptions for senior staff, institutionalizing the anti-pattern. Psychology research confirms that people with less structural power hesitate to push back against those with more power, even when they are technically correct.
+
+**What goes wrong:**
+
+Senior engineers are not immune to bugs, oversights, or blind spots. They may be less familiar with recent changes to the codebase, less current on new security vulnerabilities, or simply tired. Code that bypasses review creates knowledge silos -- nobody else understands the senior's changes. The culture of deference prevents junior developers from developing review skills. When the senior makes a mistake (and they will), nobody catches it. Google's engineering practices explicitly state that even the most experienced developers should have their code reviewed.
+
+**The fix:**
+
+Make review requirements uniform regardless of author seniority. Actively encourage junior developers to review senior developers' code and publicly praise them when they catch issues. Frame review as knowledge sharing, not error detection -- "I want to understand this so I can maintain it" is a valid and non-threatening review stance. Senior developers should model humility by thanking reviewers for catching their mistakes.
+
+**Detection rule:**
+
+Compare review metrics by author seniority: approval time, number of review comments, and number of review rounds. If senior engineers' PRs are approved significantly faster with fewer comments than junior engineers' PRs of comparable size, seniority bias is present. Track whether junior developers ever leave "Request Changes" on senior developers' PRs -- if the rate is near zero, deference is suppressing legitimate feedback.
+
+---
+
+### AP-18: Not Reviewing Error Handling Paths
+
+**Also known as:** Happy Path Only, Exception Blindness, "What Could Go Wrong?"
+**Frequency:** Very Common
+**Severity:** High
+**Detection difficulty:** Hard
+
+**What it looks like:**
+
+The reviewer traces the main execution path and confirms it works correctly. They do not ask: "What happens if this API call fails?", "What if this file does not exist?", "What if the user provides an empty string?", "What if the database connection is lost mid-transaction?" Error handling code -- catch blocks, error responses, fallback logic, retry mechanisms -- receives no scrutiny. The happy path ships reviewed; the sad path ships unreviewed.
+
+**Why reviewers do it:**
+
+The happy path is the narrative of the code -- it tells the story of what the code is supposed to do, which is naturally what reviewers follow. Error paths are branches off the main narrative that require imagining failure scenarios. This requires pessimistic thinking that is cognitively expensive and emotionally unappealing. Error handling code is often boilerplate-looking (catch-log-rethrow), making it seem unimportant.
+
+**What goes wrong:**
+
+Error handling is where production incidents live. Ding Yuan et al. found that 92% of catastrophic failures in distributed systems were caused by incorrect error handling -- and that simple testing of error handlers would have prevented them. Missing error handling causes silent data corruption, unrecoverable state, cascading failures, and poor user experience. A swallowed exception that logs nothing means a production issue will be invisible until a user reports it. An error handler that retries infinitely without backoff will turn a transient failure into a denial-of-service. Incomplete transaction rollbacks leave databases in inconsistent states.
+
+**The fix:**
+
+Add explicit error-handling questions to the review checklist: "What happens on timeout?", "What happens on invalid input?", "Are errors logged with sufficient context?", "Are transactions rolled back on failure?", "Are retries bounded with backoff?" Require that test files include error-path tests -- if the tests only cover the happy path, the review should flag it. Use chaos engineering principles to think adversarially during review.
+
+**Detection rule:**
+
+Examine test files in PRs. If fewer than 20% of test cases cover error scenarios (timeout, invalid input, connection failure, permission denied), error path testing is neglected. Review catch/except blocks: if more than 50% contain only a log statement with no recovery logic, error handling is superficial.
+
+---
+
+### AP-19: No Solution Suggestions
+
+**Also known as:** Criticism Without Contribution, The Problem Pointer, Tear-Down Review
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+Every review comment identifies a problem but offers no direction: "This won't scale," "This is wrong," "There's a better way to do this." The reviewer acts as a fault-finder rather than a collaborator. The author is left to guess at what the reviewer would accept. Multiple iterations follow as the author proposes solutions that the reviewer rejects -- again without suggesting alternatives. ACM research on effective teaching through code reviews found that explanatory rationale and sample solutions backed by standards significantly improved learning outcomes, while harsh comments and nonpragmatic reviewing that ignores authors' constraints hindered learning.
+
+**Why reviewers do it:**
+
+Identifying problems is easier than solving them. Some reviewers believe their job is to point out issues, and the author's job is to fix them. Offering solutions requires more effort and makes the reviewer vulnerable to having their suggestion criticized. Time pressure leads to terse comments. Some reviewers have an intuition that something is wrong but cannot articulate what the correct approach should be.
+
+**What goes wrong:**
+
+Authors feel attacked rather than supported. Without a suggested direction, they may "fix" the issue in a way that introduces a different problem, triggering another review round (see AP-14). The review becomes adversarial: reviewer as judge, author as defendant. Junior developers, who need guidance the most, receive the least actionable feedback. The team's collective problem-solving ability is wasted because reviewers contribute only half the value -- the diagnosis without the treatment.
+
+**The fix:**
+
+Adopt the "if you flag it, suggest a fix" convention. Review comments should follow the pattern: "I see [problem] because [reason]. Consider [alternative] -- here is an example: [code snippet]." If you cannot suggest a solution, frame the comment as a question: "I'm not sure this handles X -- could you walk me through the expected behavior?" For complex issues where a comment is insufficient, offer to pair with the author to work through the solution.
+
+**Detection rule:**
+
+Sample 50 review comments and categorize them as (a) problem only, (b) problem + suggestion, or (c) question. If category (a) exceeds 50%, the team has a solution-suggestion deficit. Track whether "Request Changes" reviews include at least one concrete suggestion -- if they do not, reviewers are blocking without contributing.
+
+---
+
+### AP-20: Review Delayed Weeks
+
+**Also known as:** The Forgotten PR, PR Graveyard, Queue Rot
+**Frequency:** Common
+**Severity:** High
+**Detection difficulty:** Easy
+
+**What it looks like:**
+
+A PR is submitted on Monday. By Friday, no reviewer has looked at it. The author pings the reviewer. The reviewer says "I'll get to it." The following Wednesday, the review arrives -- but the codebase has moved on, the PR has merge conflicts, and the author has context-switched to a different task. Resolving conflicts and re-engaging with the PR takes another day. A change that should have taken 2 days from code to merge takes 12. Google's research shows that their median review turnaround is about 4 hours -- and they consider this essential to developer productivity and 97% satisfaction with their review process.
+
+**Why reviewers do it:**
+
+Review is often not recognized as productive work. Teams that measure output by commits or story points implicitly devalue review time. Reviewers prioritize their own coding tasks and treat reviews as interruptible, low-priority work. Without SLAs or visibility into review queue depth, there is no accountability for delays. Some reviewers batch reviews to a single time slot per day or per week, which is efficient for the reviewer but costly for the author.
+
+**What goes wrong:**
+
+Context switching costs compound: the author forgets the details of their own PR and must re-engage. Merge conflicts increase with delay, sometimes requiring significant rework. The author's next task may depend on the PR being merged, creating a cascade of delays. Frustrated authors bypass the review process (see AP-03), merge without approval, or stop submitting small, frequent PRs in favor of large batches (see AP-04) to amortize the review wait time. Prolonged review cycles are one of the top drivers of developer dissatisfaction with the review process.
+
+**The fix:**
+
+Set a team SLA for initial review response: 4 hours for small PRs (under 200 lines), 24 hours for larger PRs. Make review queue depth visible on a team dashboard. Assign backup reviewers who take over if the primary does not respond within the SLA. Include review turnaround time in team health metrics alongside cycle time and deploy frequency. Schedule dedicated review time -- 30 minutes at the start of each day -- rather than treating reviews as interrupt-driven.
+
+**Detection rule:**
+
+Track time-to-first-review-comment for all PRs. If the median exceeds 24 hours or the 90th percentile exceeds 3 business days, review delays are systemic. Count PRs that are open for more than 5 business days without any review activity -- these are "forgotten PRs" and should trigger alerts.
+
+---
+
+## Root Cause Analysis
+
+| Root Cause | Anti-Patterns It Drives | Systemic Fix |
+|---|---|---|
+| Review treated as gate, not practice | AP-01, AP-03, AP-12, AP-17 | Reframe review as collaborative learning; track quality metrics, not just approval speed |
+| No automated style enforcement | AP-02, AP-06, AP-13, AP-14 | Linters, formatters, and pre-commit hooks eliminate mechanical feedback |
+| Power dynamics and hierarchy | AP-07, AP-10, AP-17, AP-19 | Psychological safety training, bidirectional review rotation, written escalation process |
+| Missing security and infra expertise | AP-15, AP-16, AP-18 | Security checklists, SAST in CI, cross-training, infrastructure linting tools |
+| No review SLAs or accountability | AP-01, AP-03, AP-11, AP-20 | Time-to-review dashboards, SLAs, backup reviewer rotation |
+| Large changeset culture | AP-04, AP-05, AP-09, AP-14 | PR size limits, feature flags, stacked PRs, mandatory descriptions |
+| Review effort is invisible | AP-01, AP-08, AP-12, AP-20 | Track review depth metrics, recognize review contributions in performance evaluations |
+| Feedback quality not measured | AP-02, AP-10, AP-11, AP-19 | Periodic comment audits, feedback training, review code of conduct |
+| Cognitive shortcuts under load | AP-08, AP-09, AP-12, AP-18 | Reduce review load through smaller PRs; assign domain-expert reviewers |
+| Cultural normalization of shortcuts | AP-01, AP-03, AP-17 | Leadership modeling thorough review; celebrate caught bugs, not fast approvals |
+| Missing design review phase | AP-03, AP-04, AP-14 | Lightweight RFC/design doc before implementation; draft PRs for early feedback |
+| No PR standards enforced | AP-04, AP-05, AP-08 | PR templates; size limits in CI; test-coverage gates |
+| Knowledge silos | AP-07, AP-09, AP-17 | Rotate reviewers; pair reviews; architecture documentation |
+
+## Self-Check Questions
+
+Use these during retrospectives, review process audits, or team health checks:
+
+1. When was the last time you left a substantive comment on a PR you approved? If you cannot remember, you may be rubber stamping.
+2. Of your last ten review comments, how many addressed logic, security, or design versus formatting and naming? If the ratio is below 50/50, you are likely over-indexing on style.
+3. What is our median time from PR submission to first review comment? Is it under 24 hours?
+4. What is the average size of PRs on your team? If it exceeds 400 lines, you are likely not decomposing work enough -- and reviews are suffering for it.
+5. Open your last five PRs. Do they each have a description that explains *why* the change was made? Could a new team member understand the context from the description alone?
+6. Have you ever blocked a PR solely for a style preference that is not in the team's style guide? If yes, consider whether a style guide update is more appropriate than blocking a PR.
+7. Is there one person on the team whose vacation would halt all merges? If so, you have a single point of failure in your review process.
+8. In your last review, did you read the test files line by line, or did you just verify that tests existed and CI was green?
+9. Can you name the OWASP Top 10 categories? If you reviewed a PR with a SQL injection vulnerability, would you recognize it in code?
+10. For the last PR you reviewed that included an API call or database query, did you verify what happens when that call fails? Did you check for timeout handling?
+11. When you review a PR that includes a Dockerfile, Terraform file, or CI pipeline change, do you review those files with the same rigor as application code?
+12. Read your last five review comments. For each one that identified a problem, did you suggest a solution or an alternative approach?
+13. Do you read the entire PR before leaving your first comment, or do you comment as you go and potentially miss issues that would change your earlier feedback?
+14. When was the last time you pushed back on a senior developer's PR? If the answer is "never," consider whether authority bias is influencing your reviews.
+15. When you leave comments on a PR, do you always return to verify the fixes and conclude your review, or do you sometimes leave PRs in an unresolved state?
+
+## Code Smell Quick Reference
+
+| Smell | Typical Indicator | Related Anti-Pattern | Automated Detection |
+|---|---|---|---|
+| Instant approvals | Approval in < 2 min for 100+ line PRs | AP-01: Rubber Stamping | PR platform analytics (time-to-approve) |
+| Style-dominated feedback | > 60% of comments on formatting | AP-02: Nitpick Focus | Comment categorization audit |
+| Unreviewed merges | PRs merged before or without approval | AP-03: Too-Late Review | Branch protection audit, merge log analysis |
+| Giant diffs | PRs with > 500 lines changed | AP-04: Huge PRs | PR size tracking in CI (Danger, PR Size Labeler) |
+| Empty descriptions | PR description < 50 chars or blank | AP-05: No PR Description | CI check on description length |
+| Preference blocking | "Request Changes" on stylistic grounds | AP-06: Blocking on Style | Review comment vs. status correlation analysis |
+| Reviewer concentration | One person reviews > 40% of PRs | AP-07: Gatekeeping Reviews | Git platform reviewer distribution report |
+| Test file neglect | Zero review comments on test files | AP-08: Not Reviewing Tests | Comment location analysis (test vs. production files) |
+| Diff-only viewing | Reviewers never expand context or check out branch | AP-09: Only Reviewing Changed Files | Review tool analytics (context expansion rate) |
+| Hostile language | Personal attacks, sarcasm, shame in comments | AP-10: Toxic Comments | NLP sentiment analysis on review comments |
+| Orphaned comments | Comments from non-assigned reviewers with no follow-up | AP-11: Drive-By Reviews | Comment author vs. assigned reviewer comparison |
+| No logic questions | Zero "what happens if" or "why" questions in review | AP-12: Syntax-Only Review | Comment content pattern analysis |
+| No lint in CI | Style comments that a linter would catch | AP-13: No Automation | CI configuration audit for linter steps |
+| High round count | > 3 review rounds per PR | AP-14: Review Ping-Pong | PR review round counter |
+| No security comments | PRs touching auth/input with zero security discussion | AP-15: Ignoring Security | Comment topic analysis on security-tagged PRs |
+| Skipped config files | Zero comments on YAML/Terraform/Dockerfile changes | AP-16: Not Reviewing Config | Comment location vs. file type analysis |
+| Seniority speed gap | Senior PRs approved 5x faster than junior PRs | AP-17: Seniority Auto-Approval | Approval time segmented by author level |
+| Happy-path-only tests | < 20% of test cases cover error scenarios | AP-18: Not Reviewing Error Handling | Test case categorization audit |
+| Criticism without direction | > 50% of comments identify problems without suggestions | AP-19: No Solution Suggestions | Comment structure analysis |
+| Stale PR queue | PRs open > 5 days without review activity | AP-20: Review Delayed Weeks | PR age dashboard, SLA violation alerts |
+
+---
+
+*Researched: 2026-03-08 | Sources: [Modern Code Review: A Case Study at Google (ICSE 2018)](https://sback.it/publications/icse2018seip.pdf), [Expectations, Outcomes, and Challenges of Modern Code Review (Microsoft Research)](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ICSE202013-codereview.pdf), [Google Engineering Practices: The Standard of Code Review](https://google.github.io/eng-practices/review/reviewer/standard.html), [Code Reviews at Google (Dr. Michaela Greiler)](https://www.michaelagreiler.com/code-reviews-at-google/), [30 Proven Code Review Best Practices from Microsoft (Dr. Michaela Greiler)](https://www.michaelagreiler.com/code-review-best-practices/), [Unlearning Toxic Behaviors in a Code Review Culture (Sandya Sankarram)](https://medium.com/@sandya.sankarram/unlearning-toxic-behaviors-in-a-code-review-culture-b7c295452a3c), [Code Review Anti-Patterns (DEV Community)](https://dev.to/adam_b/code-review-anti-patterns-2e6a), [Code Review Antipatterns (Simon Tatham)](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/), [5 Code Review Anti-Patterns (CodeRabbit)](https://www.coderabbit.ai/blog/5-code-review-anti-patterns-you-can-eliminate-with-ai), [Effective Teaching through Code Reviews: Patterns and Anti-Patterns (ACM)](https://dl.acm.org/doi/10.1145/3660764), [Why Code Reviews Shouldn't Be Gatekeeping](https://medium.com/@madhav2002/why-code-reviews-shouldnt-be-gatekeeping-7770384c0f67), [Please Don't Rubber Stamp Code Reviews (Chromium)](https://groups.google.com/a/chromium.org/g/chromium-dev/c/b0Lb_mXfp0Y), [The Rubber Stamp Engineer](https://virtuallyscott.medium.com/the-rubber-stamp-engineer-how-bad-code-review-culture-kills-good-engineers-46a4ae224e9f), [Proof Thousand-Line PRs Create More Bugs](https://tekin.co.uk/2020/05/proof-your-thousand-line-pull-requests-create-more-bugs), [Code-Review Ping-Pong (Level Up Coding)](https://levelup.gitconnected.com/code-review-ping-pong-why-it-happens-and-how-to-end-the-rally-0e13d3af72b1), [OWASP Secure Code Review Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html), [5 Signs of a Toxic Code Review Culture (SubMain)](https://blog.submain.com/toxic-code-review-culture/), [What is Rubber Stamping (Core Security)](https://www.coresecurity.com/blog/what-rubber-stamping-and-why-it-serious-cybersecurity-concern), [30% Less is More: Code Review Strategies (GitClear)](https://www.gitclear.com/research_studies/pull_request_diff_methods_comparison_faster_review), [The Psychology of Code Reviews (Java Code Geeks)](https://www.javacodegeeks.com/2026/01/the-psychology-of-code-reviews-why-smart-developers-accept-bad-suggestions.html), [Every Developer Should Review Code (Zenika)](https://dev.to/zenika/every-developer-should-review-code-not-just-seniors-2abc), [Simple Testing Can Prevent Most Critical Failures (Yuan et al., OSDI 2014)](https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan), [Czerwonka et al., Code Reviews Do Not Find Bugs (Microsoft, 2015)](https://www.microsoft.com/en-us/research/publication/code-reviews-do-not-find-bugs-how-the-current-code-review-best-practice-slows-us-down/), [IEEE SANER 2021, Anti-patterns in Modern Code Review](https://ieeexplore.ieee.org/document/9425999), SmartBear/Cisco Code Review Study, Knight Capital post-mortem*