Two people can ask for the same feature and get wildly different results. One gets working code in ten minutes, the other spends an hour going in circles and concludes the tool is overrated.
The difference is almost never the tool. It's how the request was made, and it's a learnable skill that takes about a week to get decent at.
The shape of a request that works
A good request has three parts: what you're working with, what you want, and what you want back.
Compare "add a login page" with something like: "This is a React app using Supabase for the backend. I want a login page with email and password, plus a 'forgot password' link. Give me the file, tell me where to put it, and explain anything I'll need to change elsewhere."
The second version isn't longer for the sake of it. Every extra clause removes a guess. Left to fill in blanks, it will pick something sensible that doesn't match what you already have, and then you're merging two different ideas of your own app.
Say what broke, not that it broke
When something goes wrong, the instinct is to type "it doesn't work."
That sentence contains no information. What you want instead is the actual error text, all of it, plus what you expected to happen and what happened instead.
Errors look intimidating because they're written for the person who wrote the language, not for you. But they usually name the file, the line, and the problem. Pasted in full, that's often enough to get a fix on the first try. Paraphrased from memory, it rarely is.
If nothing visible happened at all, that's still useful information. "I clicked the button and nothing happened, no error in the console" tells a completely different story from a red stack trace, and points somewhere else entirely.
Ask for options before you commit
For anything structural, asking for one answer gets you one answer, usually a reasonable one, and you'll have no idea what you traded away.
Asking for three approaches with trade-offs takes the same amount of time and teaches you the shape of the decision. You'll often pick the first suggestion anyway, but now you'll know why, and you'll recognise the pattern next time it comes up.
This matters more early on, when you can't yet tell a normal choice from one you'll regret in three months.
Verify, always
This is the part that separates people who do well with AI from people who get burned by it.
Code that runs is not the same as code that's right. It'll happily produce something that works for the case you described and falls over on the one you didn't mention. It sounds equally confident either way, which is the genuinely dangerous part.
So: read what came back. Ask what it does if you're unsure. Try the obvious edge cases. Ask it to find problems in its own code, which works surprisingly well, and is roughly what a code review does on a real team.
You own whatever you ship. Not the model. When something breaks at 2am for a real user, "the AI wrote it" isn't a position you can hold.
Small steps beat big ones
The temptation is to describe the whole app and ask for it in one go. You'll get something, and when it doesn't work you'll have no idea which part is wrong, because you didn't watch any of it get built.
One screen at a time is slower on paper and much faster in practice. You know what changed, so you know where to look.
There's a related habit worth picking up early: get one thing working, save it, then move on. Saving your work in git means you always have a version that ran, and "undo the last twenty minutes" is one command instead of an archaeology project. Ask Claude to set this up for you on day one, it takes about two minutes.
When to start over
Long conversations rot. After forty messages of half-tried ideas and abandoned approaches, the thread carries a lot of context that's no longer true, and suggestions start drifting.
When you notice yourself going round in circles, open a fresh conversation and describe the current state cleanly: here's what I have, here's what works, here's what I'm stuck on. That reset fixes more problems than another twenty messages usually will.
A quick story. When I was building my own app, I had Claude do adversarial reviews of the code, meaning I'd paste something in and ask it to try and break it rather than approve it.
That habit caught genuine problems. A signup form that could have been abused to send email to strangers. A daily reset that used the wrong timezone, so people in some countries would have seen their day flip at the wrong hour. A dependency that quietly bundled tracking code I hadn't asked for.
None of those would have shown up by using the app normally. They'd have shown up later, in front of real people, which is a much worse place to find them. Asking "what's wrong with this" instead of "does this look okay" is a small change in wording and a large change in what comes back.
If you want a prompt for getting unstuck
Point three is the one worth keeping. It's the difference between fixing this bug and slowly needing less help with the next fifty.
Next: What a screen is made of →
Go deeper: Chapter 24, Prompt Engineering and Chapter 23, AI Integration