How My Team Manages AI-Generated Code with AI-Generated Integration Tests

Code review#

I require my team to hold at least one scheduled code review session every week.

A quick digression. Software engineering is something you learn by doing. In college I memorized Spring Boot and Kubernetes deployment, but I didn’t understand why frameworks exist or why we need clusters. The main reason was simple: I hadn’t hit those problems myself.

Without seeing high traffic, you don’t understand clusters. If you’ve only written scripts, you don’t understand frameworks. Without maintaining a growing codebase, it’s hard to appreciate why abstraction, modularity, and clear boundaries matter.

Engineers starting out in the AI era still need this “outdated” knowledge. Code review does more than check quality. It helps the whole team understand each change and how the codebase is layered.

Code review couldn’t catch every bug before AI, and it certainly can’t now. So I’ve shifted its focus from finding bugs to teaching.

Unit tests#

I’ve mostly stopped investing in unit tests. When AI writes the business logic and then writes the unit tests from that same logic, the tests just confirm the code does what the code does.

To be fair, the same trap exists for integration tests. If AI reads buggy code and generates tests from it, everything passes and the bug is now “verified.” So the real rule isn’t unit vs integration. It’s that the expected behavior has to come from somewhere other than the implementation: the requirement, the product rule, real production requests. For multi-step business flows across services, integration tests are where I put most of that effort.

TDD, but with integration tests#

Most people think of TDD as development driven by unit tests. I’ve moved toward development driven by integration tests.

Inside a company, making everyone responsible for the code their AI produces is a nice management philosophy. But as a lead, I have to assume people won’t always take that responsibility. Under that assumption, testing becomes the safety net.

That’s why integration testing sits at the center of my team’s workflow. Our internal infrastructure lets us customize API call chains, control timing between calls, and mock downstream services, so we can simulate real production requests as closely as possible.

To be precise about the order: for the existing codebase, we generate integration tests after the fact. For new requirements, the expected flow comes from the requirement first, and the code has to pass it. Only the second part is really test-driven.

How AI understands the business#

I don’t want AI learning our business from hand-maintained wikis. They drift, and nobody notices until something breaks. I’d rather ground it in the code, the API contracts, and real runtime behavior.

The code is the most honest record of what the system does today. It’s not always what it should do, so the requirement stays in the loop. The challenge is getting AI to find a business flow inside a huge codebase and turn it into integration test steps.

Frontend code and data flows#

My answer is frontend code plus data flows.

Frontend code records the order of API calls, where each field’s data comes from, and how failures are handled. It’s the layer closest to real users.

Many shared backend services have no frontend at all. There, the data flow is the contract. API calls move data and push state machines forward. Follow the data and the state transitions, and you can rebuild the sequence of API calls.

The workflow#

First, we generate a full set of integration tests for the existing codebase. Then, for every new requirement, we generate integration tests from the requirement and the flows it touches, and the new code has to pass them. Test generation is now part of our requirements process.

It’s working. We’ve already caught real bugs.

In my view, integration testing is becoming one of the most important safeguards against production failures in the AI era.