⚙️ The PR Approval Is Decaying. Your Change Management Control Hasn't Noticed.

Every change-management control you have ever attested rests on one artifact: a pull request with an approval on it. Reviewed by someone qualified, approved before merge, evidenced by a screenshot.

That artifact is decaying under your feet. Every cause of the decay is measurable; attention, the thing the artifact was a receipt for, is the one input that never shows up on a dashboard.

Your auditor will keep accepting PR-approval screenshots because your control definition still asks for them. The auditor is testing a stale spec you wrote. The screenshots don't change as the meaning drains out, and that is exactly what makes this failure mode dangerous: the evidence stays photogenic while the claim underneath it quietly dies.

In this issue:

• The velocity pattern, from engineering's own reporting

• Approval decay, itemized: what each artifact attested in 2020 vs 2026

• Why provenance is not the exit

• What "approved" needs to become: sensors and an owner

• The GRC move, in three layers

The velocity pattern

This is a pattern, not an anecdote, and every step below comes from engineering's own reporting: DX's Engineering Enablement research, GitHub's blog, Addy Osmani's agentic-review data, and named engineering leaders on the record.

Output jumped everywhere agents landed:

• Anthropic: per-engineer code output up 200% this year, with review as the new bottleneck (Boris Cherny, on X). Self-reported, as most numbers in this pattern are.

• Dropbox: AI adoption up from 30% to 100% of engineers in six months while PR throughput doubled, with leadership describing validation as becoming the constraint (DX podcast).

• Monzo, a regulated bank: PR volume up 10 to 20%, average PR size up another 20% (DX podcast).

• The longitudinal curves: DX's research shows PR sizes doubling in a year, and Cursor's Developer Habits Report has lines per developer up from 3,600 to 8,600 a week, PR sizes nearly tripling at the 75th percentile, and a sharp rise in changes accepted without human review from early 2026.

• OpenAI: one data-platform team's PR volume up 5 to 10x in the past year (Every's reporting); a single reported account, so hold it loosely, but the direction matches everything else on this list.

Review capacity did not double. So the system adjusted the only free variable: how much attention an approval represents.

One boundary before anyone generalises: METR measured experienced open-source developers moving slower with early-2025 AI tools. This pattern belongs to agent-era workflows at adopting organisations, not to every developer everywhere. If your engineers are not shipping this way yet, this issue is your head start, not your emergency.

Note the missing edge. The balancing loop that should exist there doesn't, because the feedback the system needs is precisely the signal the evidence format hides.

Approval decay, itemized

GitHub's own research on agentic pull requests found the trust asymmetry running the wrong way: agent-authored code carries more technical debt per change yet gets approved more readily, more than one in five reviews now involves an agent, and agents have been caught deleting failing tests to get CI green. GitHub's reviewer guidance now says to read the CI configuration diff before the code diff, because that is where the gaming hides. The verification layer is attack surface now.

The consequence case already exists, and it has two layers worth keeping apart. As reported, users discovered they could ask Meta's AI assistant to change the email address on accounts they did not own. What is independently verifiable is the breach filing with the Maine Attorney General (June 2026): 20,225 affected accounts. The characterisation that travelled with it, reported by Gergely Orosz on anonymous sourcing, is that the hole was AI-generated, AI-reviewed code merged with no human input, and that the integrity team learned about it from the press. The filing is verifiable; the characterisation is not, so weigh them accordingly.

But the compound reading survives either way: assurance capacity was being cut while change volume rose, and those are the same decision seen from opposite ends. If the characterisation is right, that is approval decay completing its arc: the ritual ran, the artifact existed, and nobody was inside the loop it evidenced.

Then the floor itself moves: GitHub shipped the ability to disable pull requests entirely, and platform features are lagging indicators of workflow shifts already underway. The artifact your control assumes is universal just became optional at the source.

And at the far end of the curve, the dark factory already ran. Ryan Lopopolo's three-person OpenAI team shipped a million lines across roughly 1,500 PRs with zero human pre-merge review, replaced by post-merge sampling and structural prevention of failure classes. It was an internal beta, so discount accordingly. You still cannot debate that it exists, which means "a human reviewed this before merge" is now a claim you have to prove.

That table is the screenshot. Take it into your next control design review and ask which column your evidence catalog is still living in.

Provenance is not the exit

The provenance row deserves its own section, because provenance is where everyone runs next. In May 2026, 633 malicious npm versions passed Sigstore provenance verification. In the TanStack attack, 84 malicious versions carried valid SLSA Build Level 3 attestations, provenance verified at the highest level the framework defines, malice intact. Origin proofs are necessary. As a safety claim, which is how most teams quietly use them, they are already defeated.

What "approved" needs to become

A quieter data point does more work than the dark factory. In Addy Osmani's four-reviewer parallel run, a single benchmark run, so treat it as a probe rather than a law, 93.4% of bugs were caught by exactly one of the four reviewers, near-zero overlap, and zero-review merges rose 31.3%. Each reviewer is a sensor seeing a different slice of the risk, and a single "approved" is one sensor's weak, partial claim.

Someone must own which sensors run, how their findings aggregate, and what threshold constitutes "reviewed." That someone is not the platform vendor, who can supply every sensor but cannot independently attest the semantics of its own approvals.

What that ownership looks like written down:

# review-policy: payments-service (tier 1)
sensors:
  required: [static-analysis, security-reviewer-agent, human-domain-owner]
  aggregation: all-must-pass           # not "any one approval"
human_review:
  trigger: always                      # tier 1; lower tiers gate on blast radius
  attests: "domainjudgmentapplied"   # written down, so it can be audited
agent_review:
  attests: "patternscanofdiff"      # a sensor claim, not a merge decision
evidence:
  emit: signed_decision_record         # what replaced the screenshot

That policy is an illustration, and every line of it answers a question your current control leaves implicit. The last line is the real migration: from screenshot to queryable decision record.

One honest constraint on the whole design: an attention budget that simply re-mandates human review relocates burnout onto your most careful reviewers, the exact people the vicious cycle already punishes. The budget has to redistribute review load, not just concentrate it.

The GRC move

The tempting move is to defend the PR ritual harder, and it is the wrong one: the ritual was always a proxy, and the theatre version of it scales beautifully under agents, which is the problem. At least one regulated bank is absorbing this shift right now, and the skills conversation already told you where to meet the engineers living it. The move has three layers:

• Re-inventory what each evidence artifact attests. Run the 2020 vs 2026 table against your own change-management control. Every row that moved is an assessment your control definition now owes.

• Define the sensor policy per control tier. Not every control belongs in the ICU; not every diff deserves a human. Budget attention where blast radius earns it, and write the budget down.

• Move the attestation upstream of the artifact. If the PR is optional and the screenshot is hollow, the control has to attach to the process that produces change, the harness, the policy, the decision record, and the context stream feeding both.

None of this means slowing the agents down; it means you stop attesting a claim nobody is making anymore.

The green checkmark was always a receipt for human attention. Attention is now budgeted, and part of it is supplied by machines, while the receipt format carries no field for either fact. Whose job is it to say what the new receipt means? Nobody owns that today. Next issue, I'll argue who should.

Before you go

If this issue was forwarded to you, you can subscribe at grcengineer.com. And if your change-management control still asks for the screenshot, reply and tell me what you would replace it with. I read everything.