Every test passed.
Your AI still got worse.
Not because your tests are bad.
Because they’re testing the wrong thing.
Software teams have spent years building confidence into every release.
Every code change goes through an automated pipeline. Unit tests. Integration tests. Security scans. End-to-end tests. Performance checks.
The goal isn’t to prove the software is perfect.
It’s to answer one simple question:
Can we confidently deploy this change knowing we didn’t break anything?
For traditional software, that pipeline has become incredibly effective.
For AI products, we’re still missing a critical stage.
AI changes more than code
One of the biggest shifts in building AI products is that what users experience can change without a traditional code change.
A prompt might change.
You switch to a newer model.
You update an MCP connector.
You modify a tool description.
You change your retrieval strategy.
You tweak an agent workflow.
Or sometimes… nothing changes at all.
GenAI systems aren’t fully deterministic. The same input can produce different outputs over time, even without any intentional changes on your side.
From an engineering perspective, these might seem like relatively small changes – or no changes at all.
From a user’s perspective, they can completely change the experience.
Will the assistant still understand what users are asking?
Will it choose the right workflow?
Will it complete the task?
Will it ask unnecessary follow-up questions?
Will it suddenly fail on scenarios that worked yesterday?
These aren’t code quality questions. They’re behavior quality questions.
The current CI/CD pipeline doesn’t answer them
Traditional testing is excellent at validating software.
Unit tests verify functions. Integration tests verify systems. End-to-end tests verify predefined flows.
But none of them answer the question that matters most for AI products:
What happens when real users start interacting with this version?
That’s usually something we discover after deployment – through customer feedback, support tickets, or production logs.
Only then do we realize that, although the software technically works, the user experience has changed.
Which raises the question: Are we really validating what matters before we deploy?
Simulating users before they become customers
To answer that question, we need something different.
Not another unit test. Not another benchmark. Not another LLM eval.
We need to understand how real users would experience the product before those users ever see it.
That’s what I mean by simulation.
A simulation creates representative users that interact with your AI product the way real people do.
Each simulated user has a goal, a persona, and a different way of interacting with your product.
Some are cooperative. Some are vague. Some change their minds halfway through. Some deliberately explore edge cases.
Instead of evaluating a single response, simulations evaluate the entire interaction.
Did the user accomplish their goal?
Did they get stuck?
Did the assistant recover?
Was the experience consistent?
Did the workflow succeed every time, or only some of the time?
Run hundreds of these conversations across your most important user journeys, compare the results to the previous version, and suddenly you can answer a question traditional testing never could:
Did this release improve or regress the user experience?
We need a new quality gate
In the era of GenAI, I believe behavior should become another automated quality gate in every AI deployment pipeline.
Not just after production, also before production.
Imagine every meaningful AI change automatically triggering hundreds of representative user interactions.
That changes what deployment confidence means.
We’re no longer validating only that the software works.
We’re validating that users can still accomplish what they came to do.
Instead of asking:
“Did the build pass?”
We should also ask:
“Did user success improve or regress?”
But a quality gate isn’t valuable just because it runs. It’s valuable because it helps teams make deployment decisions.
At the end of a simulation, we shouldn’t just know that something failed. We should understand:
- Which user journeys regressed?
- How often does the issue occur?
- How severe is the impact?
- Is this a new regression?
- Should this block the release?
In other words, simulation shouldn’t produce a simple pass or fail. It should produce everything needed to decide whether this version is ready to ship, and if not – everything needed to understand why.
Simulation shouldn’t end with finding issues
Finding regressions is only the beginning.
In traditional software development, a failed test or bug report starts another workflow.
Someone investigates the issue.
Someone prioritizes it.
Someone fixes it.
Someone verifies that the fix actually solved the problem.
AI products should work the same way.
Someone still needs to investigate the issue – start with a complete picture of what happened: the failed conversations, the user’s goal, screenshots, traces, tool executions, supporting evidence, and even a suggested direction for the expected behavior.
Someone still needs to prioritize the work – deciding whether the issue is important enough to fix now, whether it blocks the release, or whether it can wait.
And someone still needs to implement the fix – whether that’s an engineer or, increasingly, a coding agent using the full product and implementation context to determine the best solution.
Finally, the same simulations should run again so we can answer:
Did the behavior improve?
Did the issue disappear?
Did we accidentally introduce a regression somewhere else?
The loop closes only when user behavior improves – not when the code changes or the tests technically pass.
This is the direction we’re building toward
At Arato, this is exactly how we think about simulations.
Not as a replacement for evals or traditional testing.
But as another layer of confidence.
One focused on validating user behavior before users experience it.
Simulation isn’t a manual QA exercise.
It isn’t something you run once before launch.
And it definitely shouldn’t be something you learn from only after your AI is in production.
Instead, it should become a continuous behavioral validation layer built directly into your AI development workflow.
At Arato, the platform learns about your product, your users, and your business goals to build representative simulations automatically.
Every meaningful change can then trigger thousands of dynamic, multi-turn conversations that explore realistic user behavior across expected flows, edge cases, and unexpected interactions.
The platform analyzes the results, identifies behavioral regressions, and surfaces actionable findings across user experience, accuracy, consistency, compliance, performance and more.
Every issue becomes an actionable work item with the evidence needed to investigate and fix it.
We’ve spent the last two decades automating confidence in our code.
The next decade will be about automating confidence in our AI’s behavior.
Start Experimenting Now.
One platform that does it all.