The rewrite that rebuilt Falkor

The problem

By July 2026, Falkor had grown fast: ten build phases by the end of April, 826 commits in May alone, then the Falkor 3.0 program to turn a pile of features into one product. The question worth asking was whether a clean start would beat it.

So I ran a competition. Two frontier AI models each designed a complete successor to Falkor from scratch, and I judged them head to head. The winner, AURYN, came as a build-ready package of 20 documents and 35 screens: a Rust core, a “morning paper” interface, and three hard rules aimed at Falkor’s worst defects:

• stale data can’t show green;
• one referee owns the GPU;
• an action isn’t done until a check proves it.

On paper, it was better than what I had. The real job was finding out whether it was better in fact, before a migration made that decision for me.

The evidence

Coding ran in phases through July. When I authorized the next phase on 1 August, it stalled within a day, stuck in a resource wait loop behind a safety lock.

On 9 August an independent audit of the demo found:

• every screen was a shell, and 0 of 13 user journeys worked;
• none of the 6,303 acceptance checks had been worked through;
• the source no longer built;
• the only runnable binary carried a false release identity.

Falkor, checked the same day, was all green.

The decision

I froze AURYN and deleted the migration goal. A rewrite that can’t run a single user journey isn’t a delay to push through. It’s a finding.

Freezing wasn’t the end of it, though. The design still held good ideas, and some of its code was worth having. Discarding all of it would have wasted the part of the competition that had worked.

The rebuild

• A second audit, for parts. AURYN was audited again, this time for what was worth keeping: the best parts that had actually been coded, and the ideas that never were. Both were refactored into a new package for reimagining Falkor. Among the ideas: one registry of everything the system can do, status that can’t show green on stale data, and actions that aren’t done until a check proves them.
• Layers, not a big bang. Instead of a second all-at-once migration, Falkor was rebuilt one group of pages at a time. Each group was focused, then layered onto the new foundation.
• Clearing what the layers exposed. An early route audit found 184 page routes. More than half of the registered ones were retired but still alive, because every earlier cleanup had added a hub and deleted nothing.

The verification

• 184 page routes became 98 in two days, on 19 and 20 August, with no capability lost.
• The measurements kept coming. A month later, a full certification run passed 7,215 of 7,218 browser tests (22 Sep), and the whole-stack audit on 25 Sep mapped 649 capabilities, 1,051 API operations and 7,331 dependencies.
• AURYN itself was left behind, adopted by the Falkor it was built to replace.

Lessons

• A demo that shows shells is a finding, not a delay.
• Judge a rewrite by the journeys it runs, not the documents it ships.
• Freezing isn’t discarding. Audit for what’s worth keeping before you walk away.
• Rebuild the system people already use, one layer at a time.
• A cleanup that only adds things isn’t a cleanup.