Why Agentic Testing Changes What 'Done' Means for Engineering Teams Shipping AI

Engineering teams that grew up on scripted test suites have a well-developed intuition for what "done" looks like: the suite passes, the coverage threshold is met, the build goes green. That intuition breaks down when the system under test is itself an agent capable of pursuing goals through sequences of decisions that were never explicitly anticipated. The shift to agentic testing is not a tooling upgrade. It is a redefinition of the quality gate, and the engineering leaders who treat it as the former will find themselves approving releases that their test infrastructure was never equipped to evaluate.

Companion piece to our broader work on operationalizing agentic AI in production. See What Long-Running Agents Expose About Engineering Team Readiness for a practical analysis of the trust calibration and reviewability gaps that surface when teams move beyond short-context AI assistance.

The Fundamental Mismatch Between Scripted Suites and Goal-Directed Systems

A scripted test suite encodes a fixed sequence of inputs and expected outputs. It works well when the system's behavior space is enumerable and deterministic. An AI agent operating over a multi-step horizon does not satisfy either condition.

The agent's path to a goal is a variable, not a constant. Two agents can both resolve the same issue while taking entirely different routes through the codebase, invoking different tools, and producing different intermediate states. A pass/fail result against a fixed script tells you whether one specific path worked. It tells you almost nothing about whether the agent's general problem-solving behavior is sound.

This is why goal-directed test design starts from the intended outcome and works backward to define success criteria, rather than starting from a sequence of steps and checking conformance. The practical consequence for engineering leaders is that your definition of a test case must expand to include the space of acceptable trajectories, not just the one trajectory your team happened to anticipate.

What Meta's TestGen-LLM Results Actually Tell You

Meta's TestGen-LLM work, which applied LLM-generated tests to production Java code at scale, is frequently cited as evidence that automated test generation is ready for broad deployment. The yield numbers deserve more careful reading than they usually receive.

The system generated tests that were syntactically valid and compilable at a high rate. The rate at which those tests were genuinely useful, meaning they covered new behavior, caught real defects, or survived human review without modification, was substantially lower. This gap between generation volume and actionable yield is not a criticism of the approach. It is a structural property of any probabilistic generation process applied to a deterministic correctness problem.

The implication for engineering leaders is that raw generation throughput is the wrong metric. What matters is the yield after filtering: the proportion of generated tests that pass automated quality gates and then survive human review. Planning your pipeline around generation volume without modeling that yield curve will produce an infrastructure that looks productive and performs poorly.

Automated Filtering Gates: What They Can and Cannot Do

Automated filtering is the right first line of defense against low-quality generated tests. A well-designed gate can eliminate tests that do not compile, tests that pass trivially without exercising the target code path, tests that are semantically duplicated from existing coverage, and tests whose assertions are structurally malformed.

These are necessary eliminations. They are not sufficient ones. An automated gate can check syntactic and structural properties because those properties are formally definable. It cannot reliably detect a test that is syntactically correct, structurally sound, and semantically wrong in a way that reflects a misunderstanding of the system's intended behavior.

The practical architecture here is a two-stage pipeline: automated gates handle the filterable properties, and human review handles the semantic properties that require understanding of intent. Conflating these two stages, or assuming that a sufficiently sophisticated automated gate can absorb the second stage, is where quality pipelines tend to fail in production.

Where Human Judgment Remains Non-Negotiable

The question CTOs should be asking is not whether human review is necessary. It is which categories of judgment are genuinely irreplaceable and which are being retained out of habit rather than necessity.

Semantic Correctness of Success Criteria

When a generated test asserts that an agent's output is correct, someone with domain knowledge must verify that the assertion reflects the actual requirement. An agent that produces a plausible-looking result that satisfies a poorly specified assertion has not been tested. It has been given a passing grade on a badly written exam.

Behavioral Coverage of Edge Cases

Automated tools select test cases based on patterns in historical data or structural properties of the code. They are systematically underweighted toward the edge cases that are rare in training distributions but consequential in production. Human reviewers who understand the deployment context can identify the gaps that automated selection will miss.

Trajectory Evaluation for Multi-Step Agents

Recent work on evaluating software engineering agents demonstrates that pass/fail outcomes alone are insufficient for understanding agent capability. PTA-IRT, a framework proposed for efficient SWE-agent benchmarking, uses execution trajectories as additional signal beyond binary outcomes, incorporating explored context, attempted edits, and solving paths to produce more reliable performance estimates (Duan et al., arXiv 2026). The insight transfers directly to production QA: an agent that reaches the correct answer through a fragile or unintended path is not the same as one that reaches it through a sound one, and your quality gate needs to reflect that distinction.

Redefining 'Done' at the Governance Level

The organizational consequence of all of this is that "done" for an AI-shipping team is no longer a binary state that a CI pipeline can determine unilaterally. It is a judgment that requires specifying which properties are automatically verifiable, which require human sign-off, and at what release frequency those human reviews are sustainable given team capacity.

This is a governance question before it is a tooling question. Engineering leaders who attempt to solve it by adding more automated layers without first defining the human review boundary will find that the automated layers absorb the easy cases and silently pass the hard ones. The hard cases are the ones that matter.

The practical starting point is a written policy that classifies test categories by who or what is authorized to approve them. Automated gates can close the loop on structural and coverage properties. Behavioral correctness against specified requirements, and trajectory soundness for multi-step agents, require a named human reviewer with the domain knowledge to make that call. Until that policy exists in writing, your team's definition of "done" is implicit, inconsistent, and unlikely to hold under the pressure of a real release cycle.