Not long ago, a pull request (PR) landed in your queue because a person wrote it, understood the problem, and structured the diff to tell a story you could follow. Your job as reviewer was to catch what they missed, like an edge case or a race condition hiding two functions away.

That arrangement has shifted, because a lot of the code you review now started life as a prompt, and the author might be an agent that produced two hundred lines in thirty seconds. Some tools expose the prompts, tool calls, and traces behind that diff, but what you rarely get is reliable human intent or guaranteed access to how the model reasoned.

Recent analyses suggest AI-authored PRs can introduce more review findings than human-written ones, which means teams need to treat AI-generated diffs as code to verify, not code to rubber-stamp. A good checklist pushes the mechanical checks into automation and keeps your attention on the parts a machine still can't judge.

This guide covers how to prepare a PR for review, what to check during it, the security and AI-specific items most lists skip, and how much you can hand to an agent today.

How to prepare before you start a code review

Most of the prep that makes a review fast belongs to the author and should be done before you open the diff. Start with intent you can verify against, where the ticket and PR description tell you what the change is supposed to do and why, ideally with the purpose and rationale for non-obvious decisions spelled out. If you still can't say what problem the PR solves, that confusion is your first comment.

Build checks, static analysis, linting, and the test suite belong in the CI/CD pipeline, where they fire on every push and have to pass before a human reads a line. A green check at the top of the PR means the boring questions are settled, and your attention goes to logic and design instead of indentation.

Size is the last thing to confirm, since review usefulness drops as a diff grows, the practical truth behind the old line that ten lines gets you ten comments while five hundred gets you "looks fine." When a PR stitches several unrelated changes together, send it back to be split before you sink an hour into reviewing it badly.

The core code review checklist: what to check on every pull request

The checklist works from the outside in. Begin with what the change does, then narrow toward how it does it, and run these checks on every PR:

• Functionality and intent: Confirm the code does what the ticket asks, and read every line assigned to you rather than trusting a function body because the signature looks reasonable. For anything user-facing, a quick demo tells you more than inferring behavior from the diff.

• Edge cases and failure paths: Look hard at concurrency and the unhappy paths, like an async call that fails or an exception that fires partway through. Confirm the code fails safe and doesn't leak data or skip an authorization check on the way down.

• Readability: Code that needs a paragraph in the review thread to explain what it does should usually be rewritten until it doesn't, because the next person to touch it won't have your thread.

• Design and architecture: Watch for the two opposite failures, new utility functions that duplicate something the codebase already has and clever abstractions that add indirection without earning it. Any non-obvious design choice deserves a documented reason.

• Tests: New and changed behavior needs tests that cover the error cases and not only the happy path. Functional tests carry the most weight when the change touches a sensitive or high-risk path.

• Documentation: When a change alters how people build, test, or release the code, the docs that describe those steps should move with it, and asking for the update is a fair blocking comment.

The order is doing real work here. Early items are about behavior and intent and later ones are about specific lines, so you build understanding as you go without getting lost in syntax before you know what the code is for.

Security checks to add to your code review checklist

Security-sensitive paths deserve a closer read, and AI-generated code often deserves extra scrutiny because code that runs and passes tests can still skip the threat modeling a person would have done. The Open Worldwide Application Security Project (OWASP) Top 10 is only the floor, and these are the items worth a human signing their name to.

Validate every input server-side

Validation belongs server-side through a centralized routine using allow-lists rather than block-lists, since a block-list only stops the bad input someone thought to name.

Check authorization on every sensitive operation

Authorization is mandatory on sensitive paths, and the bug you're hunting is the missing or assumed check rather than the obviously broken one. Object-level access should constrain queries to the authenticated owner or tenant instead of trusting an object ID from the request.

Keep secrets and dependencies clean

No connection strings, application programming interface (API) keys, or credentials belong in source, and credentials or personally identifiable information (PII) should never land in logs, with automated secrets scanning behind the manual read. Dependency changes want software composition analysis (SCA) in CI/CD so a known vulnerability in a bumped package gets flagged.

How to review AI-generated code and agent pull requests

AI-generated and agent-authored PRs need a handful of checks that were rarely on anyone's list two years ago, because the failure modes are different from the ones humans produce. The surface polish is part of the problem, and agent-authored PRs show mixed results that still depend on a careful human read before anything merges. All the usual standards apply, and these checks go on top:

• Scope of the change: AI-generated PRs have a habit of spreading across backend logic, config, and tests and into the user interface (UI) without the narrative a human author would have given them. Confirm the change touches only what was asked, because your review turns into context-switching as that surface grows.

• CI and test configuration: Scan anything that touches .github/workflows, test config, or coverage settings first. A dropped threshold, a skipped or renamed test, or a workflow that stopped running needs an explicit reason before it gets a pass.

• Imported packages and methods: A model will sometimes invent a package or a method that sounds plausible and does not exist. Package hallucination is a measured risk, and a 2026 replication on newer frontier models found rates of roughly 4.6% to 6.1%, down from earlier work that ranged from 5.2% on commercial models to 21.7% on open-source ones, which makes a fabricated import a supply-chain attack surface the moment someone registers the name.

• Spots where the code sounds certain: Push hardest on the sections that look the most assured, because generated code often reads most confidently right where its reasoning went wrong.

An AI review tool can make a good early pass by surfacing likely logic mistakes, missing edge cases, and security concerns.  Treat those findings as candidates: useful to investigate, but still requiring human verification.

How to give code review feedback that gets changes merged

Feedback works when it helps the author fix the problem quickly without making them feel managed, and three habits carry most of that weight.

Point to the line and explain why

The strongest comments name the specific line and the reasoning, since an explanation teaches the author something while a bare "change this" creates a chore. Pointing out the issue and letting the developer decide how to fix it lands better than prescribing the exact change.

Separate blocking issues from nits

A blocking comment is a logic error, a security hole, a race condition, or a missing test, and everything else is polish the author can take or leave. Prefixes like Nit:, Optional:, and FYI: or the categories from Conventional Comments draw that line so a style preference never carries the weight of a logic error.

Keep the tone constructive and the turnaround fast

Feedback framed as a question lands better where you're unsure, and the comment is always about the code, never the person who wrote it. It helps to respond fast enough that the author can act while the change is still fresh. When a PR is solid with only minor notes, give the "looks good to me" (LGTM), since a change that improves overall code health shouldn't sit for days because it isn't flawless.

Running your code review checklist automatically with OpenHands

The honest problem with any checklist this long is that you won't run all of it on every PR. The parts that get skipped under pressure are often the mechanical checks a machine can run consistently: known vulnerabilities, risky dependency changes, missing tests, suspicious imports, breaking API changes, and common quality issues.

OpenHands provides an automated PR review workflow, powered by the Software Agent SDK. Teams can configure OpenHands agents to review pull requests inside GitHub and surface feedback on code quality, security, and best practices before a human reviewer starts.

The right role for an agent reviewer is first-pass coverage, not final authority. Let the agent surface candidate issues, then keep humans responsible for intent, architecture, security judgment, and merge approval. As the findings prove useful, teams can expand the workflow from advisory review to more consistent enforcement for the checks they trust. Because OpenHands is open source and inspectable, teams can understand and adapt how these review workflows run. Reviewers can see the conversation, tool activity, file changes, and outputs behind agent work, giving platform and security teams more confidence before they rely on the workflow across repositories.

Turn your code review checklist into a repeatable habit

A checklist you keep in your head is a checklist you skip the moment a deadline gets close, so if you want to review well consistently you have to turn yours into a system. CI/CD proves the build and tests before a human reads anything, security scanning and SCA handle the repeatable security checks, and an AI reviewer takes a first pass at quality, which leaves the people on your team free to spend their judgment on the handful of things that genuinely need it.

That structure keeps review capacity ahead of the rising volume of AI-generated change, since more code arriving with a higher defect rate will outpace any team that reviews all of it by hand. Define a PR review workflow once, and it can run on every PR without anyone remembering to kick it off. Start locally to see how the agent reviews a diff, configure a PR review workflow that runs on your pull requests, then scale it to OpenHands Cloud for managed runs or a self-hosted deployment when your organization needs more control.

Frequently asked questions about code review checklists

How long should a code review take?

Review sessions work best kept short enough that you stay sharp, with a hard stop as soon as you notice yourself scanning instead of evaluating. A fast review that lands while the author still has context is worth more than a thorough one two days later, and an agent reviewing the PR first, which the OpenHands docs walk through, shortens each human session.

How big should a pull request be for an effective review?

A few hundred changed lines is a comfortable ceiling for a single sitting, and two small reviews done well catch more than one large review done badly. The same rule holds for agent-authored changes, and agents built with the OpenHands Software Development Kit (SDK) can be scoped to one purpose per PR.

Do you still need manual code review if you use AI review tools?

Yes, because a human still owns intent, architecture, and accountability for what ships, while AI review surfaces likely correctness and security issues quickly. OpenHands is built around that division of labor, with agents handling the repetitive checks while developers stay on the decisions. Whether that layer pays for itself depends on your PR volume.

What is the difference between a code review and testing?

They catch different classes of problems and you want both. Tests prove expected behavior under the cases you wrote down, while review catches problems in requirements, design, security assumptions, and business logic that no test was written for. The write-up on vibe coding and quality shows how teams automate the repetitive side of both.

About OpenHands

OpenHands is the open-source platform for building and running AI coding agents, with the interface, automations, and control layer needed to go from a single local agent to a system running across an entire organization. The mission is to make agent-based software development accessible, transparent, and controllable by default. That starts in the open. The core framework is open source, giving developers and platform teams full visibility into how agents execute work and interact with their systems. The project has over 78,000 GitHub stars, 9 million downloads, and contributions from hundreds of developers. OpenHands is used by engineers at large enterprises and fast-growing startups to build, run, and scale AI coding agents across real software engineering workflows. The long-term vision is to become the full stack AI coding agent platform for software engineering. Not just helping developers write code, but running meaningful parts of the software lifecycle.