The PR as the New Unit of Work

There's a scene in every heist movie where the crew splits up. Danny Ocean stands at the whiteboard, assigns the roles, draws the arrows, and says something confident and understated about meeting at the rendezvous point. Then the screen splits into four frames — the safecracker, the driver, the inside man, the distraction — all running their parts in parallel while Ocean watches from a quiet, elevated chair, sipping something expensive.

Nobody in the audience is worried about Danny. He's not doing the work anymore. He's managing what comes back.

That's the shift. And GitHub just built the inbox for it.¹

What GitHub Actually Announced

In late March 2026, GitHub released a redesigned pull requests dashboard in public preview. If you're not a developer, a pull request is a proposal — a packet of finished work that says "here's what I did, review it and approve it before it goes live." It's been the basic unit of software collaboration for years: someone writes code, packages it up, submits it for review. A human on the other end reads it, checks for problems, and clicks the green button.^{2, 3, 1}

The old dashboard showed you a simple list. The new one looks like an email inbox. There's a section for things that need your review, a section for things that need fixing, and a section for work that's ready to merge — ready to go live. Saved views, advanced filters, and triage tools round it out.^{3, 4, 1}

GitHub didn't build a better code review screen. They built a management console.¹

GitHub didn't redesign the pull request page. They redesigned it into an inbox. That tells you everything about where the volume is headed.

Why an Inbox?

You build an inbox when the volume of incoming work exceeds a person's ability to scroll through a list. Email got an inbox because humans started receiving more messages than they could hold in their heads. GitHub pull requests are getting an inbox for the same reason: there are now enough concurrent PRs that people need tools to prioritize what needs attention.^{3, 1}

The volume is exploding. And it's not because developers suddenly started typing faster.

AI coding agents — GitHub's own Copilot, Anthropic's Claude Code, Cursor, and a growing fleet of others — are generating finished work at machine speed. One person can spin up a handful of agents, point each one at a different task, and walk away. The agents research, write code, test it, and submit pull requests when they're done. Each one comes back like a crew member returning from their part of the heist, dropping a manila folder on the desk: here's what I got, boss.^{5, 6, 7}

The small, telling detail in GitHub's announcement: the "Authored by me" filter now explicitly includes pull requests created by Copilot on the user's behalf. Not a separate category. Not an "AI-generated" label tucked in a corner. Your agent's work is your work, folded into your stream, indistinguishable from the rest by design.^{3, 1}

GitHub isn't treating AI-authored code as something novel. They're treating it as the new normal, and they're building infrastructure to help humans keep up with the pace.^{6, 1}

The Bottleneck Flipped

For most of the history of software, the hard part was doing the work. Writing the code. Building the feature. Fixing the bug. The review process was a quick checkpoint — glance at the changes, make sure nothing's obviously broken, approve and move on.²

Now the work happens fast. Shockingly fast. In many workflows, an agent can complete a task in a fraction of the time it used to take a developer working alone. The new bottleneck isn't production. It's review. It's the human in the loop, looking at the finished work and making the judgment call: is this right? Does this solve the actual problem? Is it safe to ship?^{7, 6}

That's a fundamentally different job. And it requires fundamentally different tools.

The inbox metaphor is the giveaway. Sections, filters, saved views, triage workflows — that's the language of someone managing a flood, not someone checking on a trickle. It's the language of an editor running a newsroom, not a reporter filing a single story.^{1, 3}

What This Means Beyond Code

Here's where it gets interesting for everyone who doesn't write software for a living.

Pull requests aren't going to stay confined to code. The pattern — assign a task to an agent, let it work autonomously, review and approve the output — is spreading into many kinds of knowledge work: marketing copy, financial reports, legal document drafts, design variations, research summaries. The deliverable changes. The workflow doesn't.⁸

Today, a developer assigns five coding tasks to five agents and reviews the PRs that come back. Tomorrow, a small business owner assigns a week's worth of social media posts to one agent, a batch of invoice follow-ups to another, and a competitive analysis to a third. Each one comes back with a finished deliverable. The owner's job isn't to do the work. It's to review what came back, apply judgment, and approve what's ready.^{5, 6, 7, 8}

The pull request is becoming the universal unit of delegated work. Not just for engineers. For anyone who learns to work this way.

The pull request is becoming the universal unit of delegated work. Not just for engineers. For anyone who learns to describe what they need clearly enough for an agent to go build it.

The Skill That Matters Now

The people who thrive in this model won't be the ones who can do the work fastest. They'll be the ones who can review the work best. Who can look at five variations and feel which one is right. Who can read a finished deliverable and spot the subtle, dangerous error that the agent missed because it didn't have the context, the taste, or the institutional memory that only a human carries.^{6, 7}

This is judgment. And judgment doesn't automate. It gets amplified — because now the person who has it isn't bottlenecked by their own production speed. They can direct a dozen agents, review a dozen outputs, and ship a dozen things in the time it used to take to build one.^{9, 7, 6}

The metaphor I keep coming back to is the editor's desk. A great editor doesn't write every story. A great editor reads every story and knows, in a breath, whether it's ready for the front page or needs another pass. The red pen is faster than the typewriter. It always was.

What the Morning Looks Like Now

I've been working this way and loving it ❤️. Claude Code running in multiple terminal tabs, each one tackling a different piece of a client project, each one submitting its work for my review. Some run amuck and go off on incorrect tangents wandering to the place I like to call "the place where worktrees go to die" LOL. Some mornings I wake up to a dozen finished tasks waiting for me, neatly packaged, ready for the green button or the red pen. Not all mornings. Sometimes I get crap back.^{5, 6}

It changes you. Not in the dramatic, cinematic way — no slow-motion montage, no swelling score like a Michael Bay film. Gradually, then completely. You stop thinking about how to build things and start thinking about what's worth building. The constraint moves from capacity to taste.^{8, 6}

GitHub saw this coming. The inbox isn't aspirational. It's reactive. The volume is already here, and it's climbing. The dashboard they built is a concession to reality — an admission that the old, flat list couldn't hold the weight of what's pouring in.^{10, 11, 12, 1}

The pull request used to be a checkpoint. Now it's the heartbeat of the whole operation — the steady, persistent rhythm of agents finishing work and humans deciding what ships.^{7, 1}

The crew splits up. The work gets done. And Danny Ocean sits in the chair, watching the screens, making the calls.

It's fun to be Danny!

---

---