abbox

Visual verification for code changes

See what your code change did.

Your AI wrote the code. Abbox shows what changed on screen: it reads the diff, walks your running app to every element it touched, even in dialogs and behind forms, and reports what is there. One command for agents. One click for you.

Set it upBook a demo
$ npx @abbox/cli verify chg_88c84e38

PASS  Text changed "Word saved"
  Abbox: showing "Word saved". On screen now.
  page: /words/added/1a2b3c   heading: "Word saved"
  element: <h1> "Word saved" visible, 478x32
  expected text "Word saved": found
  signed in as: test-user
  console errors: 0   failed requests: 0
  screenshot: .abbox/verify/chg_88c84e38.png

From a run on our sample app: a page that only appears after a form is sent, reached with the backend’s answers mocked. Four hidden changes took 19 seconds.

Checking a change shouldn’t cost more than making it.

An agent changes twenty files in a minute. Seeing what that did to the product is the slow part, so it often gets skipped.

Today

  • ✕Start a browser, sign in, click through the app, and create test data just to reach one screen.
  • ✕States behind a form or a failed request get skipped, because forcing them means editing code.
  • ✕The agent says “done” because it type-checks. You review a long diff and still don't know what the page looks like.

With Abbox

  • ✓One command lists each change with its page, file and line.
  • ✓Abbox reads the code to find the clicks and backend answers that lead there, and does them. Nothing is written to your data.
  • ✓The answer is a few lines of text: pass or fail, the element, the page, console errors. A screenshot is there when layout matters.

Change. List. Verify.

  1. 1

    List what changed

    npx @abbox/cli changes

    Every changed element in your working copy: its page, file and line, and the condition it shows under.

  2. 2

    Verify it

    npx @abbox/cli verify <id>

    Abbox signs in with a test account, does the clicks, fills the forms and answers backend requests itself. It reports what is on screen.

  3. 3

    Try other outcomes

    npx @abbox/cli verify <id> --answers 201,404

    Pick the backend's answers by status and see the error, empty and not-found states, without breaking anything to get there.

Prefer to look yourself? The same list opens in the Abbox viewer, where clicking a change walks your app to it.

For coding agents

If you are an AI agent working on this kind of app, this is the short version. The full reference is in the agent docs and llms.txt.

When to use it
After changing the frontend of an app that has Abbox installed, before saying the change works. Especially for dialogs, success pages and error states.
What comes back
Per change: PASS or FAIL, the page it ended on and its heading, the element's tag, text, size and visibility, whether the expected text is present, console errors, failed requests, and a screenshot path. Exit code 0 only when all pass.
What it needs
The app running with npm run dev:abbox, abbox watch running beside it, and a test user in .abbox/test-accounts.json. No browser tool of your own.
What it can't do
It reaches what the code proves: state set by a click or form, pages reached with Next's router, requests to an Express backend. It shows the page handling a made-up answer, not that your real backend returns it. When it has no path, it says so.

A 2,000-line diff, shown as what your users will see.

When an AI writes the code, the diff is too long to read closely. Abbox turns it into a list of what changed on screen, and opens each one in your app, wherever it hides.

Example: four changes from one commit. Abbox opened the dialog itself to show two of them.

Every change, as an element

Added, changed and removed, each with its page, file and line. Not a list of files.

Opened where it hides

A dialog behind a click, a success page behind a form, an error after a failed request. Abbox gets there for you.

The same list for your agent

What you click through in the viewer, your coding agent runs as one command and reads as text.

Then see what the change did to your numbers.

The same map ties each element to its analytics event, its search checks and the backend route it calls. So a change can be shown with what it affects: a funnel step, a page’s search score, a slow request.

See how impact works

The same map, for the rest of your team.

The analysis that lets an agent verify a change also lets anyone click a part of your product and understand it.

Code-grounded answers

Ask about any button, form, page or change. Answers come from the code that renders it, with file and line.

Changes on every merge

Every merge to main is analyzed. See what was added, changed or removed, marked on the page where it happened, or compare any two commits.

Bug reports that find the cause

Abbox replays the last minute of clicks, requests and errors and points to the code that broke. Never what was typed.

SEO checks on the page

Missing or duplicate titles and descriptions, broken heading order and vague links, marked on the element and ready to fix.

One-click pull requests

Turn any conversation or finding into a branch and PR against main. Review stays with your engineers.

Built for developers and their coding agents. Useful to product managers, designers and support, who stop waiting for answers.

Three commands to set up.

  1. Add Abbox to your app

    npx @abbox/cli init

    Adds the inspector to a Next.js app. It only switches on inside Abbox. Your visitors never see it.

  2. Add a test user

    npx @abbox/cli accounts init

    One entry per kind of user your product has. It also writes a short note for your agents in AGENTS.md.

  3. Keep watch running

    npx @abbox/cli watch

    Analyses every save on your machine. Nothing leaves your computer. Connect GitHub and PostHog later for the team features.

Questions

How does an AI coding agent verify a UI change with Abbox?
It runs npx @abbox/cli changes to list the changed elements, then npx @abbox/cli verify with their ids. Abbox opens each one in a headless browser, signs in with a test account, walks the app to the element and prints pass or fail with the element's text, the page it ended on, console errors and failed requests.
Does verifying a change write to my database?
No. Requests on the way to the change are answered by Abbox inside the browser, and any other request that could change data is blocked. Reads still go to your backend, so the page shows real data around the change.
Does the agent need a browser or a screenshot tool?
No. Abbox runs the browser itself and answers in text, about ten lines per change. It also saves a screenshot and prints its path, for when layout matters.
How does it reach a page that only appears after a form is submitted?
Abbox reads the code: which handler navigates to the page, which requests that handler and the page make, and which answers the backend can give. It then fills the form with sample values, submits it and answers those requests with the backend's own success response.
How does it sign in?
With a test user from .abbox/test-accounts.json, a file your team keeps with one entry per kind of user. Passwords can be written there (the CLI keeps the file out of git) or named as environment variables. Accounts are only used on the local and test hosts the file lists.
Which apps does it work with?
Next.js apps today, with Express backends for mocked answers. It is free during early access.

Stop guessing whether it rendered.

See Abbox working on this page now, or on a real product in a 15-minute call.

Book a demo

Now try it on your own website.

Type your address. We read up to 5 pages from your navigation and give you a link to your own Abbox report: SEO issues marked on the page, and example numbers on your real buttons.

Your AI agents can read it too. The same reports are open to the agents working on your product, so their decisions start from what is really on your site.