Quality Gates Instead of Trust

When AI agents generate code in hours, the bottleneck of software development shifts from generation to verification. AI-generated code is not secure by default, and an agent that grades its own work is not a reviewer. This article describes how we replace trust with evidence in the agentic Software Development Lifecycle: with separate verification agents, four gates at which people decide, security checks inside the process, and acceptance tests against the specification.

Why trust is not a quality strategy

In the first article of this series, I described what changes when coordinated agents take over the executing work across all phases: people define the goal, make decisions, and are accountable for every release. The flip side of this division of labor is often underestimated. When generation becomes cheap, the volume of code, tests, and documentation that has to be checked grows, and an organization's verification capacity does not grow with it. This is precisely one of the most common reasons agentic transformations fail: verification as an afterthought. Generation scales, verification does not, and quality and trust erode with volume.

That this concern is not theoretical has been shown by research on the security of AI-generated code for years. One of the first systematic analyses of GitHub Copilot already found security-relevant vulnerabilities in around 40 percent of the programs examined (Pearce et al. 2022, arXiv:2108.09293). A study at Stanford University added a second, more uncomfortable finding shortly afterward: participants who programmed with AI assistance not only wrote insecure code more often, they also believed more often that it was secure (Perry et al. 2023, ACM CCS, arXiv:2211.03622). The models have improved considerably since then; the underlying problem remains: a language model produces plausible code, not proven code. It knows neither your organization's security policies nor the dependencies that are not permitted in your landscape, unless someone provides them as a verifiable rule. And the conviction that the code has been checked grows faster than the checking itself.

For me, one simple consequence follows: trust is not a quality strategy. Neither trust in a model nor trust in a vendor who assures you that its agent tests sufficiently. What takes the place of trust is evidence: traceable verification results at defined points of the lifecycle, decided on by a person.

When generation becomes cheap, verification becomes the bottleneck – and the quality promise.

Principle one: no agent verifies its own work

The first principle is the separation of generators and verifiers. An agent that produces code has the same blind spot as the person who wrote it: it tests against its own understanding of the task, not against the requirement. That is why, in the agentic Software Development Lifecycle, independent verification agents with their own context and their own mandate do the checking. They test against the specification, scan security and dependencies, and measure test coverage. At acceptance, a second, independent review model evaluates every test case; generation and evaluation remain separate.

The second element of this principle is test-first. Test cases are derived from the specification before code is generated. That sounds self-evident but is the exception in practice: in many organizations, tests are written after the code, by the same people, under time pressure. When the test cases come before the code, they define what "done" means, and the generator works toward a target it cannot move itself.

Both presuppose that the specification is verifiable. A requirement such as "the system should respond quickly" can neither be translated into a test case nor accepted objectively. That is why verification at ReqPOOL does not start with the code but with the requirement: with reqChecker, we check wording against IREB and ISO/IEC/IEEE 29148 for unambiguity, verifiability, and singularity before it becomes the basis for test cases and machine-readable build orders.

Principle two: four gates at which people decide

The second principle is binding quality gates along the lifecycle, from the verifiable requirement to operability. We work with four gates: Definition of Ready, Definition of Done, Definition of Deploy, and Definition of Operability. Each gate is defined by three things: a guiding question, the evidence that answers it, and the person who decides on that basis. Agents generate, agents verify, people decide; every release remains a human decision, and every agent step behind it is logged.

What matters is what does not happen at the gates: there is no negotiation. A gate that is opened under deadline pressure is not a gate but a formality, and at agentic volume one that repeats a hundredfold. That is why the gate criteria are stored in machine-readable form, so that an agent cannot even hand over what does not meet the criteria. What reaches the human is a verified result with a verification log, not a request for trust.

Human validation does not mean that someone reads every generated line. At agentic volume, that would be neither possible nor sensible, and a review that turns into rubber-stamping out of overload is more dangerous than none at all, because it feigns assurance. People check where judgment is required: in the architecture and business review of every increment, on the question of whether a solution is functionally correct and appropriate, in the assessment of risk and technical debt. Everything that can be expressed as a rule is checked beforehand by verifiers, completely and every time.

The time savings arise not despite the gates but because of them. Because verification is systematic rather than sampled, defects are found where they cost least: in the specification rather than in operations. In our projects, software quality rises by around 30 percent as a result (experience from ReqPOOL projects since 2023, verifiable per project, not scientific evidence). And the up to five times faster delivery in the agentically orchestrated implementation model holds only on the condition that the guardrails remain stable: change failure rate, production incidents, defect rate, and test coverage must not deteriorate. Speed without this condition is not a metric but a bet.

Security gates: finding vulnerabilities where they cost least

In the agentic lifecycle, security is not a separate step at the end but part of the Definition of Done and the Definition of Deploy. Concretely, this means three things for us.

• Security scans and dependency checks before every merge. Independent verification agents scan the generated code and its dependencies; libraries with known vulnerabilities or impermissible licenses block the gate, without discussion.
• Compliance as code. Security policies, architecture guidelines, and regulatory requirements are formulated in machine-readable form and enforced in the pipeline rather than remembered in documents. A policy an agent cannot read does not exist for it.
• Security review before go-live. Before the production release, our experts review the overall system in a security review; tested rollbacks are part of the go/no-go decision.

Added to this is the complete audit trail: every agent action, every context used, and every release is logged and can be reconstructed. For regulated industries, this is not an extra but the precondition for being allowed to go into production at all. The AI Act, Regulation (EU) 2024/1689, requires human oversight, transparency, and risk management for AI systems; Regulation (EU) 2022/2554 (DORA) requires robust ICT risk management and operational resilience from financial entities. Human gates, logged agent steps, and a chain of evidence from regulation through requirement and code to release answer exactly these demands.

Acceptance tests against the specification

The last question before go-live is not whether the code looks good but whether the software demonstrably meets the specification. That is why acceptance is a gate of its own for us, with its own evidence. With Signoff, we break the specification down into atomic, verifiable requirements, each with a unique identifier and a verbatim reference to the source clause. For every requirement, test cases are generated including test data, edge cases, and negative cases, linked in a traceability matrix. An agent runs the tests against the running system and collects evidence in the form of screenshots and logs; an independent review model rates every test case as passed, failed, or not verifiable. The result is an audit-proof acceptance report with full traceability from the specification clause to the test result.

Here, too, the human remains accountable: test cases and test runs are approved before execution, and the final acceptance is granted by the client. This applies regardless of whether the software was built by agents, by your own team, or by a supplier. Precisely this neutrality makes acceptance against the specification a steering instrument: what is commissioned, accepted, and warranted is the specified result, not the time spent.

In reqCoder, ReqPOOL's complete agentic Software Development Lifecycle, which is in internal use at ReqPOOL, these checks are anchored as a chain of evidence across four stages: scope proof and estimate after the prototype, reqChecker review and security scan in the beta, Signoff acceptance and audit trail before go-live in the deployment stage, full transfer of intellectual property in production. Each stage is commissioned individually, and the decision on the next one is made on the basis of the evidence at the gate. That is the practical meaning of this article's title: the advance of trust that classic projects presuppose over months is replaced by verification results you see before you commission the next stage.

What this means for your organization

From our projects, five consequences can be derived that apply regardless of the model and tooling in use.

• Define gates before tools. Whoever distributes licenses without defining gate criteria gets more code with the same verification capacity. Definition of Ready, Done, and Deploy are organizational decisions, not tool configuration.
• Derive test cases from the specification before building. This presupposes requirements of verifiable quality and is the point where most organizations have to catch up first.
• Separate generation and verification. Independent verification agents with their own context, a second model for evaluation, human review authority over every merge.
• Store security and compliance as code. What is not machine-readable is not adhered to by agents; what is machine-readable is checked automatically at every gate.
• Measure guardrails, not just speed. Change failure rate, production incidents, defect rate, and test coverage belong next to the efficiency metric; the four metrics of delivery research (Forsgren, Humble, Kim 2018) provide the standard.

I consider this the most important topic of the series because it decides the credibility of the entire approach. Delivery up to five times faster is a result that can only be justified with non-negotiable verification. Without it, agentic software development is an experiment; with it, it is a system fit for acceptance, including for banks, the public sector, and regulated industries.

The next step

How we anchor quality gates, separate verification agents, and compliance as code in your delivery organization is described on the page Agentic Software Development Lifecycle. What the chain of evidence across the four stages looks like in our own agentic pipeline is described on the page reqCoder. In an expert conversation, we jointly examine which gates exist in your organization today and which are still missing before the first agentic pilot.