• 21 min read

We need a new unit of work for AI

Epistemic status: speculative.

The pull request (PR) is the unit of work for much of the software industry. Sure, some shops allow multiple PRs per story card, but generally speaking 1 card ≈ 1 PR ≈ the smallest change you can ship.

If you weren’t in the industry before the pull request was invented, you might not know that the unit of work has varied over the years. Some teams experimented with an even more granular unit: the commit.1 More commonly, the unit of work was much larger.2

A horizontal scale of units of work ordered by size: commit, pull request, a highlighted question mark for the new unit, and release

The more I work with AI, the more convinced I become that a change is due. It is not that the PR can’t be used in a world of AI. Rather it is that a PR is a human-centric unit of work. For as long as we stick with the PR as the unit of work, we will be leveraging only a fraction of the power of agents.

Agents are already capable of working 12+ hours unattended. That is only going to become more true, and more generally applicable, as smarter and smarter models come out.

We just lived through the shift from programmers using LLMs for chat and as a powerful autocomplete–with the human still driving–to a paradigm where the agent drives the work and the human supervises. We switched paradigms because it became clear that keeping humans in the loop of writing code was holding the agents back. Humans had always been the bottleneck in the code-writing loop. For the first time, we could simply remove the human from that loop.

Three panels. 2023: a human implements a PR, with an inner loop of the LLM suggesting one line at a time. 2026: a human delivers a project, with an inner loop of the agent implementing one PR at a time. Next: the agent delivers the project itself, implementing and testing and reviewing the changes, and the human supervises how, exactly?

As I’ve experimented with giving agents a longer and longer leash, it is becoming clear that the same pattern holds one level up, at the scale of small projects. I could break down a project myself and figure out where all the right seams are to review changes and deploy them incrementally. Or I could let the agent do it.

Anyone who has planned work for a more junior engineer has run into the pitfalls of the hand-off. You can carefully design the cleanest seams between each unit of work in the project, and it all goes off the rails the moment it collides with messy reality. Either reality tests an assumption you baked into the plan, or your carefully worded write-up doesn’t click in the brain of the engineer actually doing the work.

Richard Caton Woodville's painting of the Charge of the Light Brigade: cavalry galloping into Russian guns at Balaclava The pencilled order that launched the charge, written by General Airey for Lord Raglan

Left: the Charge of the Light Brigade, Richard Caton Woodville, 1894. Public domain. Right: the order that launched it. “Lord Raglan wishes the cavalry to advance rapidly to the front, follow the enemy, and try to prevent the enemy carrying away the guns.” Raglan, on the heights, could see which guns. Lucan, in the valley, could not. Photo by The wub, CC BY-SA 4.0.

That lesson is well enough understood. Nobody needs convincing that hand-offs are lossy.

The hard part is every engineer’s deepest insecurity: being on the hook for a system they don’t understand and can’t control.

Software engineers used to achieve that understanding by writing the code, or by talking to the engineer who did. In 2026, engineers don’t really write the code. They retain understanding by collaborating on plans for the agent and by reviewing the PRs the agent produces.

It doesn’t matter how productive agents could be if given the autonomy to implement whole projects. Engineers will never embrace the paradigm until they learn some way to retain control.

What follows is my speculation on the path to get there.

Building understanding from the code

In a previous post I laid out the case that retaining control by building and reviewing plans for the agent fundamentally limits the size of work an agent can implement. Even in that vision, the human is still heavily involved in the careful definition of requirements, which does provide significant control and understanding. Still, that leaves a big gap: understanding how those requirements are achieved in the actual implementation.

I see it as inevitable that engineers will give up agent planning in order to unlock the productivity gains. If you will humor me on that premise, then we need a way to build understanding that doesn’t rely on the human laying out the plan in advance. We need to build that understanding after the code is written.

It is not hard to imagine getting an agent to review a working implementation and work backwards to produce a plausible implementation plan–one that would have produced the same result. If the requirements are achieved either way, does reading the plan before or after the fact make a difference?

I would argue it does make a difference, but not because the plans are meaningfully different. If anything, the plan produced after the fact is more likely to represent what was actually built.

The difference is passivity.

If the human is an active partner in building the plan, they are actively thinking through possible approaches. Even when the planning agent knocks the plan out of the park and the human is merely reviewing it before implementation, there is still the unknown risk, at that moment, that the plan won’t work. The human stays hooked, because they are trying to anticipate the failure modes that might lurk in the plan. Whereas when the agent comes back with the whole project implemented, and manual testing shows that yeah, it all seems to be working exactly as expected, then what is the motivation to go back and study a plan?

Active learning?

Detail of Raphael's The School of Athens: Socrates, in an olive robe, counts off the points of an argument on his fingers to a small group of listeners
Socrates working the room. Detail from The School of Athens, Raphael, 1509-1511. Public domain, via Wikimedia Commons.

Agents can be skilled Socratic teachers. That is the first solution that comes to my mind. The idea would be to have the agent interrogate you until you understand what was built and how it satisfies the requirements.

That would be fun to experiment with, and I bet some people will find success with the approach. But the idea of engineers spending a portion of their day as students under AI strikes me as too weird a future to become the dominant pattern. “I’m sorry, Dave. I’m afraid I can’t let you approve that PR until you score at least 8/10 on the comprehension quiz.”

The red eye of HAL 9000
HAL 9000 by Cryteria, CC BY 3.0.

Even without forced active learning, one can imagine any number of partial solutions to the problem.

Personally I await better pull request review tools. Why can’t I have an agent answer questions about the code I’m looking at in GitHub? One step beyond that: why can’t I have an agent test edge cases on the proposed code and report back to me? Or try a slightly different approach and report back on how it compares? I don’t have access to that in GitHub today, but it is easy enough to substitute with worktrees running on my local machine.

Another thing that is possible today, but isn’t yet as seamless as it could be, is having the agent produce review material as a precondition of the work being done. Agents can produce architecture diagrams and sequence diagrams of what was built. They can write one-pagers on the alternative approaches they considered. They can write a research report for each edge case they ran into. They can post screenshots and videos of the changes being tested. And I could easily imagine an agent someday synthesizing all of the above into a 10 minute YouTube-style video for the reviewer to watch over coffee.

I won’t claim to know exactly how it is going to work. But I’m confident we will have access to so many tools that constructing an understanding of the code after the fact will become efficient–if it isn’t already easy enough today.

AI SDLC maturity levels

Understanding is only one piece of the puzzle. We also have to get the human to the point where they are comfortable signing off on the changes. Plus we have to get to the point where the changes can be safely rolled out.

Here I see a fork in patterns, depending on how AI-native a given organization is comfortable going. Level 0 in my maturity model is the software development lifecycle (SDLC) as practiced circa 2025: agents may exist, but they haven’t meaningfully changed how we ship software.

Level 1: Agents implement the project, humans review individual PRs

For regulatory compliance reasons, it is commonly required that every PR be reviewed by another human. Even when not required by policy, the PR review process is often enshrined by inertia.

In this world, even if an agent can go off and implement a project in one go, the changes produced would typically be too large to review and deploy as a single PR. So the project isn’t ready once the agent has satisfied the requirements. The agent needs to take a second pass to identify the separately reviewable and deployable seams, rebase the changes into a sequence of logical commits, and open a stack of PRs so the changes can be reviewed and deployed in sequence.

Agents can then be assigned to each PR to produce the kind of review documentation discussed in the previous section, so humans can review the changes efficiently.

Unfortunately, while splitting up big changes is a traditional way to de-risk deploys, splitting up a big change can also introduce bugs. The split creates intermediate states that wouldn’t have existed had the whole change gone out across fewer deploys. It will be important to teach agents how the different parts of your system are deployed and run in real environments, to prompt them to sequence the changes when splitting up the work, and to prompt the reviewer agents to call out the buggy intermediate states a given split could enable. I have experience getting agents to split up big changes into reviewable PRs. Getting them to plan safely sequenced deploys is an area I’m still experimenting with, hence the vagueness of this paragraph. Still, I have no doubt it is a tractable problem.

Level 2: Agents implement the project, humans evaluate the whole project

For organizations starting anew, or with more room to experiment, I don’t know why you would stick with the old PR workflow given the capabilities of agents today. As models get smarter and agents get more capable, the value of having a human understand each line of code as it goes out goes down. Perhaps in your domain we haven’t reached the tipping point where the default posture becomes trusting AI-written, AI-reviewed code at the line-by-line level. But for most domains we will be there soon.

Not needing to read every line of code is not the same as taking the human out of the loop. I would not feel comfortable shipping an AI-delivered project to production before I had a strong understanding of the technical architecture of the new code, and before I had reviewed the code that implements the central logic of the change.

What becomes more important than human review in this world is leaning on all the other patterns we have learned for de-risking software. Some of them take place before the new code rolls out:

Others operate as part of the rollout:

The idea isn’t to get rid of PRs entirely, per se. The idea is to layer in the above techniques until you feel comfortable merging and shipping PRs at a size larger than a human could reasonably review line by line.

“So you want me to replace PR review with even more work?”

If you are shipping the initial version of a greenfield system, you probably only need a small handful of the techniques above to get started. You can build in additional layers as the complexity ramps up.

For a complex, existing system, it will likely require significant up-front effort to layer in the confidence-building techniques above. That is not going to happen overnight.

In both cases, however, the end state is the same. A line-by-line human review gate scales with the number of human hours you can employ, and with how fast you can onboard humans onto the systems in question. That is to say, it scales poorly. In contrast, most of the techniques listed above are automated. Once implemented in one part of your system, they can be scaled out to the rest of it. Organizations that make the investment will outperform to a startling degree in the long run.

“Sounds nice, but isn’t all this limited to greenfield work?”

I suspect AI can be made to implement whole projects at a time, even in legacy systems. I should also note that I have only limited experience doing this, so this section is more speculative than the rest.

From first principles, I don’t see why agents can’t implement whole projects in a legacy system. The agents of today are additive by nature.4 They can be taught how existing systems work, and they can be instructed to minimize changes to any area the project isn’t supposed to rework.

No doubt this is easier said than done. Some legacy systems will stubbornly resist attempts to scale up AI in them. The most successful legacy systems will find a way despite the challenges.

Perhaps the key differentiator will be the legacy systems that can cleanly isolate sub-components that AI can operate in safely. These “components” may be new microservices, or they may be code running in the same OS process but separated from the rest of the monolith by a clearly defined interface. The specific form of isolation isn’t important. What is important is that you can reasonably evaluate the correctness of the delivered changes by checking the inputs and outputs of the component through its well-defined interfaces. That way you don’t have to worry so much about subtle bugs caused by hidden coupling and assumptions linking far-flung parts of the codebase to each other.

Whether working on greenfield or legacy systems, the idea is the same. The human becomes the systems integrator: the person who understands what the components of the system are, how they fit together, and how to check whether things are working. The line-by-line work of implementing component internals is left to the AI.

Level 3: Agents implement the project, agents are wholly responsible?

I’m not afraid to suggest that the dark factory is likely where all this is headed. AI will eventually take the role of systems integrator, leaving humans to collaborate on requirements and consult on design, but ultimately deferring engineering responsibility to the AI.

It is tempting to look at the rapid progression of AI over the last few years and want to jump straight to the end. If you believe the AI kool-aid drinkers who say sustained double-digit GDP growth is imminent, then sure, go ahead and jump straight to the end. If you merely believe that AI is a revolutionary change that will rework the world from top to bottom over the course of a generation, then you may have to put in the effort to figure out the right way to ship software in 2027, 2028, and the years beyond, while humans still have a role in the process.5

To build intuition for how AI took over coding so quickly, but why it could take noticeably longer for AI to take over responsibility for shipping whole systems, consider how reinforcement learning fits into the process of giving models their smarts.

Diagram of a model training pipeline: pretraining, supervised fine-tuning, reinforcement learning, shipped model. The reinforcement learning step is expanded into a loop: give the model a task, model attempts the task, grade the result, update the weights, repeat.

At a high level, the AI labs give the model a task, then judge how well the model performed at the task, and use that judgment to update the model’s weights.

Coding tasks–even the complex ones–tend to be fairly self-contained.6 Coding tasks also tend to be, not exactly universal, but generally applicable. A surprising number of business rules can be distilled down to mathematical set operations.7 Algorithms are built on the same handful of data structures: stacks, queues, hashes, trees, and graphs. Systems keep finding the need for the same patterns (strategy pattern, I’m looking at you).

So the models are very good at coding tasks, in almost all domains.

Real world systems are also made of mostly the same recognizable building blocks. However, no two real world systems are the same. They develop their own language over time. They develop their own rules for how to do things. Every decision made about the system is shaped by what is and isn’t important to what that organization is trying to achieve in the real world. It is not that agents are entirely incapable of navigating these challenges today. Rather, I’m pointing out that they aren’t trained extensively to operate in this kind of problem space. During training, they aren’t directly judged by how well their decisions shape the long-term success of a system.8 Someday they likely will be–or at least on a proxy that is close enough–but it is not an easy task to set up enough training environments, at scale, that resemble full-sized real world systems. There is also the question of how to score the models on long-term outcomes.

Perhaps a good analogy for making an agent responsible for engineering the whole system: it is like finding a genius who codes at an expert level and who has read every book on good software engineering, then handing them the keys to the first real world system they have ever operated. Will it work? Sometimes, probably yeah. Especially if you are really good at communicating the desired outcomes and the constraints the system will operate under. For most systems? I wouldn’t bet on it for at least a couple of years to come.

Why this shift will be slower than the last one

The shift to taking the human out of the coding loop happened almost overnight. That is because Claude Code came out, and the tool itself teaches the right patterns if you are willing to let it.

I don’t think the shift to letting agents implement whole projects will happen so suddenly. There is not going to be a one-size-fits-all tool (at least not any time soon) that teaches your organization how to use AI to work on and ship larger units of work. Organizations will have to figure out on their own what works for them. That will take time. But the transformation will go, on net, in one direction: towards giving AI more and more autonomy, in order to reap the productivity gains from cutting humans out of the loops where they are the bottleneck.

The new unit of work

This post began with the assertion that the human-scale PR is no longer the optimal unit of work. I still don’t know what we will call the new unit, that is, the size of work that AI will be entrusted to implement autonomously, and potentially the size of work that a human will evaluate the quality of all at once.

What we can do is put some bounds on the size of the unit:

This new unit of work need not be mutually exclusive with other sizes. Humans will still direct agents to implement human-sized PRs for quick, responsive changes to the system. Areas of the system that can be fully entrusted to agents (likely peripheral concerns, not part of the core architecture) may ship one commit at a time, with no human review, with the agent monitoring the changes during and after deploy and handling any issues that arise on its own.

In most real world systems, though–where a human engineer is needed to maintain responsibility for the system–we will need a new unit of work to unlock the power of agents. Will you be the one to name it?

Shout out to my editor, Fable. The unit of work was the whole thing.

Notes

  1. This was the original meaning of continuous integration. In Kent Beck’s Extreme Programming, circa 1999, developers integrated their work into the main line every few hours, and every integration had to build and pass the tests. In effect, the commit was the unit of work. Somewhere along the way, “CI” came to mean “the server that runs the tests on my PR.” Martin Fowler’s article is the canonical write-up of the original idea.
  2. Before pull requests, and before continuous integration caught on, developers commonly worked on their own copy of the code for weeks or months, then everyone merged at the end in a dreaded “integration phase.” Shrink-wrapped software shipped on a cadence measured in years. The unit that actually got tested and shipped was the release. The exact sizes depend on who you ask and which decade they worked in, so take the specifics with a grain of salt.
  3. The last time I had an LLM help me write a model for formal verification was in 2025. It worked for a simple approximation of the system, but I had to step in to model the full complexity. If I tried again now with Fable, I bet it could get much farther.
  4. That is to say, they err on the side of not deleting existing code unless instructed. Often to a fault.
  5. If you believe that AI is a bubble that will pop soon, I can’t prove to you otherwise. But what I will say is that the cat is already out of the bag. Even if there is no money left for AI labs to push the frontier, the cheap open weight models of today are already capable enough to see through the transformation predicted by this blog post. It would push out the timeframes over which I’m predicting these changes, but this train isn’t stopping.
  6. Or, even when the coding changes aren’t actually self-contained and have subtle long-term implications, how likely is it that whatever grading framework the lab uses puts enough weight on the long-term consequences? How easy is it to troubleshoot when something goes wrong in prod? How easy is it to evolve when the requirements change? How many subtle race conditions or distributed systems problems does it risk?
  7. Even if most implementations re-implement the set operations with ad hoc code.
  8. No doubt they are judged on best practices that we think are proxies for long-term success. But there is a meaningful distinction between “writes good automated tests” and “produces successful outcomes over the long term.”