Generated code is cheap.
Merged code isn't.
AI made generation abundant. It did not make review, verification, security, or ownership free — it moved the bottleneck there. This is a vendor-neutral method for putting agents into the delivery lifecycle without giving up the accountability that makes software shippable in a regulated organization.
More generation can create more work
Every adoption program that stalls, stalls in the same place. Output goes up, throughput doesn't, and nobody can explain the gap. The gap is this:
What gets measured
- Lines generated
- Suggestions accepted
- Agent sessions run
- Seats activated
All inputs. Every one of them can rise while delivery gets slower.
What actually moves
- Work that satisfied its acceptance criteria
- Work a human accepted responsibility for
- Work that passed the checks it had to pass
- Work the team can still maintain next quarter
One outcome. Everything above is a cost signal around it.
A large change can look productive while quietly moving effort onto reviewers. Several agents can look busy while exploring the same dead end. A cheap run is expensive if it produces a defect, an incident, or a second full cycle of work. The tension isn't humans versus AI. It's generated output versus completed outcomes.
The useful unit is not prompts, lines of code, or agent activity. It is completed software work with evidence of delivery, quality, security, adoption, and economic impact. The unit of value
Code output was never the differentiator
This is the argument underneath everything else on this page, and it is not a matter of opinion. The experiment already ran, at global scale, and the result is in.
What we measured, and why
For thirty years we measured developers by output, because output was scarce and it correlated with skill. It was a proxy. It worked well enough that nobody had to examine it.
What changed
AI removed the scarcity. Generation is now effectively free for everyone in the building — the strongest engineer and the weakest, on the same day, with the same tools.
And the good developers are still good.
That is the natural experiment. If volume of code were what made a strong engineer strong, equalizing volume would have equalized engineers. It did not. Which means the differentiator was always something else — judgment about what is worth building, taste about how it should fit the system, the discipline to prove it works, and the willingness to own it after it ships.
AI did not change what makes a developer good. It removed the proxy we were using to avoid measuring it.
None of this is a new principle
Working software over comprehensive documentation — 2001. The principle did not change. The cost of generation did, and that exposed how much of our measurement had quietly attached itself to the artifact instead of the outcome.
Delegate execution. Never delegate acceptance.
An agent may investigate, implement, test, document, and prepare a change — when the work it was given is a bounded contract. Direction, acceptance, and exception authority never leave the human. That boundary is what makes the rest safe.
An agent may
- Investigate the repository and existing behaviour
- Implement a bounded technical change
- Run the available checks and gather evidence
- Document what changed and why
- Prepare a change for human review
An agent must stop and surface a decision when
- Requirements conflict with each other
- Architecture boundaries are unclear
- A security exception would be required
- A required check cannot pass
- Completion would require widening scope
Instructions are not a control
Agent instructions guide behaviour. They are not authorization and they are not an enforcement boundary. Permissions, branch controls, required checks, and human review are the controls. Treat any instruction file as documentation that an agent is likely to follow — never as a gate you can prove held.
Tools do not decide accountability
Settle this before a single piece of work is delegated. Every row has a location and a named human decision — if either is blank, that row is where your first incident comes from.
| Responsibility | Where it lives | The human decision |
|---|---|---|
| Intent & outcome | Work item | Why this matters and what result is needed |
| Scope & acceptance | Work item | What is in bounds and how completion is judged |
| Architecture & risk | Work item, repo guidance, existing code | Which constraints apply and who may approve an exception |
| Implementation | Branch and change request | Delegable — human or agent may do bounded technical work |
| Evidence | Tests, CI, scanning, the change request | Whether the result satisfies the stated criteria |
| Approval | Review and protected merge | Whether the remaining risk is acceptable |
| Accountability | Assignee, owners, reviewers, merge history | Who owns the outcome and any exception |
Exactly one row is delegable. The other six are the reason the delegable one is safe.
Eight checks between intent and delegation
Most failed agent work is failed intake. The request never said what done meant, so nothing could be judged complete. Score a work item before you assign it — to a person or to an agent. The bar is the same.
Contract readiness
InteractiveEach check counts equally. This measures whether the contract names the outcome, the boundaries, the proof, and the accountable human — not whether the write-up is long.
Put judgment in code, not in a prompt
Anywhere a rule can be deterministic, make it deterministic. A pure function is testable, auditable, explainable to a regulator, and identical on every run — none of which is true of a model asked to classify the same thing. Save the model for the work that genuinely requires judgment.
Worked example — intake risk triage
Interactive// Pure, deterministic, unit-testable. Highest matching rule wins. function assessRisk({ category, monthlyCostUsd, handlesPii }) { const sensitive = handlesPii || category === 'data-access'; if (sensitive && monthlyCostUsd >= 500) return 'high'; if (monthlyCostUsd >= 2000) return 'high'; if (sensitive) return 'medium'; if (monthlyCostUsd >= 250) return 'medium'; return 'low'; }
Thirteen lines. It has no bad days, it produces the same answer under audit that it produced in production, and you can explain it to a compliance officer in one breath. That is the bar every rule should have to clear before a model gets the job.
Copying a config directory is not governance
This is the mistake that produces the most false confidence. Half your controls live in version control where you can see them. The other half live in platform settings where you can't — and a repository that looks governed while the second half is missing is more dangerous than one that looks ungoverned.
Versioned — visible in the repo
- Build, lint, typecheck, and test pipeline
- Static analysis and code scanning configuration
- Dependency update policy and grouping
- Review-ownership routing
- Intake and change-request templates
- Agent scope and boundary instructions
- Reproducible environment setup
Platform settings — invisible in the repo
- Change requests required before merge
- Required status checks, by exact name
- Required approving and owner reviews
- Required conversation resolution
- Force-push and branch-deletion restrictions
- Secret scanning and push protection
- Token permissions and environment approvals
Three failure modes worth naming
- Mismatched check names. Require a check whose name doesn't exactly match what CI reports and you block every merge in the repository. Confirm the real name from a live run first.
- Contradictory policy models. Pick one — legacy branch protection or centralized rulesets. Running both produces effective rules nobody can predict. Verify at the target branch.
- Admin bypass left on. Decide deliberately whether administrators follow the same merge path. If they don't, you need a separate, auditable emergency process — not an unlogged exception.
Bypassing must never be the default response to a failed control
Controls fail. The question is whether the failure produces a decision or a habit. Five steps, every time, no shortcuts — and an agent may prepare the evidence or the remediation proposal, but an agent never accepts the exception.
Record the failed control
Which control, and specifically why normal remediation isn't currently viable.
Name the approver and the risk owner
Two roles, named individuals. Not a team alias.
Define narrow scope and an expiry
An exception without an expiration condition is a permanent policy change you didn't vote on.
Preserve the decision where the work lives
In the work item or the change request. Not in chat, where it disappears.
Restore the control and verify the follow-up
The step everyone skips. Unverified follow-up is how exception age becomes your real risk metric.
Nine levers, changed one at a time
There is no permanently correct configuration. Model capability, context size, task shape, and check depth all move both the probability of useful completion and the total cost of getting there. Change one lever, measure, keep or revert.
Outcome & baseline
Define done, then measure your current state on one consistent work type before anything changes. Cost data without an outcome definition rewards cheap failure.
Task design
Shape work so it can be finished and judged. Unbounded tasks fail regardless of model.
Model & context
Match capability to uncertainty. Use as little context as possible and as much as required — every extra token is carried by every later turn.
Prompt contract
State the outcome, boundaries, and evidence up front. Correcting mid-run costs more than specifying up front.
Phased workflow
Research, plan, implement, verify. Phases create checkpoints where a wrong direction is cheap to stop.
Deterministic checks
Turn requirements into executable feedback. Anything a test can decide should never reach a reviewer.
Human review
Place judgment where it changes the outcome — architecture, risk, product fit. Not on formatting a linter already caught.
Evidence
Make quality and security visible on the change itself. A reviewer who has to go looking will eventually stop looking.
Cost signals
Observe spend without letting it become the target. Optimizing tokens while increasing rework is not an optimization.
Attention is not uniform across a long context. More input is not more understanding. Context & capability discipline
A balanced scorecard, not a single number
Collapsing delivery into one score always produces a metric someone can game. Segment by work type, complexity, and risk class — then pair completion signals against cost signals and read them together.
| Signal | What it tells you | How it gets gamed |
|---|---|---|
| Elapsed time & completion rate | Whether ready-to-merge work is actually converging | Splitting work into trivially completable slices |
| First-pass CI success | Whether the contract was clear before dispatch | Weakening the checks |
| Review rework | Real effort transferred onto reviewers | Approving without reading |
| Escaped defects & change failure | What your pipeline is not catching | Reclassifying incidents |
| Alert introduction & remediation time | Whether velocity is creating security debt | Suppressing rules |
| Exception age | Whether governance is real or ceremonial | Closing and reopening |
| Human review effort per item | Where the cost actually landed | Not tracking it at all |
Do not treat these as business outcomes
Code volume. Prompt count. Agent runs. Seat activation. Suggestion acceptance rate. These are inputs. Reporting them as impact is how an adoption program loses the room the first time an engineering leader asks what actually shipped.
Where this stops
This method covers work up to reviewed, scanned, tested, buildable software. A production system needs controls this does not address, and claiming them before they are implemented and verified is how adoption programs lose credibility permanently.
Not covered
- Deployment environments and approvals
- Artifact provenance and supply chain
Not covered
- Observability and rollback
- Incident response
Not covered
- Data protection in operation
- Operational ownership
Add them deliberately, in the order your risk profile demands. Do not claim a control until it is implemented and verified.