As agents take on implementation, testing, and review, engineering teams need evidence that can challenge the assumptions those activities share.
Consider a hypothetical authentication change. A team asks a coding agent to keep users signed in while they work. The agent implements a sliding session timeout and adds tests that confirm each request extends the session. Everything passes.
The missing requirement is that administrators must be able to revoke access immediately. The implementation checks revocation only at login. Its tests never ask what happens when access is withdrawn during an active session.
A second agent reviews the change against the same task description and approves it. The team now has an implementation, a test suite, and a review that all support the same mistake.
This is a practical problem for agentic engineering. When agents produce more of the evidence used to accept their own work, apparent agreement can become easier to generate than justified confidence. The question is where the delivery process gets evidence capable of proving them wrong.
Agreement can conceal a shared mistake
Tests written by the implementation agent can be valuable. They catch regressions, exercise edge cases, and shorten feedback cycles. A separate reviewing agent can also find defects the first agent missed. Neither arrangement, however, establishes that the underlying requirement is complete.
In the authentication example, the error enters before code generation. The task describes convenient sessions but omits revocation. If implementation, tests, and review all treat that description as authoritative, each stage can perform its assigned task competently while the delivered behavior remains unacceptable.
Independence therefore depends on the basis of judgment. A different agent using the same incomplete description may add less assurance than a simple test derived from an established security policy. Using a different model can introduce a useful perspective, but it cannot supply a requirement nobody gave it.
Suppose the organization has an approved policy requiring active sessions to lose access within a defined interval after revocation. An acceptance test derived from that policy would challenge the implementation directly. Its value comes from an authority outside the generated solution, and from a measurable requirement the solution must satisfy.
Productivity evidence supports caution about the measure
The research does not establish that agents inevitably create this failure. It does explain why code-generation speed is an inadequate measure of their engineering value.
METR’s July 2025 randomized study involved 16 experienced open-source developers completing 246 tasks in repositories they knew well. With the AI tools available in that setting, tasks took 19% longer, although developers believed the tools had helped them work faster. The result concerns that population, task mix, and generation of tools; it is not a general estimate of current AI productivity. [1]
METR’s February 2026 update is equally important. Researchers believed newer tools were likely providing greater benefits, but selection effects and difficulties measuring concurrent agent work made the later experiment an unreliable guide to the size of those benefits. It should not be presented as a clean reversal of the earlier finding. [2]
DORA’s 2025 research offers an organizational perspective. Higher AI adoption was associated with greater software delivery throughput and greater instability. Those associations do not establish causation, but they show why throughput needs to be assessed alongside the consequences of delivery. DORA also describes AI as amplifying existing organizational strengths and weaknesses. [3, 4]
For the authentication team, finishing implementation sooner would be useful. A fair assessment must also count the effort spent establishing correct behavior, reviewing the change, and repairing any failure after deployment. Faster production of a candidate solution is one contribution to that result.
Give the harness something authoritative to enforce
A harness gives an agent access to tools, execution environments, feedback, and controls. Its usefulness depends partly on what those controls actually test. A harness that repeatedly runs an incomplete test suite can accelerate the authentication mistake all the way to a green build.
For this change, the harness should run a test that starts a valid session, revokes the user’s access through the authoritative identity system, and attempts another protected action. The expected result and permitted delay should come from the organization’s policy. The test must exercise the relevant integration rather than a mock that merely repeats the implementation’s assumptions.
That check addresses one requirement. It does not establish that the authentication system is secure. The team still needs to decide which other behaviors matter, including expiry, privilege changes, and the response to an unavailable identity service. Each decision needs an owner and an explicit expectation.
There is a real cost here. Maintaining realistic integration environments takes effort. External dependencies can make checks slower or less reliable, and human approval can introduce queues. The response should be proportionate: a low-risk documentation edit does not need the assurance process used for access control. Teams should reserve expensive checks for failure modes whose consequences justify them.
Controls also need maintenance. If the security policy changes while the acceptance test remains untouched, an independently derived test can still enforce an obsolete rule. Record the policy owner and version alongside the test so that changes to the authority can trigger changes to the evidence.
More agents need a specific reason to exist
Multi-agent workflows can divide useful work. One agent might inspect the session implementation while another checks identity-provider documentation. Graph-based workflows can make dependencies, branches, and handoffs explicit; they can coordinate tools and deterministic steps as well as agents.
The architecture adds value only if the handoffs preserve the evidence needed for a decision. A summary saying that revocation is supported is inadequate if it omits whether support depends on token expiry, an online check, or a particular configuration. The implementing agent needs the applicable behavior and its source.
For the authentication change, ask the research agent to identify the provider’s documented revocation behavior and the reviewer to compare it with the approved policy. That gives each role a concrete question. It also lets a human inspect a disagreement instead of receiving three reassuring summaries.
Additional agents introduce latency, tool costs, and coordination work. They can also propagate an early error through multiple stages. Before adding one, identify the failure it is meant to detect and explain how its evidence differs from what the existing workflow already provides.
Test whether the process can reject a convincing answer
Before expanding the workflow, run a controlled exercise in an isolated environment. Introduce the plausible but incorrect authentication change: sessions continue to work after access has been revoked. Allow the normal implementation, testing, and review process to evaluate it.
Set the pass condition before the exercise. The workflow must reject the change before deployment, identify the violated revocation requirement, and link its decision to the approved policy and observed behavior. Record which control detected the defect, how much review effort was required, and whether an agent-generated test had previously accepted it.
If the change passes, the team has found a specific assurance gap. Adding another reviewing agent is one possible response, but so are correcting acceptance criteria, improving the integration test, or assigning ownership of the missing policy. Choose the response that addresses the demonstrated failure.
One successful exercise proves only that this particular defect was detected under these conditions. Repeat the approach for other consequential failure modes and track actual delivery outcomes, including lead time, review effort, rework, and production failures. A team can then judge whether its added controls improve reliability at an acceptable cost.
The next decision is concrete: before giving the workflow more autonomy, can it reject a plausible change that violates an independently defined requirement? If the answer is no, faster implementation will make that gap more urgent.
Sources and background
2. METR — We are Changing our Developer Productivity Experiment Design, February 24, 2026
3. DORA — State of AI-assisted Software Development 2025
4. DORA — Balancing AI tensions: Moving from AI adoption to effective SDLC use, March 10, 2026
The authentication scenario and proposed exercise are illustrative editorial analysis. The IBM Technology presentation Agentic Engineering: 5 Terms Every AI Developer Should Know inspired the original article; the argument and recommendations developed here are the author’s analysis.