How to review AI-generated code changes when you're not a developer

When a coding agent builds a change, someone still has to decide whether it goes live. If you're a founder without a development background, that someone is you. The good news is that the review that matters most isn't a line-by-line code read. It's a behaviour check: does it do what you asked, did it break anything around it, and can you undo it if it goes wrong?

Review is step three of the loop described in our guide to building software with an AI coding agent. This article is the practical detail: how to keep changes reviewable, which tests are worth having, how to treat payments and logins, a release checklist, and a simple decision log.

Keep every change small enough to review

The single biggest factor in review quality is change size. A change that does one thing can be checked in five minutes. A change that does six things can't really be checked at all. That starts with the brief; see how to brief an AI coding agent for splitting requests.

Ask the agent to report each change in the same short format, every time:

The 'what I couldn't test' line is the one to read first. That's where your review time goes.

Previews: review on the device your users have

Open the preview where the change will actually be used. A phone for a customer page, the kiosk tablet for a kiosk app, the office laptop for an admin tool. Run your acceptance checks from the brief. Then spend two minutes doing something unexpected: an empty form, a very long name, a double tap on the submit button, a slow connection. Agents are good at the happy path you described. Edge cases are where human curiosity pays off.

When an automated test is worth writing

Automated tests are checks the agent writes once and runs on every future change. They're cheap for an agent to write, but they still need maintaining, so don't ask for tests on everything. Ask for them where a silent break would be expensive.

The last row on the left is the most useful habit: every time a bug is fixed, ask the agent to add a test that would have caught it. Over a few months, that builds a safety net around exactly the parts of your product that are fragile.

Treat payment screens as critical paths

A critical path is a flow where a failure costs you money or trust immediately. For most small products that's checkout, login and anything that writes important data. These deserve extra care on every change that touches them, and ideally a rule that changes elsewhere don't touch them at all.

• Use your payment processor's test environment. Stripe, for example, provides a sandbox where test transactions don't move funds, with test card numbers such as 4242 4242 4242 4242, and says not to use real card details in live mode for testing (Stripe: Testing).
• Test the unhappy paths. A declined card, a cancelled payment, a timeout, a refund.
• Check what the customer sees and what you see. The receipt, the confirmation screen, the record in your admin and in your accounting system should all agree.
• Never let the app store card numbers. Payments should go through the processor's own forms or hosted pages.

For RiideStar, a published Cortex customer, 'Real song payments have been live since July', with the founder approving anything outward-facing. Individual results vary. Money is where the approval habit matters most.

Logins and permissions

For every change near accounts, run three checks: a logged-out visitor can't reach admin pages; a normal user can't see another user's data; an admin can still do admin things. Turn on multi-factor authentication for every admin account, including yours.

Features that must stay switched off

Sometimes you want code finished but not visible: a new pricing page waiting for a launch date, or a feature that needs a legal check first. Ask the agent to build it behind a switch, often called a feature flag, that's off by default. Your review then has two parts: confirm it's invisible to customers with the switch off, and test it properly with the switch on, in a preview. Write down who's allowed to turn it on.

A release checklist for a small product

1. The change summary is complete, including what wasn't tested.
2. Acceptance checks from the brief pass on the preview, on the real device.
3. Critical paths still work: test payment, login, the main data flow.
4. Automated tests pass; new tests were added for any bug fixed.
5. Customer-facing wording and prices are correct, in AUD, with GST treated correctly.
6. Anything that should be switched off is switched off.
7. The rollback step is written down and you know how long it takes.
8. If stored data changes shape, a backup was taken first.
9. It's a time you can watch the result. Not late Friday.
10. The decision log has an entry.

Rollback: the way back before you need it

Every release should have a known way back to the previous version. For most screen and logic changes that's quick. For changes to stored data, such as renaming fields, merging records or deleting old data, it can be slow or impossible, which is why those changes need a backup first and deserve a 'high' risk rating. If something goes wrong after release, roll back first and investigate second. A fix-forward under pressure is how one problem becomes two.

Keep an audit trail of product decisions

Six months from now, you won't remember why the cancellation button moved or why a price rounds the way it does. Keep a decision log. One line per release is enough:

If you work with Cortex through a chat thread, the brief, the agent's questions, the change summary and your approval already live in one place, which makes the log easy to keep. For the wider principle of recording what agents did and who approved it, see AI agent audit trails.

When to bring in a human engineer

Agents and owners reviewing behaviour cover most changes. Bring in an experienced engineer to review the code itself when you're about to handle sensitive personal information at scale, when you change how payments or authentication work at a structural level, or when a 'high' risk change keeps failing. A few hours of specialist review at those points is cheap insurance. The same approach applies to internal tools once they hold important business data.

To see how changes are delegated, built, deployed and reported back in one thread, look at Fulcrum Code.