Research, plan, build, verify

The arrows that matter are the ones pointing backwards. Nothing here is specific to AI — it is the loop every working engineer already runs.

Research: What do you want to build? Think like a Product Manager.

Do you have an idea in mind, and you know what you want, or are there still grey areas? Either way, it’s usually a great idea to start with research. Most harnesses will do research on any topic when prompted to ‘research’ something. Some harnesses have a ‘deep research’ option that can be very useful for that task.

Things to research might include:

• who: audience: who will use your product? What are the user personas? How are they distributed? How do they interact? If you’re trying to monetize, who will pay money for this product?

• what: What does the product do? Research what each user persona wants to achieve with this product. This is the time to be creative and find all the possible uses and features a user may want or need.

  What are the minimal features needed to launch the product? What persona(s) should be targeted first? What will the Minimum Viable Product (MVP) include (must do, could do, won’t do)?

• how:

  • research how similar products are built, what technology is commonly used, what architecture makes sense. Also research the design side of the project: what platform should you build for (desktop, mobile, server), what user interface your users are already used to?
  • research colors, typography and other theming elements that would best represent the type of product or brand you want to project.
  • research how this product can be deployed to scale to the number of users and interactions you expect. Find out what architecture is best.

Pro Tip

As a general guidance: think big, start small. Starting with a small idea and growing it organically tends to produce very messy codebases and performance issues in the long run. Think big, think of all the things the product may do in the future, and document this future state, so whenever you work on a feature, the AI agent understands where it fits in the big picture; it is much more likely to choose the proper technology stack and architecture if it knows the end-goal. When you start small, nothing narrows the choices down. It is easy for AI to pick a technological solution that seems simple and cheap at the time, but won’t scale or grow with the product as it needs to.

Pro Tip

If you don’t know what’s best, don’t leave it to AI to choose for you. Ask AI to give you options, along with pros and cons, so you can make the right decision for your product. AI tends to recommend ‘most popular’ solutions, and might box you into using services or platforms that are meant for testing or proofs of concept (PoC), like using SQLite for a database. SQLite is not a toy, and plenty of real products run on it: reads are unlimited and concurrent, and read-heavy applications scale a very long way on it. But it allows exactly one writer at a time, it lives in a single file, so the biggest it can get is whatever your storage allows, and it isn’t safe to use when that file sits on a shared network drive. If your product needs concurrent writes, or several servers talking to the same database, that is the wall you will hit, and it is much better to know it before you build on top of it than after. Make sure you understand the choices made and their downsides.

Plan: “By failing to prepare, you are preparing to fail.”

After research has surfaced the core product features and architecture, it’s time to plan.

Planning is the continuation of the research. Some harnesses have a specific ‘plan’ mode you should use, to ensure it doesn’t start coding before you have completed the plan. Planning consists of defining precisely what will be built and how. With all your product features defined and documented, narrow down to an MVP to start with. The plan is the task list the AI will follow to write the code. It should include everything that needs to be done to build and run a local version of the product (leave deployment as a secondary phase, as long as the architecture has been thought out in the research).

Interface design

If you’re non-technical, you’ll probably want to build software that is meant for web or desktop usage, with a User Interface (UI). UI design (the look and feel of the app) comes with User Experience (UX) design, to produce a smooth and frustration-free user experience. Both of these are non-trivial, and it’s a field of software development of its own: most software developers are not UI/UX designers.

Luckily there is help. There are many open-source frameworks to build a UI on, one of the most popular being TailwindCSS, a toolkit of small, ready-made styling pieces you combine in your page. And one of the first things you might want to do, once you have researched the UI / UX, is build a design system: one file that pins down your colors, typography, spacing and radii, so that every screen the AI builds afterwards looks like it belongs to the same product.

Google, through its Stitch team, published a format and a tool for exactly that: https://github.com/google-labs-code/design.md. It works in two halves, and it is worth understanding which half is which. The DESIGN.md itself you author: YAML design tokens, plus Markdown explaining the reasoning behind each choice. That file is your source of truth, and writing it is exactly the kind of work to do with your AI agent, so point it at the repository to learn the format and then build the file together, based on the results of your research (type of theme, color schemes, typography…). The command-line tool then takes over: lint validates the file against an eleven-rule set, diff compares versions, and export generates the theme files your code actually consumes, whether that’s a Tailwind v4 theme.css, a Tailwind v3 config, or W3C design-token JSON.

That generation step is most of the value. You change a color in one place, regenerate, and everything downstream follows, instead of hunting the same hex code through three files and missing one. Incorporate this step in your build plan.

Read the plan!

Read it carefully and make sure you understand it and agree with it. Fixing a bad plan early will save you long hours of fixing the code later.

Pro Tip

Life is much easier when using containers. A container packages your app together with everything it needs to run, so the same package behaves the same way on your laptop and on a server. They are meant to be a “build once, deploy everywhere” solution, which can be used to build a local demo and later deploy in the cloud. It is often easier and safer to ask AI to build the local version in a container environment, to ensure it will run anywhere else.

Explore Further

Docker’s own getting started guide takes you from installing Docker to running, building and sharing your first container: https://docs.docker.com/get-started/

Code

You’ve done your research, you documented the big picture of the product you want to build, you defined the architecture and design principles you want the AI to follow, and you created a plan of what to build. Now you can start building.

In some harnesses, you simply need to ‘agree with the plan’, or just prompt the AI to build the software as per the plan. If your plan is documented as a file in the project directory, it may be necessary to reference it in the context (use @filename to add a file to context in most harnesses).

Goals

Some harnesses have a /goal feature. A typical goal may be simply: build the product as planned, until all features are completed and tested.

Your AGENTS.md file may include instructions to commit as the work progresses, so that a long-running goal checks itself in at meaningful checkpoints: a feature finished, a test suite green. Not after every small edit, which gives you a history too noisy to read. Done that way, you can let the goal run for a while unattended and still have a clean trail to walk back through afterwards, and a known good state to return to if it wandered off.

Verify: how do you know it works?

This is the part the skeptics are right about, and it is the other half of the argument this guide opened with. A compiler gives you a guarantee: the same source produces the same program every time, and when it can’t, it tells you exactly where it gave up. An LLM gives you nothing of the sort. Run the same prompt twice and you get different code, and nothing anywhere in the chain checks that what came back does what you asked for. So if the skill has shifted from writing code to providing meaningful inputs, it has shifted just as much to verifying outputs, and that half is not optional.

Tests are your main instrument. Ask for tests alongside each feature rather than as a cleanup pass at the end, and then run them yourself instead of taking the agent’s word for it. There is a catch worth knowing about: an agent that writes both the code and the tests can write tests that pass against the wrong behavior, so a green suite you never looked at proves very little. For the features you actually care about, read what the test asserts. And when you hit a bug, ask for a failing test that reproduces it before you ask for the fix, so that the fix has something to prove itself against.

Read the diff. If you take one habit away from this page, take this one. Run git diff before every commit and actually read it: it lists every line the agent added, changed or deleted since your last checkpoint. You don’t need to follow every line to notice that a file you never mentioned was rewritten, that a configuration value quietly moved, or that the one feature you asked for arrived with three you didn’t. It is also how you learn the codebase you are accumulating, and that knowledge is what makes your next prompt a better one.

Prefer deterministic checks over asking the AI. The linter (which flags sloppy or suspect code), the type checker (which catches mismatched data before the program even runs), the compiler and the test suite answer questions definitively, in seconds, for free. The AI answers them plausibly. Anything a tool can settle, let the tool settle, and put those commands in your AGENTS.md so the agent runs them on itself before it reports back to you.

Then run the thing. A build that compiles is not a product that works. Start it, click through it, do the first thing a real user would do. Bugs that no test caught tend to surface in the first thirty seconds of actually using the software.

Pro Tip

Watch for the agent that reports success without evidence. “Done.” “All tests pass.” “The feature is working as expected.” None of that is evidence, it is a claim, and agents make it cheerfully after doing nothing of the kind. Evidence is output: the command that was run, and what it printed. Ask for it every time (“show me the test output”), and write it into your AGENTS.md as a standing rule, so the agent knows from the start that a claim without output does not count as done.

Skip this step and you end up with a large pile of code you can’t debug, can’t change and can’t explain. That outcome is what gives vibe coding its bad name, and it isn’t the AI that produces it: it’s shipping code that nobody ever checked.

Where to go from here

That is the whole loop: research what you are building, plan it before you build it, build it, then verify it. None of it is exotic. It is ordinary software engineering practice, and the only reason it shows up in a guide about prompting AI is that AI removed the part that used to be slow, which was typing the code, and left every other part exactly where it was.

So go start something. Pick a product small enough that you will actually finish it and big enough that you care whether it works, and walk the steps in order. You will get far more out of one finished project than out of reading about it. And when the AI makes a choice you don’t understand, stop and ask it why, and ask what the alternatives were. That is the step most people skip, and it is the one that turns a vibe coder into an engineer.