Skip to content
WANCODE
BM

Building a Real App With AI

20 minIntermediateHTML · CSS · JS

In this lesson

  • Write a short spec with acceptance criteria, edge cases and scope
  • Break a feature into small steps that are each easy to review and test
  • Ship a feature with the review and testing habits from this track

The big idea

Assistants are fastest when you are clear. Decide what "done" means, then move in steps small enough that you understand every line before taking the next one.

This lesson puts the whole track together on a small but real feature: a pocket-money tracker needs a category filter. You'll play both roles — the person directing the assistant, and the reviewer who decides what ships. (The code is in the editor; there's no AI call here, so you'll write or paste each step yourself.)

The workflow

  1. Spec — write what "done" means: goal, acceptance criteria, edge cases, and what's out of scope. This becomes the context for every prompt and your test plan.
  2. Plan in small steps — ask the assistant for a plan before code. Reorder it so the easiest-to-test parts come first: pure functions, then UI wiring, then polish.
  3. One step per prompt — include the spec, the relevant code and constraints. Ask for the smallest change.
  4. Review → run → test — read the diff, run it, check it against the acceptance criteria and edge cases.
  5. Commit when green — a commit after each working step means a bad next step is one git restore away.

One giant prompt

Markdown
Add filtering, editing, charts, dark mode and
saving to localStorage to my expense app.

Step 1 of 3

Markdown
Spec: <paste spec.md>
Code: <paste the expenses array and render()>

Step 1 only: write filterExpenses(items, category)
and totalOf(items) as pure functions. "all" returns
every item. Don't touch the DOM yet. Don't mutate
items. Include 3 example calls with expected results.

The giant prompt produces a giant diff nobody can review. The step prompt produces two small functions you can test in seconds.

Know when to stop prompting

If you've asked for the same fix three times and it's still wrong, the assistant is missing context or the problem is misunderstood. Stop, debug it yourself (lesson 5), then come back with the evidence.

Final review checklist

Before shipping: read the whole diff · every acceptance criterion checked · edge cases tried by hand · tests pass and can fail · no user input in innerHTML, no secrets in the frontend · no unexplained commands were run · you could explain every line to a teammate.

Fill in spec.md for the category filter. Replace the bracketed notes with real content:

- Acceptance criteria a tester could check one by one, - at least one edge case (what if a category has no expenses?), - what's out of scope.

Use bullet points (lines starting with - ). English or Malay is fine.

Checks

  • At least 4 real bullet points
  • Mentions an edge case
  • The template notes are replaced
Self-check

This exercise is open-ended, so you judge it. Tick each item honestly when it's true.

Check understanding

Q1

Which order of steps makes an AI-built feature easiest to review?

Q2

Why include "Out of scope" in a spec you give an assistant?

Q3

You've asked the assistant three times to fix the same bug, and it's still broken. What's the best next move?

What you learned

  • Start with a spec: goal, acceptance criteria, edge cases, out of scope.
  • Build in small steps, testable parts first; one step per prompt.
  • Review → run → test → commit, every step.
  • You ship it, so you must understand it — the assistant is a fast collaborator, not the one responsible.
Preview

Console output from your code appears here.

Step 1 of 3