Code review and quality standards

Code review is one of the highest-leverage quality and culture mechanisms a team has: done well it catches defects, spreads knowledge and raises the shared standard; done badly it becomes a bottleneck, a battleground or a rubber stamp. Quality is broader than review — it is the whole system of tests, continuous integration, guardrails and standards that makes the right thing the easy thing — and the manager's job at every scope is to invest in that system, not to inspect every change. v3.0 adds the question v1.0 could not have asked: what review must establish when the author did not write every line. AI assistance has made the volume of code larger and the author's understanding of it less certain, and a review practice built for human-written changes will pass generated code it should not. It matters because the quality bar is the thing a team does not trade under deadline pressure — scope is — and because a standard that exists on paper while pull requests are waved through is the most common form of quality failure. The examinations test it through the deadline that tempts skipping tests, the review that has become cursory as assistants made changes larger, the breaking API left as the consumers' problem, and the niche stack nobody else can maintain.

1. Trade scope, never the tests. Under deadline pressure the quality bar holds and the scope moves. The tests are how the team knows the smaller thing works.
2. Review is timely, kind, specific and proportionate. Slow review blocks whole teams; unkind review teaches people to hide; attention goes to design, clarity and intent, not to trivia waved past risky logic.
3. Automate the objective, so people judge the subjective. Formatting, linting and tests belong to the pipeline. Human review is for what only humans can judge.
4. Coverage is not quality. Tests that catch what matters are quality; more tests of the wrong kind add drag, not confidence.
5. Review establishes understanding, not just correctness, when code is generated. Whoever submits a change owns it and can explain it; generated code is verified, tested and disclosed, and its security and licensing are checked as a class, not assumed.
6. Standards are a floor at the boundaries, not a uniform ceiling. Interface contracts, quality bars, security baselines, operational readiness — where teams meet. Inside a team, tools and style are the team's, weighed on organisational cost.

Code review is one of the better-studied practices in software engineering, and the unit has research-grade evidence for two of its claims.

Code review as knowledge transfer research

The finding in Alberto Bacchelli and Christian Bird, Expectations, Outcomes, and Challenges of Modern Code Review (2013), from a large study of review at one company, that developers and managers expect review to find defects but that its observed benefits are as much knowledge transfer, team awareness and improved solutions as defect detection — and that understanding the change is the main challenge reviewers face. For managers the consequence is that review is a teaching mechanism to be designed for, and that a review the reviewer does not understand has delivered none of its benefits, which is the reason generated code needs review that establishes understanding.

Security of AI-generated code research

The finding in Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt and Ramesh Karri, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (2022) that a substantial share of code produced by an AI assistant across a set of security-relevant scenarios contained vulnerabilities of known classes. Later tools and models change the proportion; the structural point stands: generated code has a vulnerability profile that must be checked as a class, through scanning and review focused on the known failure modes, rather than assumed safe because it was fluent. The governance consequences are in TJ-5 AI-assisted engineering and TJ-6 Security, privacy, and compliance as engineering responsibilities.

Review for AI-generated code practice

Not a named model but the standard this unit proposes for what review must establish when an assistant produced some or all of a change: that the submitter understands it and can explain it; that it is tested at the level the risk warrants; that its origin is disclosed where it matters; that it has been checked against the vulnerability classes generated code is prone to; and that it does not import code under a licence the organisation cannot accept. The standard is set explicitly, before adoption, and it is proportionate: the check for a documentation change is not the check for a payment path.

Quality as a system practice

Not a named model but the stance this unit treats as the manager's actual job: tests, continuous integration, guardrails, standards and the paved road as a system that makes the right thing the easy thing, invested in rather than inspected. Its provenance is ordinary practice; its failure is the manager who reviews every change and calls it rigour.

Contract at the boundary practice

The practice from DE-4 Managing scope, risk, and dependencies across workstreams, given its team-level form in Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019): interface discipline — versioning, deprecation policy, contract tests, communicated change — as the quality floor where work crosses team boundaries. The consumers' stability is part of the owning team's definition of done, and a widely used interface that keeps breaking its consumers is a quality failure of the owning team, not the consumers' problem.

The review service level

The team agrees how quickly a review is answered — the same day for most changes — and measures it. Review latency is a flow metric; a pull request that waits three days blocks the author and, usually, someone else.

The proportionality rule

Review attention goes where the risk is: design, intent, the paths that touch money, data or security. Formatting and style are automated. A reviewer who leaves fifteen comments on naming and none on the retry logic has reviewed the wrong thing.

The generated-code checklist

Before AI tooling is adopted, the team writes down what review must now establish: the submitter explains the change in their own words; tests exist at the level the risk warrants; provenance is disclosed where the organisation requires it; the change passes the scanners configured for the vulnerability classes generated code is prone to; no unacceptable licence has been imported. The checklist is proportionate to the change's risk and it is enforced in the pipeline where it can be.

Scope before tests

When a deadline is close and someone proposes skipping tests to make it, the manager reframes: what can be cut from the scope so that the smaller thing ships tested? The tests are not the thing that moves.

The standards floor

For a group of teams, a short written floor at the boundaries — interface contracts, the definition of done where work crosses a team boundary, security baselines, operational readiness — and an explicit statement that tools, ceremonies and style inside a team are the team's own. A team wanting a niche language is asked the organisational questions: maintainability, hiring, bus factor, who supports it when the enthusiasts leave.

Service ownership

Every service has a named owner responsible for its operation, its interface stability, its documentation and its future. After any reorganisation the ownership map is checked; an ownerless critical service is the priority, because everything about its health is downstream of somebody being responsible for it.

At team scope the object is the team's review practice and quality bar, and the manager keeps reviews fast, kind and proportionate, automates the objective checks, sets the generated-code standard, and trades scope before tests. At organisational scope the object becomes consistent standards across autonomous teams — a floor at the boundaries, interface discipline for widely used APIs, service ownership without gaps, technology choices weighed on organisational cost — set without prescribing each team's tools. At executive scope the object is the organisation's quality posture and the systems that maintain it: a paved road that earns voluntary adoption, an explicit and bounded innovation budget with evaluation criteria, and the recognition that a pattern of quality failures across the organisation is a leadership failure before it is an engineering one. The pattern is in How Judgment Scales; the governance of AI assistance is TJ-5 AI-assisted engineering.

• Keeps reviews fast, kind, specific and proportionate, and treats review as knowledge-sharing. team
• Automates objective checks so human attention goes to design, clarity and intent. team
• Makes standards explicit and shared, so "good" is not reviewer roulette. team
• Cuts scope rather than tests when a deadline tempts the team. team
• States what review must establish for AI-generated code, and who is accountable for it.
• Notices when assistants have made changes larger and faster than review can handle, and changes the review, not the bar.
• Failure mode — reviews that sit for days. team
• Failure mode — the rubber stamp. team
• Failure mode — bikeshedding trivia past risky logic. team
• Failure mode — "temporarily" skipping tests under pressure. team
• Failure mode — passing generated code the submitter cannot explain.
• Sets a quality floor at the boundaries — interface contracts, definition of done at the seams, security baselines, operational readiness — with autonomy inside. org
• Weighs a team's wish to adopt a niche stack on organisational cost: maintainability, hiring, bus factor, support when the enthusiasts leave. org
• Holds the owner of a widely used API to interface discipline: versioning, deprecation policy, contract tests, communicated change. org
• Ensures no critical service is without a named owner, and treats an orphaned one as the priority. org
• Sets standards for AI-generated code across teams — verification, ownership, disclosure — without prescribing each team's tools. org
• Failure mode — mandating uniformity where autonomy was the value. org
• Failure mode — waving through the niche stack the organisation cannot sustain. org
• Failure mode — letting a breaking API stay "the consumers' problem". org
• Failure mode — reorganisations that orphan services silently. org
• Failure mode — a definition of done nobody enforces at the seams.
• Steers quality and technology choice through a paved road that earns voluntary adoption, with teams free to leave it at their own cost. exec
• Holds an explicit, bounded innovation budget: pilots with criteria, contained blast radius, honest review. exec
• Migrates a fashionable adoption that became a liability with a deliberate plan, not blame, and sets adoption criteria before enthusiasm votes next time. exec
• Recognises a pattern of quality failures across the organisation as a leadership failure before it is an engineering one. exec
• Failure mode — freezing the organisation's stack in the name of consistency. exec
• Failure mode — letting every team be its own chief technology officer. exec
• Failure mode — adopting by hype and abandoning by hangover. exec
• Failure mode — punishing the team that took a risk the organisation never bounded. exec

Speed versus scrutiny. Fast review keeps the team flowing; thorough review catches what matters. Proportionality resolves it: the trivial change gets the fast path, the risky path gets the attention, and automation takes the objective checks off both.

Throughput versus understanding. AI assistance raises the volume of code and lowers the author's certainty about it, and review that keeps pace with the volume stops establishing understanding. The judgment is to hold review to understanding and let throughput be what it is, because code nobody understands is debt at its highest interest.

Consistency versus fit. Standardising tools across teams is convenient for dashboards and costs each team its fit; leaving every choice to teams produces stacks nobody else can maintain. The floor at the boundaries, with organisational cost as the test for the rest, is the line.

Autonomy versus liability. The team that adopts a bleeding-edge technology took a risk the organisation may need; the same team is left with a maintenance and hiring liability when it does not pay off. Bounding the risk in advance — criteria, blast radius, review — is what lets the organisation take it without punishing the people who did.

Kindness versus candour in review. Review that is kind can become review that says nothing; review that is candid can become a battleground. The rule is specific, about the code, never about the author, and it is the same rule as PL-2 Feedback and difficult conversations.

A team's manager notices, three months after the team adopted an AI coding assistant, that pull requests have become larger and more frequent, that review turnaround has dropped to under an hour, and that the number of comments per review has fallen by two-thirds. Delivery looks faster. Then a change to the payment retry logic ships with a subtle bug — a retry loop that could double-charge under a network partition — and the engineer who submitted it, asked in the incident review how the loop works, says that the assistant generated it and it passed the tests.

The two easy responses are to ban the assistant, which throws away a real gain and will be quietly ignored, or to treat the incident as a one-off and remind people to be careful. Neither addresses what actually changed: the review practice was built for changes the author understood, and it is now passing changes the author did not.

The manager changes the review, not the bar. With the team, they write down what review must now establish: the submitter explains the change in their own words in the pull request; changes touching money, data or security carry tests at the level of that risk, and the reviewer checks the tests as carefully as the code; the pipeline runs the scanners configured for the vulnerability classes generated code is prone to; and a reviewer who does not understand a change asks, and does not approve until they do. The manager also looks at the review service level and finds the real signal: turnaround dropped because reviewers stopped reading. They restore proportionality — payment paths get a named second reviewer, documentation changes get the fast path — and measure understanding as well as speed, by sampling a few reviews a week and asking the reviewer to explain the change.

The engineer who shipped the bug is not blamed in the review; the system passed it. They are asked, in a one-on-one, to own the retry logic properly, and they do. The product partner is told that delivery will look slower for a few weeks and why.

What the manager does not do is accept the throughput as the measure of the adoption. Fast delivery of code nobody understands is debt at its highest interest, and the incident was the first payment.

• TJ-5 AI-assisted engineering — the adoption, governance and capability-building that decide what review has to cope with.
• DE-5 Designing how work flows — review as part of how work flows, and aligned autonomy as the standards principle.
• DE-4 Managing scope, risk, and dependencies across workstreams — contract at the boundary and interface discipline between teams.
• TJ-6 Security, privacy, and compliance as engineering responsibilities — the security baseline in the standards floor, and vulnerability classes checked as a class.
• CC-1 Psychological safety and productive conflict — the safety that makes review a place to learn rather than a place to be judged.

1. Why is scope the thing you trade under pressure, never the tests?
   Answer

   Because the tests are how the team knows the smaller thing works. Skipping them to hit a date ships something nobody can vouch for; cutting scope ships something smaller that is known to work.
2. What does the research say review actually delivers, beyond finding defects?
   Answer

   Knowledge transfer, team awareness and improved solutions — and the main challenge reviewers face is understanding the change. A review the reviewer does not understand delivers none of the benefits.
3. What must review establish for AI-generated code?
   Answer

   That the submitter understands and can explain it; that it is tested at the level the risk warrants; that its origin is disclosed where required; that it has been checked against the vulnerability classes generated code is prone to; and that no unacceptable licence was imported. Proportionate to the change's risk.
4. What belongs in a cross-team standard, and why does "standardise everything" fail? org
   Answer

   A floor at the boundaries: interface contracts, quality bars where work crosses teams, security baselines, operational readiness. Standardising all tools and languages trades local fit and ownership for a uniformity mostly valuable to dashboards.
5. A team wants to adopt a niche language only they know. What is the key consideration? org
   Answer

   The organisational cost — maintainability, hiring, bus factor, and who supports it when the enthusiasts leave — weighed against the real technical benefit.
6. What does a paved road change about how quality and technology choice scale? exec
   Answer

   Consistency is achieved by making the good path the easy path rather than by mandate: teams adopt the supported default voluntarily and may leave it if they accept the ownership cost themselves. A paved road nobody would choose is a mandate in costume.
7. A team's bleeding-edge adoption has become a maintenance and hiring liability. What is the action, and what is the lesson? exec
   Answer

   A deliberate migration plan, not blame — the organisation never bounded the risk. The lesson is that adoption criteria — fit, support, exit cost — must exist before enthusiasm votes.

• Alberto Bacchelli and Christian Bird, Expectations, Outcomes, and Challenges of Modern Code Review (2013) — what modern code review actually delivers, and why understanding is its central challenge.
• Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt and Ramesh Karri, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (2022) — the vulnerability profile of AI-generated code.
• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019) — interface discipline and contracts between teams.