Break Big Tasks into Small Steps: Multi-Step Prompting

Last updated: 18 شهریور 1405

"Write a WordPress plugin that sells premium memberships, takes online payments and locks premium content." What you get back is several long files that look complete at first glance. Then you notice it guessed the payment gateway, the database table differs from what you needed, and half the code doesn't run.

The problem isn't the model; it's the size of the request. What you would do with a human colleague works here too: move the work forward piece by piece and check between pieces.

Why does a big request go wrong?#

Because a big request hides dozens of unspoken decisions, the model guesses all of them, and you only learn which guess was wrong at the end.

• Hidden assumptions. Payment gateway type, table structure, user roles: you didn't state any of them.
• Errors on errors. If the table structure is wrong in the first step, all the later code is built on that mistake.
• Very long output. The longer the answer, the lower the quality of its final parts tends to be, and the more likely it is to end unfinished.
• Impossible to check. Carefully reading a thousand lines of code in one go doesn't really happen. Two hundred lines you can read.

How does multi-step prompting work?#

Multi-step prompting means asking for the work over several turns and checking the output yourself between each turn. The simple pattern has four steps:

1. Clarify the need#

Before anything else, let the model ask questions:

I want to do [overall task]. Don't give a solution yet.
First ask every question you need to do this correctly,
especially about things where you might make a wrong assumption.

The answers to these questions are exactly the hidden assumptions that got lost in the big request.

2. Plan#

Now give me a work plan: the steps in order, one line each,
and for each step say which file or part it creates. Don't write code yet.

Read the plan and correct it. This is the cheapest place to make changes: changing one line of a plan takes seconds, while changing the same decision in written code takes hours.

3. Execute, one step per turn#

Do step 1 of the plan. Only this step.
At the end, tell me how to test that it works.

Test the output. If it's right, go to the next step. If not, fix it right here, before the next step is built on top of it.

4. Review#

All steps are done. Review the whole job once more:
is anything from the original requirements missing? Is there anywhere
two steps are inconsistent with each other? Only list the problems.

We also include these four prompts, alongside other templates, in Twenty ready-made prompt templates.

What does a real example look like?#

Suppose you want a registration form for a workshop that saves data to the database and shows the list in the WordPress admin.

In step one, the model asked: is capacity limited? Is a confirmation email needed? Do you have a form-builder plugin, or is this plain code? The answers changed the route, because limited capacity means checking the count before saving.

The approved plan was:

1. Create the table on plugin activation
2. Form shortcode with a nonce
3. Form handling with validation and a capacity check
4. Registrations list page in the admin, for administrators only
5. Confirmation email

Each step came out at fifty to a hundred lines of code, which could be read and tested. In step three it turned out the form's error messages weren't in the right language; fixing it took thirty seconds, not a rewrite of the whole plugin.

What other tasks does this pattern suit?#

Any job with several decisions in a row, from writing an article to a database migration:

For articles, we describe this method in detail in Writing an article with AI.

What do we do when the conversation gets long?#

Take a summary and continue in a new conversation. After a few steps, the conversation is full of code and old corrections, and the model may mix an old version of a file with the new one; the cause is the limit of the context window.

Summarize the work so far so I can continue in a new conversation:
requirements, decisions made, steps done and steps remaining.
Don't include code; only the file names.

Paste the summary into the new conversation, along with the current version of the files the next step needs. If you have rules that stay fixed across all steps, such as the PHP version or code style, put them in a system prompt instead of repeating them.

Where is multi-step work with AI heading?#

Tools are doing more of this cycle themselves. Many coding assistants and agents already give a plan first, then execute step by step and test their own work. This direction is clear and continuing.

But your role isn't removed; it shifts. You write fewer single prompts and spend more time approving plans and judging results. To prepare:

• Practice defining "done": for each step, write how you will know it worked.
• Have automated tests: the more automated the tool, the more tests matter.
• Read the plan seriously: the cheapest place to prevent a mistake is still there.

Summary#

• A big request is full of hidden assumptions, and its errors pile up.
• Four steps: clarify the need, plan, execute one step per turn, review.
• The plan is the cheapest place to change things; approve it before any code.
• Test after each step, not at the end.
• When the conversation gets long, take a summary and continue in a new one.