GitHub took more than 1.2 billion commits in a single week this October — 400% more than a year earlier, and more than the whole of 2025 combined.

Now ask yourself: do you feel 400% more productive than last year?

Writing software was never only "writing". Once AI accelerates the implementation step, the pressure moves somewhere else. A Faros AI study found that when a team goes from low to high AI adoption, pull requests spend 441% longer in review.

Nick Liffen and Philip Holleran at GitHub split a developer's work into four stages — Plan, Build, Verify, Observe — and go stage by stage on what agents can take over and which judgement still has to stay with a human. What follows is that breakdown, plus a table that makes the differences obvious, and one cold shower at the end.

Plan: give the human and every agent the same material

You know this scene. You need to change an API. The design lives in one tool, a compatibility requirement is buried in Slack, and an old PR explains why the current implementation has to work the way it does. To write a useful plan you have to stitch those details together, compare a few options, and confirm with everyone how existing clients keep working. What looks like straightforward planning turns into hours of searching, cross-checking, and follow-up questions. Implementation hasn't started and you are already tired.

What the agent is good for here: gathering the scattered context into one place, reasoning through the trade-offs, and turning those decisions into an implementation plan.

  • Plan where the team already works. Pull PMs, designers, analysts and stakeholders into Copilot in Slack or Teams, with the context of connected tools, so assumptions get checked live.
  • Turn agreed requirements into executable work. Have Copilot open GitHub issues with the context and acceptance criteria, and split out the tasks that can be handled separately.
  • Don't let routine triage eat planning time. Use GitHub Agentic Workflows to label issues and estimate complexity; hand low-complexity work straight to Copilot and keep your time for harder judgement.
  • Give complex work the planning it deserves. Plan Mode in the Copilot surface you already use, to compare options and refine the plan — which you review and approve before implementation starts.

Build: keep more than one thing moving

The plan can become code, but reality has other plans. An agent is halfway through a task, your next meeting starts in five minutes, and someone in that meeting points out an edge case the implementation has to handle. Everyone wants something at once, and you cannot be in three places.

What the agent is good for: keeping work moving while you are not chained to the machine that started it.

  • Continue on another device. Session continuity lets you pick up the same Copilot session in a different client.
  • Close the laptop; the job keeps running. Copilot runs tasks in cloud sandboxes, so execution does not occupy your machine and you can leave and come back.
  • Don't let tasks contaminate each other. The Copilot app gives each session its own copy of the repo, so an implementation task and a docs update don't share a half-finished working tree.
  • Carry project knowledge into every task. Repository instructions record conventions and verification commands; shared memory stores facts Copilot can reuse across the repo. Copilot Dreaming reviews eligible past sessions and PR feedback to keep that memory fresh, and proposes updates to instructions or skills.
  • Match the model to the task. Copilot Fusion lets you pick model and reasoning depth per task, and pull in extra models to double-check a plan — a trade between quality, cost and latency.
  • Keep company rules wherever you work. Enterprise managed settings carry your policies and configured tools across Copilot surfaces.

Verify: spend attention where it is worth spending

You spend an hour steering the agent to the right place, feel it has finally landed, and open a PR labelled "small refactor". It touches 47 files. The only thing you want a human to look at is the shared validation logic, but it is buried under updates to every endpoint that calls it, formatting changes, and hundreds of lines of generated tests. You start wondering how long approval will take, given the queue already on the team's review board.

That queue is what the 441% looks like in practice. You can shorten the wait from both ends: make changes easier for humans to review, and let Copilot clear routine checks and fixes before a human opens the diff.

  • Stack small PRs instead of building one large change. Stacked pull requests split dependent work into smaller pieces, each reviewable on its own, with the dependency visible.
  • Stop routine quality issues before they eat review time. GitHub Code Quality checks changes against coding practices and org standards before they reach a human reviewer.
  • Match review help to the change. Copilot code review gives lighter analysis for simple changes and deeper analysis for complex ones — you can set the depth or let Copilot decide per PR.
  • Cover more repos with security scanning. AI Scan finds vulnerabilities in languages and files outside CodeQL's coverage; AI secret detection helps catch unstructured secrets such as passwords, which pattern matching tends to miss.
  • Hold new dependencies to policy. License compliance checks dependencies against company rules before merge; GitHub's package firewall (public beta for npm) can block downloads that violate configured security policies.
  • Handle findings and follow-ups without babysitting every PR. Agentic Autofix proposes fixes for security issues, and Agent Merge handles failing checks, review comments and merge conflicts — and, if you configure it, Copilot can even merge once verification passes.

Observe: learn from what shipped

The change is approved, deploy checks pass, and you cross it off. The next morning the on-call dashboard shows intermittent timeouts and support reports a few large customers affected. Now you are matching logs, release history and customer feedback while someone asks whether to roll back. Yesterday's "all checks passed" sounds less reassuring today.

What the agent is good for: putting operational evidence next to engineering context so you can decide the next step on evidence.

  • Check assumptions against real behaviour. With observability tools and business data connected through something like Fabric, Copilot can help identify which requests and which customer segments are affected.
  • Record findings where someone can act on them. Have Copilot draft an issue with supporting evidence and acceptance criteria, including regression tests for the failure this exposed.
  • Carry the useful lesson into later work. Look at what Dreaming suggests — it uses sessions and repo activity to refine memory, skills and code review guidance.

The table worth taking away

The GitHub post reads like a product guide: every stage sounds right, but it is hard to act on. Compressed into one table, the differences become obvious:

Stage Who leads Artifact that should survive Most common failure
Plan Human leads, agent gathers and asks A reviewable plan, acceptance criteria, scoped issues The plan only exists in a chat nobody reopens
Build Agent does most, human sets direction Isolated working copies, small individually reviewable PRs Session lost on one machine; several tasks sharing one unfinished tree
Verify Machines first, human second Smaller diffs, routine checks cleared, review focused on intent The review queue balloons — that is the 441%
Observe Human leads, agent connects evidence Issues with evidence and regression tests Treating "all checks passed" as a conclusion

The column to watch is the last one. Only Verify fails visibly (the queue grows, the PR gets fat). The other three fail quietly: the plan was never written down, the session was lost, and after deploy there is only "checks passed".

So if you want to change something, start with "every stage must leave behind something another person can open" — not with swapping models.

One cold shower

These capabilities ship according to GitHub's plans and preview states. The package firewall is public beta for npm; Agent Merge, Copilot Fusion and friends each have their own toggles. The post describes capability boundaries, not what you can switch on tomorrow.

The one thing you can do immediately, with no plan and no vendor, is make the change smaller.

Originally published in Chinese on hubwiz.com. This is an edited English version of a Chinese write-up that compiles the GitHub Blog post "Beyond code generation: A developer's guide to agentic engineering" (Nick Liffen & Philip Holleran, 2026-11-06) and the Faros AI review-dwell finding; the numbers are quoted from those sources and were not independently reproduced here.