Code arrives quickly; pull requests still wait for review. Faster implementation can shorten delivery, but it can also overload the people deciding whether changes are safe. Generated work and completed work need separate measures.
GitHub’s November 6 guide organizes the workflow into Plan, Build, Verify and Observe. It is a product-oriented practice guide, not a productivity experiment. We checked it on November 9.
A plan is an input contract
GitHub recommends turning requirements into issues and acceptance criteria, and reviewing complex plans before implementation. The useful artifact is a condition that allows someone to decide whether work is complete. “Improve login” is difficult to review; specifying what happens to expired sessions and unsaved input is concrete.
Breaking work into small pieces does not eliminate shared dependencies. API contracts, schema changes and deployment order need explicit coordination before parallel implementation. That is our application of the guide to team operations.
Review capacity limits the benefit of code generation
The following is an operational model, not GitHub's internal product architecture.
Acceptance criteria → implementation → verification evidence → review → observation
↑ │
└──── discovered failure ────┘
Reviewable evidence includes scope, failure impact and rollback conditions as well as test output. Opening many small pull requests can still lengthen a queue. This is queue-based reasoning, not a measured GitHub productivity result.
| Stage | Evidence to preserve | Human decision |
|---|---|---|
| Plan | Acceptance criteria and exclusions | Problem and acceptable risk |
| Build | Diff and execution conditions | Unexpected scope expansion |
| Verify | Test results and failure analysis | Whether remaining risk is acceptable |
| Observe | Deployment version, symptoms and logs | Recovery and follow-up priority |
Make failures inputs to the next task
A team can track PR creation, first review, merge and subsequent rollback or rework. Changes in task difficulty or team composition prevent a simple before-and-after average from establishing causality. If review waits increase, inspect work in progress and evidence quality before selecting a faster model.
Agents investigating production also need a distinction between reading logs and executing recovery commands. Logs may contain sensitive data or untrusted instructions. Separating read and write permissions and naming a recovery owner are our recommendations.
Workflow stages are not quality guarantees
Passing tests cannot prove acceptance criteria were sufficient. Automated review can miss a missing requirement. A dashboard cannot reveal failures it does not measure. The loop helps only when each stage preserves evidence for the next decision.
The gap between a saved checkpoint and observed state illustrates the same problem: recorded facts and received information can differ. Start with one task and identify the missing evidence between planning, verification and operation. Improving completion means designing the waiting stages too. No team productivity measurement or code execution was performed here.