Step 1: Build Everything - by Michael Mayernick
SubscribeSign in
Step 1: Build Everything<br>Step size used to be set by build economics. It's set by review economics now.
Michael Mayernick<br>Aug 21, 2026
Share
Every builder my age inherited the same ironclad rules: work in small batches, keep PRs narrow, merge often. Ship what you’re embarrassed by, and increment your way to the answer.<br>It was important discipline, and it kept reviews flowing and work aligned. But it also reflects a previous reality: when building was the expensive act - months of engineering time per attempt - getting something big wrong was a catastrophe. The answer was continuous, manageable review increments, which meant correspondingly small build increments. Building in small steps was not just orthodoxy; it was a logical outcome of the cost structure of software development.<br>Today, the right build increment size is the one we all learned was wrong.
But that cost structure just inverted, and most of us are still living the old gospel. Today, the right build increment size is the one we all learned was wrong: step one is the whole thing.
When agents are coding, the marginal cost of the next thousand lines isn’t so different from the cost of describing them. But as the speed of writing code has exploded, the review stage is still a lot of the same work: assessing whether the work is right, safe, and on-thesis. Comparatively, that means review - even augmented by agent reviews and test suites - has become much more expensive.<br>Thanks for reading Inside AI Native! Subscribe for free to receive new posts.
Subscribe
In my own workflow, a night of unattended agent flights routinely lands what used to be weeks of work, but my morning review hour hasn’t changed. Vishal Misra calls the general version of this the verifier bottleneck: compute buys proposals; verifiers buy knowledge. I’d push the framing even further: a bottleneck is something you can route around, but when a resource is scarce, you budget. Review time is the same on the wall clock, and comparatively it has become extremely scarce. Recognizing the scarcity means recognizing you can no longer afford the old patterns.<br>Now price it in reviews and it doesn’t look so lean anymore.
Imagine “let’s ship the simple one first” - a lean and prudent use of engineering resources. Now price it in reviews and it doesn’t look so lean anymore: reviewing the simple version before the real version doubles the review, since reviewing the final version already covers the ground the intermediate one walked. And the first of those reviews evaluates decisions you already planned to throw away. If building is expensive, the intermediate version bought you information early, before large investments were made in the product direction. When review is expensive, you just doubled the price of the same information.<br>This has given rise to a new rule in how we work: ship the version whose review teaches us the most. If reviewing the half-step wouldn’t change what we build next, skip to the whole thing.<br>Now one review was evaluating the whole feature, not the incremental build.
I was working on a mobile feature and initially planned to test it over local network only - point your mobile browser at a local IP address and start interacting with the mobile view. That’s a lean build proposal: no networking, no mobile app, just the basics. But the works-anywhere version was buildable in the same breath, and reviewing the small one first would have cost a second founder-morning for zero new information - the review was the same length, and the product came out twice as far along. We did it again with a feature for live shared agent sessions: the half-step (paste your teammate a link) was essentially the same work to build as the whole feature - a one-click invitation that lands in your teammate’s inbox. Building the latter was the same overnight flight of agent work, but now one review was evaluating the whole feature, not the incremental build.<br>But “build everything” is admittedly a bit of hyperbole.<br>We retain steps that answer important questions, and these have become more important because they’re often cheap to run and in some cases need no real review. A spike or a research pass is work that never ships into the product, so it never buys a second review. We ran a research pass on a framework decision recently that returned “don’t adopt one” in an afternoon - zero build, one decision, the cheap kind of step, and cheaper than ever.<br>Thanks for reading Inside AI Native! Subscribe for free to receive new posts.
Subscribe
Steps that hold trust boundaries also stay. Our mail feature shipped first as read-only, so we had confidence in the feature before exploring something riskier: drafting, then sending email via agents. So yes to skipping the intermediate version, and no to skipping trust building. These distinctions are becoming the new senior skills.<br>And steps that are secretly new products, or...