How to review pull requests from autonomous agents (Devin, Jules, OpenHands)

The difference with an autonomous agent is not the code, it is that there is nobody in the thread. Nobody watched the run, the session that produced it may already be archived, and the description was written by the same process that wrote the diff. So the review starts one step earlier than usual: establish what evidence survived the run, then read the change against the system rather than against its own account of itself. A 2026 study of 33,596 agent-authored pull requests found 61.38% of them received no recorded review at all, and 71.58% of the review comments that did appear were written by agents rather than by people.

There is no author to ask, so the pull request has to answer for itself.

Devin, Jules and OpenHands each leave a different amount behind. Knowing which one you are looking at decides where the first two minutes go.

Devin: the session is the author, and it expires

Devin runs work in a session with a workspace you can open: a planner, a shell showing every command and its output, an embedded editor you can take over, and a browser. It pushes branches, opens pull requests and takes part in the discussion on them like any other contributor.

Two things follow.

The shell log is the strongest evidence any of these agents produce. It records every command and what came back, in the order they ran. If you want to know whether the tests were really run, whether the migration was really applied against a real database, or whether an install silently failed halfway, it is in there. Read it before the diff on anything that touches data or money.

The second thing is a deadline. Devin replies to pull request comments as long as the session has not been archived, and the loop stops once it has. Mentioning Devin in the thread wakes an archived session, so the door is not locked, but the window in which this pull request has an attentive author is shorter than the window in which it sits in your queue. Ask your questions on day one.

Devin also has a separate review product. You can comment /devin review, at the start of the comment, on an open pull request, or turn on automatic reviews when pull requests open or when commits land, and it sorts findings into bugs (severe in red, non-severe in orange), flags (investigate, informational) and security (critical, warning). It reviews Devin's own pull requests too. That is a reasonable first pass on defects and it does not answer the question of whether the change belongs in the system at all.

Jules: check who the commits belong to, and why CI went green

Jules is Google's async agent: you hand it an issue, it works in its own cloud VM, and it opens a pull request when it is done. Its public changelog is the best record of what it does today. Gemini 3 Flash became the base model for every tier on 30 January 2026, MCP support arrived on 2 February 2026, and Gemini 3.1 Pro replaced Gemini 3 Pro as the default for Google Pro plan users on 9 March 2026.

Two entries from 19 February 2026 change how you should read a Jules pull request.

The first is the CI fixer. On pull requests Jules itself opened, it detects failing GitHub Actions checks, works through a fix, and resubmits with no manual intervention. This is a real improvement and it also removes a signal you were probably relying on. A green pipeline used to mean the change passed. Now it can mean the change passed on the third attempt, after the agent adjusted something. Look at the branch history for commits whose only job was to make CI happy, and read those diffs closely. GitHub's own red flag list calls the failure mode CI gaming, and an agent that is explicitly authorised to iterate against your checks is the case where it is most likely to happen by accident.

The second is commit authorship. Jules can commit as itself, as a co-author, or with you as sole author. If your team uses git blame to route questions, or treats a familiar name in the author column as a reason to look less carefully, that setting quietly breaks the assumption. Check who a branch says wrote it before you let the name do any work.

OpenHands: the trigger is a label, so check who pulled it

OpenHands is the open source one: MIT licensed, model agnostic, and past 86,000 stars on GitHub as of 7 September 2026. You can run it yourself or use the managed OpenHands Cloud.

Its GitHub integration is the part that matters for review. Label an issue openhands or comment @openhands, and it comments on the issue to say it is working, links to the session so you can follow along, and opens a pull request if it decides the issue is resolved. Mentions inside a pull request only work when the pull request is both to and from a repository you have added. It works through short-lived tokens that expire after eight hours, with read and write access to actions, contents, commit statuses, issues, pull requests, webhooks and workflows.

"Opens a pull request if it determines that the issue has been successfully resolved" is doing a lot of work in that sentence, and it is the agent's own determination. In a repository where the label is available to anyone who can comment, the volume of pull requests is set by your issue tracker rather than by your team.

So the first question on an OpenHands pull request is which issue triggered it and who triggered it. An issue written as a bug report by an outside reporter, turned into a diff by an agent, is a change nobody on the team ever scoped. Review the issue alongside the diff when that happens, because the scope needs a decision as much as the code does.

The three checks that replace asking the author

With no session to interrogate, three things carry the weight.

Read the evidence trail for what it actually shows. A test that exercises the new path counts. A shell log with a real test run counts. "All tests pass" in a description written by the model does not, and neither does a green check that the agent had permission to repair.

Read the removals. Autonomous runs are the ones most likely to retire something in passing, because nobody stopped them at the moment they decided to. A deleted worker is three lines in a diff and a page of consequences.

Read the change against the parts of the system it did not touch. This is the one a diff cannot help with at all, and it is where most agent defects live: a new queue whose consumer assumes ordering the producer never promised, a helper rewritten forty lines away from an identical one, a call left pointing at a path that no longer exists.

Give the pull request something that answers for itself

This is why I built PR Lens, and autonomous agents are the case it was built for. It draws the pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request, redrawn on every push. Green is new, amber is changed, red is gone and struck through, and the parts of the system nobody touched stay on the page, so what you read is a model of the system rather than a patch.

The reason it helps here specifically is that it does not depend on the agent. The diagram is generated from the diff and the repository, so it says the same thing whether the session is live, archived, or was never watched. It is the one artefact in the thread that was not written by the author.

The hosted GitHub App keeps a baseline of the repository so a change is drawn against the system and tracked across commits, which is the part that lets a removed component still show up with a line through it. It is free for open source and MIT licensed, and it also runs as a GitHub Action with your own key, a CLI, or a skill inside whatever agent you already have open.

The ten minutes, with nobody to ask

The clock is the one from how to review a 400-line pull request in ten minutes. Autonomous agents change only the last row.

If the ten minutes turn up a structural problem, write the comment about the structure and expect to fix it yourself or reopen the task with a better brief. Asking an archived session for changes gets you nothing, and asking a live one for a change to a line gets you a change to that line.

Six in ten agent pull requests are never reviewed by a human is the study behind the number at the top of this post. Five red flags in agent pull requests maps each of GitHub's warning signs to what it looks like when the change is drawn. The method underneath both is in the complete guide to reviewing AI-generated pull requests.