On a Friday afternoon, an engineer assigns the issue “Member export should support Excel” to a coding agent and heads into a meeting. An issue is the ticket an engineering team uses to record a piece of work; a coding agent is an AI tool that can read and change code on its own. An hour later, a pull request is waiting for him, the bundle of code changes submitted for review and merging. Fourteen files changed, two new dependencies added, every test green. He opens the diff, the line-by-line view of what changed, and scrolls through three screens before admitting he can’t tell which changes the requirement needed and which ones the agent made along the way. He closes the PR and rewrites it himself.

This ending is common, and the agent’s code is usually not the problem. The issue it received said what to achieve. It never said what the first finished step should look like.

That gap matters more now. On September 1, 2026, GitHub announced that Copilot code review, GitHub’s built-in AI code reviewer, can approve pull requests once an administrator allows it, and that approval counts toward the repository’s required number of reviews. If AI writes the code and AI can approve it, the place where a person can still exercise judgment moves earlier, to the moment the task is handed over. Before you hand it over, can you describe the first diff that could be reviewed on its own? If not, the issue isn’t ready for an agent to implement.

Finishing and being reviewable are two different things

Coding agents really can finish the job now. According to GitHub’s documentation, its own Copilot coding agent researches the repository in a cloud environment, plans the change, edits files, and runs tests and linters, the tools that automatically check how code is written. It creates a branch, a separate line of work, writes commit messages describing each change, pushes them, and opens the pull request. Another example is Devin, a coding agent from the startup Cognition that is marketed as able to complete engineering tasks independently. In a May interview with TechCrunch, Cognition CEO Scott Wu said that 89% of the code the company’s engineers committed was committed by Devin, and he described Devin as working somewhere between a junior and a mid-level engineer.

It’s easy to conclude from this that if the agent can go from issue to PR, you should hand it the whole feature. That conclusion skips one thing: finishing a task and producing something that can be checked are different.

Even if every line of a fourteen-file PR is correct, the reviewer first has to reconstruct the agent’s reasoning before they can judge it. If they can’t, they’re left with two choices: accept everything or reject everything. The first puts code nobody really understands into main. The second throws away the agent’s hour and the reviewer’s half hour together.

In the same interview, Wu said that what gets done “should always be up to the human.” The trouble is that if the human only decides when the finished PR arrives, the decision has shrunk to accept or reject.

Review cost follows the size of the diff

How hard a piece of code is to review depends on how many things it changes at once. With a diff that touches one module and comes with one test, the reviewer knows where to start and what “correct” looks like. With a diff that changes a data structure, the interface, the configuration, and the docs together, just deciding which file to open first takes time, and every additional area touched adds one more assumption to verify.

Agents make this more visible because they tend to tidy up as they go. To get a test passing, an agent might adjust the test itself. To make a new function easier to use, it might refactor the code next to it. Each move makes sense on its own. Together they add up to a design decision nobody asked for and nobody reviewed.

The tools themselves point the same way. GitHub’s documentation states that Copilot coding agent opens one pull request per task, works in one branch and one repository at a time, has a 59-minute limit per session, and may produce output that is incorrect or insecure, so its work should be reviewed and tested before it reaches production. All of these limits say the same thing: the task you hand over should be small enough for a person to review.

Advertisement

If you can’t describe the first diff, don’t hand it over yet

So before assigning the issue, add one line to it: “The first diff only changes ___, and ___ proves it works.”

Here’s one that can be written: “Add Excel to the export feature. The first diff only adds xlsx output to the exporter module, verified by a test that exports ten member records and checks that the columns match the CSV version.” An issue like this is ready to hand over, with an instruction for the agent to stop after this diff and wait for review.

When you can’t write that line, it’s usually for one of three reasons:

  • The requirement isn’t settled. Product hasn’t decided between Excel and Google Sheets, so the agent has to guess.
  • Nothing can prove it right or wrong. The flow has no tests, so every change can only be judged by eye.
  • The change is spread out by nature. Permissions, payments, login, deletion, and data migration all ripple through the system.

In these cases the agent is still useful, just for different work: reading the code, listing the files that would be affected, drafting tests, comparing two approaches. None of this goes into main, and if it’s wrong you’ve lost a little time, but it helps the team settle the requirement faster. Once that one line can be written, hand over the implementation.

The rule has a cost. Smaller pieces mean more PRs and more reviews. For work that already has thorough tests and follows a repetitive pattern, such as upgrading a large batch of dependencies or renaming a set of functions by a fixed rule, handing over the whole batch at once is more efficient. This is the long tail of maintenance work that Wu says agents are best suited to take on. The test is the same: can you say how the result will be verified? If “all tests pass, the build succeeds, and behavior is unchanged” can prove a bulk upgrade, the batch is fine to hand over.

Three places to hold once AI can approve, too

Copilot’s approval feature is currently in public preview and off by default. Administrators turn it on at the enterprise, organization, or repository level, and repository admins can choose which file paths Copilot is allowed to approve. Once it’s on, a repository can contain a path that no person ever touches: the agent writes, AI approves, and the merge requirements are met.

To keep a person in the loop, hold three places:

  1. Don’t open Copilot approval on paths where agents implement changes. For directories related to permissions, payments, and data migration in particular, approval should always come from a person.
  2. Add a “first diff” field to your issue template. An issue that can’t fill in that field goes to “research only” by default.
  3. Release one step at a time. Let the agent take the next step only after the first diff is merged, and have every step come with the test that proves it. If you tend to approve an agent’s next step from your phone, this matters even more; see Before Merging AI-Written Code From Your Phone, Let Repository Rules Guard the Gate.

Smaller pieces have another benefit. Each step carries a shorter context, so less needs to be redone when something fails, and the bill is harder to lose control of. The reasons are in Long AI Tasks Spend Most of Their Budget on Retries and Rereading Context.

For the next issue you plan to assign to an agent, add that one line first: what the first diff changes, and which test proves it. If you can write it, hand the issue over. If you can’t, the issue needs a person to think the requirement through first.

AI handoff card

Ask AI whether this issue is ready for a coding agent This prompt asks about the issue first, then tries to write the first reviewable diff. If it can’t, it suggests research the agent can do right now instead.

I want to decide whether an issue can go straight to a coding agent (for example Copilot coding agent or Devin) for implementation.
The standard comes from this article: https://boosterminiclass.com/en/posts/coding-agents-need-human-checkpoints/
A task is ready to hand over only if I can describe "the first diff that can be reviewed on its own": which files or modules it changes, and which test proves it is correct.

Ask me 3 questions first:
1. What is the issue's definition of done, and are any product decisions still open?
2. Does the related code currently have tests that prove its behavior?
3. Does this change touch permissions, payments, login, deletion, or data migration?

Based on my answers, give me:
- A one-line verdict: hand it over / split it first / research only.
- If it can be handed over: one sentence describing the first diff's scope and the test that verifies it, ready to paste into the issue.
- If not: which reason it is stuck on, and the research the agent can do now (for example listing affected files, drafting tests, comparing two approaches).
Don't assume tests or code structure that don't exist. If you don't have enough information, keep asking.

AI’s suggestions can only help you ask the right questions. Whether to hand the issue over is still up to the person responsible for the repository.

Advertisement

Share

Share this mini class

If this lesson helps untangle a work bottleneck, share it with someone deciding how to use AI.

References