For looking at a page, you do not — an agent with a browser is genuinely better at that, and cheaper. Use it.

What that session is not is a gate. It is ephemeral, unauthenticated unless you walk it through a login every time, and it leaves no record. Nobody is prompting it at 2am when a bad merge lands. Vera runs the same flows credentialed, as a chosen role, against a chosen environment, on a schedule and in CI — and keeps the result, so there is something to compare against next week.

It is also not either/or. Vera ships an MCP server, so you can ask Claude to run the checkout suite against staging, read the failure, and open the issue — it just does it through the thing that keeps the record.

You can, today, and it will hand you something plausible. Then you own the part that is actually hard: running it on every pull request as the right user, against the right environment, on real browsers, with credentials that work; keeping it green when the DOM shifts next sprint; and knowing whether any of it proves something.

Writing the first draft is the cheapest step in the job. Vera is the rest of it.

The generation feature is a wrapper, deliberately and thinly, so you can swap the model the day a better one ships. We would rather be a thin wrapper than a stale prompt.

The rest is not. Turn AI off entirely and Vera still records flows, runs them on three browser engines, holds a browser pool, seals credentials, keeps video and traces, diffs screenshots against baselines, runs on a schedule, gates pull requests, and exports back to code. The model writes first drafts. It does none of that.

A better model makes a generated test wrong less often. It does not tell you whether this test is wrong — that is a different kind of question, and no amount of model quality answers it, because the model grading its own output is the problem, not the solution.

The negative control is an experiment, not a prompt: run the test against data it should reject and see whether it fails. That check gets cheaper as models improve, and never redundant. If anything, the better generation gets, the more tests you will have and the less any human will read them.

Because the use cases are written down. Vera keeps a per-project rule book of what your app is supposed to do — each rule proposed from your source with file-and-line evidence, and approved only by a person. Coverage is then measured against those rules, not against how many tests got generated.

The distinction matters because a page can only ever tell you what is on the screen. It can never tell you what the screen is supposed to say. That is the one thing no amount of DOM reading solves, and it is why the rule book is human-approved rather than inferred.

A negative control. Vera re-runs the test demanding an outcome your app cannot produce — a data table has its pass/reject column flipped, and any other test has one assertion's expected value falsified. Every one of those controls must fail. If the test passes anyway, its assertions are not connected to your app at all, and Vera records the verdict insensitive.

An insensitive test is then refused as coverage. It gets its own bucket on the coverage map, ranked below uncovered on purpose: an uncovered rule at least looks like work to do, while a rule covered by a test that cannot fail looks finished and is not.

Because it is a real browser run, not a static check, and you see each control, which assertion it falsified, and whether it failed. A control that passes is displayed as the failure it is. Only the expectation is mutated — never the selector — so a control that fails does so because the app disagreed, not because the test could no longer find the button.

Here is its limit, since you will find it anyway: an assertion that only checks something is present has no expectation to falsify. A test built entirely from those is reported unknown, not sensitive — Vera will not award it a clean bill of health it did not earn, and tells you to assert an expected message, value, URL or status instead.

Healing replaces the locator, never the expectation. The step is retried with a new selector and the same assertion, and that assertion still has to pass — if you broke the page, it fails and the run stays red. An expectation like a URL check is deliberately never re-derived from the live page; only a locator is. That asymmetry is the entire safety property.

Where you are right: healing can mask a deliberate removal — a button you meant to delete gets found again under a new name. So heals are capped at three per run, each one is recorded on the report with the old selector and the new one, and an in-run heal never rewrites your stored test. It gets the run past a renamed class; it does not quietly edit your suite.

Then leave it off, which is where it already is. Auto-repair is opt-in per project, needs a paid plan and your own AI key, and only ever touches saved tests.

Switched on, it escalates heal, then suggest-a-fix, then diagnose-by-reading-your-source — and a fix persists only after the test has actually gone green on a re-run. Nothing is accepted because a model sounded confident. Every change lands in an append-only audit log and is revertible.

Some will be, and so are hand-written ones — flake is a property of end-to-end testing, not of who wrote the test. Pretending otherwise is how suites get abandoned.

So Vera measures it instead. Every test carries a 0–100 flake score, a pass-on-retry is flagged rather than hidden, and quarantine lets a flaky test keep running and recording while it stops blocking the pipeline. The GitHub Action fails a pull request only on real failures; quarantined and passed-on-retry surface as warnings. The goal is not zero flake. It is that red keeps meaning something.

You get an editor, not an export folder. Every generated step lands in the visual builder, so you fix the one that is wrong and move on — no code, no regenerating the suite, no waiting for a better prompt.

When Vera repairs something itself, the fix only persists after the test has actually gone green. Nothing is accepted because a model sounded confident, and every change is recorded and revertible.

There is a ceiling, and it is worth knowing where it is. Below it: 27 step types, if/else and loops with element, URL and variable conditions, project and per-environment variables, reusable flows shared across tests, HTTP calls with JSON path extraction, and values captured from one page and used on the next.

Above it: if a test needs arbitrary code in the middle of it, Vera is the wrong shape and you should not fight that. Export the test as runnable Playwright and take it with you — that path is there precisely so hitting the ceiling costs you a click rather than a rewrite.

You pay them to write code. Neither of them remembers that checkout worked yesterday, notices that it stopped working this morning, or blocks the merge that broke it.

And you are not paying twice for the model: AI in Vera runs on your existing Anthropic, OpenAI or Google key. We resell no tokens and meter no credits, so the subscription buys the part your assistant does not do.

Everything that is not the model. Free is real and generous enough to answer "does this work on my app" — unlimited tests and runs, the editor, the recorder, AI generation on your key, the local agent, site audits, video and failure traces, and shareable reports.

You pay when it has to run without you: scheduled runs, environments with their own URLs and sealed credentials, the CI API and pull-request gating, quarantine, visual regression, alerting. And you pay more when more than a couple of people depend on it: custom roles, an audit log, the coverage map, cross-project chains. That is the bill — operations, not intelligence.

So is the compiler, and teams still buy build systems. The cost of end-to-end testing has never been the runner.

It is that the person who knows which flows matter — support, QA, the founder — usually cannot write the code, and the engineers who can have shipping to do. It is that a suite decays every sprint until someone declares bankruptcy on it. If your team is genuinely maintaining a healthy Playwright suite today, keep it, and point Vera at the flows it does not cover.

You could build a Playwright runner in a sprint. Then you own a browser pool that does not exhaust the box, artifact storage with retention, a step schema, retries and flake scoring, environments and sealed credentials, screenshot baselines with an approve/reject review, a live progress stream, role-based access, an audit log, and an interface a non-engineer will actually use.

That is not a sprint. It is a product, with an on-call rotation. If all you need is Playwright in CI, build it — genuinely, that is the right call for some teams. Vera earns its price when the people who know what to test cannot write the tests.

Yes, and you never have to switch it on. Record a flow by clicking through your app, import a suite you already have from Cypress, Playwright, WebdriverIO, Selenium, TestCafe, Postman, a HAR capture or an OpenAPI spec, or build the steps by hand in the editor.

Nothing in the recorder, the builder, the runner, the scheduler, the CI action or the reports calls a model. Even self-repair is off until a project opts in. AI is a feature here, not a dependency.

AI runs on your own Anthropic, OpenAI or Google key. Keys, login credentials and captured sessions are sealed before they touch the database and are write-only over the API — they can be set, never read back. We resell no tokens and meter no credits.

When Vera reads your repository to propose config or rules, it reads: it can open, grep and glob files, and it cannot write one or run a command. And the local agent executes tests on your machine, next to localhost — no tunnel into your network, no database access.

Correct, so do not migrate. That is the honest answer and it is also our advice: your Cypress suite already works, and converting it buys you nothing but risk.

Point Vera at the flows you never got round to covering — the ones that keep breaking in production because nobody had time to write them. If you do want a head start, the importers turn Cypress, Playwright, WebdriverIO, Selenium, TestCafe, Postman, HAR captures and OpenAPI specs into editable steps. Be clear-eyed about what that gives you: the steps, not a passing suite. You will still run them and fix what breaks.

Then the test did not cover that case, and no tool on earth can promise you otherwise. Anything claiming to guarantee you will never ship a bug is selling you something.

What Vera does is narrow the gap and refuse to hide it: coverage is measured against a rule book you approved rather than against a test count, a test that cannot fail is not counted, a denial that was not observed is not scored, and an uncovered rule is shown as uncovered. You will still ship bugs. You should be able to see, afterwards, exactly which rule nobody had a sensitive test for.

It is a fair thing to price in, and the mitigations are concrete rather than reassuring words. Every test exports to runnable Playwright, WebdriverIO, pytest or TestCafe code, and every run to JUnit XML, so your suite leaves in a form your team maintains by hand — no proprietary format to reverse-engineer. The local agent already executes those tests on your own machines rather than ours.

What that adds up to: if we disappear, you lose the dashboard and the history, not the tests. That is the most any vendor can honestly offer, and rather more than most do.