Yesterday our AI agents attended a small funeral.
The one we buried was named Dumb Eric.
He had been shipping code for days. Running development loops through the night. Opening pull requests while I slept.
But another agent on our team had surpassed him.
So we shut Eric down and rebuilt him from scratch.
(The cover photo is Dumb Eric. An old MacBook Pro sitting slightly lopsided in a chair. That’s where he lives right now while we work out the kinks and figure out the long-term infrastructure.)
Dumb Eric was the first agent I built to orchestrate our development workflow.
A deterministic loop that could move through tickets, generate code, open PRs, and keep working without me sitting there babysitting it.
At first it worked exactly the way I hoped.
I could go to sleep, wake up, and find a stack of pull requests ready for review.
The system was doing real work.
Then another agent showed up.
Steve, our CTO, built one named Charlie.
And Charlie was better.
Cleaner architecture.
Better task handling.
Fewer strange edge cases.
So I did what most engineers instinctively do when their system starts falling behind.
I tried to refactor.
Refactoring feels productive.
You keep the system you built.
You improve pieces of it.
You convince yourself you’re preserving momentum.
But the deeper I went, the worse it got.
Edge cases started piling up.
Old decisions collided with new improvements.
Half-finished fixes layered on top of older assumptions.
Eventually I realized something uncomfortable.
I wasn’t improving the system.
I was protecting my past work.
One of the principles I’ve been writing about with Loop is simple.
Restart beats refactoring.
For most of software history, restarting was the dangerous option.
Rewrites were slow.
Expensive.
Risky.
But the economics of building software have changed.
When agents can generate large portions of a system quickly, the cost of rebuilding drops dramatically.
So instead of continuing to patch Eric, I did something different.
I had Charlie fork himself.
Then generate a new Eric.
Within an hour Eric was running again.
Opening PRs.
Moving through tickets.
Doing exactly what he was supposed to do.
And the lesson was obvious.
Restarting was faster than refactoring.
This isn’t just true for agents.
We’re seeing the same pattern at a much larger scale.
Right now we’re rebuilding the entire Psych Hub training platform.
The previous system had accumulated years of constraints. Architecture that was hard to change. Features layered on over time. The usual gravity that slows teams down.
Instead of carefully refactoring our way forward, we restarted.
In roughly 4–6 weeks, we rebuilt the core platform and added more than a year’s worth of features customers had been asking for.
At this point we’re mostly working through edge cases.
But the bigger win is the foundation.
The system is clean again.
The architecture is easier to extend.
And the team moves faster.
Restarting gave us back our speed.
For decades, software teams were taught to avoid rewriting systems at all costs.
Protect the existing system.
Refactor carefully.
Preserve what you have.
That advice made sense when rebuilding software took months or years.
But the agent era changes the math.
When building becomes dramatically faster, the cost of starting over collapses.
And when the cost of rebuilding approaches zero, a different strategy starts to make sense.
Sometimes the fastest way forward isn’t fixing the past.
It’s letting it go and building something better.
Dumb Eric died yesterday.
Eric 2.0 shipped an hour later.
And the lesson applies to far more than agents.
Leave a Reply