Your Agent Finished the Code, But the Feature Never Got Wired In

An agent tells you the feature is done, the test suite passes, and the build succeeds, so you have every reason to think the feature you asked for was actually implemented.

Then a senior engineer reviews the change more closely, or QA tests the feature and finds that it does not work.

Now the team pays for that mistake twice.

A senior engineer has to figure out what went wrong, reproduce the failure, and give the agent enough context to debug it. After the agent fixes it, the change goes through review and QA again.

And if the team misses it, the customer discovers the failure instead.

The time AI saved writing the code comes back as rework, and much of that rework lands on the senior engineers whose time you were trying to save.

Completed code is not the same thing as an integrated feature

This is one reason I keep a failure ledger when I work with agents. I want repeated failure modes to turn into engineering controls instead of repeating as surprises.

I have logged several versions of this one.

In one case, an agent implemented a new analysis service, including persistence, but the server kept running the old code instead of using the new service.

In another, an agent built the code that creates and manages isolated workspaces for analysis, but never integrated it into the server.

Another change added the method needed to pass workspace information into the analysis process, but nothing that used the feature called it.

Different tasks. Same failure.

The code itself was not necessarily the problem. Leaving that code isolated from the rest of the codebase was.

No one asks an agent to build a feature expecting it to leave behind orphaned code that nothing calls, doing nothing for the customer.

The mistake was treating completed code as an integrated feature.

Passing tests can prove the wrong thing

Suppose an agent adds a new service and writes good unit tests for it.

Those tests may prove the service behaves correctly when it is called. They still do not prove that the server calls it.

The same problem appears when tests replace real dependencies with fakes. A handler can behave correctly against a fake service, and the service can behave correctly against a fake store, while the real product still connects those pieces incorrectly.

I have logged that failure too. Tests passed against a mock database store while the real persistence code contained a database column mismatch that would have made the actual write fail.

The test proved that the persistence method was called. It did not prove that the real database write worked.

That is not an argument against unit tests. It is a reminder to ask what each test actually proves.

A unit test can prove that a component works in isolation.

It cannot prove that the feature works in the product.

The expensive part is the second pass

The first implementation can be fast enough to look like a major productivity gain.

Then the supposedly finished feature comes back.

A senior engineer has to reload the context, reproduce the problem, and figure out what the agent missed. The agent gets another prompt and another implementation pass. The engineer reviews the fix. QA repeats its work. That can delay the release.

The organization did save coding time on the first pass.

It also created another cycle of engineering work that should not have existed.

That matters because senior engineering attention is usually one of the resources teams are trying to free up by adopting agents in the first place.

If agents write code faster but senior engineers spend the saved time debugging incomplete integrations, the bottleneck did not disappear. It moved downstream.

For agentic development, the useful question is not how many tasks an agent marks complete.

It is how much of the work reaches a human ready to accept.

Test the outcome the task was supposed to deliver

The fix is to add the right tests at the right level.

Unit tests still matter, but they only prove that a component works in isolation. When a feature depends on several pieces being wired together, you also need integration or end-to-end tests that exercise the real product flow and verify the required behavior.

If a user action is supposed to save data, an integration or end-to-end test should perform that action through the real application boundary and verify that the expected data was actually saved.

If an API endpoint is supposed to expose new behavior, an integration test should call the real endpoint and assert the response and any required downstream effects.

If a UI control is supposed to change something, an end-to-end test should use the control and verify that the expected state actually changed.

If a new service is supposed to participate in a request, an integration test should send the request through the real entry point and verify that the service is reached and produces the required result.

The exact mix of unit, integration, and end-to-end tests depends on the feature. What matters is that the test coverage reaches the integration boundary where the feature could be missing.

Do not stop at proving the new code works by itself. Add coverage that proves it has been correctly integrated into the product and the feature actually works.

That catches the service nobody registered, configuration nobody reads, a component nothing uses, the method nobody calls, and the database write that only worked against a fake.

All of those failures can survive a review focused on whether the new code looks correct.

They have a much harder time surviving integration and end-to-end tests that prove the feature has been correctly integrated and actually works.

The goal is not more manual review

I do not want senior engineers manually tracing every feature an agent writes. That would throw away too much of the value agents can provide.

The better goal is to make the workflow around the agent require stronger evidence before the work reaches them.

The task should explicitly define the behavior the feature must deliver, the integration points it has to cross, and the observable results that count as complete. For substantial work, put that in the PRD, ADR, Spec, and acceptance criteria rather than leaving it implicit in a prompt.

The agent should leave evidence for each acceptance criterion: which test exercises it, what boundary that test covers, and the result. That gives the reviewer something concrete to verify instead of another completion claim.

Automate everything that can be checked deterministically: build and type checks, static analysis, unit tests for isolated behavior, integration tests for real component boundaries, end-to-end tests for critical product flows, and any other deterministic acceptance check the feature allows.

Then the human reviewer can spend time on the judgment that actually requires a human.

That is the version of agentic development worth building toward.

The goal is not more generated code or more tasks marked complete.

It is more work that survives verification and reaches the team ready to accept.

Finished code is not the same thing as an integrated feature.

If the new feature is sitting in orphaned files that the rest of the product never uses, the task either failed to specify the integration clearly or the verification failed to enforce it. Either way, the agent did not actually complete the feature.

If your team is using agents and senior engineers are spending the time they were supposed to save debugging supposedly finished work, this is exactly the kind of failure a Consulting Audit is built to surface.

I audit the codebase and the way your team works with agents, identify where incomplete work is getting through your current checks, and show you where better specs, acceptance criteria, tests, and review can cut the rework.

If you want me to run that against your own setup, book a 30-minute call.