The useful question is not simply whether an agent can write a change. It is whether the team can understand, approve, ship, and support that change without moving the bottleneck down the hall.
Why review deserves equal billing
GitHub’s argument draws on Faros AI’s 2026 engineering report. Faros says its analysis covers two years of telemetry from 22,000 developers across more than 4,000 teams, comparing each organization’s periods of lowest and highest AI adoption. It reports a 441.5% increase in median time in review—the figure GitHub rounds to 441%.
That is an association within Faros’s dataset, not proof that AI alone caused the slowdown. Nor does it mean every reviewer spent 441% longer actively reading code: Faros separately reports a 199.6% increase in average time spent in code review and a 156.6% increase in median time to first review. The distinctions matter when choosing what to measure locally.
Plan: establish the task before delegating it
GitHub proposes gathering connected context through Copilot in Slack or Microsoft Teams, creating issues with acceptance criteria, automating triage through Agentic Workflows, and approving complex implementation plans in Plan Mode.
For a pilot, make the handoff explicit: what must change, what must remain compatible, and what evidence will demonstrate success? Treat unanswered questions as planning work, rather than invitations for an agent to improvise.
Build: preserve context without confusing it with policy
The Build stage combines cloud execution, cross-client session continuity, isolated repository copies, shared knowledge, Dreaming’s proposed guidance updates, Fusion’s model choices, and enterprise-managed settings.
GitHub’s Memory documentation adds an important qualification. Repository facts and personal preferences are separate types of memory. Repository facts apply to that repository; personal preferences can follow a user across repositories. Availability requires a paid Copilot plan and depends on client support, access, and applicable settings.
More importantly, remembered context is not an enforcement mechanism. GitHub says Copilot checks a repository fact’s supporting citations against the current branch, but that assessment is a model judgment, not a system guarantee. Its documentation recommends custom instructions for important rules—and cautions that neither instructions nor memories guarantee compliance. Review remains necessary.
The practical recommendation: distinguish helpful background from mandatory controls. A remembered build command is useful; a required security check should not depend solely on whether an agent recalls it.
Verify: keep automation accountable
GitHub pairs smaller, stacked pull requests with automated quality, security, secret, and license checks. Agentic Autofix proposes security repairs; Agent Merge handles follow-up work and can merge after configured verification passes.
One concrete deployment detail deserves attention: GitHub package firewall is not automatically protecting every dependency download. GitHub’s documentation says administrators must configure enterprise policies and route endpoints through the firewall instead of directly to public registries. It remains in public preview, with npm the supported ecosystem and Artifactory integration marked experimental.
Documented defaults include:
- Blocking known malware.
- Blocking vulnerabilities rated critical.
- Blocking attestation downgrades and newly introduced installation scripts.
- Requiring package versions to be at least one day old.
These controls also create operational decisions. GitHub documents an exception process because, for example, the age restriction could block a newly published security fix. For a Windows development fleet, the rollout checklist should therefore include local developer environments, agent environments, and CI runners—not just a policy toggle in the enterprise console. The firewall evaluates requests that actually pass through it.
Before enabling automatic merging, our recommendation is to define the required checks, protected areas, and circumstances demanding human approval. A green dashboard should answer a specific question, not serve as a decorative permission slip.
Observe: turn production findings into better requirements
For Observe, GitHub describes using connected operational and business data, including Fabric, to investigate affected requests or customers, draft evidence-backed issues and regression tests, and suggest reusable guidance improvements through Dreaming.
For an initial trial, require the investigation output to separate observed facts from proposed explanations. Record the affected behavior, supporting evidence, uncertainty, and the test that would reproduce the failure. Keep rollback authority explicit rather than implicitly delegating it with the investigation.
Measure the handoffs, not just the output
Our recommendation is to evaluate one bounded task across all four stages before expanding automation. Record planning corrections, review waiting time, reviewer effort, defects found before release, and the effort needed to diagnose problems afterward.
That makes GitHub’s framework useful even without adopting every product it names. The test is not whether the agent stayed busy. It is whether the team delivered a change it can explain, trust, and maintain.