Do AI app builders test the code they generate?

What their documentation says

We read each tool's own public documentation on 19 August 2026 — not review sites, not last year's blog posts — and recorded what it says about checks that run before you are shown a preview. The comparison pages carry the sourced version of each cell.

Replit is the most explicit. Its Agent documentation states that the Agent "tests its own work on a regular basis" and "writes code, sets up infrastructure, and tests the result". What is not documented is a fixed sequence of checks that has to pass before you see anything.

Base44 ships a testing agent that "opens a real browser, follows the flow like a user would, then tells you exactly what passed, what failed, and why". Its documentation is equally clear that it "runs on demand only — not automatically before preview", with scheduled runs listed as planned.

Lovable does not document a pre-preview check. It offers a "Try to fix" option once an error appears, with ten free automatic fixes per workspace before further fixes consume credits.

v0 describes an isolated per-chat virtual machine that runs your project and the live preview. Neither the sandbox documentation nor the FAQ mentions a build, test or typecheck gate.

Testing as a habit versus testing as a gate

The distinction that matters is not whether tests exist somewhere in the system. It is whether a result can reach you without passing them.

An agent that tests its own work is doing something genuinely useful, and it is more than most of this category does. But "on a regular basis" is a description of a habit. It leaves you unable to tell, on any given preview, whether the checks ran and passed or simply did not run.

A gate is a different property. If a fixed chain has to pass before a preview is released, then the existence of the preview is itself the evidence. There is nothing to wonder about.

Why so few tools do it

Three reasons, and they are all honest ones.

It costs time. A full chain adds tens of seconds to a build, and this category has spent two years competing on how fast something appears. Showing you a preview four seconds after you hit enter is a better demo than showing you one forty seconds later, even when the second one works.

It requires somewhere safe to run. You cannot execute untrusted generated code on shared infrastructure, so a verification chain implies a per-project sandbox and the cost of running one for every build.

It only pays off later. The benefit of verification shows up on the fifth prompt, not the first, and by then the trial is over.

What to ask before you choose

• Which checks run, and do they run on every build or when the agent decides?
• Is the preview held until they pass, or shown regardless?
• When something fails, does the tool fix it automatically, or tell you and wait?
• Does fixing generated errors cost the same currency as generating features?

That last one is not a rhetorical question. On at least one tool in this category, fixing what the model got wrong consumes the same credits as asking for something new, after a small free allowance. Whether that is reasonable is your call — but it is worth knowing before you pick.

How to check for yourself in ten minutes

Documentation tells you what a tool promises. This tells you what it does.

Build something small, then deliberately ask for a change likely to produce a type error — adding a field that can be empty and using it where a value is required is reliable. Then watch what happens. Does a preview appear immediately and break when you click? Does an error surface with a button? Or does the tool visibly check, fail, fix and re-check before showing you anything?

Do the same thing twice more with different changes. Three data points will not tell you the repair rate, but they will tell you which of those three behaviours is the normal one — and that is the behaviour you will live with for the rest of the project.