Iteration Discipline: Give AI Enough to See the Destination, Not Enough to Get Lost

One of the easiest mistakes to make with coding agents is giving them too much to do at once.

It is tempting. You have a clear idea in your head, the model looks capable, and writing one giant prompt feels quicker than breaking the work down.

Sometimes it even works.

But if you want an output you can actually trust, build on and maintain, I think you need to get comfortable with iteration.

Not endless back-and-forth. Not asking the model to “try again” until something sticks.

Controlled iteration.

Give the agent enough context to understand where you are heading, but only enough responsibility to complete the next meaningful part of the journey.

Then look at what happened before you send it further down the road.

Giant prompts are usually a false economy

You can ask a good coding model to do an enormous amount in one go now.

And the amount they can handle keeps increasing.

But there is a difference between what a model can attempt and what you should actually ask it to do.

If your prompt effectively says:

Build this feature, redesign this page, create the interactions, tidy the architecture, make it responsive and fix anything else you notice.

you might get something that initially looks impressive.

You might also get five different design decisions you never asked for, three bugs buried underneath them and a new architecture you now have to understand before you can work out which bit has gone wrong.

For throwaway experiments, that can be fun.

If I asked a model to make me a Mario-style platform game, I could probably let it rip. There is enough material out there for a strong model to produce something recognisable.

But if the result is full of bugs and vaguely resembles something I could already play on a Super Nintendo, what have I really gained?

For work you actually care about, “look what the AI made” is a pretty low bar.

Find the size of one comfortable push

A big part of working well with coding agents is developing a feel for how much work you can give them in one pass.

There is no perfect number of files, tasks or lines of code.

It depends on the model, the codebase and the type of work.

You get a feel for it over time.

What makes this more interesting is that the answer keeps changing. Models are improving quickly, and they regularly surprise me with how much they can take on comfortably.

But model capability is only half of the decision.

The other half is how much control you want to keep.

A model might be perfectly capable of implementing four parts of a feature in one run. But if each of those parts involves a design decision, you have also handed over four opportunities to steer the result.

That can create more work later.

The question therefore isn't just:

Can the model do all of this?

It is also:

Do I want the model making all of these decisions before I see any of them?

That is where iteration starts to become useful.

Show the destination, constrain the current stage

I used to think breaking a larger task down meant I had to hold the entire plan in my head.

That creates its own problem.

You end up mentally managing all the dependencies, worrying about exactly where each prompt starts and stops, and sometimes breaking the task down further than it really needs.

The approach I now prefer is to tell the agent about the whole job first.

Something along the lines of:

We are going to implement this in three stages. The overall goal is X. Stage one will establish Y, stage two will add Z, and stage three will finish the remaining behaviour. For now, work only on stage one. Once that is complete, stop so we can review it before continuing.

The agent understands the destination.

It knows that what it is building now is not the finished product.

But it also has a clear boundary around what it should actually change.

That combination is powerful.

You are not starving the model of context, but you are not asking it to solve the whole problem at once either.

Let one iteration inform the next

The other advantage is that your original plan does not have to be perfect.

Stage one might reveal something you had not considered.

The agent might implement a pattern particularly well, and you decide that should become the standard for the remaining work.

Or you might realise that one assumption in your original plan was wrong.

Now you can adjust stage two before anything has been built on top of it.

Your follow-up prompt can say:

Stage one is working well. Keep the approach you used for X. One change before we continue: instead of Y, use Z from this point onward. Now proceed with stage two.

That is much easier than asking the agent to implement the entire feature and then trying to untangle decisions spread across ten different files.

Iteration gives you places to steer.

And that matters just as much as catching bugs.

Stop, inspect, and be willing to go backwards

The checkpoints do not need to become enormous code reviews.

Often I am mainly looking for two things:

Does it work?

And:

Has the agent understood what I was actually trying to achieve?

That second question is especially important after the first iteration.

If stage one has gone in roughly the direction you expected, you now have much more confidence that the agent understands the job.

You can keep moving.

If it is completely off track, stop.

Do not keep feeding it stages two and three because that was the original plan.

Revert if necessary, rethink the first step and start again.

A wrong interpretation becomes far more expensive once several apparently sensible layers have been built on top of it.

Iteration limits how far down the wrong road you can travel before noticing.

Yes, sometimes you can just let the agent rip

There is still a place for giving an agent a large task and seeing what happens.

I probably do less of this than some people because I like keeping control over where things are heading.

But for exploration it can be useful.

If you are curious whether an idea is even possible, or you want to see one interpretation before committing to it, let the model have a go.

Just recognise that you are experimenting rather than carefully implementing.

And if you are working with Git, a separate branch is a very cheap way of making that experiment disposable.

If it comes back brilliant, great.

If it comes back as absolute rubbish, delete the branch and carry on.

A simple three-stage prompting pattern

You do not need an elaborate framework for any of this.

For a larger coding task, a structure like this is often enough.

Stage 1 — establish the direction

Give the agent:

• the overall goal;
• the broad stages you expect the work to take;
• enough repository or product context to understand why it is doing the work;
• the exact scope of stage one;
• an instruction to stop when stage one is complete.

Then review the result.

Stage 2 — build on what survived the review

Tell the agent what worked.

Correct anything that did not.

If stage one established a useful pattern, explicitly tell it to preserve that pattern.

Then give it the detailed requirements for stage two.

Again, stop when that stage is complete.

Stage 3 — complete and integrate

By this point, the agent should understand both the original goal and the decisions made during the first two stages.

Give it the final scope, ask it to integrate the work cleanly, and then perform your wider checks.

The exact number of stages does not matter.

Sometimes there will be two. Sometimes there will be six.

The useful habit is simply this:

Give the model a view of the destination, but only one sensible stretch of road at a time.

The point isn't smaller prompts

It is easy to reduce this whole idea to “keep your prompts small”.

I don't think that is quite right.

Sometimes a detailed prompt is exactly what the model needs.

And sometimes modern coding agents can comfortably complete surprisingly large pieces of work.

Iteration discipline is really about controlling when decisions are made.

You give the AI enough room to be useful.

You give yourself enough checkpoints to remain in charge of the direction.

And you avoid discovering, several iterations too late, that the first turn was wrong.

As the models get better, the size of that comfortable push will keep growing.

The need to decide where you want to stop, look and steer probably won't.