Sigao
A modern cyan train waiting at a daylight platform while old machinery is craned off the track ahead.
All posts
Operating model·5 min read

Why your legacy stack is the real blocker to AI leverage

You don't have an AI tooling problem. You have a systems problem. The fastest agent in the world still moves at the speed of the codebase it's editing.

By McCaul Baggett

Most of the teams that call us about AI have already bought the tools. Copilot, an agent harness, a few seats of something newer. The pilot looked great. Then the lift never showed up in the numbers, and now someone on the board wants to know why.

The answer is usually the same. The tools aren't the bottleneck. The system underneath them is. A legacy stack that's slow for humans is slower for agents, and the gap is wider than most teams expect.

This stopped being anecdote in 2024. The DORA State of DevOps report, the largest ongoing study of software delivery, drawing on about 39,000 professionals that year, found that AI adoption was associated with *worse* delivery, not better: for every 25% increase in AI adoption, throughput dipped an estimated 1.5% and delivery stability fell 7.2%. In the same survey, 39% of respondents said they have little or no trust in AI-generated code. Read those together and you get the story of the last two years in one sentence: the tools landed in systems that couldn't absorb them, and the systems won.

Speed is a property of the system, not the tool

An AI agent doesn't ship a change. It proposes one. The change still has to compile, pass tests, clear review, deploy, and survive in production. The agent only touches the first step. Everything after it runs at the speed of the system you already have.

If your build takes twenty minutes, the agent waits twenty minutes. If your tests are flaky, the agent's output is as untrustworthy as anyone else's. And when a change touches four services with no clear contracts between them, the agent makes the same mistakes a new hire would, except faster and at higher volume.

You can put a faster engine in the car. The road still decides the speed.

What the agent touches, and what decides the speed

Stage times illustrative. The agent accelerates the first box; lead time lives in the other four. A faster engine doesn’t change the road.

Where legacy systems starve agents

The same handful of things show up on nearly every modernization engagement we run:

  • No fast feedback loop. Slow or flaky tests mean nothing gets verified quickly, human or agent. Agents make it worse, because they generate more changes to verify, not fewer.
  • Implicit contracts. When the rules of a module live in someone's head instead of in types, tests, or a spec, an agent can't read them. It guesses. Sometimes it guesses wrong, and you find out three sprints later.
  • Tangled boundaries. A change that should touch one thing touches six. Your engineers navigate that with tribal knowledge. Agents don't have it, so they either over-reach or stall.
  • No safe path to production. If shipping is manual, risky, and rare, faster generation just creates a bigger queue in front of the same narrow door.

None of these are AI problems. They were already taxing your team. Stripe's developer survey found engineers spending more than 17 hours of a 41-hour week, roughly 42%, on maintenance, debugging, and bad code before a single agent showed up. AI made the tax visible by removing the one constraint, typing speed, that used to hide it.

It can also make the tax grow faster. GitClear's analysis of 153 million changed lines of code found churn, where lines are reverted or reworked within two weeks of being written, on track to double against the pre-AI baseline, with copy-pasted code rising and refactoring falling. In a system with weak tests and unclear boundaries, faster generation doesn't mean faster delivery. It means faster accumulation.

Modernization is AI-readiness

This is the reframe we push hardest: modernizing your stack and getting AI-ready are the same project.

Fast tests, clear contracts, clean boundaries, a safe deploy path. That work lets agents move, and it lets your senior engineers move. So you're not standing up AI infrastructure as a separate initiative. You're paying down the debt that was already capping your delivery speed, and AI leverage falls out of it.

That helps the budget conversation. You're not asking a CFO to fund an AI science project. You're asking to fix the delivery system, with AI leverage as the return.

The honest trade-off

This is slower than buying more tools, and we won't pretend otherwise. Redesigning the systems an agent runs against is real engineering. It takes senior judgment and it takes time. A team under quarterly pressure will feel the pull to buy another seat instead. We understand the pull. We've also watched it fail, repeatedly, for the same reason every time.

The teams that got durable leverage from AI didn't find a better tool. They made their system one a person, and therefore an agent, could actually move through. The tool was never the hard part.

The Sigao take

If a pilot stalled and you can't say why, start with the system, not the next tool. Look at your feedback loop, your contracts, your boundaries, and your path to production. That's where the leverage is hiding. Fix those, and the tools you already own start earning their keep.

Sources