An AI agent found a bug that let a hotel check a guest into a room someone was already sleeping in.
Nobody wrote that test.
Nobody told it where to look.
We pointed it at the repository and gave it no test plan, no selectors, no "click here, assert that."
It figured the product out on its own.
It read the routes, API modules, services, and database schema, then reconstructed the business workflow:
• Book → Check-in → Night Audit → Checkout
• Group Reservations
• Cancellation → Availability Release
Then it executed those workflows end-to-end.
Not fake data.
Not mocked APIs.
Real reservations.
It verified data on the backend—not just whether the UI looked correct.
It completed 364 steps for $1.79.
And it found a critical production bug:
The check-in endpoint never validated room occupancy.
That isn't a broken button.
That's a guest arriving at 11 PM, walking into an occupied room, and your hotel paying for refunds the next morning.
Why this isn't another "AI testing your app" demo
Most browser agents only know how to click buttons and compare screenshots.
If the UI looks fine, they assume everything is fine.
Real products don't fail that way.
They fail in the gap between what the UI claims happened and what the backend actually persisted.
Our approach changes two things.
1. It reads the code before touching the UI.
Instead of following a human-written script, it derives its own test plan from your routes, services, and schema.
2. It verifies the backend, not just the browser.
It drives the UI with Playwright while validating state through authenticated API calls.
A green toast message isn't enough.
If the reservation wasn't actually saved, the test fails.
Three mistakes we made building it
1. Agents aren't deterministic.
One run found zero bugs.
The next found five.
Same repository.
Same commit.
The solution was to execute flows multiple times and merge the findings.
2. Agents hallucinate.
One run invented an API endpoint, received a 404, and confidently concluded the feature didn't exist.
We fixed that by giving it the application's real endpoint map instead of letting it guess.
3. Agents never know when to stop.
"Please wrap up when you're done."
It ignored us.
103 tool calls later, it was still exploring.
The fix wasn't a better prompt.
It was enforcing hard execution limits inside the tooling itself.
That's the real engineering challenge.
Getting an AI agent to click through a website is a weekend project.
Building one you'd trust to file production bug reports takes months of engineering guardrails.
This doesn't replace your existing test suite.
It finds the failures your test suite was never written to look for.
It's open source under the MIT license.
If you have a product with a real backend and want us to run it against your application, comment "run it" and we'll set one up.
Top comments (1)
Try it yourself
The code is open source under the MIT license.
Self-host it, inspect it, or adapt it to your own workflow.
GitHub: github.com/Simbastack-hq/sentinel
It runs on a simple 15-minute scheduler and is designed to continuously explore your application for issues traditional test suites often miss.
If you're interested in how it works under the hood—including how it derives business workflows directly from a codebase and the safety model behind it (read-only reviews, docs-only worktrees, and zero writes to your application)—the full technical write-up is here:
Engineering blog: blog.simbastack.com/announcing-sen...