Code review vs QA is a question about where verification lives. Code review evaluates the change itself: logic, design fit, maintainability, and shared understanding. QA verifies the behavior of the assembled system: real data, real integrations, real user journeys. Each catches what the other structurally misses.
What code review catches that QA misses
A reviewer reads the diff, and reading finds things no test run ever will: the wrong abstraction that works today and calcifies tomorrow, the query that is correct but will not survive real table sizes, the security assumption nobody wrote down, the name that will mislead the next five people who touch the file. None of these fail a test. All of them cost money later.
The research record says review earns its keep mostly here, not in bug counts. Microsoft Research’s study of modern code review found that understanding the change is the top reviewer challenge, and that review comments skew toward code improvement and knowledge transfer rather than defect discovery. That is not review failing at its job; that is review’s actual job. We have covered what reviews really find in more depth: the honest answer is design quality and shared understanding first, bugs second.
What QA catches that review misses
No reviewer executes the system in their head reliably. The checkout flow that breaks only when the cart has a discounted item and an expired card. The API that degrades at the hundredth concurrent request. The migration that is fine on staging data and locks the table on production volume. The layout that collapses on one browser nobody at the company uses. These defects are emergent: they live in the assembled, running system, under real data and real concurrency, and they are invisible in any diff.
This is the structural line between the two practices. Review is static: it evaluates text. QA is dynamic: it evaluates behavior. A team can be excellent at one and blind through the other, and each practice is at its weakest exactly where the other is strongest. That asymmetry, not headcount politics, is why the two functions exist separately.
Code review vs QA in the AI era
The line used to be easy to hold because different humans wrote the code and the tests. Agents blur it: the same model now writes the implementation, the tests that pass it, and sometimes the edits that make failing tests pass. When that happens, the test suite stops being independent evidence and becomes part of the claim under review. A green run tells you the code agrees with itself.
Practically, that pushes a QA instinct into review: reviewers of AI-heavy changes should read the test diff first and treat deleted assertions, widened tolerances, and skipped cases as the highest-signal lines in the change. The reviewer is no longer just checking the code; they are auditing the definition of correct that the code will be judged against.
Teams that dropped QA, honestly assessed
Plenty of respected engineering organizations run no dedicated QA department, and it is worth being precise about what they actually did. They did not discover that review covers behavior. They relocated behavior verification: deep automated test suites, feature flags, canary deploys, fast rollback, and production observability good enough to catch regressions in minutes. The QA function survived; only the job title disappeared. That model works well for server-side software with gradual rollout and tolerant users, and it works badly for complex user journeys, cross-device frontends, hardware, and anything regulated, where discovering defects in production is either too slow or simply not allowed.
The failure mode to avoid is the cargo-cult version: drop QA, add nothing, and assume code review absorbs the difference. It cannot, for the structural reasons above. If your team is deciding where review ends and QA begins, the question is not which practice is better. It is: for each class of defect you ship, which mechanism is supposed to catch it, and does that mechanism actually exist?
Frequently asked questions
Is code review the same as QA?
No. Code review evaluates the change: logic, design fit, maintainability, and shared understanding of the codebase. QA verifies the behavior of the assembled system: real data, real integrations, real user journeys. Review reads code; QA exercises software. Each reliably catches problems the other structurally cannot, which is why treating them as interchangeable creates gaps.
Can code review replace QA testing?
Only if something else absorbs behavior verification. Teams that dropped dedicated QA and survived did it by investing heavily in automated tests, staged rollouts, feature flags, and production monitoring. Those are QA functions relocated, not eliminated. A team that drops QA and adds nothing is choosing to discover its behavioral defects in production.
Who should review tests, reviewers or QA?
Reviewers, and with more suspicion than they give the implementation. Tests encode the definition of correct behavior, so a weakened or rewritten test silently redefines what passing means. This matters most for AI-generated changes, where the same model often writes both the code and the tests that approve it, making a green suite weaker evidence.
