If You Stop Writing Code, How Do You Keep Reviewing It?

As AI and automation take on more of the typing, many engineers find themselves shifting from author to reviewer. This post gives practical, sociotechnical guidance for keeping code reviews effective, relevant and satisfying when you’re not the one writing most of the code.

Introduction: a shifting desk

It’s a familiar pattern now: code generators or AI assistants produce a working pull request, tests pass, and the human engineer’s job becomes to review and approve. Some of us find it liberating; others feel a bit "icky" about not looking at the code that will ship (a feeling echoed by engineers discussing their experiences with Claude Code and other assistants). The question then becomes not just how to read someone else’s code, but how to keep exercising judgement, stewarding quality and maintaining skills when you’re increasingly a reviewer rather than a primary author.

Start by re-framing the role

Reviewing isn’t a degraded form of engineering — it’s a different social-technical task. Historically, code review delivers several concrete benefits: knowledge transfer, fewer defects, improved security practices and the Hawthorne effect where the expectation of review raises authoring quality. When AI writes code, those same benefits still matter, but the techniques you use to secure them need to change.

Practical ways to keep reviews useful

Adopt explicit acceptance criteria. If you’re uneasy about reading every line, create a checklist or set of criteria the artefact must meet (tests, linting, security checks, clear API contracts, documentation). One engineer reported using predefined criteria when working with code generators, then focusing manual attention on the most critical issues. This turns review into a confident triage rather than hair-splitting.
Lean on automated safety nets. Make CI and linters do the routine work. The community evidence shows that linting and test suites catch many issues, and automation can reduce the need for low-value manual inspection. But automation is an enabler, not a replacement — you still need to evaluate what the tests and linters mean in context.
Focus your human attention where it pays off. Not all pull requests are equal. Spend deep review time on design, architecture, security boundaries and interfaces that affect other teams. Use quick passes for small, well-tested changes. This risk-based strategy prevents burnout and keeps cognitive effort aligned with potential harm.
Request explicit reviews and use ownership files. Tooling features like GitHub’s CODEOWNERS and explicit review requests make the social process reliable. If reviews are optional or ad hoc, they often disappear; make them visible and routinised so reviewers know when their judgement is required.
Turn reviews into teaching moments. Good reviews help the requester be more productive. Offer context-aware feedback that explains trade-offs rather than just stamping “LGTM”. Over time, this helps authors (human or AI-assisted) improve the quality of subsequent requests.
Set timeboxes to avoid analysis paralysis. Reserve time for tricky technical decisions, but decide reasonably fast. Organisations that obsess over a mythical perfect solution slow teams down; better to iterate and fix than never ship. If a decision is blocking work, choose a pragmatic direction after a focused discussion.
Keep a small amount of hands-on coding. Even if most of your day is review, periodically write code to retain muscle memory. This can be a spike, a tight bugfix, or a short demo. The act of coding keeps your sense of what is idiomatic, performant and maintainable — useful context when you review others’ work.

Sociotechnical practices that sustain quality

Code review is as much about people and processes as it is about files and diffs. Here are organisational practices that make the reviewer role sustainable and effective.

Create shared norms for AI-generated code. If your team uses AI to generate code, agree what counts as “review-ready”: who checks tests, how to document prompts and how to record why a change was accepted. Norms reduce friction and the uneasy feeling of not being the author.
Measure review quality, not just speed. Fast approvals are not the same as good ones. Collect signals about defect rates, rework and whether reviewers are catching architectural issues. Where organisations treat reviews as negligible, engineers report poorer outcomes — and some conclude that the only remedy is changing employer or team.
Encourage cross-team knowledge transfer. Use reviews to spread understanding across the codebase and reduce single-person bus factors. This aligns with the classic reasons for peer review: when multiple people look at the same area, the team is more resilient and more able to maintain the system over time.
Empower reviewers to raise concerns. If an organisation ignores technical feedback, reviewers will become disengaged. Constructive escalation paths — from peer review to tech lead to product decision — keep safety valves functional. If those paths are blocked repeatedly, the community wisdom is blunt: consider moving to teams that value engineering craft.

Working with AI as a partner, not a black box

AI can be an efficient coder but it does best when paired with an informed reviewer. Practically that means:

Ask the AI to run its own review against your criteria before you look at the code.
Keep and improve the test suite so you can trust behavioural checks.
Use the review to teach the AI: when you spot a recurring issue, codify it into tests, lint rules or documented prompts.

Personal craft: how to remain a seasoned reviewer

Beyond process, there’s a craft element. Experienced engineers who shifted into a reviewer role report two successful habits: 1) focusing their deep attention on high-leverage areas; and 2) deliberately preserving some small authoring tasks to stay sharp. Pair-programming, mentoring and occasional spike work all keep tacit knowledge alive.

Conclusion: review intentionally

If you’re no longer writing most of the code, you haven’t been made redundant — your role has morphed. The core responsibility becomes stewarding system health, transferring knowledge and shaping how automation is used. The tools and AI are powerful allies, but they aren’t substitutes for sociotechnical judgment. By adopting explicit criteria, automating low-value checks, focusing human attention on risk, and keeping organisational norms aligned with engineering goals, you can keep reviews meaningful and effective — and keep feeling comfortable about what you approve.