One Day, $1,000 in Tokens: An AI War Room for Legacy Code — Ford Prior, GEICO

Ford Prior, a senior staff engineer and tech evangelist in GEICO's claims technology group, describes an AI-native multiplayer war room built to unblock major, outer-loop software changes. The talk covers a one-day, $1,000 token experiment across rentals, damages, and salvage legacy domains, the FleetKit markdown rulebook that steers the agent fleet, the worksheets and design artifacts it produced, and the cost, model-selection, and tooling lessons that shape what comes next.

8 min read
One Day, $1,000 in Tokens: An AI War Room for Legacy Code — Ford Prior, GEICO
source: https://www.youtube.com/watch?v=DouK81O8R3o

Ford Prior opens with a tension that many teams will recognize: coding got fast, but the outer loop of decisions, sign-offs, and context stayed slow. Borrowing Jean Kim’s inner and outer loop framing, he argues that GEICO has accelerated the building step, yet the surrounding risk-driven process still sets the pace. As he puts it, GEICO is ’not a tech company, we’re a risk management company,’ and that risk posture shapes how software gets developed and delivered.

The Capacity Problem

GEICO thinks about its work in semantic versioning terms. Six months before this experiment, the team found that engineers, after patches and minor upgrades, had roughly 25% of their bandwidth on a good day for major, V1-to-V2-style changes that keep the company competitive. The first response was to offload patch and minor work to GEICO-managed AI agents across several harnesses and models, from spec through deployment, so engineers could focus on major work.

Major work, however, is limited by two things: the ability to assemble the right people at the right moment to make decisions, and the intelligence to weave together every variable in the problem space, including fact-checking and code analysis, quickly enough to match the pace of decisions. Ford’s diagnosis is that the missing pieces are collaboration and intelligence at the major-change scale.

The AI-Native War Room

The answer was a multiplayer, AI-native war room. It has three components: a roster of decision makers and subject matter experts relevant to the topic, a driver who operates the expensive AI tooling, and an AI-native productivity suite. The suite includes comms channels, an interactive design studio, and code repositories, all wired together with workflows, agent skills, MCPs (including enterprise MCPs), and agent fleets that handle the heavy lifting.

The guiding question was: how might we accelerate delivery of agent-callable APIs for legacy core capabilities? GEICO’s legacy claims systems run to millions of lines of code, so the deep context built during this work is meant to be built once and reused.

The One-Day, $1,000 Bet

Ford’s bet was that with $1,000 in AI tokens and one day, a team could map one domain end to end, including graph representations of business topology and complex legacy code, and then have an agent find and propose one serious change. They scoped that change to an agent-callable API into the legacy claims systems, deployed it to their skills agent platform, and demoed it to his boss at 4 p.m. He describes putting that pressure on himself deliberately.

They ran the experiment three times, using a taxonomy borrowed from the Anthropic code modernization plugin: uplift, transform, and reimagine.

  • Rentals (uplift): The simplest domain, covering the technology behind getting customers rental cars after an accident. They reimplemented a newer version of existing tech and extended an existing API. The agent connected data points to show that giving customers up-to-date rental information would save 8,500 calls per month.
  • Damages (transform): Damages is the process of putting dollar values on a reported loss. The team built new agent-callable APIs to unlock a larger workflow that needed damages data.
  • Salvage (reimagine): Arguably the most complex domain, covering everything that happens when a car is totaled. The output was a fully vetted migration plan with API specs and design mockups, ratified by product and technology leadership at every level. The agent also surfaced a production bug, which Ford says was shocking, though he could not discuss it further.

He emphasizes that a vetted project plan with everyone aligned is itself a milestone that usually takes a long time to reach.

Vendor Versus GEICO: What Is Replaceable

The architecture splits cleanly into two halves. On the vendor side (Anthropic’s contributions) sit the harness, the model, FleetKit, and the code modernization plugin. Ford notes that any of these could be swapped for another vendor, model, or framework.

On the GEICO side sit the things that cannot be replaced:

  • Context: a knowledge base with software standards and years of past decision archaeology.
  • Tools: the list of tools the agent can access on his machine, plus instructions for using them.
  • Methods: the skills and the quirky, highly optimized, domain-specific way GEICO develops software.
  • Judgment: who can decide what, and at which gate, from both the subject matter expert and leadership perspectives.

These are split across repos so that agents and humans can both add to and correct them.

FleetKit: Steering the Agent Fleet

Running AI at scale is expensive, so Ford argues that a ‘PhD-level fleet manager’ is needed. FleetKit, developed in collaboration with Anthropic and not yet open source, is a tightly structured collection of rules, protocols, and instructions written in Markdown. It is optimized for the Claude harness and designed around architecture transformation. Ford suggests that newer Opus-class models are what make this kind of high-level steering workable, since FleetKit sits one level above the system prompt as rules the agent must follow.

The workflow is simple. FleetKit takes a goal and breaks it down. It dispatches leaders to research and decide on the approach. Their output goes into a human-in-the-loop queue, which could be GitHub issues, where humans comment and approve, and other agents add context. Once everything looks right from an approval standpoint, it dispatches builders to do the rest. Beads helps the agents track their own state. The end goal is a ‘material change,’ either a change request into internal systems or a code change in a repository. Ford’s framing is that software development should look less like painting on a canvas and more like running a factory.

Inside the War Room

Each mission gets a dedicated channel where relevant people are invited. The agent follows a nine-step process, with the first step being booting, and at each milestone it produces one of two artifact types.

The first is worksheets: HTML artifacts built with Claude artifacts that people fill out, with autosave. They surface gaps by asking the questions teams had not considered. Ford describes them as high-quality, not the kind of dumb questions people expect from an agent. The second is design documents, including complex architecture visualizations that did not exist before. Teams kept many of them afterward because they mapped things nobody had taken the time to document, since not every engineer enjoys diagramming. People can edit these in draw.io or Figma, and the agent rereads the edits.

The agents come in two types. Cloud-based code dives perform heavy code crunching and graphing of legacy domain-specific languages. Local agents run on the driver’s laptop with access to MCPs, many not yet in production, and surface valuable data such as chunked versions of the codebases under analysis. A bindings file describes the machine and maps it to the FleetKit work. The laptop served as the runtime. Steps were forked from the code modernization plugin and adapted to GEICO’s needs, with orange-colored worksheet steps requiring human approval. The plugin also performs deterministic checks to confirm that each step produced the artifacts it needed.

Lessons and What Comes Next

Ford is candid about the costs. His top takeaway is not to let Claude running a high-end model set up cron jobs to check on work, since each check launches a new session and burns the budget quickly. Prompt caching was much higher than he expected, and he noticed quirky subagent behavior.

Benchmarking against recently written, trusted code as golden data showed that Sonnet 5.5, transcribed as ‘Fable Sonnet 55,’ wrote legacy code as well as or better than the top-tier model, which he takes as a reason to invest in model selection.

Looking forward, he expects enhanced gate enforcement to be the biggest win, along with better decision models inside the harness and model selection framework. The context is currently just Markdown files, and he is looking for a better way to search and graph it, having considered tools like graphify and Obsidian. He also wants audio to become a data source: meetings currently require him to take furious manual notes, which is lossy and distracting. Finally, he suggests that others find a group in their organization that struggles to make decisions, deploy the approach there, and control the cost. GEICO’s next question is where to place humans in the loop as agents climb one hill, so that its best engineers can choose the next hill.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

What Is Loop Engineering? Building Better AI Agents

What Is Loop Engineering? Building Better AI Agents

Martin Keen explains loop engineering as the next step beyond prompt engineering: designing systems where AI agents act, observe, adjust, and repeat toward verifiable goals. The discussion covers goal design, triggers, context and persistent state, tools via MCP and APIs, verifier subagents, and why humans must remain in the loop to manage comprehension debt, intent debt, and cognitive surrender.

Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto

Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto

Abhi Arya from Reducto shares how the team went from a one-tool-per-endpoint MCP server that confidently built workflows nobody could explain to a design that makes uncertainty visible, asks instead of guessing, and improves itself through instrumentation. The talk centers on one question: who pays when the agent is wrong?