Ford Prior: An AI War Room for Modernizing GEICO’s Legacy Code

For years we have tried to speed up the software development lifecycle, particularly the build phase. Coding has accelerated dramatically, but at GEICO, a risk management company, the work around it still sets the pace. The inner loop is faster; the outer loop of decisions and delivery has not kept up.

We wanted to imagine what software delivery would look like if the outer loop moved at the same speed. My team works in claims technology: after an accident, a claim is where the insurance policy comes to life and the customer is helped back on the road.

I am Ford Prior, a senior staff engineer and technology evangelist in GEICO's claims group. Our roughly 300 engineers work in about 32 teams. My role is to introduce better development practices, run a claims innovation lab and share what we learn.

Six months ago we found that, after patches and minor upgrades, engineers had at best 25% of their time for the major changes that keep us competitive. We began using GEICO-managed agents, with different harnesses and models, to handle smaller changes from specification through deployment.

Major changes still depend on assembling the right people at the right moment. They also require facts, code analysis and a growing understanding of the domain to be available as decisions arise. We needed both faster collaboration and intelligence to support it.

Our answer was a multiplayer, AI-native war room: decision makers and domain experts, a driver operating the AI tools, and shared communications, design and code repositories. Workflows, skills, MCP connections and fleets of agents carry out analysis, synthesis and checking.

The challenge was to make legacy claims capabilities callable by agents. The legacy systems contain millions of lines of code, so the context is expensive to build but can be reused. My bet was that one day and $1,000 of AI tokens could map a domain end to end and produce one serious change.

The proposed output was an agent-callable API for a legacy system, deployed to our agent platform for a 4 p.m. demonstration. We ran three experiments, using the uplift, transform and reimagine categories from Anthropic's code modernization plugin.

First, in rentals, we extended an existing API using a newer version of the same technology. The agent connected pieces of information and identified a way to give customers current rental information; Prior says this could save about 8,500 calls a month.

Second, we added agent-callable APIs to the damages domain, which assigns a dollar value to a reported loss. Third, in the complex salvage domain—the work after a vehicle is totaled—we produced a migration plan with specifications and mockups, approved by product and technology leaders. The work also surfaced a production bug.

The vendor supplied a model, a harness, FleetKit and a code modernization plugin. Those components can be replaced. What GEICO must supply itself is context: the knowledge base, standards, past decisions, available tools, working methods and the people authorized to exercise judgment at each gate.

FleetKit, developed with Anthropic and not yet open source at the time of the talk, is a structured set of Markdown rules and instructions for managing the fleet. It decomposes a goal, dispatches research leaders and places their proposals in a human-in-the-loop queue; after approval, builder agents make the change.

The queue can be implemented with something like GitHub issues, where people can comment or approve and other agents can add context. The desired result is a material change: a change request or code change in the organization's systems.

A mission starts by loading the repositories and creating a shared communications channel. Relevant decision makers and subject experts join. When the agent needs product information, it can identify and mention the person responsible rather than waiting for the driver to find them.

The agent also creates interactive worksheets to fill information gaps and editable design documents, including architecture diagrams. People can edit the artifacts and feed them back into the session. Teams kept some diagrams afterwards because they documented systems nobody had mapped in this way before.

Two kinds of agents supported the work: cloud agents performed deep code analysis and graphing over legacy languages, while local agents used enterprise-specific tools and MCPs available on my laptop. A bindings file told the agent what was available locally and how it connected to FleetKit.

The driver's laptop was the runtime. The process had nine steps including boot, scope, research, target, plan, build, test, deploy and maintain. Worksheets acted as approval gates, and scripts checked deterministically whether a previous stage produced the required artifacts.

Cost was a lesson. Prior warns against letting an agent schedule repeated AI sessions merely to check on work, because the budget can disappear quickly. He also saw more prompt caching than expected and some unusual subagent behavior.

After building the context, the team compared models on recently written legacy code used as reference data. In this particular test, Sonnet 5.5 performed as well as or better than Fable, Prior says. The result is an argument for measuring model choice against the actual task rather than assuming the most expensive option is necessary.

Next, Prior wants stronger enforcement of approval gates, better decision and model-selection methods, and improved ways to search and organize context that currently lives in Markdown. He also wants to capture conversations as audio so that the driver does not have to take every note manually.

The broader question is how to spread this approach across an organization while controlling cost and keeping people at the right decision points. As agents make progress up one hill, Prior wants engineers to choose the next hill worth climbing.