Engineering · AI delivery
Agent work needs reviewable slices. Here’s how to size them
When an agent can take an issue and return a pull request, leaders face a new sizing question: how much work should one assignment contain? Recent GitHub data shows agent-involved changes are often multi-file, while research describes a shift toward supervisory engineering. The practical decision is how to define a unit of delegated work that stays understandable, reviewable and reversible.
By Nythrex team3 min read
A broad assignment can look efficient: one prompt, one agent run, one pull request. But a single PR may combine a behavior change, a migration, tests, configuration and cleanup. Even if it merges quickly, reviewers have to determine whether each part is right and whether the parts fit together. The number of files is not a quality score; it is a cue to ask whether the change can be understood as one decision.
- Agent-involved PRs were more likely to change multiple files than PRs without detected agent involvement, in GitHub’s 2026 Octoverse report.
- 87% vs. 79%
- By September 2026, agent-involved PRs merged within two weeks at this rate versus the comparison group, according to GitHub. The measure says nothing by itself about defects or later rework.
- 90% vs. about 86%
1. One assignment should make one review question answerable
GitHub’s October 2026 Octoverse report says about 87% of agent-involved pull requests changed multiple files, compared with 79% of PRs without detected agent involvement. That difference does not prove that agents make worse changes: legitimate features often cross file boundaries. It does mean teams should not assume a delegated task naturally returns in a convenient review unit. The report also says the share of agent PRs merged within two weeks reached 90% in September, while the comparison group was about 86%. Merge speed is useful flow evidence, but it cannot establish that the delivered behavior was correct or durable. Ask reviewers to state the PR’s behavioral claim in one sentence. If the change contains multiple independent claims, consider splitting it.
2. Review the work shape, not an arbitrary file limit
A hard maximum file count can encourage cosmetic splits and leave reviewers reconstructing the feature across branches. Instead, consider whether each slice has a clear purpose, a testable boundary and a safe point to stop. A change that updates several files for one cohesive API behavior may be easier to assess than a smaller PR mixing unrelated fixes. GitHub reported that stacked pull requests, which let developers split related work into smaller changes reviewed in sequence, had been used by more than 264,000 developers by September 2026. That is evidence of uptake, not proof that stacking improves every team’s outcomes. Use the pattern where dependency order helps reviewers follow the work.
| Signal | Ask | Possible response |
|---|---|---|
| One purpose | Can the requested behavior be described as one outcome? | Split independent behaviors into separate assignments. |
| Test boundary | Can acceptance be checked without guessing intent? | Specify observable behavior and relevant tests. |
| Change surface | Do files span distinct risks or owners? | Plan separate review or stage the dependent changes. |
Delegation changes who produces the first draft; it does not remove the work of deciding whether the change belongs.
3. Count the supervisory work in the delivery picture
A May 2026 longitudinal study by Annie Vella and Kelly Blincoe, revised on November 3, followed professional software engineers through two questionnaires six months apart. The matched cohort included 95 participants. In the abstract, 82% reported spending less time writing code; the authors also describe a broader shift from creation toward verification and supervisory work, including directing, evaluating and correcting AI output. These are participant reports, not a controlled measure of time saved for every team. For your own workflow, record how much reviewer and author effort goes into acceptance, corrections after review, and reverts. Compare similar task types over a defined period, and keep quality signals visible. A faster merge with more unplanned repair may not represent a better trade.
What to do on Monday
- 1
Choose a narrow task family
Pick recurring work with acceptance conditions your team can state plainly. Avoid treating results from one task family as a universal agent benchmark. - 2
Write the boundary into the assignment
Name the behavior, relevant constraints, expected checks and conditions that should trigger a question or stop. Let the agent propose a decomposition when the issue is too broad. - 3
Review a small batch end to end
For each change, log task type, files touched, review effort, post-merge fixes and reverts. Compare with similar human-led work and report the limits of the comparison.
Sources
Frequently asked questions
Should teams limit the number of files an AI agent can change?
A file limit can be a useful local signal, but it is not a reliable measure of reviewability by itself. Set scope around a clear behavior, test boundary and risk, then inspect multi-file changes for independent decisions.
Does faster merging show that AI agents improve software delivery?
No single merge-time measure establishes quality or total delivery impact. Compare similar work and include review effort, follow-up fixes and reverts in the assessment.
Read next
Stop guessing.
Start seeing.
No card and no subscription: paid plans have not launched yet.