Skip to content
Download .md

Building with Claude ​

Claude builds your app in NodeGX, a piece at a time. Your part is to read its plan before you say yes, look at what it made, and tell it what's different from what you expected.

Round and round: ask, read the plan, let it build, look, say what you see.

Ask it to build ​

Open NodeGX first. Claude can only open your project in NodeGX if NodeGX is already running.

Then, in your Claude conversation, send this:

text
Please build this app in NodeGX on my computer, following the build plan.
Tell me what you're doing as you go, in plain words.
When a page is ready, open the project in NodeGX and show me the app
in my browser.

If you're starting a new conversation rather than carrying on from your planning one, tell Claude which project to open first. It will read the brief and build plan saved in it.

Read the plan before you say yes ​

Before it builds, Claude tells you what it's about to do. Read it properly.

Most of my bad days started with "yeah, just do it". Claude spells out exactly what it will do, I skim it, and later I'm unhappy with something the plan told me about in plain words.

  • If a line surprises you, ask about it.
  • If you don't understand a line, ask: "Can you explain that more simply?"
  • Before you say yes, ask: "What would you recommend here that you haven't suggested?"

Plan mode

Claude Code has a plan mode (Shift+Tab in the terminal, or the mode selector in the desktop app). In plan mode Claude reads and proposes, and changes nothing until you approve.

What Claude and NodeGX check for you ​

NodeGX checks every change before it is saved. If Claude tries something that's wrong, NodeGX refuses it, explains why, suggests a fix, and writes nothing. So your app doesn't end up half-changed.

Claude looks at its own work. It can draw your app's pages out of sight and look at pictures of them, so it catches things like a button hanging off the edge of the page.

But those checks can only tell whether the app works as it was built. They can't tell whether it's what you wanted. On one of my apps every automatic check passed, and the game was still annoying to play. You are the one who knows if it's right.

Look at it yourself ​

When Claude says a part is ready, open it and click through it like a visitor would. Try three things:

  • The normal case. Do the main job from start to finish, the way a real person would.
  • The empty case. What does a new person see before anything has been added?
  • Something typed wrong. Leave a box empty. Type letters where a number should go. Use the wrong password.

Tell Claude what you see ​

Claude can't see your screen. Tell it what you did, what you expected, and what happened:

text
I clicked [what you clicked].
I expected [what you expected].
Instead, [what happened].

A screenshot helps a lot. Paste or drag it into the message box. If something is properly broken, see When something goes wrong.

Ask how sure it is ​

When Claude finishes a part, ask:

text
How confident are you, out of 10, that this part is finished and works?
What's missing that would make it a 10?

Below 8, something is off. Ask what's missing and fix it before moving on. Building on a shaky part means the next parts inherit its problems.

Don't take the number on trust, though. The score is Claude's view. Your own click-through is the one that counts.

Ask a fresh pair of eyes ​

When a big piece is finished, like your first version, and before you show it to anyone, get it checked by a conversation that didn't build it. It sees the app without the assumptions the building conversation picked up.

Start a new conversation in the Code tab and send:

text
Open my NodeGX project "[project name]". Read its brief, then check
the app against it. Look at every page. List anything that is missing,
broken or different from the brief, most important first.
Don't change anything.

"Don't change anything" matters. You want a list, not a surprise rewrite.

Then fix the items one at a time, starting with the most important. Keeping each conversation to one job helps: see One job per conversation.

Quick reference ​

  • Open NodeGX before you ask Claude to build.
  • Read the plan before you say yes. Ask about anything that surprises you.
  • NodeGX checks every change and Claude checks pictures of its work. You check it's what you wanted.
  • Click through it: the normal case, the empty case, something typed wrong.
  • Tell Claude: I did this, I expected that, I got this. Add a screenshot.
  • Ask for a confidence score. Below 8, fix it first.
  • When a big piece is done, ask a new conversation to check the app against its brief.

Written by Richard Osborne, main developer of NodeGX · nodegx.io