3 Checks Before Shipping an AI-Built Website

jaosnmayn — Sat, 07 Nov 2026 11:53:35 +0000

Before You Trust AI-Generated Code, Check These 3 Things

Disclosure: I'm developing Agent Mission Guard, a local prototype that checks declared file scope and limited static HTML acceptance evidence. This article explains a free manual method; the prototype isn't available for outside installation and isn't a browser-test or security certificate.

A coding agent can write a surprisingly polished landing page, announce that the task is finished, and even report that its checks passed. The question for a freelancer delivering that page to a paying client is narrower: which exact properties did anyone verify, and which remain unchecked?

I learned this distinction while testing a small synthetic HTML task. A page contained the required heading and button, but one strict local-link acceptance rule did not pass. The underlying anchor was href="#", a common top-of-page shortcut, rather than the explicitly declared named anchor. That wasn't proof the browser button was broken. It was proof that our checklist and the intended user behavior needed to be reconciled. A useful verifier needs to make that distinction visible rather than just drawing a red badge.

Here is a simple review workflow you can use without buying another tool.

1. Write a tiny mission contract first

Before the agent starts, specify three things: the allowed files, files that must remain unchanged, and the evidence that would count toward acceptance. For example:

Allowed: site/index.html and site/styles.css.
Protected: site/legal.html and deployment.txt.
Expected result: the edited page has the agreed heading, a CTA pointing at a declared local section, and an explicit demo footer.

Notice what this doesn't say: that the project is secure, the CTA works in all browsers, the deployed site is accessible, or the client has approved it. Those are separate questions.

Rules written in a prompt are useful context, but they aren't independent proof that an agent obeyed them. Save the initial Git revision before work starts; otherwise you can end up comparing against a moving target.

2. Inspect the changed files, not just the summary

Use Git to inspect what changed relative to the agreed baseline, including committed changes and files that are newly untracked. Which exact diff commands you need depend on whether the changes are staged, unstaged, or committed. The official Git diff reference documents the distinctions. A single git diff without considering index state or untracked files isn't a complete inventory.

Write down the changed paths. Did the agent modify deployment.txt while making a layout change? Did it delete a protected page? A list of paths can answer these questions even before a human reads every line of code.

But a scope PASS has a narrow meaning: the files in the comparison were allowed. It cannot prove that a login works, that a form submits, or that a third-party service hasn't changed.

3. Check acceptance criteria one by one

A useful acceptance item is something a person can inspect without guessing. Compare:

“The page looks professional.” That's subjective; review it visually.
“The HTML contains a CTA with href="#contact" and a section with id="contact".” That's an explicit static check.

Even the second check does not establish a successful browser click. JavaScript can interfere, links can be hidden, or the target may be off-screen. Static checks are necessary only when they match the requirement, and often insufficient by themselves.

If you ask an agent for evidence, don't let the agent's own explanation substitute for a separate read of the resulting files. A good outcome record distinguishes present, missing, and not checked.

4. Deliberately break one declared property

On a disposable fixture, change the CTA target to a nonexistent ID. The heading and button still exist, but the destination check should fail. If your checklist continues to say everything passed, it isn't testing the property you think it is.

It's just as important to check for false alarms. In one local example, href="#" was technically navigable in the browser, but a stricter explicit-anchor rule treated it as incomplete. Instead of rewriting valid code solely for a green check, first decide whether that strict rule represents what the client actually requested.

This is why every failed criterion needs an explanation: the file, the observed mismatch, and what a reviewer should consider. Vague red labels waste time; unexplained green labels create false confidence.

5. Finish with human checks the static list can't do

Open the page at desktop and narrow widths. Use the keyboard and click the navigation. Verify the form with safe test data if it exists. Check the real deployment, authentication and server behavior separately. For accessibility and security decisions, use appropriate independent testing beyond static HTML.

Write a short handoff summary: what changed, what was tested, what failed, and what remains unverified. This will be far more honest to a client than “AI finished the website.”

6. Keep your free baseline in the comparison

Git plus a clear manual checklist may already be sufficient. Claude Code hooks and other agent lifecycle tools also let builders execute their own checks. But hook coverage matters: post-action checks cannot undo edits, and a matcher covering only one tool can miss another kind of write.

A separate verification product should earn its place by reducing repeat review effort, producing clearer evidence, or finding in-scope mistakes that existing free checks missed. If it only reproduces a diff with an extra screen, it may not be worth paying for.

That's the experiment we're running with Agent Mission Guard. The current private prototype checks a narrow set of local file-scope and static HTML requirements; it's not distributed or sold. The useful habit doesn't depend on it: *define what done means, inspect the artifact, and report the boundaries of the evidence.