The Iterative Developer in the AI Era
If I had to name the one trait that defines how I build software, it’s that I’m highly iterative. Rather than trying to ship the perfect thing on the first pass, I like to ship something imperfect, see how it behaves, and improve it from there. This has always been a personal preference of mine, but with AI tooling I’ve found it makes a much bigger difference in how quickly I can ship.
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. As a result, writing the first version is no longer where the time goes. Most of the effort now goes into figuring out whether the first version is the right one.
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. For example, I’ll notice edge cases I didn’t think of, or a UX flow that seemed fine in the design but is awkward when I actually click through it. This kind of feedback only shows up once the code is running somewhere real.
When Is Broken Code Okay?
I have no problem with code being broken in a production-like environment as long as customers aren’t touching it. For example, a staging environment, a feature-flagged path, or an internal-only deploy are all places where broken code teaches you something without hurting anyone.
The first version rarely ships to customers as-is. It usually teaches me what the customer-facing version should look like. From my experience, the cycle of shipping something, using it, noticing what’s wrong, and fixing it produces a better end product than trying to design everything perfectly up front and shipping once.
However, this only works if the cost of being wrong in prod is close to zero.
What a Company Has to Do to Support This
From my experience, this is where companies make or break iterative development. An iterative developer with AI tools is fast, but if the company’s process punishes broken intermediate states, the whole loop collapses and you end up back in “design perfectly, ship once” mode.
A company that wants to support iterative development needs to invest in a few things:
- A staging or pre-prod environment that actually mirrors production. 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 code only affects the people you choose, which keeps the blast radius of a bad iteration small.
- Fast deploys. If shipping a fix takes hours, iterating stops being practical. It needs to take minutes.
- Strong observability. Iterating depends on seeing how the code actually behaves, and logs, traces, and metrics are how you get that feedback.
- A code review culture that treats each diff as a step in the process. Reviews should catch real problems rather than stall iteration, since the current diff usually isn’t the final one anyway.
- 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. In fact, most of them show up in the DORA research as markers of high-performing engineering teams. However, they matter much more when you pair them with a developer who’s willing to ship an imperfect first cut and AI tooling that can produce that first cut quickly.
Getting the Best of Both
Being iterative by itself isn’t enough. I’ve found that iterating without good tools is slow, and that having good tools without organizational support is frustrating. When both are in place, it’s the fastest way I’ve found to ship good software.
While this isn’t an exhaustive list, these are the things I’ve seen make the iteration loop work. If you’re an engineer, I’d encourage you to get comfortable shipping an imperfect first version. And if you help run a company, it’s worth asking whether your process rewards iteration or punishes it.
// END