Building in small steps
An AI coding tool can write a whole app from one long prompt, and the result usually looks finished long before it works. This lesson gives you the loop that keeps you in control: plan, build one step, check it, save it, and only then move on. You will use it to build Ravi's reorder app one feature at a time.
By the end you can
- Explain why one big prompt produces an app you cannot check, and why fixing it breaks other things
- Ask the AI for a numbered plan of small steps from your spec, each one you can see and test
- Write a step prompt with context, the change, what not to touch, the check and a stop
- Check a step without reading the code, and save it with a Git commit
- Keep the AI on track with fresh chats, a progress note and a quick way back when it goes in circles
The everyday picture
Imagine you run a small shop and you hire a very fast, very keen helper to rearrange it. If you say "rearrange the whole shop" and go out for the afternoon, you come back to a shop that looks tidy. Then you look for the rice and it is behind the tea. The prices on two shelves are swapped. You ask the helper to move the rice back, and in doing so they knock the cooking oil out of its place. You can't tell what else changed, because everything changed at once.
A careful shop owner works differently. "Today, only the rice shelf. Put the 5 kg bags at the bottom, keep the price labels with their goods, and don't touch the drinks fridge." When the helper finishes, you walk over, look, and check three things on your list. If it is right, you take a photo of the shelf. Then you do the next shelf. If a shelf goes wrong, you put it back the way the photo shows and try again with a clearer request. Building an app with an AI works the same way. One shelf is one step. Walking over and looking is the check. The photo is a commit, a save point you can always go back to.
Why one big prompt fails
A prompt like "build me a reorder app for partner shops with sign-in, a product list, a usual order, editing, sending and order history" feels efficient. The AI tool takes it, works for half an hour, and creates or edits dozens of files. Four things then go wrong, and they go wrong for reasons that have nothing to do with how clever the model is.
- It changes many files at once. To build six features, the AI has to make dozens of small decisions you never saw: how money is stored, what happens when a quantity is zero, where data lives. Each decision is a guess based on what is common, and some of those guesses will not match your spec.
- You cannot check it. A beginner cannot read 4,000 lines of code, and an expert would need a day. So you click around, the screens look right, and you assume the rest is right too.
- One mistake hides in a thousand lines. A wrong total, a missing check on who may see an order, a value stored in dollars instead of cents. Nothing on screen points to it until a real user hits it.
- Fixing one thing breaks another. When you finally find the bug and ask for a fix, the AI edits code that several features share. The totals now work and sign-in stops working. Because nothing was saved along the way, you have no known good version to go back to.
Small steps fix all four at once. Each step changes a few files, does one thing you can see, and comes with a check you can run in a minute. If something is wrong, you know it was this step, because the last step was checked and saved. Coding agents also tend to do better on a small, clear task than on a vague large one, because everything they need fits in what they are looking at.
Quick check
After one long prompt, the reorder app looks finished and every screen opens. What is the main risk of building the next feature on top of it?
The screens opening tells you very little. Hidden mistakes in thousands of unchecked lines stay hidden, and each new feature is built on them. Without a save point you cannot tell which change caused a problem or return to a version that worked. Cost and speed are minor next to that.