Let it build. Review like an architect.

How do I build an app with Cursor or Claude Code without it drifting?

Run the build prompts from step 5 one at a time, and keep each one small.

• Start with a plan. Ask the tool to plan the prompt before it writes code, and read the plan.
• One service at a time. Don't start the next prompt until the current one passes its tests.
• Tests after every prompt. Fix failures while the context is small. A failure found three prompts later is harder to trace.
• Limit what it can touch. Read-only by default. Write access only where the build needs it.
• Keep a hand-off file. When a chat gets long, write what's done, what's next and what's decided into a file, and start the next chat from it.

A hundred revisions is normal. What matters is that every revision passes the same checks.

How do I review code written by AI?

Review like an architect, not a typist. You're not checking every line. You're checking that the structure you decided still holds. After every service, five checks:

1. Structure. Folders, service boundaries, tests beside the code. If a boundary moved, move it back first. Drift compounds.
2. Failure paths. Model down, empty result, bad input, timeout. Each one handled, logged with a request id, and visible somewhere a human looks.
3. The gate. Anything that can leave the system (an email, money, a client-facing answer) goes through the reviewer and the confidence gate. No exceptions.
4. The NEVER lines. One search per line in the brief. About thirty seconds a service.
5. Hand-over. Deploys from main, seeded demo data, a runbook. Could someone else run this service from what's in the repo?

Why read the error paths before the happy path?

Because the happy path is the part the AI is best at. It's what the demo shows and what the first tests cover. The error paths are where a generated codebase hides its guesses: a caught exception that logs nothing, a fallback that returns made-up data, a timeout that retries forever. Read those first, while you still remember what the service is meant to do.

review notes, March 2025

What are the common mistakes?

• Accepting a big change because the app runs. Running isn't the same as correct. Run the five checks.
• Leaving tests for later. Later, the context is gone.
• Giving the tool write access to everything. Scope it to the one place the build needs.
• One endless chat. Long chats lose early decisions. Use a hand-off file and start fresh.
• Fixing structure drift later. It compounds with every prompt.

Which templates should I use?

The review is the five checks as a one-page list. The Claude Code starter kit adds a .claude/ folder with permissions and two hooks: one formats every edit, one blocks your NEVER list. The security-hardening skill from the JobFuture build applies secure-by-default rules on every prompt.

What did building look like in the real JobFuture build?

The first Cursor prompt went in at about 6:37 pm. The first commit landed at 7:02 pm. Cursor ran in agent mode, starting each prompt with a plan. Tests ran after every prompt and were fixed while the context was small. Access was read-only everywhere except one GitHub organisation. A hand-off file carried decisions between chats. Grok handled the basic work, Opus wrote the code, and Claude Code ran inside Cursor for the heavy lifting. By about 11:25 pm there were 41 commits.

From the sessionIt takes you probably two hours to build an application, and then five hours to fix that application. The first phase can be a bit tedious, but it builds you the right application.

Watch episodes 5 and 6.