There was a time when legacy code modernization meant multi-quarter roadmaps, repeated context-building sessions, and decision loops that stretched for months. The code changes themselves were a fraction of the work. The rest was coordination.
That ratio is starting to shift — but not quite in the way most teams expect.
The inner loop is already fast
For many engineering teams, AI now handles the routine coding: patch work, minor refactors, boilerplate generation. The constraint that remains is what practitioners are starting to call the outer loop — convening the right people, building shared context across a complex legacy domain, and getting a decision ratified by the people who need to own it.
That outer loop is slow not because of bad process, but because legacy systems are genuinely hard to understand. Domain knowledge lives in people’s heads, in undocumented code, in years of accumulated decision archaeology. Before anyone can agree on what to change, they first need to agree on what exists.
What a war room actually looks like
One approach to this is a structured one-day session: a small roster of decision-makers and subject-matter experts, a “driver” wielding AI tools, and a clear challenge — map one legacy domain end-to-end, produce a meaningful change, and demonstrate it to leadership by end of day.
This format was run three times against three different claims domains at a large US insurance company: a rental claims flow, a damages valuation system, and a salvage (total-loss vehicle) workflow. Each session spent roughly $1,000 in API tokens — a meaningful but bounded investment. Each session produced either a deployed agent-callable API (a software interface that other automated systems can call directly) or a fully ratified migration plan, approved at every level of product and tech leadership.
One session also surfaced a production bug no one had known about.
The real investment is context, not code
What makes this pattern work — and what is hardest to replicate — is not the AI tooling itself. The orchestration layer used dispatches research agents to map the domain and propose approaches, puts results into a human approval queue, then dispatches builder agents once decisions are confirmed. That structure is constructible independently; it is a set of rules and protocols in plain text files, not proprietary technology.
The actual investment is elsewhere:
– Context: a structured knowledge base of software standards, past architectural decisions, and domain knowledge — the institutional memory the agents draw on
– Tools: the right enterprise integrations wired up and described in a way agents can use them
– Methods: highly optimized, domain-specific development practices
– Judgment: knowing which decisions need which humans, and at what point in the workflow
The vendor tooling is swappable. The context, methods, and human roster are the real advantage.
This is a useful corrective to a common framing. Much of the conversation about AI in enterprise settings focuses on model selection and toolchain assembly. What this pattern suggests is that the durable advantage comes from building a structured body of institutional knowledge that agents can navigate — and from being deliberate about where humans stay in the loop.
A few practical findings worth noting
These sessions produced lessons that do not make it into most architecture talks.
After the initial context was built, a mid-tier model performed as well as the flagship model for code generation — a meaningful cost difference at scale. Prompt caching (where the system reuses previously processed context rather than reprocessing it from scratch) was also higher than expected, offsetting a significant portion of the token spend.
One clear pitfall: do not let agents set up recurring background checks on their own work. Each scheduled tick spawns a full new agent session and burns through budget instantly. Supervision of in-progress work should be driven by human-triggered checkpoints or explicit orchestration, not agent-initiated timers.
The artifacts the sessions produced — architecture diagrams, domain worksheets — were kept by the teams not because they were formal deliverables, but because they documented things no one had mapped before. That may be one of the more durable benefits of the war room format: not just the API that gets deployed on the day, but the institutional memory that finally gets written down.
What comes next
The format as described is still early. Context lives in plain Markdown files rather than a proper semantic retrieval system (one that finds relevant information by meaning rather than exact keyword match). War room conversations are manually transcribed instead of automatically captured. Gate enforcement inside the orchestration layer could be tighter.
But the structural insight holds regardless of those gaps: the bottleneck in legacy modernization has never really been writing code. It is the human coordination work that has to happen before and after. What is changing now is that AI can compress the “before” dramatically — one day, one domain, shared context everyone can work from. The “after” — ratification, deployment, accountability — still takes human judgment. That division of labor is probably the right one, and worth building deliberately around.
Text summarized and optimized using Anthropic’s models and reviewed by a human.