Green, and still broken
A link on one of our own pages pointed at www.trailmem.com. It looked right. It was styled right, it lit up on hover, and the markup was correct HTML.
It went nowhere.
An address with no https:// in front is read by the browser as a page on the site you are already standing on. So the link landed on /bag-om/www.trailmem.com — a page that does not exist. No error. No warning. You find out when you click.
That is the costliest failure form in software, and it has nothing to do with carelessness: something that succeeds without having any effect.
What a test can actually see
A test asks the code. It asks: was the function called, did it return the right thing, did the server answer 200. Those are good questions, and they catch a great deal.
But every one of them is asked from the inside. A test can confirm that a button exists in the code, that it carries the right label, and that clicking it calls the right thing. It cannot see that the button sits behind another button. It cannot see that the text is cut off on a phone. It cannot see that the menu vanished in Safari.
We measured it on one of our own sites this week: the front page linked to a pricing page that did not exist. Not for an hour — for three months. Every test was green. Every page answered correctly. The menu entry had arrived, because menus are content; the page it pointed at had not, because it was code. Two halves of the same thing travelled by different roads, and only one of them got there.
There was no error to find. There was only a page that was missing.
So we open it
Lens is our answer. It opens the real page in a real browser, does what a user would do, and keeps the picture.
That sounds less technical than it is. A browser is not a formality — it is the only place where a page exists as the thing it is meant to be. Everything before that is a description of the page.
So Lens clicks. Types into fields. Signs in, if what you need to see sits behind a password. Waits for something to finish. And after each step it can take a picture a human can open afterwards.
The manuscript is written in ordinary sentences:
go to the front page
click Book a time
type the name
expect it to say Thanks
take a picture
No code. That is deliberate: the person who needs to read what was checked is not necessarily the person who wrote it.
What a screenshot alone cannot do
This is where most tools stop. They compare the new picture with the old one and report how many pixels moved.
It is a poor measurement, and the reason is worth understanding: a pixel diff can say something changed. It cannot say whether the result is usable. If a button moves ten pixels down because the text above it got longer, everything is fine. If it moves ten pixels down and lands underneath another button, it is gone. Same number, opposite conclusion.
So Lens measures the geometry of the finished page instead, and asks whether the screen holds together:
- Is anything sitting on top of anything else?
- Is a line of text clipped mid-sentence?
- Has an element ended up past the edge of the screen?
- Is the contrast too low for anyone to read it?
Those are questions with a right answer, and they are independent of what the page looked like yesterday. A serious finding turns the run red and stops the delivery — not because something changed, but because the result cannot be used.
If you want a model to look as well, it can be switched on. It runs on Mistral, hosted in Europe.
The trap we fell into ourselves
Here is a story against us, and it is the best argument we have.
We ran a check on a page. The check clicked a field to start editing it. The click succeeded. The element was there. Nothing happened.
The failure surfaced one step later — the toolbar that should have appeared did not. So everything pointed at the toolbar, while the problem was that the click came too early: the page was still starting up, and the field was not yet wired to anything.
Four runs went into looking in the wrong place, because every instrument said the click was fine.
It is the same shape as the dead link, one layer deeper. An action that succeeds without having any effect, and reports itself green. That is not a fault you find by reading a log. It is a fault you find by looking.
Three answers, not two
The single most important thing we have learned from building this fits on one line:
A check that can only answer "yes" and "no" is dangerous. It has to be able to answer "I could not look".
This week we fixed one of our own tools that reported 37 faults on a customer site. Seventeen of them were the tool's own. Live pages reported dead, email addresses it tried to "fetch", a server that simply does not answer one kind of request.
The damage is not the time. The damage is that a tool where half the warnings are wrong is one people stop reading — and then the one real fault becomes invisible among the nineteen wrong ones. There was one real fault in that pile: a dead link in a legal reference on the terms-and-conditions page.
So a check must never round "I could not get there" up to "everything is fine", nor down to "it is broken". The third answer has to stand there as its own.
What it means for you
You do not get a report saying it works. You get a picture.
Every change to your website passes through this step before it becomes something you can see. If the check fails, the work goes back to the AI colleague who made it, and you never see it. If it passes, a screenshot comes with it — kept, so it can still be opened six months later if anyone asks what the page looked like back then.
And it applies without exception. None of our AI colleagues is allowed to use a browser on the side. There is one road, and it leaves a trail.
"It works" is a claim. A picture is proof.