AI Team Cross-Review: An Integration Error Missed by Separate Tests
An error between separately tested components
During development of a product-listing screen, a separate AI reviewer reported a release blocker. The service that retrieved product categories and the web app that consumed them used different field names. Component and browser checks had passing results, but a check connecting the two programs failed to retrieve categories.
The reviewer found the problem by feeding one program’s output directly into the other. Dividing implementation among AI agents had left a gap between what each component’s tests covered.
In an earlier request about running an AI team, I had asked the agents to form their own views, review one another’s work, and then execute. In this task, the coordinating AI assigned the detailed work and review scope. The reviewer chose how to reproduce the integration error. This article examines what that review found and how it changed the release decision.
What the reviewer received
The coordinating AI assigned a reviewer separately from the implementation agents. The reviewer tested a separate copy and did not edit application code. Along with the implementers’ reports, it received the final source and the list of files intended for deployment.
Code was still changing during the work. A passing check on an intermediate version could not approve the final release. The coordinator therefore fixed the final review version, requested another review, and required a passing result before activation.
| Review assignment | What to check |
|---|---|
| Compare implementation requirements | The service’s response against the format expected by the web app |
| Run independent checks | Price entry, category selection, delayed responses, and other behavior |
| Compare final files | Whether the tested code matched the code intended for deployment |
| Report release readiness | Blockers, required corrections, and retest results |
The reviewer was not assigned to publish real products to external marketplaces or change operational data. The work specified both what the separate reviewer could inspect and what it could execute.
The same value under different field names
Category lookup connected a Python service to a JavaScript web app. It supported three operations: retrieving child categories, searching by name, and looking up a specific category.
The mismatch was in the response fields. The Python service returned the lookup value under selector for every operation. The web app expected a different name for each operation.
| Operation | Field returned by the service | Field expected by the web app |
|---|---|---|
| Child categories | selector |
parentId |
| Name search | selector |
query |
| Category detail | selector |
categoryId |
The reviewer also checked that no code between the programs translated those names. A response could contain the right value and still fail because the web app could not find the expected field.
The components’ tests used different synthetic response formats. Testing each component against its own prepared responses did not expose the mismatch with the other component.
The reviewer passed responses produced by the actual Python service code into the JavaScript response validator. All three operations failed. This did not call external marketplaces; isolated inputs were used to check whether the two programs worked together.
A review that changed the release decision
The reviewer reported the reproduction and placed the release on hold. The coordinating AI accepted the hold, stopped the first build from being activated, and assigned the correction to the service implementer.
The service was changed to return the field name required by each operation. The web app’s validation was not relaxed to accept the incorrect response.
After the correction, the reviewer checked nine combinations: three marketplaces and three operations. All passed. It also checked that the old incorrect format and incomplete responses were still rejected. Before reporting release readiness, it compared the deployment files with the tested files.
The documented result is specific: the first build containing this integration error was not activated in production. The review led to an implementation change and a retest.
A review request to reuse
The useful instruction here is more specific than “check it again.” It identifies what to test between separately built components and what decision to stop if a check fails.
The following request is adapted from the workflow for use in other projects. It is not a quotation from the original conversation.
Review the work separately from the implementation agents. Do not edit the code. Run checks on a copy of the agreed final source.
Feed the data that A actually produces into B. Do not rely only on synthetic responses prepared separately by each component’s tests. Compare the exchanged fields and error-handling requirements.
If you find a problem, report a release hold with a reproduction. Repeat the same check after the implementer corrects it, and verify that the deployment files match the tested files.
This does not establish that the AI team performed better overall. There was no comparison with a single agent doing the same task, and complaints about the screen layout followed. The integration check did not establish the quality of the entire interface.
In this task, however, a separate reviewer connected the two programs and found an error before release that the component checks had missed. The case shows how to give a reviewer a defined inspection scope and make its findings part of the release decision.
This article draws on the development session from the evening of September 16, 2026, and its review and deployment reports. The production server was not retested while writing it.