GitHub Copilot moves beyond code generation to orchestrate the developer's entire workflow

- Reading
- 6 min
GitHub logged 1.2 billion commits in one week in October, but a Faros AI study shows pull requests take 441% longer to review. The GitHub Blog details how Copilot tries to tackle that bottleneck across four stages: plan, build, verify, and observe.
The bottleneck moved
In October 2026, GitHub logged more than 1.2 billion commits in a single week, more than 400% above the volume from the same period a year earlier. That number surpasses the total commits the platform received in all of 2025, according to the GitHub Blog.
Generating code has never been faster. But Nick Liffen and Philip Holleran, authors of the post published on November 6, 2026, ask the question that underpins the whole argument: do you feel 400% more productive than you were a year ago?
The answer, based on the data they cite, tends to be no. A Faros AI study found that, as teams move from low to high AI adoption, the time a pull request spends in review grows by 441%. The bottleneck didn't disappear: it migrated from writing the code to everything that comes after it.
It's this mismatch that drives the Copilot overhaul. Instead of treating it as supercharged autocomplete, GitHub now markets it as an agent that follows four stages of a developer's work: plan, build, verify, and observe. The content was presented at GitHub Universe 2026, in the session "Agentic Engineering: Past the Pilot," and detailed on the official blog.
Plan: taking requirements out of Slack and out of someone's head
The scenario described is familiar: the design for an API change is in one tool, a compatibility requirement is lost in a Slack conversation, and the reason the current implementation works the way it does is explained in a pull request from months ago. Before writing any plan, someone has to manually piece all this together.
To address this, GitHub proposes using Copilot inside Slack or Teams, pulling context from connected tools so that product, design, and business stakeholders can review assumptions together with whoever will implement the change. Based on what's agreed, Copilot creates GitHub Issues already including acceptance criteria and separate tasks.
To keep triage from eating into planning time, GitHub Agentic Workflows labels issues, estimates complexity, and assigns simple tasks directly to Copilot. More complex work goes through Plan Mode, where the developer compares approaches, refines the plan, and only then approves execution.
Build: multiple tasks running at once, without getting stuck on your laptop
The second friction point the post describes is temporal: the agent is in the middle of a task, a meeting starts, and partway through it someone points out an edge case that changes the implementation. No one can be in three places at once, and until now that meant losing track of the work.
GitHub solves this with session continuity across devices and execution in cloud sandboxes, which takes the task off the local machine and allows it to be resumed later. The Copilot app gives each session an isolated copy of the repository, so that an implementation task and a documentation update don't share the same unfinished working tree.
Three additional features support this parallelism:
- Repository instructions and shared memory: capture conventions and validation commands, and Copilot Dreaming reviews eligible sessions and pull request feedback to keep these memories up to date.
- Copilot Fusion: lets you choose the model and reasoning depth per task, bringing in additional models to review a solution when needed, with control over cost and response time.
- Enterprise managed settings: loads company policies and configured tools across all Copilot surfaces, reducing setup differences between clients.
Verify: smaller diffs, automated review before the human
Here's the point that connects directly to the 441% figure cited at the start: the review queue. The example in the post is a pull request labeled as a "small refactor" that changes 47 files, mixing shared validation logic with updates to every endpoint that calls it, formatting, and hundreds of lines of generated tests.
The proposed solution has two fronts. On one side, stacked pull requests split dependent work into smaller pieces, each reviewable in isolation, while keeping dependencies visible. On the other, a stack of automated checks tries to resolve what's routine before a human opens the diff:
- GitHub Code Quality checks changes against the organization's code practices and standards.
- Copilot code review gives automated feedback, with lighter analysis for simple changes and deeper analysis for complex ones.
- AI Scan finds vulnerabilities in languages and files outside CodeQL's coverage, and AI secret detection helps identify unstructured secrets, such as passwords, that traditional pattern matching tends to miss.
- License compliance checks dependency licenses against company rules, and the GitHub package firewall, currently in public preview for npm, can block downloads that violate configured security policies.
When something goes beyond those limits, Agentic Autofix proposes fixes for security issues, and Agent Merge resolves failing checks, review comments, and merge conflicts, leaving the pull request ready to be merged automatically, if configured that way.
Observe: from a production incident back to the next plan
The final stage closes the loop: the change was approved, the deploy checks passed, and the next morning the on-call dashboard shows intermittent timeouts affecting large customers. "All checks passed" doesn't reassure as much as it did the day before.
GitHub proposes using connectors like Fabric to give Copilot access to observability tools and business data, helping investigate which requests or customer groups were affected. Based on the investigation, Copilot can draft an issue with evidence and a regression test for the bug found.
Closing the loop falls to Copilot Dreaming, which reviews sessions and repository activity to suggest improvements to memories, skills, and code review guidelines, carrying the lesson from the incident into the next plan.
What this changes in practice, and what's still left to answer
For developers in Brazil, the interesting angle isn't the commit volume, it's the review queue. If your team already feels pull requests slowing down after adopting generative AI, GitHub's diagnosis matches a concrete pain, not a theoretical one: the problem isn't generating code faster, it's absorbing that code at the same speed through the rest of the process.
It's worth noting that much of what addresses this bottleneck, like Copilot Fusion, Enterprise managed settings, and the package firewall (still in preview for npm), depends on paid tiers or early-stage features. Smaller teams using Copilot in a simpler way don't access the full package described in the post, and it's up to each team to assess whether stacked pull requests and multiple parallel agent sessions actually reduce friction or just trade one kind of complexity for another.
GitHub itself acknowledges this in how it closes the piece: the recommendation isn't to restructure the entire process at once, but to pick a task that's already a pain point this week and apply an agent to it, expanding gradually as results show up.
Translated from the Brazilian Portuguese original · Read the original
OpenAI uses AI to find 1,724 Linux kernel vulnerabilities for $1.21 million
OpenAI agents scanned the Linux kernel, confirmed 1,724 vulnerabilities, and built around 950 exploits capable of granting root access, for a fraction of the cost of a human audit.





