Bug: Code review workflow forces minimum 3 issues, causes endless review cycles and developer fatigue

[blade035]

Describe the bug
The BMAD code review workflow (_bmad/bmm/workflows/4-implementation/code-review/instructions.xml) enforces a minimum of 3 issues per review, which forces reviewers to find nitpicks even when code is genuinely good. The workflow explicitly states "Find 3-10 specific issues in every review minimum - no lazy 'looks good' reviews" and validates that total_issues_found is not less than 3, forcing additional issue finding if fewer than 3 are discovered.

This contradicts agile values by preventing reviewers from approving good code, leading to endless review-code-review cycles and artificial nitpicking to meet the quota.

Steps to Reproduce

1. Run code review workflow (*code-review or /bmad:bmm:workflows:code-review) on a story with high-quality implementation
2. Reviewer finds 0-2 legitimate issues (or none)
3. Workflow triggers validation:
4. Reviewer is forced to find additional issues to proceed, even if code is production-ready
5. Results in artificial nitpicking and multiple review cycles

Reliably reproducible on any story where the code quality is high and genuinely has fewer than 3 issues.

Expected behavior
The adversarial code review should:

• Find 0-10 issues based on code quality (not a minimum quota)
• Allow "looks good" outcome when code genuinely has no issues
• Only enforce thorough review when there are red flags (complex story, known risks, etc.)
• Celebrate high-quality code rather than forcing artificial criticism

Please be Specific if relevant
Model(s) Used: Claude (multiple versions tested)
Agentic IDE Used: VS Code with Claude Code / CLI
Project Language: TypeScript (but bug is workflow-agnostic)
BMad Method version: v6.x (current as of 2026-01)

Screenshots or Links

Problematic code in _bmad/bmm/workflows/4-implementation/code-review/instructions.xml:
Find 3-10 specific issues in every review minimum - no lazy "looks good" reviews

NOT LOOKING HARD ENOUGH - Find more problems! Find at least 3 more specific, actionable issues

Suggested fix:
Find 0-10 specific issues in every review - celebrate good code when you find it

No issues found - Code is ready for production! Great work! 🎉 Mark story as "done" and proceed

Additional context
The adversarial review pattern is excellent for catching real bugs, but the forced minimum undermines trust in the process.

Real-world impact: Just completed a story with 400+ lines, comprehensive test coverage, and all acceptance criteria met. The code was genuinely good, but the workflow forced multiple review cycles to find 3+ issues. This is review fatigue, not quality assurance.

This is a process bug, not a code bug. The workflow works as designed, but the design itself creates a perverse incentive: rejecting good code to meet an artificial quota.

Related principle: Goodhart's Law - "When a measure becomes a target, it ceases to be a good measure." The "issue count" measure was meant to encourage thorough reviews, but making it a minimum target incentivizes artificial nitpicking.

Labels to add: bug, workflow, code-review, priority: medium

[miclivne]

I am using version 6.23 and copied back the older version of code review because the new version caused endless cycles of code review and always changes the status.

[bmadcode]

Agree - if this is still in place, will be improving this soon. Investigating.

[alexeyv]

There are three separate stories here.

• "find at least N findings" is by design, forces LLM to continue reasoning in depth. Having done this close to a thousand times by now, I am convinced that the right value of N is between five and ten. DEFINITELY not zero.
• showing them all to a human is a workaround for an LLM limitation. They're much better at finding things to complain about than at judging which ones are worth complaining about. Trusting an LLM to filter the findings on its own is a bad idea.
• better process for dealing with findings, including something about the endless review loop (which is a problem until you learn when to stop). That's a worthy endeavor.