The Governance Barbell: Run Projects Like Pull Requests

How AI coding’s heavy-plan, light-inspection, heavy-verify pattern becomes a Project Review Build — freeze intent, shift the layer, replay history, and keep multi-lens disagreement instead of one green light.

Scott Farrell · LeverageAI · Capital-project governance for regulated organisations

The middle is where control goes to die

Ask a senior leader how they “control” a capital project and you will hear a familiar answer: more packs, more dashboards, more line-by-line inspection of the artefacts the project team already produced. That is governance as reading. It burns the scarcest resource — senior attention — in the one place it changes outcomes least.

Software engineering under AI has been forced to relearn where review effort belongs. The emerging pattern is not “AI writes code, then a senior carefully reads every line.” It is a barbell:

Heavy thought before implementation. Cheap implementation in the middle. Heavy verification after.

Seniors never read every line of junior code in the old world either. They looked for design fit, weak test coverage, and whether the story was still the story they asked for. Treating AI as a junior who must be line-audited is a regression. Treating project delivery the same way — drowning sponsors in exhaust — is the same regression with bigger stakes.

This article ports that barbell into project governance. Call the operating model a Project Review Build, or simply a Project PR. The project team still authors through existing process. Existing authority still merges. AI reviews beside the path — as design critic at the front, and as multi-lens adversarial reviewer at the end — never as the designer of record or the approver of record.

What software already proved

Modern AI coding tools have shifted effort into plan mode: inspect the environment, compare patterns, define constraints and tests before touching implementation. Anthropic’s Claude Code exposes plan mode as a permission mode, not merely a prompting suggestion.¹ Early bake-offs and smoke tests now happen inside the design conversation because they are cheap. On the far side, verification has thickened: unit and integration tests still matter, but so do browser-level checks, intent-aware harnesses, and independent review agents that look for what the authoring model optimised away.

Tools such as CodeRabbit combine multiple models with static analysis, security scanners, repository-wide context and CI results.² Greptile builds a graph of the whole repository so consequences outside the changed files become visible.³ GitHub’s Copilot code review gathers context and comments on risk — and explicitly does not count as formal approval or block the merge.⁴ That last point is the architecture we want for projects:

Authoring systems — human teams and the AIs that help them write reports — optimise for completion and green. Adversarial review asks a different question: where was minimum compliant completion not sufficient? That is why verification should consume more cognition than reporting, and why independent lenses must not be copies of the same model voting on the same prompt.

The software-to-project mapping

Once you see the mapping, the barbell stops being a metaphor and becomes a work design: invest where AI made the expensive ends cheap, and stop pretending senior humans can read the organisational equivalent of every code line.

Left plate: design intensity

Tight Intent, Loose Method

Without explicit permission, AI interprets “plan this feature” as “work out how to implement the mechanism I specified.” It becomes a highly articulate order-taker. The upgrade is a different contract:

Preserve my intent, but treat my proposed design as only one candidate. Generate alternatives, move the intervention point if useful, include simpler and no-build options, and test them against available evidence before recommending an implementation.

That is Tight Intent, Loose Method. Hold purpose constant. Explicitly permit challenge to mechanism, timing, and layer. A reusable clause for every serious design-review brief:

Do not merely plan my proposed implementation. Preserve the underlying intent, independently challenge the mechanism and intervention point, generate materially different alternatives, and use existing evidence to smoke-test them before proposing implementation.

Intent-Preserving Layer Shift

I asked AI to challenge a design I thought was interesting: intervene at the very start of a search process. It smoke-tested the idea against existing user walk-path logs and found only a marginal improvement. Then it kept the same intent and the same conceptual idea, moved the intervention halfway through the search — where more context exists — and used the idea to augment results rather than assist the initial algorithm. Replayed against golden walk paths, measured coverage moved from 13% to 83%. No production assets built. No code changed. The valuable idea was not rejected; it was repositioned.

That move deserves a name: Intent-Preserving Layer Shift. Ask: is this the right idea at the wrong layer? Should it improve the input, guide the process, or augment the output? Does the idea need more information than exists at its proposed intervention point? Is a downstream augmentation stronger than an upstream replacement?

Counterfactual Design Replay

The second capability is Counterfactual Design Replay: before building, run proposed designs against historical traces that approximate how the future system would behave — golden journeys, production logs, failed sessions, community complaints, variation sequences, prior approval pathways, workforce patterns. The question is not perfect prediction. It is:

Had this proposed mechanism existed during these historical situations, what would it have seen, changed, missed, or made worse?

Traditional design: need → preferred design → business case → approval → implementation → discover consequences. The AI-supported loop inserts bake-offs and replay while change is still cheap. This is kinship with Cognitive Time Travel — compress, parallelise, prefetch, and simulate candidate futures before humans commit — without re-deriving that framework here. Real data is the tether: generate → replay → measure → compare → human judge. Not generate → admire → approve.

For a transmission network service provider or any capital-intensive operator, the replay corpus is not only software logs. It is completed contested projects turned into labelled test suites: decisions, variations, contractor correspondence, community outcomes, formal status versus later reality. The old project paid the tuition; the new one should receive the crash report before kickoff.

Design bake-offs before commitments harden: for a system-strength package, independent explorations of synchronous-condenser-heavy design, grid-forming battery-heavy design, staged hybrid, greater use of existing generation support, changed sequencing under retirement uncertainty — each tested through technical, procurement, regulatory, workforce and community lenses while options are still cheap.

The middle: stop reading every line

If a project has clear intent, a well-reviewed design, explicit constraints, strong acceptance criteria, complete evidence capture, and independent review mechanisms, senior management does not need to manually read every email, meeting note, or work product. AI can read the organisational equivalent of every code line. Humans concentrate on whether the design was sound, whether intent was preserved, whether tests were comprehensive, where evidence was weak, where exceptions accumulated, and what independent reviewers disagreed about.

That is not negligence. It is the same attention economy seniors already use in software — finally admitted for projects.

Right plate: verification intensity

Two classes of check

Deterministic alone fails by being gamed or by measuring only what was defined. Judgement alone fails by being soft, correlated, or unfalsifiable. Together: AI sees messy reality; deterministic machinery ensures required checks cannot quietly disappear. That split — models as fact factories, deterministic code as evaluator — is the architecture of proof we have argued elsewhere for decisions that carry their own receipts.⁵

Independent lenses, not one general AI

Delivery, technical, regulatory, workforce, community, consumer, operational, adversarial — each asks where minimum compliant completion was insufficient. Scale effort by criticality: lightweight for routine milestones; full adversarial build for irreversible commitments and regulatory submissions. Do not let correlated judges create the appearance of consensus. Agreement among copies of the same prompt is an echo, not verification.

Preserve the disagreement

A conventional dashboard would average every lens into another overall traffic light and recreate the information loss you were trying to fix. Instead keep a multi-lens status line:

The project is still formally green. It is no longer falsely green in every meaningful dimension. Make Green — Under-Represented a formal state: the control passed; soft-data review found a material concern outside the control’s present representation; management should investigate, expand the model, or explicitly accept the uncovered risk. Workforce signals of green-by-heroics — reserve margin collapsing under the dashboard — belong in that amber column, not in a single forced recolour of formal status.⁶

Intent regression testing

Do not only test “was consultation conducted?” Also test whether the affected community appeared to understand the proposal and see commitments reflected in later delivery. Do not only test “was the engineering review completed?” Also test whether it exposed meaningful alternatives and failure modes or merely certified the selected implementation. The project may pass every local test while regressing against its original purpose. Completed projects become labelled test suites for future ones — the harness that makes replay possible.

The Project Review Build loop

1. Freeze the intent — purpose, constraints, promises, acceptance criteria.
2. Explore alternatives — cheap early bake-offs under Tight Intent, Loose Method.
3. Record rejections — why other approaches lost and what would reopen them (visible rejection is how discovery earns trust).
4. Run the project — existing governance remains authoritative.
5. Create the formal report — the team’s declared state.
6. Build the soft review — AI reads the period’s accessible project exhaust.
7. Run deterministic checks — completeness, thresholds, approvals, hard-data consistency.
8. Run independent lenses — delivery, technical, regulator, workforce, community, consumer, adversarial.
9. Preserve lens disagreement — never average into one new traffic light.
10. Ship the review package — findings, exhibits, counter-cases, missing evidence emit into a parallel assurance plane rather than rewriting formal status.⁷
11. Human disposition — accept, reject, investigate, resource, redesign, or monitor.
12. File it back — findings become typed derived project knowledge.
13. Re-run incrementally — focus the next build on what changed, as code-review systems focus on new commits.⁸

Walk one contested milestone through that loop and you have not bought a chatbot project manager. You have installed an operating model: design intensity on the left, verification intensity on the right, and a middle that finally stops pretending that reading everything is the same as governing.

What this is not

It is not “use code-review bots on project PDFs.” It is not AI selecting the binding design, changing formal status, committing expenditure, or sitting on the operational hot path. The Lane Doctrine still applies: batch the review, ship the artefacts, let existing governance decide.⁹ Sensor taxonomies for how organisational soft data announces failure, static-analysis rules for institutional defects, and the continuous organisation-wide review plane are companion work — the Institutional Linter, Institutional Failure Radar, and Elastic Assurance pieces develop those layers.¹⁰¹¹⁷ Retrieval internals that make multi-angle investigation cheap are the subject of a forthcoming Intent Compiler treatment; they are out of scope here. The Cognition Scarcity Audit will ask where senior attention should be rationed next — this barbell is already an answer about where on the project timeline that attention belongs.

The deeper shift

The lesson from AI coding is not a tooling purchase. It is a relocation of human effort: away from inspecting every unit of implementation, toward specifying intent, designing the test harness, selecting independent reviewers, and judging unresolved disagreements.

Preserve the intent. Vary the implementation layer. Replay before commitment.

And at the end of the period, refuse the false comfort of a single light. The most valuable output may be: Formally Green. Community Yellow. Workforce Amber. Technical Green. Assurance Coverage Yellow. Not because AI overturned the project status — because it finally prevented one green light from pretending to represent the entire organisation.