Jarvis · chapter 2 of 4

What I lost rewriting my AI agent system

I rewrote my AI agent system from scratch and kept the old app's 307 screens as the design, but only 8 of 208 lessons from the old version fully carried over.

At 14:58 UTC on October 10, 2026, one commit titled “Jarvis 2.0 starts here” deleted 1,526,985 lines across 5,605 files, about 1.53 million lines. It kept the 307 screens of v1’s three Apple apps and almost nothing behind them. The next day an audit checked 208 lessons from v1 against the new pipeline. 8 were honoured.

A rewrite throws away code on purpose. It also throws away what the code had learned, unless something carries it across.

What What happened to it Detail
v1’s screens Kept as the spec 307 across Mac, iPhone, Watch, and shared views, ported as they were onto fake data
Designs not yet built Mostly kept 106 of 120 baked into v2
The daemon and its store Rebuilt ports and adapters and the repository pattern; RunnerStore and v1’s 40 daemon packages deleted
The Swift apps Dropped on October 12 one React web app in their place
Pipeline mechanisms Ported on purpose 35 audited, from the merge train and failed-batch bisect to load-based admission
Personal features Dropped call recording, meetings, a personal CRM
v1 itself Frozen on a branch in the same repository

What I believed

I believed starting clean was cheaper than fixing in place. “It’s obviously a lot easier to fix it from when you’re trying to build from scratch than try to retroactively go fix everything.” The audit that morning had found a 271-method class, and the estimate for fixing it in place ran longer than the project had existed.

The agent argued the other way. “The code mostly works. … A rewrite would rebuild all of the behaviour from scratch and take longer than fixing the structure.” It recommended a strangler rebuild “in the same process on the same port, behind the same API,” and named the risk of the big bang: “Nothing is usable for weeks.” I chose the reset anyway. I kept every screen, because they looked right, and replaced everything behind them.

What broke

The lessons didn’t come across by themselves. The port audit on October 11 scored the 208: “HONOURED: 8, PARTIAL: 89, VIOLATED: 27, MISSING: 55, N/A: 29.” Three of the misses showed up in v2’s first week.

  • The merge train. v2 launched without v1’s landing path, merging one PR per tick, and 62 PRs piled up before it came back. Landing only the tree the gate tested has that one in full.
  • The quota rule. v1 had learned to spend the subscription seat whose limit resets soonest. v2 rewrote the choice as “most room left,” which would have picked a seat resetting in 143 hours over one resetting in 30.
  • The Claude builders. v2 started Codex-only, to use a temporary surplus of Codex quota, and the v1 cleanup deleted the Claude builder path because nothing in v2 referenced it. Those lanes had merged 200 cards to Codex’s 38 in 48 hours. They came back on October 16. The write-up of the loss says it best: “a capability nobody in v2 used yet looked dead.”

“I think it’s hard when you try to start something from scratch to take all the learning and lessons and port them over. Even if you try, it’s really hard to do that unless you’re very systematic about it.”

What I do now

Port on purpose. The 35 pipeline mechanisms came across through an audit table, one row each, not through anyone’s memory of v1. Every lesson the fleet learns goes onto a bake list for Jarvis to absorb, and since October 17 a new entry that doesn’t name the check enforcing it, or say why no check is possible, fails the pipeline’s own gate. And “nothing references it” is not proof that code is dead. A capability the new system hasn’t needed yet looks exactly like one it never will.

v2 is a spec-first build: contracts first, every screen running on fake data, the back end arriving one domain at a time. That choice has a price I’m paying now. A spec-first rewrite “causes issues of its own where you don’t see anything running for a long time and that’s kind of what I’ve done with V2.” I “still don’t have … really anything that’s running in V2 that I can use on a day-to-day basis.”

The other road is the one v1 took. “If so then you need to be willing to kind of start with the minimal viable product, right? The MVP and keep on growing onto that as you need it.” v1 was running inside a week, and that’s how it lost Omnigent’s landing rule. Either road, the job is the same: “keep track of the lessons that you previously learned and find ways to bake it in whenever you can.”

What’s still open

v2 isn’t something I use every day yet. The fleet runs every day, building it. The babysitter, the agent session that has supervised shipping from outside since v1, was supposed to be absorbed into Jarvis by now, and it hasn’t been. The prose rules carried over from v1 are still being converted into checks.

I don’t know yet whether spec-first was the right call. I’ll know when v2 runs my day. Where the rules live is the part of the rewrite that’s already paying.

This project

This project, in order

Start

Tell me what’s stuck

I’ll tell you in about a day whether I’m the right person. The first conversation is fit, not a free architecture review.