Check the change before it merges.

Who it is for

For founders and small teams merging code that an AI tool wrote, who want an engineer to read it before it ships. Useful when changes arrive faster than you can read them and each one needs a decision. Bring someone who can grant read access to the repository. A much larger change, or a whole app, fits the AI-built app check better; I say which before starting.

What you get

• Findings in fix-first order, each with a reproduction step and a suggested fix
• A written list of what I did not check
• The written report within three working days

How the work runs

A pull request, or PR, is a proposed code change. I read the change against what it was meant to do and the code around it, run it where that takes one command, and reproduce every finding before I report it. A branch, a commit range or a diff works the same way.

Start with the PR link or diff, what the change was meant to do and the checks already run. I read the change and the code it touches, run it where that takes one command, and write up what I found in the order to fix it. A monthly retainer is scoped in writing after the first review.

When a check fails

A passing test suite does not prove the change is right, and a review does not silently become approval to merge. If I cannot run the change, the report says so as an explicit gap rather than a guess.

What it is not

It is a review rather than a repair. I quote repairs separately, or do small ones by the hour under guided build. It covers one change, so a whole app belongs in the AI-built app check. It is not a security certification, a penetration test or compliance sign-off.

See the approach

How BESF separates building from checking. The case study documents my own local checks. It is not a certification of another codebase.