The JournalBuild Your Proof

Can you trust code an AI wrote

A practical checklist for verifying AI-written code before you ship it: read the diff, make it explain itself, run the right tests, and check the edges.

The ProoV Team··5 min read

An AI agent just handed you a change. The build passes. It looks reasonable. Do you merge it?

That question does not have a single yes or no answer, because trust is not a property of the tool. It is something you earn or fail to earn on each individual change, by actually checking it. Here is what checking properly looks like.

Read the diff before you accept it

This is the step people skip, because the agent already told you what it did in plain English and that summary is easier to read than a diff. Read the diff anyway. The summary is the agent's account of its own work, and an account can be wrong or incomplete without being dishonest, the same way a person can misdescribe their own change by accident. The diff is what actually happened. Look at every file it touched, not just the one you expected it to touch.

Make it explain the change

Ask the agent why it made a specific decision, especially anywhere it deviated from the obvious approach. A good answer references the actual constraint it was solving for, something like "the existing function already handled negative values this way, so I kept the pattern consistent." A vague answer, something that sounds plausible but does not point at anything concrete in the code, is a signal to look closer yourself rather than take the explanation at face value. This is not about catching the agent lying. It is about using its explanation as one more data point, not as proof.

Run the tests it wrote, and the tests it did not write

An agent can make its own new tests pass while quietly breaking behaviour that nobody was watching. Run the full existing test suite, not just the tests the agent added, and pay attention to anything that was passing before and is not passing now. If there is no existing suite covering the area it touched, that absence is itself useful information: it tells you exactly where your own manual check needs to happen, because nothing else will catch a mistake there.

Quick check

An agent adds a new function and writes three passing tests for it. What is the one thing those three tests cannot tell you?

Look for silent behaviour changes

The most dangerous mistakes are not the ones that crash. A crash gets caught immediately. The dangerous ones are quiet: a rounding rule that changed slightly, a default value that shifted, a condition that used to be inclusive and is now exclusive. None of these throw an error. They just produce a slightly different answer, and slightly different is often worse than obviously broken, because nobody notices until it has been running in production for weeks. Say you asked an agent to fix one broken discount rule, and while it was in that file it also tightened a date comparison two lines away, because the tighter version looked more correct to it. Nobody asked for that second change, the tests still pass, and it ships along with the fix you actually wanted. Scan for anything that changes a comparison, a boundary, a default, or a data format, even if it was not the thing you asked for.

Check the edges, not just the middle

Most bugs in AI-written code, like most bugs in anyone's code, live at the boundaries: the empty list, the first or last item, the value of exactly zero, the string that is already in the format you expected the code to produce. Test the middle case to confirm the happy path works, then deliberately test the edge cases the agent's summary did not mention. If it does not mention edge cases at all, that is worth noticing on its own.

Trust is earned per change, not per tool. The agent that got the last five things right can still get this one wrong.

Practise this on something real

Reading a checklist is not the same as doing it under pressure on a codebase you did not write. The Legacy Fix runs as an exciting IBM Bobathon challenge, built with IBM Bob. You take over a legacy repository as a junior engineer at a German car-parts company, direct an agent through a fix, and your grade depends on whether you caught what it got wrong, not on whether the code ran. You can read more about the format on the IBM Bobathon page.

Next time an agent hands you a change that looks fine, do not stop at fine. Read the diff, ask it to explain the part that surprised you, and run the tests that were not written today.

From ProoV

Prove this on a real project

You just read about the skill. These live briefs use real industry data and end in a certificate a recruiter can verify.

See all projects