Your Tests Pass. Your AI Agent's Code Is Still Wrong.

Your CI pipeline is green. Coverage is at 87%. The agent's PR passes every check. And the code it wrote is wrong.

Not syntactically wrong. Not crash-on-startup wrong. Wrong in the way that only surfaces three weeks later when a customer reports that their billing data is silently being written to the wrong account. The function signature was correct. The types checked out. The tests all exercised the happy path. But the agent didn't know that getAccount() in this service returns the service account, not the caller's account, because the original developer made that decision four years ago and documented it in a code comment the agent never read.

This is the gap that's opening up across engineering organizations adopting AI coding agents. The test suite, the thing teams rely on as the final quality gate, was built on an assumption that no longer holds: that the person writing the code shares the team's mental model of how the system works.

Tests encode what developers already understood

Think about how a test suite gets built. A developer writes a feature. They think about the edge cases they've seen before. They write tests that guard against the failure modes they anticipated: null inputs, off-by-one errors, race conditions they've been burned by, boundary values from the spec. Each test is a record of something a human already understood about the system.

Over time, more tests accumulate. Bug reports turn into regression tests. The suite grows into a comprehensive net that catches the kinds of mistakes humans make when working within the existing architecture. It's good at that. Really good.

But the suite has a blind spot. It doesn't test for deviations from the mental model itself. It doesn't test whether the code's author understood why the system is structured the way it is. When a human developer writes code, they carry that context implicitly. They know which functions are read-only by convention, which services own which data, which boundaries are trust boundaries. They don't need a test for "don't call the admin endpoint from the public API" because they'd never do that.

An AI agent doesn't carry any of that.

The four failure modes tests don't catch

After looking at how AI-generated code fails in production, a pattern emerges. The bugs cluster into categories that test suites are structurally unable to catch.

Logic drift. The code is locally correct but wrong for the context. A function calculates a discount correctly in isolation, but it's being called in a flow where the discount was already applied upstream. The test passes because it tests the function, not the flow. GitClear's 2025 AI Code Quality research, analyzing 211 million changed lines across repos owned by Google, Microsoft, and Meta, found that copy-pasted code blocks rose from 8.3% to 12.3% of all changes between 2021 and 2024, while refactoring dropped from 25% to under 10%. That's exactly the signature of logic drift: more code gets duplicated rather than reused, and less code gets restructured to fit the existing architecture.

Security assumption violations. An agent generates code that calls an internal service endpoint directly because the function signature is public and the types match. It doesn't know that endpoint sits behind an auth boundary that's enforced by the API gateway, not by the code itself. ProjectDiscovery's 2026 AI Coding Impact Report surveyed 200 cybersecurity practitioners and found that security teams are absorbing the impact of faster AI-driven engineering output. The top challenges they reported from AI-generated code: secrets exposure, business logic flaws, and supply chain risk. Two-thirds of those practitioners spend more than half their time manually validating findings rather than fixing actual vulnerabilities.

API misuse. This one's subtle. The agent calls a function with the right arguments and gets the right return type. But the function has semantic constraints that aren't expressed in the type system. Maybe it's a database query helper that was designed for read replicas, and the agent uses it in a write path. Maybe it's a caching function that assumes idempotent inputs, and the agent passes it something with side effects. The function works. The test passes. The system misbehaves under load.

Dead code that passes by omission. The agent adds a conditional branch. The test suite doesn't exercise that branch because no existing test was designed to trigger that specific condition. The new code passes because it's never executed during testing. Coverage tools might flag the line as uncovered, but if coverage isn't gating the build (and for most teams, it isn't at the branch level), the code merges. It sits there until someone hits it in production.

None of these are exotic edge cases. They're the natural result of code being written by something that treats a codebase as a token sequence rather than a system with design intent.

Higher coverage won't fix this

The instinctive response is to write more tests. Raise the coverage threshold. Require branch coverage. Add mutation testing.

Those are all good practices. They'll catch some of the dead-code-by-omission bugs. But they fundamentally can't address the core problem: coverage measures which lines execute during a test run, not whether the logic is correct or appropriate for the context.

You can have 100% line coverage on a function that calls a read-replica query helper in a write transaction. Every line executes. The test asserts the return value. It passes. The function is still wrong, because "wrong" here means "violates an architectural constraint that exists in the team's heads, not in the type system."

Coverage is a proxy metric. It tells you how much of the code was touched, not how much of the design was validated. When humans wrote all the code, the gap between those two things was small, because the humans writing the code also wrote the tests and shared the same understanding of the system. When an agent writes the code, that gap becomes a chasm.

The review gate is the missing layer

Code review has always been the quality layer that tests couldn't replace. A senior developer reviewing a PR doesn't just check whether the code compiles and the tests pass. They check whether the change makes sense in the context of the system. They ask: "Why is this calling the admin API from a public handler?" or "This query runs on the read replica, but you're using it after a write. Did you mean to hit the primary?"

That's the review gate. It evaluates the diff against the system's design intent, not just its type signatures. It catches the bugs that tests structurally can't catch, because those bugs are about context, not correctness.

The problem is scale. When AI agents are generating dozens of PRs per day across a codebase, human review becomes the bottleneck. You can't ask your senior engineers to review agent output at the same pace the agents produce it. The math doesn't work. But skipping review means accepting the very class of bugs that tests can't catch.

The answer is automating the review gate itself. Not replacing human review entirely, but putting an AI-powered review step into CI that reads the diff with full repository context and flags the issues a test suite can't. "This function is being called in a write path but it was only ever used in read operations." "This endpoint is internal-only but the new handler exposes it to unauthenticated callers." "This conditional duplicates logic that already exists in the billing module."

Tests plus review, not tests versus review

This isn't an argument against testing. Tests are essential. They catch regressions, enforce contracts, and validate behavior. They'll continue to be the first line of defense in any CI pipeline.

But if your pipeline's quality assurance ends at "tests pass and coverage is above threshold," you have a gap. That gap was always there, but it was small enough to manage when humans wrote all the code. AI agents are widening it, fast.

The analogy is straightforward. Code review was always the quality layer tests couldn't replace. For human-written code, human review scaled well enough. For agent-written code, you need review that scales the same way the code generation does. That means an automated review gate in CI, running on every PR diff, after tests pass, as an independent quality signal.

This is exactly how Tenki's code reviewer works. It runs on every PR diff in CI, after your tests have passed, as a separate quality layer. It reads the change in the context of the full repository, not just the diff in isolation, so it can flag the kinds of issues tests can't: a function used outside its intended scope, an auth boundary being crossed, duplicated logic that should be consolidated. It's not a replacement for your test suite. It's the layer that catches what your test suite was never built to find.

The CI pipeline for agent-era code

If you're running AI coding agents at any meaningful scale, here's the honest assessment of where your pipeline probably stands:

• Lint and type checks catch syntax and type errors. AI agents rarely fail here.
• Unit and integration tests catch regressions in anticipated failure modes. AI agents pass these most of the time.
• Coverage gates verify line or branch execution. They don't verify design intent.
• Context-aware review gate — this is the missing step. It reads the diff against the repository's full context and evaluates whether the change is appropriate, not just whether it compiles and passes.

Most teams are running steps one through three. Step four is what separates teams that catch agent-introduced defects before production from teams that find them in incident postmortems.

Your test suite isn't broken. It just wasn't built for this.