Proof
AI lets software teams ship more changes than ever. Testing has not kept pace. Proof maps your website, creates tests from confirmed behavior, and records evidence when you run them.
AI helps each engineer write more changes, but every change still waits for one review desk. The line backs up, and the backlog grows.
01 · The new pace
For years, work moved through lanes. Design handed off to engineering. Engineering handed off to QA. QA approved the release.
AI changed the middle of that line. Engineers now write and ship many more changes, and the pull requests keep coming. The lanes on either side did not speed up with them.
Without Proof, review can’t keep up with AI-written changes. They pile up, and some ship without review.
In the new SDLC, writing a change is the easy part. One engineer with an AI assistant can open several pull requests before lunch. The hard part is verification: knowing that the change does what it should, and that it did not break something else.
Verification used to happen at the end of the line, in QA. It was slow, but changes arrived slowly too. Now the line is full. Changes wait for review, or they go around it. Waiting slows every release. Skipping review means nobody is sure what the change touched.
QA teams feel this first. They cannot keep up with the volume, and everyone knows that skipping independent verification is a risk. The cost of software has moved from writing it to verifying it.
02 · The blind spot
Most changes now arrive with tests, often written by the same AI that wrote the code. Those tests check the code from the inside: a function returns the right value, a component renders. They rarely use the product the way a customer does, across pages, with a real sign-in, a real cart and a real checkout.
So a change can pass every one of its own tests and still break the product. The code works, the tests pass, and a customer finds the problem a week later.
That is how a fix to sign-in empties a shopping cart. Only a test that signs in and then opens the cart, like a customer would, catches it.
03 · What Proof does
Proof explores your website and uses what your team tells it. From that, it builds a list of the things your product must do and why each one matters. Your team confirms or corrects that list.
Proof uses your product in a real browser, the way a customer would. It clicks, types, waits for pages and reads what is on the screen. It does not only check that the code ran. It checks that the customer got what they came for.
Your team confirms the expected results and permitted actions. Proof writes and verifies the selected tests. Run saved tests after a change and compare the results with their evidence.
The fictional example below shows a browser journey and a Finding.
Opening the store as a new visitor.
Proof follows the Cart flow: add a backpack, sign in, open the cart. The cart is empty, so Proof writes a Finding.
Open the result to compare expected behavior with what the browser observed. Evidence can include screenshots, steps, and video when available. The report below is a fictional example.
| What broke | The cart is empty after a customer signs in. |
|---|---|
| Why it matters | Customers who sign in at checkout lose their order. |
| Started after | Change #215 · “Update session handling” |
| Diagnostics | The cart request after sign-in returns 0 items. The session ID changes at sign-in, and the cart stays with the old session. No console errors. |
| Recording | Open the store, add a backpack, sign in, open the cart. Reproduced twice. |
| Not yet confirmed | That the session change is the cause. It is the strongest lead. |
04 · Keeping pace
Saved tests repeat confirmed steps without another model call. Your team chooses which tests and Environment to run. The current website workflow does not automatically test every pull request. A safety stop blocks scheduled monitoring.
Fast teams also change their pages often, and that usually breaks tests. Someone then spends the week fixing them instead of testing. Request a repair when a saved test needs attention. Proof verifies the candidate in a fresh browser and preserves the confirmed expected text. A failed repair keeps the current version.
05 · People
Proof can explore your website and propose useful test cases. Your team reviews its understanding and confirms tests before writing starts. You choose when to run saved tests and when to request a repair.
If you have full-time QA engineers, Proof gives them superpowers, the same way AI gave software engineers superpowers. They stop repeating the same checks and fixing broken scripts. They decide what matters, point Proof at the hard cases and get the reach of a much larger team.
06 · Where we are
The first teams will help shape how Proof grows. They get hands-on setup, direct access to the founder and real influence over what we build next. Expect rough edges.
If this is how you think QA should work in the age of AI, talk with the founder and see what we are working on.
