From iterative development to speculative development

Iterative development became the default way to build software for good reasons. Writing software was expensive, and the further you went in the wrong direction, the more expensive it became to change course.

The sensible response was to work in small increments. Build a little, get feedback, learn something, then decide what to build next. Agile, Lean, small batches, and short feedback loops all grew out of roughly the same economic reality. We reduced the size of each commitment because implementation itself carried a substantial cost.

AI changes that underlying assumption.

We are still early in the transition, but it is already possible to produce surprisingly large proofs of concept in hours. The code may be rough and some of it may ultimately be discarded, but a proof of concept only needs to be good enough to let us properly evaluate the idea.

That gives us a different way of reducing risk. Instead of carefully limiting how much we build before getting feedback, we can sometimes build a substantial version of the thing we are considering and get feedback from that.

Suppose you are considering a new architecture for an existing product. Traditionally, you might draw the architecture, implement one small part of it and gradually expand the experiment as you gained confidence.

With AI, it can make more sense to give an agent a branch and ask it to implement most of the alternative architecture. You can then run the application, put realistic data through it, measure it, use it and see where the design becomes awkward. If the approach turns out to be poor, throwing away a day’s generated code is cheap compared with spending several weeks carefully iterating towards the same conclusion.

The feedback loop still matters, but the unit of experimentation can become much larger. I think of this as speculative development.

There is a useful parallel with speculative execution in CPUs. A processor can perform work before it knows whether that work will ultimately be needed because computation is cheap enough that doing unnecessary work can still make the system faster overall.

AI gives software development a similar option. We can implement an idea before deciding whether we want to commit to it because implementation is becoming cheap enough to participate in the decision itself.

Iteration has a cost too

Small steps are often treated as the low-risk option, but they have their own costs.

Every iteration means loading the context again, deciding on the next slice, implementing it, integrating it, validating it, and often reviewing it before moving on. Architectural changes may require temporary abstractions or compatibility layers purely because the system has to remain valid at every intermediate step.

That made sense when writing the final implementation was the expensive part. With AI, the coordination around each increment can become more expensive than generating a much larger change.

Imagine a migration that could be completed by an agent across fifty files in an afternoon. Splitting it into ten carefully controlled stages may give you ten sets of intermediate states to reason about, ten validation cycles, and a collection of temporary code that disappears when the migration is finished.

The incremental route can therefore create more work than simply generating the destination and evaluating it as a whole.

There is also a subtler problem. Small iterations tend to constrain each subsequent decision around what has already been built. You can end up improving your way towards a local optimum because each step is judged relative to the current system.

A large disposable implementation lets you explore a more distant alternative without first constructing a careful path from here to there.

This is particularly useful when the thing we are uncertain about is difficult to understand in the abstract. Architecture is an obvious example. So are major UI changes, new workflows, library migrations, and substantial changes to a data model. A diagram can tell you something about these things, but a running implementation tells you much more.

The generated code does not need to survive for the experiment to have been worthwhile. Its purpose may simply be to expose the consequences of a decision while that decision is still cheap to reverse.

As AI becomes faster and more reliable, I expect this style of development to become increasingly normal. Teams will be able to generate several credible versions of a feature or architecture, evaluate each one against the real system, then keep the parts that turned out to be useful.

Small batches minimise the cost of being wrong by limiting how much work we do before learning. Speculative development can achieve the same goal by making substantial implementations cheap enough to discard.

Iteration will still be useful once we know roughly where we are going. During exploration, though, repeatedly taking small steps towards an uncertain destination may increasingly be the expensive way to work.