At Goldman, I was part of a small team that built the pre-jQuery JavaScript framework used by browser applications across Banking Technology. A mentor told me software wasn't done until it had been refactored three times. I didn't take three as a quota. The point was that the first implementation captures the first understanding of a problem. You have to work through it before you can see what is actually stable.
Developers across Banking Technology depended on the framework, so the interface mattered far more than the classes and libraries behind it. If we kept the promise small and deliberate, we could keep improving the implementation without forcing everyone else to change with us.
Agentic coding changes the economics of that lesson. For the systems I'm building now, another implementation is effectively free. Understanding the problem still costs something. So do judgment and the work of matching the problem to a useful pattern. I now spend more of my time deciding what role a system should play, what a person or agent should be able to ask of it, and which promises need to survive a rewrite.
What survived the rewrites
I started Maverick in the summer of 2025 because a chat transcript was a
terrible place to keep a project. By September, its local directory held plans, conversations,
decisions, instructions, and artifacts. I moved 323 files into a visible FlightPlan directory,
built web and desktop interfaces around it, then archived the Next.js version and started another
one. When I later found different versions on two computers, I still didn't reconcile them
(apparently source control wasn't the problem I was interested in solving).
The code kept changing, but the interface was becoming clearer: one project conversation, with substantial work moving into focused threads behind it. I described that as the chief of staff pattern. The plans, decisions, corrections, and reasons survived each implementation and gave the next one somewhere better to start.
The models were changing too. Workflows that once needed application code could increasingly live in a skill or command. By February, I had started separating Maverick's lower-level identity, memory, routing, and communication into Voxelbox, a local agent system I could use across projects. That let Maverick return to the problem I wanted it to solve: guiding agents through the work of testing and building a company.
The same reasoning has raised my threshold for SDKs. I still use libraries that contain years of work I don't want to rebuild. When they don't, I increasingly prefer a small amount of code I can inspect, own, and replace. I don't keep an implementation simply because I already paid to build it.
The old versions are still in git. I expect to rewrite both systems again.