When AI Writes Both the API Integration and the Tests, What Are We Actually Verifying?

I've been thinking about a problem with coding agents that I keep coming back to.

An agent can write an API integration and then write tests for that integration. Everything passes, but the tests may just be confirming the same assumptions the agent made while writing the code.

For example, the agent thinks an endpoint returns:

{
  "total": 100
}

It writes the integration expecting total, and then writes a test that expects total.

The test passes.

But if the real API contract says something different, the whole thing can still be wrong.

I'm experimenting with a small open-source project called Kaktoos that puts an independent verification step between the agent and the API:

AI agent → integration → Kaktoos → OpenAPI + real API → result

The idea is that the verification layer shouldn't share the agent's assumptions.

It currently supports multi-step API workflows, OpenAPI response validation, MCP, and GitHub Actions.

I'm still trying to figure out how far this idea should go. One interesting question that came up is whether contract validation is enough, or whether verification should also check the actual outcome of an operation — for example, creating a resource and then reading it back to confirm the state actually changed.

I'm curious how other people building with coding agents are handling this today.

Do you rely mostly on the agent's generated tests, existing integration tests, mocked APIs, live API tests, or some combination?

GitHub: KaktoosLabs/kaktoos

Comments

[Kent Bodrov]

I would separate three checks: whether the request matches the contract, whether the provider actually reached the expected state, and whether that state solves the user's problem. OpenAPI validation covers only the first. A read-after-write check helps with the second.

The third still needs an acceptance oracle defined outside the generated implementation-and-test pair. Otherwise both can preserve the same mistaken interpretation.

[richocolate]

Thanks, this is a really interesting way to think about it. I can see how having an acceptance oracle outside the implementation could make a big difference.

I’m going to explore adding these checks to Kaktoos, especially the state and outcome verification. Hopefully you’ll get a chance to try it out later and find it useful!