Judging What Claude Builds
Everyone can build now. The rare skill is telling the good version from the generic one. This is that skill.
The Catch in “You Don’t Need to Code”
It’s true that you don’t need to write code. It’s not true that anything Claude hands you is good.
Claude produces working software fast. Working is not the same as good, and good is not the same as safe. A weather app can run perfectly and still leak your API key. A form can look clean and be unusable with a keyboard. Code can do exactly what you asked and quietly do three things you didn’t.
You can’t catch those by reading the code. You catch them with judgment. The good news: most of it is judgment you already have.
You Already Have the Eye
You review work for a living. You spot the misaligned element, the inconsistent spacing, the interaction that feels wrong. That instinct is exactly what’s needed here. You’re just pointing it at a running product instead of a static comp.
The difference is knowing where to look. A designer’s eye covers the surface naturally. The problems below the surface, security, error handling, accessibility, need a short checklist until they become habit. That’s what the rest of this lesson gives you.
Judge the Experience First
Before anything technical, use the app like a real, slightly difficult user. This is where your taste does the most work.
- Click everything. Every button, link, and control. Twice.
- Feed it garbage. Empty fields. A 200-character name. Emoji. A pasted essay where a word belongs.
- Check the in-between states. What shows while data loads? When there’s no data yet? When something fails? Generic builds skip these. They handle the happy path and nothing else.
- Break the size. Resize the window. Open it on your phone. Watch where it falls apart.
- Throttle the network. A slow connection reveals whether loading was ever considered.
If the experience only holds up when everything goes right, it isn’t finished. That’s a judgment only you can make, and it’s the most valuable one.
Five Problems You Can Catch Without Reading Code
These are the issues that hide below the surface. You don’t need to understand the code to find them. You need to know they exist and ask.
1. It only works on the happy path. No empty state, no error message, no loading indicator. The moment something is missing or slow, the screen goes blank or freezes. Ask: “What does the user see while this loads, when it fails, and when there’s no data?”
2. Secrets are exposed.
If your app talks to a paid service, it uses a key. That key must never ship in code the browser can read, or anyone can take it and run up your bill. Ask: “Are any API keys or secrets visible in the frontend? Should anything move to a .env file or a server?”
3. One file is doing everything. When a single file grows to hundreds of lines doing unrelated jobs, every future change gets riskier. You don’t need to read it to ask: “Is any one file doing too much? Would this be easier to change if it were split up?”
4. Custom controls aren’t accessible. A div styled to look like a button often isn’t one. It can’t be reached by keyboard or announced by a screen reader. Ask: “Can everything here be used with just the keyboard? Are the controls real, labeled elements?” (The Accessibility guide goes deeper.)
5. It changed more than you asked. Claude sometimes “improves” things you didn’t mention. Before you approve, read the summary of what it’s touching. If it’s editing files unrelated to your request, stop and ask why. Scope creep is how working features quietly break.
Make Claude Check Its Own Work
You can’t read the code, but Claude can, and it’s a sharp reviewer when you point it at itself. After a feature works, before you move on, ask:
Review what you just built like a skeptical senior engineer. What would you flag for security, error handling, accessibility, or things that could break?
What happens if the network is down, the data is empty, or the user does something unexpected?
Did you change anything I didn’t ask for?
Is there a simpler way to do this that’s easier to maintain?
This costs you thirty seconds and catches most of what the checklist above is looking for. Treat it as a standard step, not a special occasion.
When Not Understanding Actually Bites
For a weekend project you use alone, “I don’t fully get how it works” is fine. Ship it. Learn from it.
The stakes change the moment any of these enter the picture:
- Real users. Other people will hit edge cases you never would.
- Real data you’d hate to lose. Notes, photos, records. Ask how it’s saved and whether it can be recovered.
- Money. Anything that charges a card, or any paid service behind a key.
- Private information. Logins, personal details, anything you wouldn’t post publicly.
When you’re in that territory, slow down and lean harder on the questions above. Get Claude to walk you through how data is stored, how failures are handled, and what could go wrong. You still don’t need to read the code. You do need to refuse to ship until the answers are good.
Taste Is the Job
The whole promise of building with AI is that taste becomes the bottleneck instead of syntax. That cuts both ways. Claude removes the excuse that you couldn’t build it. It doesn’t remove your responsibility to judge what got built.
You don’t need to read code. You need to know what good looks like, ask the right questions, and decline to ship the generic version. That part was always yours.