Iterating with prompts without losing control of the project

Iterating with AI means small changes, verifying each step and clearing context in time. How to give verification criteria and correct early.

info Quick Definition
Iterating with prompts means building something with an AI in small steps: ask for a change, check it, correct it if needed and move on. It keeps you in control because each step can be reviewed and, if something goes wrong, undone.

Why does asking for everything at once go wrong?

A long prompt with ten requirements produces a result that is hard to review. If something fails, you do not know which part caused it. And if you correct it by asking for something else on top, the AI works with a more confused context. Anthropic’s Claude Code guidance summarizes it this way: the context window is the most important resource to manage, and performance degrades as it fills. A session full of irrelevant information can make the AI forget earlier instructions or make more mistakes (Anthropic, Claude Code best practices).

So the practical rule is to ask for one change at a time and verify it before the next. If you are not yet clear on this way of working, start with what is vibe coding.

How do you give the AI a way to verify?

Anthropic’s guidance warns that, without clear success criteria, the AI can deliver something that looks right but does not work. Without a way to check, that impression is the only signal, and the person becomes the only verification loop. The fix is to give it a criterion that returns pass or fail: tests, a build, a linter or a screenshot to compare with the design.

For an interface, the criterion can be the list of states that must exist (with data, empty, loading, error) or a screenshot compared with the design. For a text, it can be a list of tone rules checked one by one.

Compare three ways of asking for the same thing:

Weak promptPrompt with verification
“Write a function that validates emails”“Write validateEmail. Cases: user@example.com is valid, usuario is not, user@.com is not. Run the tests when you finish”
“Make the dashboard look better”“This is the design screenshot. Implement it, take a screenshot of the result, compare and list the differences”
“The build is failing”“The build fails with this error: [paste]. Fix it and verify the build passes; do not hide the error”

Explore, plan, then write code

Another practice from the same guidance: separate exploration from implementation. Asking the AI to read the code, understand how it works and propose a plan before touching files avoids solving the wrong problem. The plan can be edited before the AI runs it, and tools like Claude Code have a plan mode built for this. That separation is part of the flow described in spec-driven development.

It is not always necessary. If the change fits in one sentence and affects one file, asking directly is faster. A plan is worth it when you do not know the code or when the change touches several files.

Correct early and clear in time

Osmani recommends working in small steps: “Small, incremental testing prevents nightmare debugging sessions”, and treating generated code like code from a junior developer that needs review before it is merged (Osmani, Beyond Vibe Coding).

Three correction rules:

  1. Correct as soon as you notice the drift. Stopping the AI mid-change saves more time than waiting until the end.
  2. If you correct the same thing more than twice, clear. The session fills with failed attempts. A clean context with a better prompt usually wins.
  3. Separate tasks. One session per task. What is unrelated to the current task only gets in the way.

Restore points also help. Many tools save the state before each change, so you can go back to an earlier point. Note that those points do not replace Git, because they do not capture changes made from the terminal.

Example

Illustrative example: a designer wants a searchable FAQ page. Instead of asking for everything, she takes four steps: first the list with test data, then the search box, then the empty state, and finally the mobile version. After each step she looks at the screen and checks the console. In the search step, the AI renamed a component that another page uses; she spots it in the test of the previous page and asks for a fix before continuing. Four small steps cost less than one prompt that failed everywhere. The same method applies to going from idea to app in a day and to debugging, covered in debugging with AI.

How to apply it tomorrow

  1. Pick a task from your week and split it into four steps you can review separately: data, structure, behavior and finish.
  2. Before each step, write the criterion you will use to accept it, in one sentence.
  3. If a step fails twice, change the description, not the insistence: clear the session and rewrite the prompt with what you learned.
  4. At the end of the day, note how many prompts you needed. That number will show whether your first descriptions improved with practice.

Common mistakes

  • Asking for ten changes in one prompt.
  • Correcting the same thing five times in one session.
  • Accepting changes that “look right” without testing them.
  • Keeping a session with tasks that have nothing to do with each other.
  • Asking for an explanation and not verifying it, or trusting a sentence just because it sounds confident.
  • Believing the AI’s history can replace Git.

Sources

Frequently asked questions

What does iterating with prompts mean?
Building something with an AI in small steps: ask for one change, verify it, correct if needed and continue, instead of asking for everything at once.
What should I do if the AI keeps making the same mistake?
Stop correcting in the same session. Clear the context and write a new prompt that includes what you learned from the failed attempts.
How do I know an AI change is right?
Give the AI a way to verify it: tests that pass or fail, a screenshot to compare with the design, or a command you can run. Without verification, ‘it looks right’ is the only signal.
When is a long session fine and when should I clear the context?
A long session works while you are on one complex problem. Between unrelated tasks, clear the context, because old information can degrade new answers.