← Back to the feed

Rebuild, not refactor

Sherwood came together fast — about a month from an empty repo to a working trading engine. Building that fast with agentic tools that were still improving left debt from unintentional drift, and I realized I needed to re-write Sherwood.

I realized the drift was too far into the foundation when floating-point numbers I used for money drifted a fraction of a cent on every trade, risk checks were written but never wired in, and there was no way to change the database without hand-editing tables. None of those is a bug you fix in one place. You can’t refactor your way out of a poor foundation — to swap the money type alone I’d have to touch nearly every file. So I made the call: rebuild, not refactor. I archived v1 and started v2 with the constraints baked in from the first commit.

I stopped not long after. I realized that if I was going to avoid the same mistakes, I would need to change some of the fundamentals of how I was building. The agents needed more reinforcement and more grounding than I could give with even the best prompt engineering. They needed a real, durable memory beyond the few facts they remember between sessions. They needed to gain experience like any engineer you would work with, and the harnesses (Claude Code and Antigravity) I was working with didn’t have that.

Around then, durable memory for agents began making the rounds on the internet — and kept turning up in my feeds. A couple of weeks earlier, Karpathy had sketched a pattern for giving an LLM its own wiki: the model maintains a structured memory it reads and updates as it goes, instead of retrieving documents at query time. That got me experimenting. I put together a rough v0 of what became Agent M: somewhere to keep a project’s context so I’d stop repeating myself. I used it to write the v2 spec for Sherwood — the retro became a list of hard constraints, the design doc the shape to build to.

Agent M quickly took over as the project. Sherwood v2 stayed a design; the thing I actually rebuilt was the way I work. I’d set out to rebuild a trading engine and ended up rebuilding my process instead. My workflow went from one agent to two, one harness to two, one platform to multiple. My agent needed to work on all of them if I was going to make the best use of these new tools.

So “Rebuild, not refactor” turned out to apply to more than the code. When the foundation under your work is wrong — when you’re re-explaining yourself to the agent every single session — you don’t patch it. You rebuild it.

Liked this? Get new experiments by email — or grab the RSS.

Discuss → LinkedIn · X · Hacker News
← Back to the feed