Code Is Getting Cheaper. Why Are We Still Managing Delivery by Hand?

Many people assume that adopting AI agents gives a business a “magic wand” capable of cheaply handling almost any task end to end. Unfortunately, reality is still far from that appealing vision. Architecture, debugging, integration, security, operations, domain understanding, and the ability to determine what actually needs to be built have not gone anywhere.

Even the productivity picture for AI-assisted coding is still far from clear. In METR’s early-2025 randomized controlled trial (RCT), experienced open-source developers working on familiar codebases took 19% longer to complete tasks with AI. The authors now believe AI is likely speeding developers up, and newer measurements point in that direction: among developers who returned for the follow-up, the average measured speedup was 18% (although the spread remains wide, from -38% to +9%). Because of selection bias, however, the authors explicitly avoid claiming a precise effect size. (METR: 2025 study, 2026 update)

AI can certainly produce plausible and correct code changes. Especially when a task is well-bounded, the relevant context is available, tests exist, and the result is relatively easy to verify. That alone is enough to speed up code production to the point where it affects the rest of the development and delivery process: review, debugging, integration, and so on. But are those surrounding stages ready for it?

I should make my own stake in this explicit: over the last several months, I have been building The Tam, a delivery system with an AI Delivery Partner, @tam, that is meant to move part of this operational work out of the manager’s head and into the system itself. So throughout the rest of the article, I will keep separating findings supported by external research from my own perspective as someone who has spent years running software delivery.

Writing Code and Shipping the Result Are Still Different Problems

In May, the U.S. National Bureau of Economic Research (NBER) published a paper with an almost perfect title for this discussion: Writing Code vs. Shipping Code. The authors combined AI-usage telemetry with data from more than 100,000 GitHub developers and compared engineers’ activity before and after tool adoption against similar peers who were not using AI. That distinction matters: this is an observational study, so the numbers show a consistent pattern rather than an established causal effect.

The result is revealing. Among developers using autonomous AI agents, commit-level activity increased by 180%. At the completed-project level, that uplift shrank to 50%. At the release level, it fell to just 30%. The authors attribute this decay to a weak-link effect: a dramatic acceleration in code generation immediately runs into adjacent stages of the production chain—review, testing, integration—where human work is still much harder to automate. (NBER)

The statistics merely reinforce something that is easy to forget while chasing generation speed: writing code is only a small part of the end-to-end development process.

Review, integration, tests, dependencies, architecture, security, deployment, acceptance, and requirements that change mid-flight have not disappeared. They rarely show up in polished coding-agent benchmarks, but they account for much of the time between implementation and release.

Linear saw a similar effect inside its own engineering organization. Between January and March 2026, both the number of issues created and the amount of code merged increased by 50%. The agents did exactly what was expected of them: substantially more work started flowing through the team. But review became the next constraint. Linear engineers admitted that at some point you start feeling the persistent temptation to stamp PRs with a boilerplate looks good just to get through the queue. (Linear)

The obvious conclusion is that review should now be automated as well—which, of course, is already happening. But that answer feels too local to me. Review is simply the first place where a broader problem became highly visible: the cheaper it becomes to produce the next action, the more actions begin flowing through the entire development system. And every one of those actions changes more than code; it changes the state of the project.

DORA (DevOps Research and Assessment) describes the same shift from another angle: AI accelerates initial code generation, but a significant share of the saved time is consumed by audit and verification. At the same time, heavier AI usage is associated both with higher delivery throughput and with greater delivery instability. In DORA’s qualitative research, engineers repeatedly describe the additional verification burden as the new cost of acceleration. (DORA)

At that point, the question “how much faster can code generation get?” becomes less interesting to me.

The more interesting question is: who is going to scale the system around that acceleration?

Software Development Has an “Invisible” Runtime Layer

Consider a fairly typical team. It has a tracker—Jira, Linear, or something else. GitHub or GitLab. Slack. Documentation. CI/CD. Observability. Meetings. And now Codex, Claude Code, Cursor, and several agents that actually execute work rather than merely answer questions.

On a diagram, we want the process to look like this:

In reality, there is an entire layer of work between these blocks that has little to do with writing code itself.

Sometimes this “invisible” work is handled by a project manager (PM). Sometimes by an engineering manager (EM). Sometimes by a tech or team lead (TL). And sometimes it is simply “that one person” — the one nobody wants to disturb because they are the only person who knows why everything works the way it does right now.

That person is constantly performing reconciliation: bringing together what was planned, what actually happened, and how reality is currently represented across the team’s systems. Good work here rarely looks impressive. It means noticing that a task is stale; realizing a pull request no longer matches the latest requirements; remembering that a dependency is not formally blocked but another team still has not made a decision; connecting yesterday’s conversation to the next action; or recognizing that 90% done for the third day in a row is a state of its own, not a percentage.

All of this existed before AI. But the amount of reconciliation work and the rate at which changes entered the system naturally matched the speed of “human execution,” and an experienced PM, EM, or TL could keep a substantial part of the whole picture in their head.

When the number of change sources grows and the changes themselves are produced faster, the human factor becomes the bottleneck that prevents the rest of the system from scaling with them.

There Is a Task in the Tracker. But What Is Actually Happening?

Let’s take one task and keep the same example for the rest of the article.

There is PAY-421: add a new payment flow. In the tracker, it is In Progress. At the time the task was created, the acceptance criteria require support for two client versions.

A coding agent picks up the task, reads the repository, makes the change, and opens PR-883. From the agent’s perspective, the work is complete enough to send for review.

The reviewer finds edge cases in the old client. QA confirms the problem. A short discussion starts in chat, and the product owner makes a perfectly reasonable decision: the old client version will no longer be supported. The original acceptance criteria have changed.

At the same time, a neighboring team rolls out a new version of a related API, which means part of the original implementation now has to be done differently.

The tracker still says:

PAY-421 — In Progress.

It is not lying. That is almost worse.

It is accurately showing the last recorded state. The problem is that the last recorded state and the current state of delivery are no longer the same thing.

And the problem is not the Status field itself. Status is a derived projection over more specific events: a pull request was opened, review requested changes, a decision was made, acceptance criteria changed, a new API version appeared, deployment has not happened yet.

For a developer, you can think of it as a materialized view over several sources. The value In Progress itself knows almost nothing about the causes that produced it.

Today, that projection is often maintained by a human. They know which events actually belong to PAY-421, which conflicting source should be treated as more recent, which decision invalidates an older requirement, and what that implies for the work plan.

In that sense, the task description and status in a tracker sometimes stop being a representation of truth and become merely a cache of what is happening.

That cache is useful. Necessary, even. But invalidation has always been the hard part, because every refresh requires manual work and somebody’s time.

As long as code changes are produced only by people at human speed, the model still holds together. The more actions are executed automatically, the faster reality diverges from its representations in the tracker and documentation.

Connecting AI to Jira Is Useful. But It Still Isn’t Enough

The natural next step is obvious: if a human is spending time moving information between systems, give AI access to those systems.

The market is moving exactly in that direction. Microsoft’s current Planner Agent, for example, can generate tasks from a goal, execute tasks assigned to it using the plan’s context, respond to feedback, and produce status reports. In its current form, it can also work with tasks and plans as a full participant in Microsoft Planner. (Microsoft)

So the claim that “an AI project manager will appear soon” is not particularly interesting anymore. We are already seeing it.

The more important question for me is: once that agent exists, who is responsible for continuity of the process and for its outcome?

Back to PAY-421. The agent has already written the code and created PR-883, but the acceptance criteria are now different. The task can no longer be considered complete merely because the code matches the original requirements. At the same time, the pull request does not automatically become invalid: some of the work in it is still necessary. In other words, the old state—agent completed task—no longer means the outcome has been achieved, because the contract itself has changed.

Who connects the product decision to the new version of the acceptance criteria in the tracker? Who determines which parts of the previous execution remain valid? Who replans the remaining work? Who notices that an adjacent service changed its API and broke a dependency? Who decides that a new action is required?

If the answer is “the manager will look at it and figure it out,” then fundamentally, connecting AI to the issue tracker changes nothing about the work of the person responsible. The team’s operating model remains the same.

Historically, project management looks roughly like this:

A human runs delivery.
The system stores the history of changes and displays the state of work.

The current generation of AI tools is gradually turning that into:

A human runs delivery.
AI agents execute more and more individual parts of the work.
The system stores the history of changes and displays the state of work.

This is where The Tam starts for me. I am building a model in which:

A human defines the target outcome, constraints and priorities, and makes the material product, technical, risk and acceptance decisions.
The Tam keeps the current delivery state: goals, plan, ownership, dependencies, decisions, context, evidence and review state.
@tam, the built-in AI Delivery Partner, carries the operational loop between those human decisions: building and maintaining the plan, coordinating people and coding agents, following progress and blockers, surfacing decisions and preparing the result for human review.
People and coding agents execute the work.

This is not “the human leaves the loop.” It is closer to the human no longer serving as the runtime for all the mechanics of that loop.

If the System Actually Runs Delivery, an “Update Status” Button Is Not Enough

The PAY-421 example makes the requirements for such a system more concrete.

Initially, there was not merely a task, but a target outcome: the new payment flow had to work for an agreed set of clients. That outcome had a specific version of its acceptance criteria. Those criteria produced a plan, and the plan produced PAY-421.

After the product owner’s decision, a new version of the criteria appears: the old client is excluded. The system needs to preserve the fact that this was a decision made by an authorized human, not a model’s interpretation of a copied chat thread. It then has to determine whether the new version of the contract affects the current plan and existing tasks.

PR-883 should not be discarded. It remains evidence that a specific part of the work was completed. But the task’s status still does not prove that the target outcome has been achieved.

Then the adjacent service changes its API. This is a new fact about the environment, not a business decision. It affects the plan differently: perhaps additional work is required; perhaps part of PR-883 is now obsolete; perhaps the system has to stop and request a human decision because the change falls outside the boundaries it was authorized to handle.

Only after implementation, testing, deployment, and acceptance do we have a body of evidence sufficient to claim that the target outcome was actually achieved.

The lifecycle starts to look something like this:

The task does not disappear. It is still a convenient unit of execution, responsibility, and communication. But it becomes clear that a task is too small an object to own the entire lifecycle.

PAY-421 Done may be a perfectly accurate local fact while the business outcome is still nowhere near ready. Likewise, PR merged or agent run successful tells us something useful about an individual step, but neither is evidence that the work as a whole is complete.

There is no new project-management philosophy here: good project management has long emphasized outcomes and value rather than a cult of closed tasks. The new part is the consequence. If the target outcome is really what the work is about, the system’s runtime also has to live longer than an individual task, chat, or agent run.

It has to survive waiting for a human decision, a criteria change, a new plan, a worker restart, partially completed work, an ambiguous external-tool timeout, and the next iteration two days later.

One Extremely Smart AI PM Is Not an Architecture Either

You could try to solve the whole problem with a single agent: give it a huge context window, tools, memory, and permission to collect state, plan, execute, and verify on its own.

That can look elegant in a prototype. In production, however, you quickly run into the question of authority.

Back to PAY-421. If the same component decides that the criteria change requires a new plan, then performs the action itself, then interprets the resulting data as sufficient evidence, and finally declares the target outcome complete, what we have built is not autonomous management. It is automated self-certification.

In a conventional organization, a person who defines the boundaries of the work, spends the budget, performs the work, audits it, and signs off on acceptance makes the process externally ungovernable.

The need for separation of duties does not disappear with agents. Planning, execution, process stewardship, and independent verification are different functions precisely because they rely on different grounds for decision-making. That does not mean you necessarily need a “team of five agents.” The number of processes or models is an implementation detail. Different roles can be enforced within one model through hard authority boundaries, or they can be physically separated.

The important point is this: the executor should not be the sole source of the claim that its own work produced the required outcome.

So What Is Left for PMs, EMs, and Humans in General?

If the system takes over the operational loop and keeps context synchronized, the obvious question follows: why do managers remain in the loop at all?

First, good PMs and EMs do not spend their time merely moving cards around a tracker.

Second, not all coordination is meaningless overhead. Human conversations are often where different mental models of the system are synchronized, conflicting goals become visible, compromises are negotiated, and uncertainty is discovered that nobody could see before the conversation.

PMI reaches a similar boundary from another direction in Pulse of the Profession 2026: project complexity comes not only from workload or deadlines, but also from contested decisions, interdependencies, fragmented shared understanding, and constantly changing context. According to PMI, teams that work effectively with complexity are significantly more likely to achieve their outcomes; the emphasis is on outcomes, alignment, and the ability to revise the picture—not simply on more detailed management of a task list. (PMI)

So it is more useful to separate types of work than professions.

There is human responsibility: deciding why PAY-421 is needed in the first place; deciding that the old client version is no longer worth the cost of supporting; accepting risk; resolving a conflict between teams; changing priorities; and ultimately accepting the result.

And there is continuous maintenance of the operating model: noticing stale state, connecting an event to the right context, refreshing the state projection, checking a dependency, reminding someone about a decision, preparing a requirements clarification, collecting evidence, detecting divergence, and realizing that the current plan no longer matches an accepted decision.

The second class of work looks far more automatable. And here transparency is critical: at any moment, we need to understand where the data came from, what each conclusion is based on, and how the entire chain of steps can be traced for verification.

If the system can explain, at any moment, which outcome we are driving toward, which version of the criteria is currently in force, what changed and on the basis of which source, which person or agent took an action, what is blocked, where a human decision is required, what evidence already exists, and why the current evidence is still insufficient for acceptance, then it removes some of the work involved in reconstructing operational context.

The PM spends less time collecting status updates. The EM spends less time searching through team chats. Developers are interrupted less often with questions whose answers are already present in the execution log. Leadership gets a fresher picture not because the team was forced to fill in reports on time, but because the system itself is better at capturing the real state of the project.

Local AI Productivity and System Productivity Are Not the Same Thing

This is why I do not like measuring AI adoption maturity by tokens consumed, agent runs, or the number of pull requests created by agents.

Those metrics are useful as telemetry. But they measure executor activity, not the output of the production system.

NBER shows a steep decay in the estimated effect as you move from commits to releases. DORA shows that gains in generation speed are partially consumed by verification, while active AI adoption can coincide with both higher delivery throughput and higher instability. (NBER, DORA)

On a much broader sample, Microsoft’s Work Trend Index 2026 found that organizational factors—culture, processes, and management support—are associated with AI effectiveness more than twice as strongly as individual skills (67% versus 32%). At the same time, only 19% of surveyed AI users are in the zone where personal readiness is matched by mature organizational workflows. The report explicitly notes that this is a statistical association, not a strict causal estimate. (Microsoft Work Trend Index 2026)

A practical question is enough: what share of the additional work performed with AI actually reached an accepted outcome, and how much human labor did it take to get there?

For a specific team, this already yields sensible metrics: decision wait time, blocked time, number of rework cycles, share of false reports of completion, human review time, number of manual interventions before acceptance. And ultimately: the cost of a useful, verified outcome rather than the cost of a million tokens.

We already tried measuring productivity in lines of code once. Repeating the experiment with tokens makes little sense.

Limits: Where This System Won’t Work

The strongest objection is that we are trying to automate a problem that good process already solves in many teams.

Yes. A strong team with limited WIP, clear ownership, strong tests, short feedback loops, and good discipline around keeping the tracker current experiences far fewer of the problems described above. DORA explicitly describes AI as an amplifier: strong platform practices and clear processes help teams extract more value, while fragmented or weak systems simply expose their defects faster. (DORA)

To me, that is more of an argument for automating known properties of a good process than an argument against it. CI/CD did not replace engineering culture; it simply stopped requiring a human to remember to run tests every time. Observability did not eliminate responsibility for production; it removed the need to stare at a log file manually around the clock. Infrastructure as Code did not eliminate infrastructure expertise; part of the operational mechanism simply stopped living exclusively in an administrator’s head.

Why should maintaining the delivery process be fundamentally different?

The second objection is that AI does not always make developers faster. METR’s experiments demonstrate this clearly, and the debate around the actual numbers is still ongoing. But our problem does not require a claim of universal acceleration. It is enough that AI makes even some classes of tasks faster. As soon as productivity jumps at one stage, the bottleneck immediately moves farther down the chain—to integration and coordination. (METR: 2025 study, 2026 update)

The third objection is the most important to me: not all coordination is waste. Sometimes manually working through PAY-421 is valuable precisely because, in the process, a PM and a developer discover that they hold different models of the product. If the system silently “resolves” that divergence, we could end up with a perfectly up-to-date tracker and a badly managed project.

So the goal is not to eliminate communication or human judgment. Quite the opposite: a good system should be able to distinguish between the places where it can safely maintain state automatically and the places where genuine ambiguity appears and the decision must be handed back to a human.

There is also one uncomfortable practical risk: we could automate the management layer so thoroughly that maintaining the management layer itself requires a dedicated specialist. Conceptually, that would be very ironic. In practice, I would rather avoid it.

How This Problem Turned into The Tam

I did not arrive at this topic through abstract reasoning. I have been leading software development and engineering teams for more than eight years.

Over time, you get used to how much invisible labor goes into synchronization: keeping context in your head, connecting agreements from meetings to the real state of repositories, noticing in time that the business goal and the task list have drifted apart. In conventional teams, this coordination tax is at least spread out over time.

But when, toward the end of last year, I started using autonomous AI agents heavily in my own projects and experiments, the scale of the problem became obvious almost immediately. Execution velocity increased dramatically, but so did the coordination load on me: decisions remained trapped in chats and notes, the real state of work diverged from the tracker almost instantly, while tasks and documentation (SDD—Spec-Driven Development) continued living their own lives after the original requirements had changed. The faster agents generated changes, the more time I had to spend manually rebuilding context and explaining to the system what had actually happened.

That is how The Tam started. The first version of the idea was, in effect, my own tracker. Not another board, but a working system that agents could interact with directly through MCP: read the same project context, work with the same tasks, and write results back to the place where a human would see them. The idea seemed straightforward enough: if a machine has already performed an action, do not force a human to manually retell it to another machine.

On real projects, it quickly became clear that machine access to tasks was not enough. An agent can read a card, open a PR, change a status, or create the next task. But that does not mean anyone is managing the whole lifecycle. The goal may have changed; a decision may have remained in a chat or in new research produced by an agent; old criteria may continue living in the plan; and locally correct execution may no longer correspond to the outcome that is actually needed.

That is where The Tam stopped being just a tracker. What is needed is a shared working environment for people and agents that stores not only cards, but goals, criteria versions, decisions, dependencies, wait states, permissions, and evidence. Not as an event archive that a human periodically cleans up, but as a delivery system capable of maintaining continuity of the model.

The next logical step became @tam, the AI Delivery Partner built into The Tam. It does not merely execute isolated commands. It carries the loop between human decisions: building and maintaining the plan, coordinating people and coding agents, following progress and blockers, connecting events back to project state, surfacing decisions, and preparing the result for human review. It does not own the business goal, accept risk on behalf of a human, or sign off on its own work. But the human no longer has to remain the runtime for the entire operational mechanism.

I have returned to individual parts of this problem many times in shorter notes, including on LinkedIn. Recent research, some of which is cited above, did not create the idea, but it provided enough external support to stop assembling the argument piece by piece and bring it together in one article.

This is the hypothesis I am now testing in The Tam. What matters here is not a list of product features, but the boundary of automation itself: what the system can and should carry between human decisions, and where it must stop and return the decision to a person. Because the question is no longer whether we can build yet another agent that knows how to git commit. We already have plenty of those.

Code Is Only the Beginning

AI is already good enough at producing changes that the old constraints of the surrounding system are becoming visible.

Review was one of the first. Beyond it are integration, decisions, dependencies, acceptance, state reconciliation, and the entire layer that today is often carried invisibly by a PM, EM, TL, or simply the person with the deepest context on the team.

If execution keeps getting cheaper, that layer will become an increasingly visible constraint. And the next significant step in developer tooling may not be another way to complete an individual task faster, but a system that lets a human spend less time manually maintaining the process of delivering an outcome—while still understanding, controlling, and making the architectural and product decisions that genuinely matter.

Code is already getting cheaper.

That is the direction I am building The Tam toward: not another coding agent and not a tracker with an AI chat box, but a delivery system that carries more of the operational loop between human decisions.

Primary Sources and Research

1. METR (2025–2026):
   • Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
   • We are Changing our Developer Productivity Experiment Design
2. NBER (2026): Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools (Working Paper No. 35275)
3. Linear (2026): Reviewing code in the agent era
4. DORA (DevOps Research and Assessment): Balancing AI Tensions
5. Microsoft (2026): Work Trend Index 2026: Agents, Human Agency, and the Opportunity for Every Organization
6. PMI (Project Management Institute, 2026): Pulse of the Profession 2026: Driving Success in Complex Projects