A pull request can look finished and still be unreviewable. That gap has widened now that AI can produce fluent diffs at speed.
Complete-looking changes are not the same as understood changes. When generated code arrives formatted, commented and accompanied by a confident summary, the temptation is to skim and merge. The cost of that habit does not show up in the pull-request counter. It shows up later as rework, fragile systems and incidents nobody can explain.
This is the operational sequel to Practical AI in engineering — judgment over volume: if judgment should matter more than volume, a change is ready only when its author can explain the intent, evidence and risk — and a reviewer can independently judge them. The review bar is where that standard becomes real, or quietly disappears.
What “done” used to signal
Before assistants could draft large parts of a change, a tidy pull request was never proof of understanding. But producing a substantial diff usually imposed more friction on its author. That friction often left fingerprints: awkward edge cases, comments that admitted uncertainty, and tests that revealed what the author feared.
Those fingerprints mattered in review. They gave the reader places to ask questions. They also gave the author a story they could tell about intent, trade-offs and verification.
AI compresses that signal. A diff can now look intentional without the author having built the mental model that makes the change safe. The reviewer’s job is no longer only “find bugs in the patch”. It is also “decide whether anyone here actually understands what is about to ship”.
Why rubber-stamping got cheaper — and more expensive
Rubber-stamping always existed. AI makes it feel rational. The patch is large, the description is polished, the CI is green, and the queue is long. Approving becomes the path of least social friction.
That convenience is expensive. Escaped defects cost more than a careful review. So does the cultural signal: if leaders praise speed of merge more than quality of explanation, teams learn to optimise for appearance. Reviewers stop practising the craft of reading systems. Authors stop practising the craft of defending decisions.
There is a quieter cost too. When nobody can explain a change, on-call becomes archaeology. Knowledge concentrates in tools and transcripts instead of in the team. That is the opposite of staying close to the craft.
Accountability questions for authors
Before requesting review, an author should be able to answer without reading the model’s summary back to the room:
- What problem does this change solve, in one or two sentences of my own words?
- What did I deliberately not change, and why?
- Where did AI assistance materially shape architecture, security, data handling or code outside my confidence — and what extra verification did those areas receive?
- How did I verify behaviour — tests, manual checks, data checks, accessibility or performance where relevant?
- What would break if my assumptions about the surrounding system are wrong?
- What should a reviewer spend their scarce attention on?
If those answers are vague, the pull request is not ready. Asking for review is asking colleagues to spend trust. Arrive with enough context that their time can improve the change rather than reconstruct it.
Accountability questions for reviewers
Reviewers need a different checklist when fluency is cheap:
- Can the author explain the change without pasting the assistant’s wording?
- Is the change small enough to review properly, or should it be split?
- Do the tests exercise the risk, or only the happy path the prompt happened to mention?
- Are new dependencies, permissions, network calls or data flows explicit and justified?
- Would I be willing to debug this in production with the author unavailable?
- Am I approving because I understand it — or because it looks complete and I am tired?
Review should end in one of three honest states: approve because the risk is understood; request changes because specific evidence is missing; or pause and pair when the author or reviewer lacks the context to judge safely. “Looks finished” is not a fourth state.
That last reviewer question is the honesty test. Tired approval is still an architectural decision. Own it, or withhold it.
How leaders set the bar
Individuals can keep personal standards. Leadership decides whether those standards survive delivery pressure.
Make expectations explicit. Assistants may accelerate exploration and drafting. They do not reduce the need for readable intent, verified behaviour and accountable authorship. Say that in onboarding, in guild notes and in the moments after a near-miss — not only in a policy nobody opens.
Praise the right behaviour. Celebrate the engineer who shrinks a generated patch into something reviewable. Celebrate the reviewer who asks a sharp question and blocks a merge that would have shipped confusion. If the only public recognition is for “closed tickets fast”, the review bar will fall to match.
Protect review time in the system. Unbounded queues, weekend freezes and hero merges teach people that scrutiny is optional. Prefer smaller changes, clearer ownership and enough capacity that “I did not have time to read it” is not the default excuse.
Measure outcomes, not theatre. Pull-request volume and AI usage dashboards are weak proxies. Watch escaped defects, rework, change-failure rate, time to understand incidents and whether cycle time improves without quality declining. If merges accelerate while understanding collapses, the organisation is winning the wrong race.
Ecommerce and frontend make the bar non-negotiable
Storefront and platform work punish shallow confidence. Catalogue rules, promotions, localisation, accessibility, performance budgets and payment edge cases rarely announce themselves in a generated summary. A “simple” template change can touch revenue paths that only someone with system context will recognise.
For example, a generated product-grid refactor can preserve screenshots and unit tests while changing DOM order, focus behaviour or analytics events. The diff may look tidy; the customer and revenue impact can sit outside the prompt.
That is why review quality is not politeness. It is how teams keep customer journeys coherent when tools make it easy to produce something that looks finished.
A practical review bar
Use a short standard that can be evidenced before merge:
- The author can explain intent, assumptions and blast radius in their own words
- Areas where AI materially shaped risk, novelty or uncertainty are called out so review attention can be targeted
- Verification matches the change: tests, checks and relevant accessibility or performance validation
- The diff is sized for genuine human review
- At least one reviewer can say what would make them reject the change
- The team remains accountable for what ships — tools do not absorb blame
Keep the bar where the risk is
Keeping the bar high does not mean applying the same ceremony to every diff. Calibrate review depth to blast radius, reversibility, novelty and the sensitivity of the data or customer journey involved. A small copy change should not wait behind the same process as a checkout, identity or pricing change.
The standard remains constant: enough evidence for the risk being taken. Low-risk work should move quickly; high-risk work should earn deeper verification, clearer rollback thinking and reviewers with the right system context.
AI did not invent weak review. It made weak review look efficient. The response is not nostalgia for slower typing. It is a clearer bar: accountability before merge, questions that expose understanding, and leaders who refuse to confuse fluency with readiness.
Use assistants to get to a reviewable artefact faster. Keep humans responsible for deciding what deserves to ship. That is how judgment stays ahead of volume when the diff already looks done.
