Breaking a Big Ask Into Steps
You would not ask a new employee to 'build the whole product by Friday' on their first day. You would break the work into tasks, assign them in a logical order, and check progress along the way. AI models are surprisingly capable, but they share one limitation with any builder: the bigger and fuzzier the request, the higher the chance of going in the wrong direction. Learning to decompose — to break a large project into a sequence of focused, prompt-sized pieces — is one of the most important skills in vibe coding. It turns impossible-feeling projects into a manageable series of steps.
Why Big Prompts Go Wrong
When a prompt is very large, several things happen: The AI has to make more assumptions. Every requirement you do not specify precisely is a decision the AI makes on its own. Big prompts have many such gaps. Errors compound. If the AI misunderstands one part of a large prompt, that error gets baked into everything built on top of it. Fixing it later may mean rewriting more than just the broken piece. You cannot verify as you go. If you ask for twenty features at once and get them all at once, how do you know which parts work? You have to test everything before you can catch anything. Small, focused prompts let you verify each piece before moving to the next. A bug caught after one prompt is easier to fix than a bug discovered after ten.
Decomposition means breaking a complex problem into smaller sub-problems, each of which can be solved independently. In build prompting, it means planning the sequence of prompts you will send — each one producing a working, testable piece — before you start sending any.
Here is a real decomposition. Suppose you want to build a flashcard study app. An inexperienced prompter might write one enormous prompt describing everything: the home screen, adding cards, a study mode, tracking progress, and a settings page. A decomposed approach might look like this: Prompt 1: Build the basic HTML structure — a card display area, a Flip button, and a Next button. No logic yet. Prompt 2: Add JavaScript so clicking Flip toggles between showing the front and back of a hardcoded flashcard. Prompt 3: Replace the hardcoded card with an array of five cards. Next and Flip should work through the whole deck. Prompt 4: Add a progress indicator showing which card you are on, for example '3 of 5.' Prompt 5: Add the ability to type new cards and save them to the array. Each prompt produces something testable. You verify it works before adding the next layer. By the end you have the same app — built more reliably and with fewer wasted retries.
How to Plan a Decomposition
Before you write your first prompt, sketch the build plan. Ask yourself these questions: What is the core feature — the one thing without which nothing else matters? Start there. Build the skeleton before the skin. What depends on what? If the study mode depends on the card data structure, build the data structure first. Identify dependencies and order your prompts accordingly. What can be tested at each step? Plan your decomposition so every prompt ends with something you can look at, click, or run. If a step produces output you cannot yet test, it is probably too early or too abstract. How big is each piece? A good decomposition produces pieces small enough that a single prompt handles each one completely. If you find yourself writing three paragraphs for one step, that step probably needs to be split further.
A common mistake is jumping straight to the most interesting feature. But if the underlying structure is not right, you will rebuild it later anyway. Start with the simplest possible working version — even if it is just static HTML with placeholder text — and layer on functionality from there.
Prompt Challenge
Write the FIRST prompt in a decomposed build plan for a simple two-player tic-tac-toe game. This first prompt should build only the skeleton — the board and basic layout — no game logic yet.
Your prompt should…
- State clearly that this is only the first step of a larger build (set expectations for scope)
- Describe the visual artifact to build — what the player sees — without any behavior or logic
- Include at least one constraint about what NOT to include in this first step
Why do large, single prompts for complex builds tend to produce worse results?
In a decomposed build plan, what should be true of each step?
Decompose a Build
- Step 1: Pick one of these apps to build: a tip calculator, a color-mixer tool, a simple to-do list.
- Step 2: Write a list of 4-6 prompts you would send in order to build it. Each prompt should produce one specific, testable piece.
- Step 3: For each prompt in your list, write one sentence describing what you would check to know it worked.
- Step 4: Review your decomposition: Does step 1 really have no hidden dependencies? Does each step build logically on the one before it? Revise if needed.
- Step 5: Compare your decomposition with a classmate's. Did you break it up the same way? Discuss why different orderings might both be valid.