Two engineering leaders compare notes. One has doubled the number of changes his team produces. The other has shipped a feature he can defend to a regulator, a customer and his own board.

Both describe progress. Only one can say what the progress cost.

The asymmetry nobody budgets for

Agentic development moves one price dramatically. Producing a plausible change — a function, a test, a migration, a refactor — has become cheap, and it keeps getting cheaper.

It barely touches the second price. Being confident that a change is correct, safe and still wanted when it lands has not become cheaper at all. If anything, it rises, because there is more to review.

That gap is the whole decision. Not whether the tools work. Whether your organization can absorb what they produce.

What the vendors actually shipped

Two OpenAI posts from November 2, 2026 are worth reading together, because each addresses a different end of the same pipe.

The first describes Pando, a Git-compatible backend built for the scale of development that Codex makes possible. Read plainly, a vendor concluded that its own version control needed re-engineering because the volume of change had outgrown the tooling around it.

The second describes Qodo bringing company knowledge and coding standards into Codex, catching high-severity issues across repositories before a pull request opens. That is standards supplied as an input to the tool, rather than a document a reviewer is expected to recall at 6pm.

Both are company statements about the companies' own work. Neither includes a defect rate, a delivery metric or a customer outcome, and none is asserted here. What they show is where the friction is being felt by the people building the tools.

OpenAI's November 3 post on accelerating engineering for the physical world points the same pressure at CAD, PCB design and simulation — domains where a wrong answer is not a bad page load.

Vibe coding is a control posture, not a personality

The phrase gets used as an insult. It is more useful as a description.

Vibe coding, in the sense that matters to a buyer, means the change was produced without a written specification, without acceptance criteria, without bounded tool permissions, and without retained evidence of what was asked or what the agent inspected. The code may be excellent. The absence is procedural.

Agentic delivery means the same tools operating inside a defined envelope: a written intent, a stated definition of done, a bounded set of permissions, a review step with named authority, and a record that can be produced later.

The distinction is not effort or seniority. It is what exists before the agent starts and what survives after it stops.

Where review actually breaks

Four failure points recur, and only one of them is about model quality.

  • Diff volume. A reviewer facing four hundred lines reads them. Facing four thousand, they read the description and approve. The gate still exists; it stops gating.
  • Context gap. The agent worked from what it was given. The reviewer holds what was never written down — the legacy partner agreement, the deliberate inconsistency, the reason the odd branch exists.
  • Unencoded standards. If your conventions live in a senior engineer's head, an agent cannot consult them and a reviewer must enforce them manually on every pass.
  • Accountability blur. When an agent writes, tests and flags a change as ready, the human in the loop may not have read a line. That is a workflow design problem, not a discipline problem.

None of those are solved by a better model. All of them are solved, or not, by the process wrapped around it.

What authoritative guidance already says

Little of this is novel, which is the reassuring part.

GitHub's own guidance on Copilot agents states that these tools can inspect and change files, perform tasks and tests, and produce code changes and reviews — and that human review and security validation remain important. That is the vendor of the tool telling you where the responsibility sits.

OWASP's entry on excessive agency is blunter. Excessive functionality, permissions or autonomy can turn an unexpected or manipulated output into a damaging action. The recommended response is limited tool scope, downstream authorization, and human approval for high-impact actions.

NIST's Secure Software Development Framework, published in February 2022, recommends integrating secure practices across the development life cycle to reduce vulnerabilities and address root causes. It is guidance, not a certificate, and it promises no protection — but it describes the shape of a serious process, and agentic work does not exempt you from it.

For deployment, Microsoft's safe deployment guidance sets out controlled test environments, progressive exposure, health checks, the ability to halt a harmful rollout, and recovery mechanisms. None of that is specific to AI. All of it applies more often when change volume rises.

Six decision criteria

  • Specification before generation. Is there a written intent and a definition of done the change can be measured against, or only a prompt?
  • Permission envelope. What can the agent touch — repositories, environments, credentials — and is that enforced outside the prompt?
  • Evidence packet. For each change, can you retrieve what was asked, what was inspected and what ran?
  • Named reviewer authority. Who approves, against which version, and does that approval expire when the underlying code moves?
  • Encoded standards. Are your conventions available to the tool as an input, or stored in a person's memory?
  • Reversal. Can this change be backed out cleanly, and is the backout path exercised rather than assumed?

Three ways to deliver

Tools inside the existing process. Buy the assistants, keep the pipeline. Cheapest to start, and it inherits whatever your review discipline already was. If that discipline was thin, this amplifies it.

A delivery platform with gates. Evaluation thresholds, deployment approvals, policy checks and tracing wired into the same pipeline that already ships application code. More configuration and more platform dependency, but the gate is enforced by something other than good intentions.

A custom harness around your systems. Your repository layout, your standards, your environments and your records, engineered deliberately. Highest cost and slowest to stand up; the strongest fit when the work touches money, inventory or a customer commitment.

Most organizations should start with the first, measure honestly, and expect to outgrow it. The error is describing the first as if it were the third.

A 30-day pilot that produces a number

  • Days 1 to 5, pick one repository and one change class. Something routine enough that reviewers know what good looks like.
  • Days 6 to 12, write the spec first. Intent, acceptance criteria, and the standards the change must satisfy. If you cannot write it, that is the finding.
  • Days 13 to 22, run with evidence capture. Record prompts, inspected files, test runs and reviewer decisions for this change class only. Resist redesigning anything else.
  • Days 23 to 30, measure review, not generation. Time to first meaningful review, rework rate, and how often a reviewer found something the tool missed.

Four indicators worth baselining

Review latency: median hours from change ready to first substantive comment. Rework share: the proportion of agent-produced changes requiring a second pass. Escape rate: defects reaching a shared environment per hundred changes. Evidence coverage: the share of changes with a retrievable record of prompt, inspected files and test results.

Baseline all four before the pilot and again after. Those numbers are defensible. A vendor's throughput claim is a claim about someone else's repository.

What this means for the people doing the work

The productivity story is real but it relocates effort rather than deleting it.

Engineers move toward decomposition, direction, validation and architectural stewardship. That is a more senior job, not a smaller one, and it needs different measures. A team judged on lines of code will optimize for volume; a team judged on escaped defects and review latency will optimize for trust.

Which means the honest executive conversation is about hiring and retention as much as tooling. If your best people spend their day reviewing machine output with no time left to design, you have converted expertise into a bottleneck.

What remains unknown

  • No independent, peer-reviewed measurement of agentic delivery's effect on defect rates is cited here, because none was reviewed for this edition.
  • No standard exists for what an evidence packet must contain, so every implementation invents its own.
  • No published method prices the risk of a review that looked thorough and was not.
  • No market data was reviewed for this edition, so no stock movements are reported.

Evidence notes and limits

Pando, Qodo and the physical-world engineering post are OpenAI's own descriptions of its own work and partnerships, published November 2 and November 3, 2026. No defect reduction, delivery speed, adoption figure or customer outcome is drawn from them; the posts supply no such figures in the portions available.

GitHub's guidance is vendor documentation about that vendor's tool. OWASP's entry is a risk taxonomy, not a test result. NIST SP 800-218 is guidance and is not a certification. Microsoft's safe deployment guidance is a pattern description. None of the four measures whether any organization has implemented what it recommends.

The review-bottleneck framing, the four failure points, the criteria, the options, the pilot and the indicators are this publication's analysis and suggested method. They have not been validated as a protocol. The advertisement above is separate from this analysis and is not a source for any claim in it.