3 posts tagged with "legacy-systems"

For twenty-five years, "never rewrite from scratch" has been the closest thing software engineering has to a commandment. The canonical argument rested on a cost structure everyone took for granted: rewriting means re-reading, re-understanding, and re-typing years of accumulated code, and while you do that, the old system keeps moving and your competitors keep shipping. The rewrite was forbidden because it was slow.

Coding agents just deleted the slow part. An agent can translate a hundred-thousand-line codebase from one language or framework to another in days, not quarters. Teams that ran the numbers on mainframe modernization watched average program costs drop from $9.1 million in 2024 to $7.2 million in 2025, largely on the back of AI-assisted conversion, and consultancies now report 40–50% acceleration on modernization timelines. So the commandment is dead, right? If the expensive part of the rewrite got cheap, the rewrite is back on the menu.

Here is the problem: the typing was never the expensive part. It was just the visible part. The organizations that failed at big migrations rarely failed because the code was hard to convert. They failed on everything around the code — undocumented behavior, data migration, integration cutover, and the operational muscle memory that nobody thought to write down. Agents made the rewrite cheap to start. They did much less for what made rewrites dangerous to finish.

Most AI coding demos show an agent building a greenfield Todo app or implementing a clean API from scratch. Your codebase, however, is a fifteen-year-old monolith with undocumented implicit contracts, deprecated dependencies that three teams depend on in ways nobody fully understands, and a service layer that started as a single class and now spans forty files. The gap between demo and reality is not just a size problem — it's a structural one, and understanding it before you hand your agents the keys prevents a specific category of subtle, expensive failures.

AI coding agents genuinely help with legacy systems, but only within certain task boundaries. Outside those boundaries, they don't just fail noisily — they produce plausible-looking, syntactically valid, semantically wrong changes that slip through code review and surface in production.

Every AI demo starts with a blank slate. A fresh repo, no dependencies, no legacy authentication system, no decade of business logic encoded in stored procedures. The demo works beautifully. Then someone asks: "Can we add this to our actual product?"

That's where brownfield AI begins — and where most teams get stuck. The gap between a working prototype and a production integration inside a ten-year-old monolith is not a matter of scaling up. It's a fundamentally different engineering problem, one that requires adapter patterns, careful boundary design, and a deep respect for the existing system's constraints.