How to review code your AI assistant wrote: a checklist for solo developers
George · 2 min read
The short answer: read every change before you ship it, as if a fast new teammate wrote it. Check that it does what you asked and nothing more, that inputs from users are validated, that secrets and data stay safe, and that it handles empty, slow and failing cases. Then run it for real. Tests that the assistant wrote for its own code are a start, not proof.
AI coding assistants have changed how solo developers work. You can describe a feature and get working code in minutes. The catch is that you are now the reviewer for a very productive colleague, and reviewing is a skill of its own.
Read the diff, not just the result
It is tempting to check that the page loads and move on. Read the actual changes instead. Look for:
- Changes you did not ask for. Assistants sometimes rename things, reformat files or "improve" code nearby. Each extra change is something you did not test.
- Removed code. A deleted check or a simplified condition can quietly remove a safety rule.
- Copied patterns. If the assistant repeated a pattern from elsewhere in your code, make sure the original was right.
Small, focused changes are much easier to review. Ask for one thing at a time.
Security checks that matter most
- Validate input on the server. Anything from a form, a URL or an API call must be checked where it is used, not only in the browser.
- Check who is allowed. Every action that changes data should confirm the user is signed in and allowed to touch that record. "The button is hidden" is not protection.
- Keep secrets out of code. API keys belong in environment variables, never in the repository or in code that runs in the browser.
- Watch database queries built from user input, and file paths or URLs that users control.
Edge cases assistants often skip
- What happens when the list is empty?
- What if the network request fails or is slow?
- What if the same button is clicked twice?
- What if the text is very long, or contains emoji or another alphabet?
- What happens to existing data when the shape of a record changes?
Run it for real
Click through the feature in a browser, on a phone size too. Try the unhappy paths on purpose. If the assistant wrote tests, read them: a test that checks the code does what the code does proves nothing. A few tests written from what the user should see are worth more.
Keep your own understanding
The biggest long-term risk is a codebase you no longer understand. If a change is too large to follow, ask for it in smaller steps or ask the assistant to explain it. You will be the one fixing it at midnight after launch.
The short version
- Review the diff, and question changes you did not ask for.
- Validate input and check permissions on the server.
- Keep secrets in environment variables.
- Test empty, slow, failing and repeated cases yourself.
- Ask for smaller changes so you can keep understanding your code.