How to review AI-generated code when you are still learning
The button works. The page looks tidy. The AI says the code is ready. Then someone clicks twice and your carefully prepared total turns into a mystery.
Reviewing AI-generated code means checking a proposed change against what it should do. You do not need to understand an entire application to begin. You do need a small enough change to inspect, a clear rule and a way to challenge the result.
This guide uses a fictional workshop booking page. It is a learning exercise, not production-ready booking software. The aim is to practise spotting gaps before you accept a suggestion.
Write the rule before reading the solution
Suppose a visitor can reserve one place at a free workshop. Your rule might be: a non-empty name is required, one click creates one reservation, repeated clicks do not create duplicates, and the visitor receives a clear confirmation.
That sentence gives you something independent of the generated code to test. If the rule is vague, the AI may fill the gap with a behaviour you never intended. Write down what should happen when a name contains only spaces, when the workshop is full and when saving fails.
1. Ask for the smallest reviewable change
Request one behaviour at a time. A name validation change is easier to inspect than a replacement page containing a new layout, payment flow and database connection.
Ask for a short explanation of the change, its assumptions and how to test it. Treat that explanation as a claim to check. Keep the original version so you can compare the differences and undo the experiment.
2. Trace an awkward input
Read this deliberately incomplete JavaScript function. It checks whether a name has characters. JavaScript is the language adding behaviour here; length counts the characters in the string.
function hasName(name) {
return name.length > 0;
}Predict the answer for "Maya", "" and " ". Which input breaks the booking rule?
Reveal the gap and a focused correction
Three spaces have a length of three, so the function accepts them. For a text input that supplies a string, name.trim().length > 0 checks the length after removing whitespace from the ends. MDN documents this behaviour of trim().
That correction only addresses the name rule. It does not prevent duplicate reservations, check capacity or save a booking. If callers might supply a value other than a string, decide and test how to handle it explicitly.
Test the promise, then the surroundings
A test compares an actual result with an expected result. Start with an ordinary input, an empty input and one boundary case. A boundary case sits at the edge of a rule, such as the final available workshop place.
- Try a second click and a slow response. Does the page explain that saving is in progress?
- Disconnect the network in a practice environment. Does a failed save still display a success message?
- Use the keyboard to reach and activate controls. Can you understand any error without relying on colour?
- Check where data goes. Are you adding a dependency, external service or permission you did not request?
For a real booking system, server-side validation and appropriate access controls still matter. A browser check improves the experience, but a visitor can bypass it. Ask an experienced developer to review changes involving personal data, payments or permissions.
3. Practise the review decision
Your practice page passes the name checks. The AI also added an unfamiliar external script to handle clicks. What is the useful next step?
Option A: Accept it because the visible tests passed
Pause. Your tests cover a few visible behaviours. They do not explain what the new dependency does or what it can access.
Option B: Ask why the dependency is needed and inspect it
This is the stronger next step. Check its purpose, provenance and alternatives. If the change does not need it, request a simpler version and run the relevant checks again.
Option C: Ask the same AI to confirm that everything is safe
Another reassurance is not independent evidence. Use documentation, inspection and appropriate human review to answer the specific question.
Leave a useful review note
Record the rule, the inputs you tried, the results and any question still open. For example: “Whitespace-only names are rejected. Double-click behaviour is still unverified. The added script needs an explanation before this change is accepted.”
You can make a valuable contribution by asking a precise question. If you are new to a team, “What happens if saving fails?” is a useful review comment, even when you cannot yet propose the whole fix.
For your next practice session, choose one small generated function. Predict three results before running it, then compare your prediction with the output. Explain one remaining limitation in your own words.
You May Also Like
Mastering Agile Project Management with Scrum: A Comprehensive Guide
The Most Common Agile Glossary (Clear Definitions for Modern Teams)
