You used to just upgrade your humans
The intelligence doing the implementation upgrades on a schedule you don't control. So how do you build for the rebuild?
For pretty much all of history in Tech, a team got better one way: the people did. And people get better slowly. You grew the ones you had or you paid up for someone who had already done the growing. Either way the cost was yours in both time and money. The ceiling on what you could build was the ceiling on who your people could become and who you could afford to hire.
That is definitively not the singular limit.
Between October 2025 and April 2026, six of us at SpecStory each running our own agents built Stoa. Our git log, for the most part, is a good proxy record of which Anthropic model was used to implement the code that has landed in production.
Opus 4.5: 510 commits
Opus 4.6: 890 commits
Opus 4.7: 366 commits
Our cadence didn’t stop for a single model swap. We trained none of it and benefitted from all of it. Some mornings we just opened our laptops to a better underlying model in our harness than the one we had closed it on.
The intelligence doing much of the implementation jumps a whole generation at a time, on a schedule you don’t set (notably Opus 4.8 dropped five hours ago today and based on early evidence seems to be quite spectacular). Each new version is a free upgrade to the whole team, delivered overnight, asked for or not. You don’t make the worker better. It arrives that way. The only thing you control is whether what you already built can benefit from it.
I’ve wrote two weeks ago about how the labs cannibalize their own dominance. But this meditation is about you.
Two speeds
Kahneman gave us two systems for thinking. Fast: automatic, cheap, intuitive. Slow: deliberate, effortful, expensive. Neither is better and their used based on which the moment calls for.
Building has two speeds now, and they don’t map to what they used to.
Build fast is the implementation. The code you get the model to write. It ships with an expiration date, because the next model will do it better. Write it quick and don’t get attached. I made the case for disposable software a year and a half ago and it felt like a provocation. It feels much like that now. For example:
In January I had a branch with days of commits. All green and working. The kind of code you might want to protect. I deleted it because it had turned into band-aids: pagination that called an old slow path and new endpoints that dodged a bug instead of fixing the underlying. I then rebuilt it again cleanly. I kept an artifact document about the root cause (which was the true asset) and the code was not.
Build slow is what the implementation comes from. The intent and the decisions behind it. The brief in artifact form that says what you are trying to do and why. This is the layer you keep. Be deliberate about it.
What I’ve got much better at has not been coding. It has been writing and refining the brief. First interactive prompting, then spec driven development, now goal engineering. The code is downstream and cheap.
The old split that people (still wrongly) debate is prototype versus production. Build fast to learn, build slow to last. The true new split is current functional implementation versus intent. Build fast on what the model will obsolete. Build slow on what you intend to survive the next upgrade.
Implementation has been thought of as precious because it cost a lot. Now it’s possible to completely refactor at speeds we couldn’t have dreamed about a year ago.
The expense is knowing what you meant well enough to ask for it again.
Developing on the edge
To develop on the edge is to build for the rebuild.
Build so that a model release is an upgrade you absorb and not a rewrite to dread. Treat every implementation as a draft against an intent that outlives it.
In my mind, this changes implementation in three ways:
In some cases you can stop fixing what the next model fixes for free. Every hour spent working around what today’s model is bad at is an hour you delete in two months. Learn to tell a permanent problem from an early one, and don’t pour work into the early kind.
You build things that are slightly too hard for today’s model, on purpose. The cost of being early collapsed along with the cost of being wrong. Ship the version today’s model does badly. The rebuild is nearly free and the intent is already written down. Build for the model arriving in two months, not the one you have.
You put your patience in the right place. I argued before that patience is the moat in an age of speed, and I still do. But patience moved up a layer. The moat has always been your own clarity about the future that will surpass today’s implementation.
To stand up straight—not straightened. III. 5
What’s left to you
When the worker upgrades itself, your edge can’t come from the worker. Everyone gets the same upgrade on the same day. The model that made me look good made every one of my competitors look good too the day it ships.
So your edge falls back to what the upgrade doesn’t touch: what you meant, and whether you can prove the system does it. The agent writes confident, plausible code, and some of it is wrong. It can’t see the running system. It once told me a service was stale and holding old state. I had just built the binary and run it on a clean machine. It couldn’t see that. I could. That job has not yet been fully automated. And acting as a verifier and judge is very important.
The teams that win will be those who write their intent down clearly enough to replay it against each new frontier the day it lands. Their old work becomes new work but at a lower cost. The teams who only save their code are stuck.
When the better intelligence shows up, and it will, will you still know what you were trying to build?