The majority of engineering teams have already discovered that AI writes tests well. Point it at a codebase, and you’ll get unit tests, edge cases, and coverage numbers that look excellent on a dashboard.
That’s verification. It proves you built the thing right. Validation is the other question: did you build the right thing?
You can look inside the box and prove the code does what the code intends to do. That doesn’t prove the solution does what the requirement said it was supposed to do.
This distinction has always existed, and many teams treated it as a formality at the end of a release. It isn’t a formality anymore. When AI is generating a large share of your code, verification tells you almost nothing you didn’t already assume. The code will run. The tests it wrote for itself will pass. The question that matters is whether any of it reflects what the business asked for.
Everything else in the AI development conversation - review gates, linting, policy checks, coverage thresholds - sits upstream of the outcome that the stakeholders are paying for.
Validation testing is hard for a reason that has nothing to do with tooling.
Requirements age fast. They’re seldom complete when development starts; they change while it’s underway, and almost nobody has the time to go back and correct the inaccuracies. By the time you get to validation, you’re testing this month’s system against last quarter’s description of it.
So validation got pushed to the end, done by hand against a description of the system that had already drifted, and squeezed whenever the release date moved. Organizations know this, but few have had a practical alternative.
AI changes the economics of that. The formal requirements can be regenerated whenever the truth changes, so testing no longer has to wait for someone to reconcile the documentation first.
Pointing a model at a requirements document and asking for tests doesn’t work. The approach that works has three distinct stages that should be completed in order.
Implied in the existing requirements and documentation is a language that defines the solution: the entities, the relationships, the rules, the vocabulary the business already uses. Making that model explicit gives everything downstream something stable to reason against. Without it, generated tests drift into whatever the model inferred from phrasing.
Because the domain model regenerates whenever the source material changes, it needs a way to stop the AI from overwriting something a human has already signed off on. We track the status of each artifact so that collaborating agents and people agree on what has been accepted and rejected.
From the domain model and the product requirements, AI constructs stories and Gherkin statements. They’re readable by product people, reviewable by engineers, and precise enough to generate tests from. Each statement maintains a traceable link back to the requirement it came from, so a failing test points to the line it tests rather than to a general feature area. Because they’re generated rather than handwritten, they can be regenerated when requirements change, removing the manual requirements cleanup that used to block validation entirely.
This is where the interesting part is, and it isn’t where we expected it to be.
Because tests are generated rather than hand-built, you can regenerate them as often as you like. Every build, if you want.
Which means the tests running against this release aren’t identical to the tests that ran against the last one.
Our first read on that was that it’s a weakness. Repeatability is a core testing virtue. Non-deterministic suites are the kind of thing that gets a testing strategy quietly abandoned.
We now think it’s one of the strongest properties of the approach. A fixed suite tests the same paths indefinitely, and its coverage degrades from the day it’s written as the system moves underneath it. A regenerated suite explores adjacent variants on every run, which is continuous exploratory testing at the cost of automation. You get the breadth a manual exploratory tester would give you, at a frequency no manual team could sustain.
The trade-off is real: If you need a byte-identical regression suite for a regulatory audit trail, keep one. For everything else, a suite that keeps pace with development beats a suite that stays comfortably the same.
AI increases the speed at which code gets written. If validation doesn’t change, all you’ve done is move the bottleneck downstream and make it more visible. Faster coding with unchanged validation just means a larger queue ahead of the release.
Generated validation removes that queue. Full validation coverage becomes available inside the sprint, rather than trailing it by a hardening phase or a release cycle. The requirements no longer need to be manually reconciled before testing can start because they’re regenerated from the domain model as changes occur. That’s the gain, though not the full picture.
Generating the tests doesn’t remove the review step, it moves it. A team that’s had zero requirements formally written down doesn’t suddenly have the capacity to review nine hundred generated scenarios in a sprint. The fix isn’t asking people to review faster. It’s using the same domain model and functional decomposition that generated the tests to rank them, so a two or three person product team signs off on the ten most important scenarios first and works down the list, instead of facing the whole set at once. The review capacity constraint doesn’t disappear. It gets managed instead of ignored.
None of that changes the underlying effect. Full validation available inside the sprint, rather than trailing it, is what moves Lead Time for Change. That gap between code complete and confidence in the release accounts for a large part of the metric, and it’s the gap generated validation closes.
What we’ve learned building this for one of our clients is that the results hold up. The pipeline consistently achieves 73% or higher functional requirement coverage through systematic decomposition and scenario generation, with full bidirectional traceability from requirements to tests to test results and back again. Test suite creation time, from requirements to executable tests, has dropped by 70 to 85%.
The requirements themselves come out clearer, more consistent, and easier to test in the process. That was a side effect rather than the goal.
There’s a second effect that’s harder to measure and easy to underrate. The Gherkin scenarios serve as up-to-date documentation, since they evolve with the system. So teams can trust that what’s written down still matches what’s built, rather than checking that separately.
Continuous test execution surfaces drift early, before it becomes an expensive fix, and since every result traces back to a specific requirement, stakeholders can see what a pass or a fail means rather than taking someone’s word for it. The suite keeps pace with the system on its own, so developers spend less time maintaining tests by hand.
AI-augmented development needs guardrails. The ones being built right now check whether the code is well-formed and well reviewed, with decent coverage.
What matters even more is whether the system does what the business meant. Using AI to prove that is the guardrail that matters most, because it’s the only one measuring the thing you were trying to achieve.
If your validation is still trailing development by a release, that gap is where your lead time and most of your release risk live. We’ve built this pipeline on real engagements, including the parts that are still fragile. A two-week requirements and BDD readiness assessment will tell you where your team stands and what it would take to pull validation into the same sprint as the build.
