Self-review: the build opens its app in a browser and fixes what it sees
A model writing code can't see the result, which is why AI-built apps so often ship with text spilling off a phone screen or a button that throws an error. When Cloudflare Browser Rendering is available, Anticode opens each new app build in headless Chrome, screenshots it at a phone's and a laptop's width, clicks through its buttons, and hands the pictures and errors to the Critic to fix.
The gap between code and what people see
A language model writes HTML, CSS and JavaScript from patterns, and most of the time the patterns hold. What it can't do, by itself, is notice that a heading wraps into four lines at 390 pixels wide, that two panels overlap, or that pressing Start throws an exception because a variable was renamed halfway through. Those are things you find by opening the page. AI builder screenshot testing closes that gap: the build looks at its own output in a real browser before you do.
What happens during the review
- Once the app is written and has passed the code gate, it's saved as a private preview.
- A headless Chrome opens the preview at 390 pixels wide, the width of a typical phone, waits for it to settle, and takes a screenshot of the first 2,400 pixels of height.
- It does the same at 1,280 pixels, a common laptop width.
- At the laptop width it clicks through up to fourteen buttons and submit controls, once each, skipping anything hidden or covered.
- Throughout, it collects every error the app reports, up to a dozen.
- The screenshots and the error list go to the Critic with a fixed brief: fix each error at its cause, then fix anything visibly broken, such as overlapping or cut-off text, something squashed or off-screen on the phone, an empty section, an unreadable control or inconsistent spacing.
- The Critic makes focused edits. It isn't allowed to redesign the app, change what it does, or touch anything you specified: your words, colours, fonts, items and order. If nothing's wrong, it changes nothing.
You see the step in the build log as the app being reviewed, with how many controls were clicked and how many errors were found, followed by the Critic's one-line note on what it fixed, or that it looked right.
A fix can't make things worse
The edited app goes back through the code gate. If any check is worse after the fix than before it, the fix is dropped and the app as originally written stands. That rule matters because a visual fix that, say, adds an outside script to solve a layout problem would be trading a cosmetic issue for a security one.
Errors found later
The review only covers what fourteen clicks can reach. When you use the app in the builder's preview and it reports an error, the builder notices. If the error happens as the app starts, it fixes it straight away, once, without being asked. If it happens later, a card shows the error with a Fix it button. Either way the fix is a normal change request, so it appears in the log and can be undone. More on that loop is on the change requests page.
Limits
| Covered | Not covered |
|---|---|
| New app builds | Changes to an existing app, and pages from the design engine |
| Two widths: 390 and 1,280 pixels | Tablets, very wide screens, landscape phones |
| The top 2,400 pixels of each width | Content further down a long page |
| Up to fourteen clicks, once each | Typing into fields, long game sessions, multi-step flows |
| Errors the app reports and what's visible | Whether the content is right for your business |
It also depends on Cloudflare Browser Rendering being available. Without it, the step is skipped and the build works as before, with the code gate and the design checks still applied. Self-review is a safety net, not a test plan: open the app on your own phone before you share it, and see testing a website on mobile for what to look for.
Questions people ask
Does the review cost extra?
It's part of the build, and what each build actually costs is measured against your allowance as usual. Failed builds aren't charged.
Why don't design-engine pages get this review?
They're laid out by a deterministic engine written to pass the design checks, rather than by a model writing code from scratch, so the risk this review targets is much lower.
Can I see the screenshots?
No. They're sent to the Critic for the review and aren't shown in the builder. The log tells you what was clicked, what errors were found and what was fixed.
What if the Critic's fix is wrong?
Restore the previous version from History, or ask for the change in words. A fix that makes any check worse is dropped automatically.