The Case Against the Pull Request: Pair, Push, and Move On

The standard industry workflow - feature branches, pull requests (PRs), and asynchronous reviews - is often treated as law. However, by embracing Trunk-Based Development paired with Pair Programming, the PR model can become an unnecessary bottleneck rather than a artificial quality gate.

Velocity and Context

The core philosophy is simple: Code review should happen during creation, not after completion.

• Zero Context Switching: In the PR model, a reviewer must stop their work, load a mental model of someone else's code, review it, and return to their task. This destroys flow. By having two developers on one ticket, the "review" happens in real-time.

• True Contextual Insight: An external reviewer often lacks the deep context of the specific problem being solved. They tend to catch syntax errors (which a linter could catch) rather than architectural flaws. A pair partner possesses the full context of why decisions were made.

• Eliminating the "Waiting Room": Feature branches often sit idle waiting for review. By pairing and pushing to main, code is integrated immediately. The perceived "loss" of manpower (2 devs on 1 PC) is regained by eliminating the idle time of queued code and merge conflicts.

A Foundation of Extreme Trust

Implementing this workflow is impossible without a culture of high trust. The Pull Request often functions not just as a code quality check, but as a mechanism of control - a lack of faith that an individual developer will do the right thing without supervision.

Removing that gate creates a requirement for high-agency teams:

• Trust Over Control: Developers must inherently trust their teammates to make responsible changes without an external "approver" checking every line. The safety net shifts from a gatekeeper to the pair actually writing the code.

• The Talent Bar: Because such a high level of trust and autonomy is placed on individual members, the recruitment process becomes critical. You cannot hand the keys to production to just anyone. Hiring must focus on acquiring not just skilled coders, but conscientious, high-ownership individuals - the "best and brightest" who understand the weight of pushing straight to main.

• Hiring for Collaboration: A brilliant "lone wolf" developer will destroy a pairing culture. Recruitment must heavily weigh collaborative skills, communication, and a willingness to share ownership of code. A bad hire in a PR controlled environment is slow; a bad hire in a trunk-based environment is dangerous.

The Risks

While high-velocity, this approach requires a mature engineering culture and robust tooling.

• Remote Friction: Effective pairing relies on low-latency interaction. Screen sharing heavy IDEs over Zoom or Teams often introduces input lag. This technological friction breaks the "driver/navigator" flow, making remote pairing significantly more frustrating than sitting side-by-side.

• The "Build Breaker" Anxiety: If you push straight to main, you must be certain you haven't broken the build. If the codebase has long compilation or test times, a broken main branch blocks the entire team until fixed.

• Exhaustion: Pair programming is mentally draining. It requires 100% focus and social interaction all day. Introverted developers may burn out quickly without "heads down" solo time.

• Compliance: In regulated industries (FinTech, MedTech), a formal Pull Request often serves as a necessary audit trail.

Mitigation Strategies

These risks are manageable with specific protocols and tooling choices.

• Hybrid Protocols

  • If the team is hybrid, schedule pairing sessions specifically for office days where latency is zero and communication is fluid.

  • For remote days, move beyond standard screen sharing. Use specialised tools (like Tuple or IDE-specific live share plugins) that allow two developers to type in the same environment without video lag.

• Feature Flags

  • Wrapping new logic in Feature Flags allows you to push "unfinished" code to main safely. If the code causes an issue, the flag can be disabled remotely without a hot fix or rollback.

  • Pre-push hooks can run unit tests and basic linting locally before the code ever leaves the developer's machine.

• Supporting Introverts

  • Don't mandate 100% pairing. Allow developers to write code independently for defined blocks of time.

  • Instead of a formal async PR, the pair partner joins for a 15-minute "shoulder check" review before the code is merged. This maintains the velocity of trunk-based development while giving developers the quiet time they need to think deeply.

• Compliance Complexities

  • The goal of compliance is usually to prove Segregation of Duties (no single person can deploy code unilaterally) and Traceability. You can satisfy these without a slow, asynchronous PR process.

  • The "Co-authored-by" Trailer (Digital Proof)

    • Most compliance auditors accept cryptographic proof that two people worked on the code.

    • Configure your git commits to include a Co-authored-by: trailer in the commit message. GitHub, GitLab, and Bitbucket automatically parse this and attribute the commit to both developers. This creates an immutable audit trail proving that two unique accounts authorised the change at the moment of creation.

  • The "Instant" PR (The Artefact Compromise):

    • If your tooling hard requires a Pull Request object for the audit log, create a PR but merge it immediately.

    • Pair on the code → Push to a branch → Open PR → Pair partner clicks "Approve" immediately (because they just wrote it with you) → Merge.

    • This generates the required bureaucratic artefact (the PR link) without the asynchronous wait time.

Conclusion

Pushing straight to main shifts the focus from gatekeeping to collaboration. It requires trust, excellent automated testing, and low-latency collaboration tools, but it removes the single biggest drag on development velocity: the wait.