2 posts tagged with "legacy-systems"

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.