The Merge Request as {Friction, Leverage}

The merge request is one of those things that’s so embedded in how software gets built that it’s easy to forget it’s a design choice, not a law of nature. For decades it has been the dominant mechanism for forcing context-sharing among people building complex systems together. Not just code review in the narrow sense of “does this work” but the broader function: when you open an MR, you’re asking another human to reconstruct the reasoning behind a change, internalize it, and either confirm or challenge that reasoning. The diff is the artifact. The shared understanding is the product.

This is worth stating explicitly because much of the conversation about AI and code review treats the MR as a quality gate, a bottleneck to be optimized away. That framing misses what’s actually at stake. The MR is how teams build and maintain a shared mental model of what they’re constructing together. It’s knowledge transfer disguised as a review process. Junior developers learn architectural patterns by reviewing senior work. Senior developers catch conceptual misunderstandings early. The entire team develops a collective sense of how the system behaves and why it’s shaped the way it is. Over time, the MR history itself becomes a record of patterns for how changes and concepts are realized, the lore behind a system’s construction. That lore is part of what makes a codebase legible to the people who maintain it.

I’ve been building an AI harness over the past few months and watching my own pace of production increase dramatically. In taking inventory of what skills still matter, I kept circling back to the same observation: the ability to describe desired system state clearly enough that repeated implementations converge is becoming the core skill. But that formulation assumes someone (or something) is verifying convergence. Right now, that verification largely happens through merge requests, and the system is showing strain.

The data on that strain

The numbers are interesting. A LinearB study of one million pull requests across roughly 25,000 developers found that PR review pickups are the single largest bottleneck in cycle time, with average PRs taking five days to merge. AI-assisted development appears to be intensifying the pressure, not relieving it. Jellyfish data shows PRs growing roughly 18% larger as AI adoption increases. Faros AI telemetry reports a 154% increase in PR size alongside a 98% increase in raw code output. Google’s 2025 DORA Report found a 91% increase in code review time correlated with 90% AI adoption growth. A September 2025 research roadmap from Hassan et al. found that over 68% of agent-generated PRs face long delays or remain entirely unreviewed.

The cognitive load problem underneath these numbers resonates with my own experience. When I write code myself, I’m externalizing a mental model I already hold. Reviewing someone else’s code requires reconstructing that model from scratch, which is harder. Reviewing AI-generated code is harder still, because there’s no other human whose reasoning I can trace. SonarQube metrics show cognitive complexity increasing 39% in agent-assisted repositories. The Stack Overflow 2025 survey reflects something similar: only 29% of developers trust AI accuracy (down from above 40%), and 45% say debugging AI code takes longer than writing it themselves.

When the pace of building increases, the builders get overwhelmed if their concentration is still fixed at the level of individual diffs. Where there’s that much friction, there’s usually that much leverage. The amount of creative and productive energy locked up in review bottlenecks is striking, and a lot of people are exploring how to unlock it.

What the artifact becomes

The most interesting development isn’t better code review tooling (though there’s plenty of that). It’s a deeper question about whether code is the right artifact to review at all.

Spec-driven development is the umbrella term for an emerging set of practices where humans write specifications and AI generates code to match. ThoughtWorks identifies three maturity levels: spec-first (specs guide development, code is still truth), spec-anchored (specs serve as validation contracts checked at CI time), and spec-as-source (specifications are the maintained artifact, code is derived). The progression is from “specs help” to “specs are the system.”

Several companies are exploring different bets on what replaces code as the artifact of record. Entire, founded by former GitHub CEO Thomas Dohmke, stores prompts, constraints, decisions, and execution traces alongside each commit in a git-compatible database. Their open-source CLI captures agent reasoning on an append-only branch. Tessl, founded by Guy Podjarny (previously Snyk), goes further: their Spec Registry contains 10,000+ specifications, and their thesis is that natural language specifications should be the primary maintained artifact with code generated to match. Kilo Code, founded by former GitLab CEO Sid Sijbrandij, takes an agent-session-first approach where the orchestration between multiple AI modes (Architect, Code, Debug, Review) becomes the unit of work.

These are three different explorations of the same question: if builders can’t keep up with reading every diff, what should they be spending their attention on instead? Reasoning traces. Specifications. Agent sessions. All three attempt to shift the unit of human attention from “lines of code changed” to “intent and reasoning behind the change.”

I’ve been exploring a version of this problem at a smaller scale. My AI harness uses AGENTS.md files and structured workflows as the primary context artifacts for agent sessions, and once those artifacts started mattering more than the code they produced, I wanted to understand their properties over time. Harness explorer is a tool I built to do static analysis on instruction files: measuring redundancy, detecting contradictions, scoring information density, tracking drift across edits. The idea is that if the harness is the artifact of record, it needs the same kind of measured, iterative quality improvement that codebases get through review. Experiential insight at measured intervals, not just vibes about whether the instructions feel right.

The verification gap

If code becomes a derived artifact, something generated from specs or agent sessions, then the question of how you verify it becomes central. This is where formal verification enters the conversation.

Martin Kleppmann articulated the thesis clearly in December 2025: AI will make formal verification go mainstream, because LLMs simultaneously make proofs cheaper to write and make verification more necessary. The economics have historically been prohibitive. The verified seL4 microkernel required 20 person-years and 200,000 lines of Isabelle proof for 8,700 lines of C code. That’s a ratio that only makes sense for the most safety-critical systems.

Those economics are shifting. A September 2025 paper from the Beneficial AI Foundation (co-authored by Max Tegmark) coined the term “vericoding” for LLM generation of formally verified code from formal specifications, explicitly contrasting it with “vibe coding.” Their benchmark achieved 82% success rates in Dafny, 44% in Verus/Rust, and 27% in Lean. A multi-model approach combining Claude and GPT models generated correct verification annotations for 98.2% of 110 programs within eight repair iterations. These are benchmark numbers, not production results, and it’s unclear how they translate to real codebases with messy dependencies and underspecified requirements. But they’re high enough to make the question interesting: at what point does the cost of writing formal specs drop below the cost of reviewing AI-generated code by hand?

Property-based testing sits at a lighter weight on the same spectrum. Amazon’s Kiro IDE (launched July 2025) automatically translates natural language specifications into executable properties and reports finding three times more bugs in AI code compared to traditional example-based tests. A June 2025 paper on property-generated solvers showed 23-37% relative gains in pass@1 over established TDD methods by using separate Generator and Tester agents, breaking what the authors call “the cycle of self-deception” where tests share flaws with the code they validate. That phrase is worth sitting with: when the same model writes both the code and the tests, it can be wrong in the same way twice.

The practical verification stack emerging in industry has layers: IDE-level real-time feedback (Cursor, Copilot), PR-level automation (CodeRabbit, Graphite Diamond, Qodo), cross-codebase architectural analysis (Greptile), and formal verification for high-stakes code. A tiered model is converging across multiple independent sources: fully automated checks at the bottom (linting, security scanning, coverage), AI-augmented human review in the middle (summaries, risk highlights, suggested tests), and human expert review at the top (architecture, business logic, long-term maintainability). The interesting implication is that the human role shifts from reviewing all code to focusing on the changes that actually need human judgment.

The thing I keep returning to is that even with all of this, the translation from specification to code is still stochastic. Formal verification can prove that generated code satisfies a formal spec. Property-based testing can check that code satisfies properties derived from a natural language spec. But the spec itself is an expression of intent written in imprecise language, and the generation process is probabilistic. Verification is checking probabilistic output against deterministic intent, and I genuinely don’t know how that gap closes. The seL4 proof works because the spec is mathematical. Most software specs aren’t, and the interesting question is whether they can be made precise enough for formal methods without losing the flexibility that makes natural language useful for describing intent in the first place.

I find myself wanting this to work. The idea that we could build faster and verify more rigorously at the same time is compelling. But I don’t yet see how we get from benchmark results on isolated programs to the messy reality of evolving systems with ambiguous requirements and shifting business context. That’s the gap I’m watching most closely.

The people who built the forges

There’s a pattern worth noticing. Within roughly twelve months, three former CEOs of major DevOps-adjacent platforms each started exploring this space.

Dohmke, after nearly four years leading GitHub, launched Entire in February 2026. Sijbrandij, who stepped away from GitLab in late 2024 to focus on cancer treatment, became involved with Kilo Code in 2025. Podjarny, who built Snyk into a major security platform, started Tessl. None of this signals something wrong with the platforms they built. These are people with uncommon depth of experience in developer workflows choosing to explore what comes next, and attracting significant funding to do it.

Meanwhile, Cursor (Anysphere) acquired Graphite, merging code generation and code review into a single platform. CodeRabbit is building pure-play AI code review. ICSE 2025 dedicated nearly a third of its 436 paper presentations to AI for software engineering. There’s a lot of energy converging on the idea that how we share context about code changes is ready to evolve.

These aren’t people speculating from the outside. They spent years inside the forge platforms, understanding what the MR workflow does well and where it runs into limits. That all three are independently exploring adjacent spaces is worth paying attention to, not as a verdict on what exists, but as a signal about where experienced builders think the interesting problems are.

I keep thinking about my own transition from Phabricator-style patch workflows to the forge model that GitHub and GitLab popularized. That shift didn’t eliminate peer review. It reduced the friction of modeling work for peer review until the practice became nearly universal. Patch-by-email had all the same goals (shared context, quality, knowledge transfer) but the mechanics were painful enough that many teams didn’t bother. The forge platforms made it easy enough that code review became a default expectation rather than an aspirational practice. Every time that kind of friction drops, people build more and share more of what they’re building.

If that’s the pattern, the question isn’t whether the merge request disappears. It’s what the next reduction in friction looks like, and what becomes possible for builders as a result. Maybe it’s specs reviewed instead of diffs. Maybe it’s agent reasoning traces becoming as natural to read as a commit message. Maybe it’s verification layers that handle enough of the mechanical review that humans can focus on the conceptual questions they’re actually good at. I genuinely don’t know. The probabilistic gap between intent and implementation is real, and it may resist closing longer than anyone expects. But the people exploring these ideas have earned the benefit of curiosity, if not yet conviction.

Things I’m watching

What	The question it might answer
Entire CLI adoption	Does storing agent reasoning alongside commits change how people review code, or does it just add noise?
Tessl Spec Registry growth	Can natural language specs get precise enough to be the maintained artifact, or do they drift from reality the way documentation always has?
Kilo Code Slack-to-PR workflow	What happens when the boundary between conversation and code change dissolves? Does quality hold?
Formal verification benchmarks on real codebases	The Dafny/Lean numbers are promising on isolated programs. Do they survive contact with legacy code and ambiguous requirements?
Property-based testing as default practice	If separate Generator and Tester agents break “the cycle of self-deception,” does PBT become the new linting, something every CI pipeline runs without thinking?
Tiered review adoption at scale	Does routing human attention to escalated reviews actually reduce cognitive load, or does it just concentrate the hardest problems on the fewest people?
DORA metrics under AI-heavy workflows	The 2025 report showed review time increasing with AI adoption. Does that curve bend as teams adapt, or does it steepen?
Harness quality as a discipline	My own [[harness-explorer