The Iterative Developer in the AI Era

19 May 2026

If I had to name the one trait that defines how I build software, it’s that I’m highly iterative. I don’t try to ship the perfect thing on the first pass. I ship something imperfect, see how it behaves, and then sharpen it from there.

That trait used to be a personal preference. In the AI era, it’s become a superpower.

Why This Works Well With AI

AI tooling has changed the cost curve of writing code. Getting to “something that runs” is faster and cheaper than it’s ever been. The expensive part isn’t typing the first version anymore, it’s figuring out whether the first version is the right version.

The fastest way to figure that out is to put it somewhere I can use it. Once I’m interacting with a real version of the thing, the gaps become obvious. The edge cases I didn’t think of show up. The UX awkwardness I would have rationalized away in design becomes intolerable the second I click through it. The behavior I assumed would feel right doesn’t.

None of that feedback exists when the code is theoretical. It only exists once the code is real.

Broken in Prod (When Customers Aren’t There) Is Fine

I have no problem with code being broken in a production-like environment as long as customers aren’t touching it. A staging environment, a feature-flagged path, an internal-only deploy — these are the places where “broken” is information, not a failure.

The first version is rarely the version that ships to customers. It’s the version that teaches me what the version that ships to customers should look like. The cycle of ship → use it → notice what’s wrong → fix it produces a noticeably better end product than the cycle of think really hard → ship once → hope.

The trick is that the first cycle is only viable if the cost of being wrong in prod is close to zero.

What a Company Has to Do to Support This

This is the part that matters most. An iterative developer with AI tools is fast, but if the company’s process punishes broken intermediate states, the whole loop collapses. You end up back in “design perfectly, ship once” mode — which is exactly the mode AI is best at outgrowing.

A company that wants to support iterative development needs to invest in a few things:

• A real staging or pre-prod environment that mirrors production. Not a toy. If staging doesn’t behave like prod, the feedback you get from it isn’t useful, and developers stop trusting it.
• Feature flags everywhere. Shipping behind a flag means “broken in prod” affects only the people you choose. The blast radius of a bad iteration is bounded.
• Fast deploys. If shipping a fix takes hours, the iteration loop dies. If it takes minutes, the loop thrives.
• Strong observability. You can’t iterate on what you can’t see. Logs, traces, and metrics are how the developer hears what the code is telling them.
• A code review culture that’s a checkpoint, not a gate. Reviews should catch real problems, not stall iteration on the assumption that the current diff is the final diff. The final diff usually isn’t even written yet.
• Easy rollback. The cost of being wrong has to stay low. If reverting is painful, developers will over-engineer the first version to avoid ever needing to revert — which defeats the point.

None of these are new ideas. What’s new is how much leverage they give you when paired with a developer who’s willing to ship an imperfect first cut and an AI that can produce that first cut quickly.

The Combination Is the Unlock

The trait by itself isn’t enough. Iterating without good tools is slow. Iterating with good tools but no organizational support is frustrating. Iterating with both is the fastest way I know to ship software that’s actually good.

If you’re an engineer, lean into the iteration. The first version doesn’t have to be right. It just has to exist.

If you’re building or running a company, look at your process and ask whether it rewards iteration or punishes it. The answer determines how much of the AI productivity story you actually get to live in.