When code is produced faster and parts of the system cease to be deterministic, verification becomes essential: it becomes the only way to know if something works. The opposing intuition—"if AI writes better code, less QA will be needed"—confuses two distinct things: the syntactic correctness of what is written and its suitability for the business.
A model produces code that compiles and does something reasonable. It doesn't know if that something is what your company needs, because that information isn't in the code: it's in the process, in the regulations, and in the exceptions that no one has written.
Current systems combine deterministic and probabilistic components, and each is verified differently. Confusing them is the cause of most production problems.
|
Aspect |
Deterministic component |
Probabilistic component |
|---|---|---|
|
What is checked |
May the result be as expected. |
That the result is acceptable frequently enough |
|
Test result |
Pass or fail |
Quality distribution over a set |
|
When it runs |
In every change |
With each change and periodically in production |
|
What it detects |
Regressions |
Regressions and behavioral drift |
|
Who defines the criteria |
The technical team |
Business, with real-world case studies evaluated |
The most important row is the last one. In terms of probability, the "correct" criterion cannot be set by the technical team alone, because it depends on what the business considers acceptable: a summary that omits a secondary piece of information may be perfect in one context and unacceptable in another.
That's why the most valuable asset of an AI project is not the model or the prompt: it's the set of cases evaluated, with the response that the organization considers correct for each one. This set survives changes in vendors, allows for objective comparison of alternatives, and detects if a new version has worsened anything. It is the piece that makes it possible to change models without fear.
When the team wrote all the code by hand, peer review covered a good portion of the verification. With a larger volume, that coverage is diluted: not because the reviewers are worse, but because there is more to review in the same amount of time.
The 2024 DORA report measured the practical consequences: as AI adoption increased, delivery stability fell by 7.2%, associated with the growing size of changes. And 39.2% of developers reported little to no confidence in the generated code, introducing a rarely accounted-for cost: the time spent manually verifying something that was supposed to save time.
The solution isn't to increase review hours. It's to replace manual review with automated verification where possible, and reserve human attention for what only a person can judge: whether this is what the business needs.
Unit testing and integration. The same old thing, and now even more necessary because there's more code. Written or at least reviewed by one person: if the same system generates implementation and testing, the loop closes on itself.
AI component assessment set. Real-world scenarios with expected outcomes, run with every model, prompt, or configuration change. Without this, it's impossible to know whether an update has improved or worsened the system.
Evidence of exceptions. The rare cases in the process are used as tests. This is how we ensure the system scales to a person when it should, instead of improvising.
Specific safety tests. Prompt injection attempts, checking that the component cannot exceed its permissions, and verifying that it does not expose information it shouldn't. OWASP includes these vectors in its Top 10 for LLM applications in 2025.
Continuous verification in production. Periodic sampling of real-world cases, reviewed by a human. This is the only way to detect drift: a system can degrade without a single line of code changing, because the model, the data, or the context of use has changed.
The fifth layer is the one that almost never exists and the one that prevents the most incidents, for the reason we explained when talking about observability and automation [internal link]Without continuous measurement, the signal that something is wrong comes through the customer.
This is not a conservative argument. The profile of QA changes substantially, and for the better:
It's a shift from "checking that it works" to "defining what it means for it to work." The second task is more difficult, more valuable, and cannot be automated.
When someone proposes reducing investment in quality because "AI writes better code," the question that guides the conversation is: How will we know when it has stopped working?
If the answer is that someone will notice, the organization has delegated its quality control to the patience of its customers. If the answer includes automated testing, a versioned assessment suite, and continuous sampling in production, then efficiency can be realistically discussed.
No, it increases it. A model produces code that compiles and does something reasonable, but it doesn't know if that's what the business needs, because that information is in the process and the exceptions, not in the code itself. Furthermore, the higher volume of changes dilutes the coverage of peer review.
With a set of real-world cases evaluated and their expected response, executed with each model change, prompt, or configuration, the result is not "pass or fail" but a quality distribution. The acceptance criteria should be defined by the business, not just the technical team.
It's the collection of real-world case studies with the answers the organization considers correct. It's the most enduring asset of an AI project: it allows for objective vendor comparisons, detecting whether a new version has worsened the system, and changing models without taking blind risks.
Five: unit and integration testing, AI component evaluation suite, process exception testing, specific security testing (prompt injection, permission overreach, information exposure), and continuous verification through production sampling.
Yes. It can worsen because the model version changed, the input data changed, or the usage context changed. This is why verification cannot end with deployment and must continue with periodic sampling reviewed by people.
It shifts from repetitive manual execution to designing cases, building and maintaining assessment suites, and analyzing results in production. It moves from verifying that it works to defining what it means for it to work.
How would you know if your AI system has stopped working properly? We designed the assessment suite, exception testing, and continuous verification so that the response does not depend on a customer complaint. Let's talk →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
