Skip to content

It proposes, you merge

A little while after you assigned the threshold issue, a pull request appears on orders-service - opened by Copilot, marked draft. That word is the whole point of this lesson, so it’s worth saying plainly: the cloud agent does not commit to your main branch. It cannot. What it produces is always a draft PR - a proposal sitting on its own branch, waiting for a human to look at it before it goes anywhere.

Think back to your very first change, where you read the diff before you accepted it and you made the commit. The async surface doesn’t loosen that rule - it enforces it structurally. The agent ran with no one watching, in an environment you never saw, so the guarantee you get in exchange is that nothing it did can reach your protected branch without passing through review. A draft PR is the agent saying here’s what I’d do in the most reviewable form GitHub has. The decision to merge is still a human keystroke, exactly as it was for the one-line sort fix.

So the loop is identical to the one the whole course has run - agent proposes, you decide - just lifted up a level. The diff isn’t in a chat view anymore; it’s a pull request, with all the review machinery that comes with: the file-by-file diff, the CI checks, your team’s review tools.

Open the draft and read it the way you read every change in this course - with the three questions from your first review, now against a PR:

  1. Did it change what the issue asked, and only that? Scope creep is easier to spot in a PR diff than anywhere; flag it if the agent wandered.
  2. Is the fix correct? Read the boundary comparison and the test it added. A passing check is necessary, not sufficient - the agent wrote that test, and a test can pass for the wrong reason.
  3. Does it match how this repo does things? Because it read your custom instructions and skills, it usually does. When it doesn’t, that’s a signal those instructions have a gap.

That second question is the whole trust model of unattended work in one line. The agent ran with nobody watching, so the checks in its environment decided what “done” meant - and a green board can mean less than it appears to. Watch a night’s batch come back green, then decide what its report has to get past before you believe it:

Nine chores, queued for an agent to run overnight. The terminal replays the night as it happened; the panel is the morning report - the only thing you’ll actually read. Watch what its checkmarks are made of, and when playback pauses, decide what the run has to get past before you believe it.

overnight batch - ledger-app
overnight batch · repo: ledger-app · 9 chores queued · nobody watching
the morning report

    The flaw rate here is theatrical - seven duds in nine - because the point is what each wiring would have caught, not the odds. The checks wear different clothes per tool (a CI step, a test command the loop must pass, a verifier agent), but the question is always the same: what does this run have to get past before “done” reaches you? And the residual is real: no check catches a requirement nobody wrote down.

    If the PR is close but not right, you don’t necessarily re-assign and start over. You can comment @copilot in the pull request thread - “the test only covers the at-threshold case; add one just below it too” - and the agent continues work on the PR branch with the pull request’s context available. Do not assume the exact prior ephemeral environment is reused. The PR thread becomes the conversation, the way the chat view was in the IDE. You steer with words here exactly as you did in Agent mode; the medium changed, the move didn’t.

    When the draft is right, you do the last step the agent is deliberately not allowed to do: mark it ready, and merge it. One issue down.

    That clears the backlog item - but the agent ran inside an environment you’ve taken entirely on faith so far. The last lesson opens that box: what it can install, how long it’s allowed to run, and who decides it’s allowed to run at all - customizing the agent’s environment.