How to tell whether the AI’s code is good, without being an expert

An AI coding assistant can write a working screen in minutes. That speed is real, and it is why more and more software is built this way. The catch is that “it works on my screen” and “it is good code” are different things. Good code keeps working when someone changes it, when usage grows and when the person who wrote it has moved on.

You don’t need to read code to tell the difference. Whether you’re approving the project or building it yourself with an AI tool, there are signals you can check from the outside.

Six signals anyone can check

1. It runs from a clean setup, with written steps. Ask someone who has never touched the project to set it up on a fresh computer using only the written instructions (usually a file called README). If it takes a phone call to the original author, the knowledge lives in one head, not in the project. Think of a recipe: if only the cook can make the dish, you don’t have a recipe.

2. There are tests, and they pass. A test is a small automatic check that the code still does what it should, run every time something changes. Ask how many there are, what they cover, and to see them run. “We test by hand” means every change depends on someone remembering to click through everything.

3. Secrets are out of the code. Passwords and API keys (the keys that let your software use paid services) belong in a separate, protected settings store, never written inside the code. AI tools sometimes paste a key straight into a file to make something work. Ask: “Is any password or key written in the code or its history?” If nobody knows, have it checked. A leaked key can run up bills or expose your data.

4. Someone else can explain any part. Pick a screen or a feature at random and ask a person on the team how it works. If the answer is “the AI wrote that, I’m not sure,” nobody owns it. Code no one understands is code no one can safely fix when it breaks at 2 a.m.

5. Changes are small and reviewed. Healthy projects move in small steps: each change does one thing, and a second person reads it before it goes live. One giant change that rewrites half the system is hard to review and hard to undo. Ask to see the list of recent changes (the version history). Many small, clearly described changes is a good sign.

6. It handles errors. Try the unhappy paths. Submit an empty form, an impossible date, a very long name. Lose the connection halfway through. Good software shows a clear message and keeps your data safe. Weak software shows a blank page or a wall of technical text. AI tools tend to write the path where everything goes right and forget the rest, so this is where problems hide.

Questions to ask the AI itself

If you’re building with an AI tool, use it as a second pair of eyes. It won’t catch everything, but these prompts surface a lot:

• “List every place where a password, key or token appears in this project.”
• “What happens if this outside service is down or slow? Show me the code that handles it.”
• “Which parts of this project have no tests? Rank them by risk.”
• “Explain this file to someone who doesn’t code. What could go wrong with it?”
• “What would you change before real customers use this?”

Treat the answers as leads to check, not verdicts. The same tool that wrote the code can be confidently wrong about it.

Questions to ask a reviewer

An experienced engineer can answer in a day or two what would take you weeks to learn. Ask:

• What is the riskiest part of this code, and why?
• If the main developer left tomorrow, could someone else take over?
• What would break first if usage grew ten times?
• Is anything here unsafe for customer data?
• Which three fixes are worth doing first?

A good reviewer gives you a short, ranked list, not a lecture.

AI-written code can be good code

None of this means AI-written code is bad. It means it needs the same discipline as any other code. On SuperEscuela, a free learning platform for children, 74 of 97 code changes were co-written with an AI coding assistant, and every one was accepted by an engineer before it went in. The AI brought the speed; a person stayed responsible for each change. That is the pattern to look for.