Ball asks why anyone still uses pull requests

Thorsten Ball asked why anyone still uses pull requests and went through the usual answers one at a time. Code review? You can spawn Opus 5.5, Fable and Astra and have all three check four times each. Knowledge sharing? Models will generate explainer videos, presentations, walkthroughs or quizzes for any code they can reach. CI? He points out that continuous integration originally meant the opposite of long-lived branches, and that running the test suite in the agent's environment, then on a branch, then again on merge, does not make sense.

This extends the workflow he described earlier. Asked directly how work gets into the codebase, Ball said his team does trunk-based development and pushes to main. Everyone works in their own orb, the agent writes the code, runs the tests, provides proof and runs the application end to end inside that orb. For feedback they share an orb portal URL if there is something visual, tag a colleague in the orb thread, or split the change into small pieces behind a feature flag. They toggle flags on for themselves and might turn them off an hour later if someone complains.

The reply that reframed it

Benjamin Glickenhaus was the one who asked the question, and he was not satisfied by the answer. He said what the article was missing was how work in an orb gets merged so everyone else can use it, and how teammates arrive at consensus on the APIs and contracts for shared tooling. The richer interactive review Ball describes, he argued, sounds like a better PR review experience rather than something fundamentally different.

His own version of this is telling a teammate to have their agent build on top of a change and report what works, then folding that feedback back in. That, he said, points at the real gap.

It feels like we need a more continuous consensus protocol (whereas PRs are discrete moments of consensus building)

What PRs still buy

Matt Pocock listed three things he still gets from a pull request. Some changes are one way doors. A PR attaches richer context to why a change was made without bloating the repo. And it is useful for reviewing processes, not just code. He then noted that most of his PRs automerge anyway, which is roughly Ball's point arriving from the other direction.

Matt Pocock

@mattpocockuk

X

Some changes are one way doors

For working engineers, the argument on the table is not whether an agent can catch a bug a human would miss. Nobody in this thread disputed that. It is where a team settles on a shared interface when nobody is reading a diff, and none of the three had a mechanism for that yet.

Benjamin Glickenhaus

@benglickenhaus

X

It feels like we need a more continuous consensus protocol (whereas PRs are discrete moments of consensus building)