Your AI Coding Agents Aren't Slow. Your Process Is.

I was sitting in a conference room last month listening to a presenter describe his team's experience with AI coding agents. They'd been running them for six months. The agents were writing code, submitting pull requests, responding to review feedback. Everything you'd expect.

Then came the question from the audience: "What kind of velocity gains have you seen?"

The presenter paused. "Well, we haven't really seen meaningful improvements yet. But we're hopeful they'll materialize eventually."

I've heard this story before. Not about AI agents—about MRP systems in the 1980s.

The Monthly Report Problem

MRP—Material Requirements Planning—was enterprise software designed to help manufacturers coordinate inventory, schedule production runs, and manage supply chains. In the 1980s it represented the same kind of transformational promise that AI tools carry today: buy the right system, and efficiency would follow. Manufacturers invested heavily. Results varied wildly.

Eli Goldratt, the physicist-turned-management-consultant who developed the Theory of Constraints, spent years studying those MRP implementations. What he found was remarkable: companies using the same software, sometimes even from the same vendor, experienced wildly different outcomes. Some saw order-of-magnitude improvements in profitability. Most saw modest reductions in accounting overhead and not much else.

The difference wasn't the software. It was the reports.

Before MRP, running those reports monthly wasn't a choice born from indifference — it was a physical reality. Compiling production schedules, inventory positions, and demand forecasts required teams of people manually reconciling paper records and doing calculations that consumed most of the month. Running them more often simply wasn't feasible. Monthly was the cadence because anything more frequent was operationally impossible.

MRP changed that. It automated the data compilation and could produce the same reports overnight. What had taken a human month of effort now took a few hours of compute time. Weekly decision cycles became physically possible for the first time.

Companies getting transformational results saw that shift and acted on it. They ran their reports weekly — sometimes more often. They had fundamentally changed the cadence at which they made decisions, and better information at shorter intervals meant dramatically better decisions. The compounding effect of that was the order-of-magnitude gain.

The vast majority of companies did something different: they used their shiny new MRP system to run the exact same monthly reports they'd always run, just faster. They got exactly what they optimized for—slightly more efficient execution of an unchanged process. The MRP system gave them the capability to decide weekly. They chose to keep deciding monthly.

Same tool. Same data. Radically different outcomes.

The constraint wasn't the technology. It was the willingness to redesign the decision-making process around what the technology made possible.

Running Monthly Reports with Weekly Tools

That presenter's team is running monthly reports.

Here's what I mean: they have agents that can write code in parallel, work around the clock, and iterate on feedback in minutes. Those agents are wrapped in a process designed for sequential human work.

Pull requests sit in review queues for days waiting for human reviewers who are context-switching between meetings. Agents submit changes and then idle, waiting for approvals that assume code review is the bottleneck worth optimizing. Sprint planning happens every two weeks because that's the cadence humans need to absorb and plan work. Architectural decisions get made in the same meetings, at the same intervals, with the same deliberation they always have.

The agents can run weekly. The process is still monthly.

And so the team waits for velocity gains that won't materialize—not because the agents can't deliver them, but because the process won't let them.

What Weekly Reports Actually Look Like

If you're going to run the reports weekly, you have to change more than the calendar.

The first thing that shifts is the constraint itself. When agents can write code faster than humans, the bottleneck moves from "how fast can we write this?" to "how fast can we make good architectural decisions?" Your senior developers stop being code producers and become architecture definers and outcome verifiers. That's not a small shift—it's a fundamental change in how you staff and structure work.

Paired with that is a new relationship to code review. You can't review every line of agent-generated code the way you review human work—it's too much volume, and the agents are too fast. Instead, you define architectural guardrails upfront: here's the API contract, the data model, the security posture you require. Agents run in those lanes. You review at meaningful checkpoints—does this feature work end-to-end, meet the architecture, solve the user problem?

Work itself becomes parallel rather than sequential. Backend doesn't finish and then frontend starts. Agents work the full stack simultaneously while you orchestrate parallel execution across domains instead of managing a relay race.

Your sprint cadences need redesigning too. When agents deliver features in days instead of weeks, two-week planning cycles feel like drag. The rhythm of standups, planning sessions, review cycles—they were designed around human cognitive load and human output rates. If those aren't your constraints anymore, neither should your schedule be.

Finally, approval gates get rethought. Manual approval at every commit or PR made sense when commits were expensive and humans were slow. When agents generate dozens of commits per feature and iterate in minutes, approval gates become pure overhead. You need different quality controls: automated verification, contract testing, architectural fitness functions. You're not eliminating oversight; you're redesigning it for a process that moves faster than human sign-off allows.

This isn't about speed. It's about decision-making at a fundamentally different cadence.

The Constraint You Designed

Here's the uncomfortable part: if your AI coding agents aren't delivering velocity gains, it's probably not the agents. It's the process you've wrapped around them.

You bought the MRP system. You're running the monthly reports.

Goldratt would call this a policy constraint—a bottleneck you designed and continue to enforce, even though the underlying conditions have changed. Policy constraints are the hardest ones to fix, not because they're technically difficult, but because they require admitting that the way you've always worked isn't the way you should work now.

The team I watched present had wrapped agents designed for parallel, continuous execution inside a process designed for sequential human work. And then they waited for gains that couldn't materialize within those constraints.

The agents could deliver. The process couldn't.

The Architect's Role in This

If you're a software architect or technical leader, this is your problem to solve. Not your team's. Not the agents'. Yours.

You designed the process. You own the decision cadence. You set the architectural guardrails—or didn't. You decide whether reviews happen at every commit or at meaningful checkpoints. You choose whether sprints run on human timelines or capability timelines.

The agents will do what you tell them to do, within the lanes you give them to run in. If those lanes are a relay race and the decisions happen monthly, that's what you'll get.

But if you're willing to rethink the constraints—if you're willing to run the reports weekly—the gains are real. Not incremental. Transformational.

The question isn't whether AI coding agents can deliver velocity gains. They can. The question is whether you're willing to redesign the process to let them.

Four Questions That Expose the Real Constraint

If I were looking at a team that says, "We have AI coding agents, but we still aren't seeing much velocity improvement," I wouldn't start with the prompt quality or the model choice. I'd start with Goldratt's four questions. They're a practical way to separate the power of a new technology from the habits that smother it.

What is the power of the technology?

The first question is simple: what can this technology do that wasn't realistically possible before?

With AI coding agents, the answer is not just "write code faster." That's too small. The real power is that they can work in parallel across multiple concerns at once, keep moving without fatigue, iterate in minutes, and stay locked on a task without context-switching. A human team has to serialize a lot of work because attention is scarce. An agent doesn't have that problem in the same way.

That changes the shape of delivery. You can have one agent adjusting an API contract, another updating tests, another wiring frontend behavior, another fixing documentation, all in the same window of time. You can explore options quickly instead of protecting every iteration because each one is expensive. If you define the lanes well, the system can move with a kind of concurrency that human teams usually can't sustain.

What limitation does it diminish or eliminate?

This is where the conversation gets more interesting. What limitation was the old system built around?

For most software organizations, the obvious constraint has always been human throughput. How many good engineers do we have? How much focused time do they have this week? How many features can they realistically build, review, and refine before cognitive overload kicks in? That assumption is baked into everything from sprint planning to PR etiquette.

Agents reduce that limitation hard enough that it stops being the dominant constraint. The bottleneck shifts. The question is no longer, "How fast can we write the code?" It's, "How fast can we make good architectural decisions, define clear boundaries, and verify that the outcome is actually correct?" That's a very different system.

Once you see that shift, a lot of familiar frustration makes sense. The agents are producing. The backlog is moving. But progress still stalls because decisions are trapped behind human review queues, weekly meetings, or approval structures that were designed for a world where code creation itself was the scarce resource.

What rules helped us accommodate the old limitation?

This is the question most teams skip, and it's the one that matters.

If human coding capacity was the constraint, then a lot of your current rules probably made sense. You staggered work. Backend first, frontend after. You reviewed every line because each change represented a meaningful slice of expensive human effort. You planned in two-week sprints because people needed time to absorb context and protect focus — and because coordinating work across a team of humans with limited attention is genuinely hard. You put manual approval gates everywhere because commits were relatively infrequent and the pace was manageable.

None of that was irrational. Those rules were accommodations to real limitations — the same kind of real limitations that made monthly MRP reports the only feasible option before the software existed.

The problem starts when teams treat those rules as permanent truths instead of adaptive responses. I've seen organizations put agents into a workflow where they can generate useful work all day, then force that work to wait three days for a reviewer, another week for planning alignment, and another meeting for architecture clarification. At that point the agent isn't the system. The queue is the system.

That's exactly the MRP mistake Goldratt was describing. New capability arrives. Old rules stay in place. The organization gets a more efficient version of the old outcome.

What rules should we use now?

If the limitation has changed, the rules have to change with it.

That usually means defining architectural guardrails earlier and more clearly, because you cannot rely on line-by-line review as your main control mechanism anymore. It means reviewing at meaningful checkpoints instead of treating every commit like a governance event. It means letting work happen across the stack in parallel when the dependencies are understood, rather than forcing a relay race because that's how human teams used to stay coordinated.

It also means replacing some manual sign-off with automated verification. If agents can produce ten times the change volume, then quality control has to live in tests, contracts, fitness functions, observability, and clear acceptance criteria. Senior engineers become less like code producers and more like system designers and outcome verifiers. That's not a demotion of engineering judgment. It's where the judgment becomes most valuable.

And the cadence changes. Not recklessly, but honestly. If the capability now supports faster iteration, you don't keep a two-week rhythm just because the calendar is familiar. You choose a decision cycle that matches the actual constraint.

That's the flashlight Goldratt gives you. Not "use agents everywhere," but "look at the rule you kept after the limitation moved." If you want the gains, that's where to look next.

The Reports Are Running Overnight Now

The presenter in that conference room isn't failing. He's doing exactly what most organizations did with MRP in the 1980s: he bought the capability, integrated it responsibly, and kept the process intact. The agents are running. The reports are being generated. Nobody is taking a risk.

They're just still running them monthly.

Goldratt watched this same movie play out again when ERP arrived in the 1990s. Companies that had missed the MRP window tried to catch up with the next wave of software. Some still carried over the same unchanged decision cadences, the same approval structures, the same assumption that the technology would deliver the gains on its own. Many got the same results.

The technology changes. The constraint migrates. The organizations that win are the ones willing to look honestly at which rules they're following because the limitations still exist — and which ones they're following out of habit.

Your agents can run overnight. The question is whether you'll run the reports weekly.