The four failures a screenshot approves
Mock data
POST returns
200, the row appears, nothing persisted. Reload and it’s gone. The screenshot
during the demo is perfect.Dead handler
Button has an
onClick, the onClick calls a function, the function was never wired to the
store. Looks connected all the way down.Double submit
One click, two POSTs, customer charged twice. Zero pixels differ.
Silent validation
The form accepts
"abc" as a quantity and sends it to your database. Renders beautifully.”Just use a better model”
This is the intuition worth killing, because it sounds reasonable and costs teams months. Model quality is not the constraint. You cannot see a network call. You cannot photograph a state mutation. A screenshot of a page whose bug is non-visual contains no signal about that bug, so asking a stronger model to look harder produces a more confident version of the same wrong answer. Improving the model improves the reading of the evidence. It does not create evidence that was never captured.What “reading the program” means instead
Reticle runs inside the app and reads what actually happened:net.total: 1 kills double-submit. stateDiffs kills mock data, the store genuinely changed. signals is the app declaring success in its own words. consoleErrors: 0 kills “it worked but threw”.
No pixel in the world carries that.
A real one, caught on the first run
On the first drive of a real production dashboard, before any instrumentation, Reticle’s network observation flagged two endpoints returning500. A database migration that had not been applied.
The page rendered fine. The sidebar loaded. Nothing looked broken. A screenshot agent would have called it done and moved on.
That is the thesis in one incident: “looks done” and “is done” are different properties, and the difference is usually non-visual.
When a screenshot is the right tool
Screenshots are not useless. They are the correct instrument for a specific class of bug, and this page would be dishonest without saying so:- A font that failed to load
- A GPU or compositing glitch
- Layout that breaks only at a particular viewport
- Anything where the actual rendered frame is the thing under test
reticle_screenshot and reticle_visual_diff for exactly this, and if pixel regression is your primary concern, a dedicated visual tool will serve you better.
The argument is not “screenshots are bad”. It is that a screenshot cannot answer “did the code work”, and that is the question an AI coding agent needs answered on every change.
The honest limits
We have not proven that Reticle makes agents fix more bugs. A controlled test did not show a fix-rate improvement; the benchmark was confounded and we are still working on measuring it properly. What is measured is detection: 10 of 10 injected regressions caught with zero false alarms, against 9 and 8 for the alternatives.See a real verdict
Five minutes, and the output on that page was captured live.
The full benchmark
Method, raw numbers, and where Reticle comes second.