Opening
Pull requests used to transfer understanding. Under AI-scale code generation, they increasingly transfer risk.
This article is about how that happened.
For years, the software industry treated the pull request as a workflow object — a diff, a review thread, a merge button, a place where code was inspected before entering the shared system. That description was never wrong. It was just incomplete.
A pull request was not merely a mechanism for checking code. It was a mechanism for converting private reasoning into shared responsibility.
When a developer opened a pull request, they were implicitly saying: I understand this change. I know why it exists. I can explain the tradeoffs. If this breaks in six months, I will not disappear when someone asks why this was written this way.
When a reviewer approved it, they were implicitly saying: I am not just approving syntax. I am accepting the judgment behind this change into a system other people will now have to maintain, debug, secure, and extend.
The pull request was therefore never just a technical tool. It was a social contract around understanding.
And that contract worked — not perfectly, but well enough — as long as the cost of producing code and the cost of understanding code were roughly aligned. Writing code took effort. Structuring a change took time. Opening a pull request usually meant the author had already invested enough thinking that the reviewer was evaluating finished reasoning rather than unfinished guesses.
AI changed that balance.
It made it dramatically cheaper to produce code-like artifacts, but it did not make it equally cheaper to produce shared understanding around them. The result is not simply faster development. The result is that more pull requests now arrive carrying code whose production cost has fallen faster than its comprehension cost.
That is why the pull request is quietly changing roles.
It used to be a mechanism for transferring understanding. Increasingly, it is becoming a mechanism for transferring risk.
Everything else in this article follows from that shift.
What Pull Requests Were Actually For
Pull requests were never primarily about catching syntax errors. Compilers do that better. They were never primarily about style enforcement. Linters do that better. They were never even primarily about tests. CI systems do that better.
Pull requests existed to answer a different question:
Should this decision become part of the system?
A pull request review was historically a review of judgment, not just implementation. Reviewers asked questions like:
- Does this belong in this system?
- Is this the right abstraction?
- What breaks if this assumption changes?
- Does this introduce hidden coupling?
- Will someone understand this in a year?
These are not syntax questions. They are system questions.
Pull requests worked because code carried the author's reasoning with it. The reviewer was not reconstructing intent from scratch; they were validating intent that already existed.
The process only works if understanding travels with the code.
AI Changed the Economics of Code
AI did not just make coding faster. It changed the cost structure of software development.
- Producing code became cheaper.
- Producing explanations did not become equally cheaper.
- Producing architectural judgment did not become cheaper.
- Understanding large changes did not become cheaper.
So the bottleneck moved.
The slowest step in software development used to be writing code. Increasingly, the slowest step is understanding code.
When generation becomes cheap but understanding remains expensive, systems accumulate code faster than they accumulate understanding.
This is the core asymmetry introduced by AI-assisted development.
And pull requests sit exactly at the boundary where code production meets shared responsibility.
So the pull request absorbs the asymmetry.
Why Surface Signals Fool Review
AI-generated code often looks correct before it is understood.
It compiles. It passes tests. It follows style conventions. Variable names look reasonable. The structure resembles patterns the team already uses.
These are surface signals. They are visible and easy to evaluate.
But many real software failures do not come from syntax errors or obvious logic mistakes. They come from deeper system issues:
- Hidden state coupling
- Incorrect assumptions about invariants
- Performance complexity explosions
- Concurrency issues
- Security boundary violations
- Incorrect abstractions that become impossible to change later
These are not visible in a diff unless the reviewer reconstructs the reasoning behind the change.
If the reviewer does not have access to that reasoning, they are not reviewing a decision. They are reviewing an artifact.
And artifacts are much easier to approve than decisions.
The Pull Request Becomes a Risk Transfer Mechanism
When a pull request no longer reliably transfers understanding, it starts transferring something else: responsibility without full context.
The author says the model suggested it. The reviewer sees that tests pass. The change is merged. Months later, a production issue appears, and the question is no longer who wrote the code, but who owns the decision that produced it.
If no one can explain why the code exists in its current form, ownership has already failed.
The pull request has then functioned not as a knowledge transfer mechanism but as a risk transfer mechanism — moving long-term system risk from the moment of creation to the future maintainer.
And once risk is transferred this way, the next question is unavoidable: where did the missing reasoning go?
AI systems are very good at filling gaps. When they do not know something, they do not stop. They produce plausible code based on patterns they have seen before.
This creates what can be called the Wall of Missing Information.
On one side of the wall is the code that exists. On the other side are the things the model did not know:
- Business constraints
- Security assumptions
- Performance requirements
- Edge cases not in training data
- Historical reasons certain patterns exist
- Previous failures that shaped the current architecture
The dangerous part is that the generated code does not look incomplete. It looks finished. The absence of information is hidden behind plausibility.
A gate only works if uncertainty remains legible.
If a pull request process cannot distinguish between what is known, what is assumed, and what is unknown, then review becomes approval of plausibility rather than evaluation of understanding.
Code Archaeology
When code is written without durable reasoning attached to it, maintenance turns into archaeology.
Developers encounter a piece of code that works but whose purpose is unclear. Comments are minimal. The original author may have left. The change history shows a pull request, but the reasoning is not documented in a way that explains the decision.
So developers start reverse-engineering intent from behavior. They run experiments. They search old tickets. They try to infer why something was written the way it was.
This is software archaeology: reconstructing decisions from artifacts instead of reading the decisions themselves.
AI-assisted development risks increasing the amount of code that arrives in systems without durable reasoning attached to it, which means future developers spend more time excavating intent rather than extending systems.
And o## What Governance Actually Requiresad of architectural mistakes that look reasonable enough to pass review.
The assembly begins to train on the assembly.
What Governance Actually Requires
If pull requests are increasingly transferring risk rather than understanding, the solution is not simply stricter reviews or better tests. The solution is governance — systems that preserve reasoning, uncertainty, ownership, and traceability.
Each governance requirement exists to close a specific failure mode described earlier.
1. Pull requests must explain why the change exists, not just what changed.
This addresses the surface-signal problem. Code that compiles and passes tests can still be architecturally wrong. Requiring reasoning forces the review to evaluate decisions, not just artifacts.
2. Unknowns and assumptions must be explicitly documented.
This directly addresses the Wall of Missing Information. AI often hides missing context behind plausible code. Declaring unknowns keeps uncertainty visible so review can evaluate risk instead of plausibility.
3. Architectural decisions must have clear ownership.
This addresses risk transfer. If a change alters system behavior, someone must own the decision, not just the diff. Ownership ensures responsibility does not disappear after merge.
4. Decisions, discussions, and code must be traceable to each other.
This addresses code archaeology. When reasoning disappears, future developers reverse‑engineer intent from behavior. Traceability preserves the decision so future engineers do not have to excavate it.
5. Review must evaluate system impact, not just diff correctness.
This addresses hidden system failures — performance, coupling, security boundaries, and long‑term maintainability — which are rarely visible from the diff alone.
Traceability is the minimum requirement for ownership.
If no one can trace why a piece of code exists, then no one truly owns that code, regardless of who merged the pull request.
Conclusion
Pull requests were designed for a world where merging code meant merging understanding.
AI made it possible to merge code without merging th