You check it the same way you check any code, but more carefully: read the whole diff, confirm every function and package exists, run it against tests that could fail, especially one you wrote yourself, try the edge cases, and make sure you can explain every line. Correct means proven by evidence, not "the tool said it works".
What people tell me
I use AI tools to write a lot of my code now, for university projects and a side project. It usually runs, but sometimes I find bugs days later, and once a function it used did not even exist in the library version I had. I do not have years of experience to spot problems by eye. How do I actually know whether what it gave me is right before I move on?
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Running once without errors is not the same as correct; the tool predicts plausible code, it does not verify it.
- Read the full diff and check every unfamiliar function, flag and package against the official docs for your version.
- Write at least one test yourself, watch it fail first, and break the code on purpose to prove the tests catch it.
- Test the edge cases: empty, huge, zero, negative, missing, duplicate and unusual input.
- If you cannot explain a line, you have not finished checking it.
Why "it runs" is not enough
AI coding tools are built on language models that predict what correct code usually looks like. That is why the code usually runs. It is also why it can be wrong in quiet ways: an edge case not handled, a business rule guessed, a function that existed in an older version, or a test that checks nothing. The tool did not run your program against every case, unless you made it. So correctness has to come from evidence you collect, not from the tool's confidence.
The good news is that you do not need years of experience to do this. You need a routine.
A routine that works
1. Read the whole diff
Look at the list of changed files first. Anything you did not expect is a warning. Then read every line, not only the summary. Summaries can say "fixed the bug" when the change also deleted a check or a test.
2. Check that everything exists
The most common AI error is a call that does not exist in your version: an invented method, a renamed option, a removed flag, a made-up package. Hover over each unfamiliar call in your editor, run the type checker, and open the official docs for anything you do not recognise. Before installing any new package the tool suggests, check it on the official registry: real repository, recent releases, real usage. Some attackers publish malicious packages under names models tend to invent.
3. Test it with tests that could fail
Write at least the first test yourself, before or right after asking the tool, and run it to see it fail before the code exists. Then let the tool suggest more cases and keep only the ones that test real behaviour. Finally, break the code on purpose, for example change > to >= or return early, and rerun. If no test fails, your tests are decoration.
4. Try the edges
Models write the normal case well and the edges badly. For almost any function, try:
| Input | Example |
|---|---|
| Empty | empty list, empty string, no rows |
| One item | a single element |
| Very large | a million rows, a huge number |
| Zero and negative | 0, -1 |
| Missing | null, None, undefined, a missing field |
| Duplicates | the same item twice |
| Unusual text | Unicode, emoji, very long strings |
| Time | time zones, month ends, leap years |
5. Explain it back
Before committing, explain in your own words what the code does and why it works, without reading the tool's explanation. If you cannot explain a line, look it up or step through it in a debugger until you can. Asking the tool to explain its own code is not proof: it explains wrong code just as fluently as right code.
Make the tool prove it
You can move much of this work into the tool itself. In your prompt, say exactly which command proves the work, such as the test suite and the type checker, and ask it to run them and paste the output. Add one rule to your project's instructions file: never change or delete existing tests to make a change pass. Then check test changes in every review anyway. The tests-first stage of the Coding with AI tools roadmap walks through this for Claude Code, Cursor and GitHub Copilot.
A checklist to keep next to your editor
- Does it do what I asked, and nothing else?
- Does every function, flag and package exist in my version?
- Are errors, empty input and limits handled?
- No secrets, no disabled checks, no
eval? - Would a test fail if this code were wrong?
- Were any tests deleted or loosened?
- Can I explain every line?
The Coding with AI tools cheat sheet has this checklist with examples, plus the weak test patterns to watch for.
Build the judgment behind the routine
The routine catches most problems. Over time, your fundamentals catch the rest: knowing why a nested loop over a big list is slow, why string-built SQL is dangerous, why a race condition only shows up under load. Keep practising without AI regularly, and read Is it bad that I rely on ChatGPT or Cursor and cannot write code from scratch? if you worry that you are leaning on the tool too much. For a deeper method, Test Driven Development: By Example and Debugging: The 9 Indispensable Rules are both short and worth it.
If you want a second pair of eyes on how you review and test your own projects, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- How to Use AI as a Companion, Not a CrutchHow to use AI for coding without losing your skills: the one rule that decides it, what the research says, where AI helps and where it quietly hurts, how students should learn with it, and how to verify its code.
- Five Kinds of API Test and When Each One Earns Its PlaceThe five types of API testing that do most of the work: functional, integration, regression, load and security. What each catches, what each misses, how to spread your effort, and the one-minute check OWASP ranks as the top API risk.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.