The thing people get wrong about AI coding tools is assuming they are bad at their job. They are not. If you ask Cursor or Claude Code to build a booking form, you get a booking form, and it usually works.
The problem is narrower and stranger than "the code is sloppy". It is that the tool only answers the question in front of it, and you are the one choosing the questions.
What does that look like in practice?
You asked: add user login.
You got user login. Accounts, passwords, a session that persists. Everything you asked for.
What you did not ask, because why would you: and make sure a logged-in user can only read their own records. Those feel like the same request. They are two different pieces of work, and the second one is where the data leaks live.
The tool did not withhold it. It answered what you said.
The questions worth asking, in plain English
You do not need to learn to code to ask these. Paste them into whatever tool you built with, one at a time, and read the answers carefully.
"If someone is logged in as customer A, can they see customer B's data by changing something in the URL?" The honest answer is often yes. Ask it to show you exactly what stops it, not to assure you that something does.
"Which of my secret keys end up in the browser?" Anything in the part of the app that runs on the customer's machine is readable by that customer. A payment key or a database key that ships to the front end is not a secret any more, and nothing visibly breaks when this is true.
"What happens if this request fails halfway?" Payment taken, order not recorded. Email sent, record not saved. Ask specifically what the app does in between.
"If the app threw an error right now, how would I find out?" Not "is there a log". Would anything reach you.
"What would break if I changed this later?" If the answer is a shrug, the app is already harder to improve than it was to build.
"What did you assume that I didn't tell you?" This is the best one, and almost nobody asks it. The answers are usually illuminating and occasionally alarming.
Why this is not a criticism of the tools
I use these tools every working day. I run a company on software built with them. The leverage is real and I am not interested in the genre of article that pretends otherwise.
But a tool that does exactly what you ask is a different thing from a colleague who tells you what you forgot. The gap between those two is not filled by a better prompt. It is filled by someone who has had the specific experience of watching software fail in front of a paying customer, which changes which questions occur to you first.
The cheap version of getting that
Ask the six questions above. Write the answers down somewhere you can look at them. That alone puts you ahead of most half-built apps I have seen, and it costs you an evening and no money.
If the answers worry you, that is useful information rather than a verdict. Most of what comes back is fixable in days, not months — the expensive scenario is not "the app has faults", it is "the app has faults and nobody looked until a customer found them".
Run the free website check — same instinct, pointed at a public site: specific faults, ranked by which would actually cost you something.
If you want someone to ask those questions of your app rather than asking them yourself, tell me what you are building. I am one engineer, so I will tell you honestly if it does not need me yet.
