Ship a cross-repository change with coding agents

An API change can look finished in two repositories and still fail the first time the frontend talks to the backend. Each pull request has tests. Each agent followed its brief. The briefs described different versions of the contract.

When a change crosses repositories, agree on the shared contract before you start the agents. Keep it small enough to paste into both tasks and specific enough to test, whether you run the tasks locally or as Hoplite cloud threads.

Write the contract before splitting the work

Suppose a backend returns a customer's name in name and a frontend needs separate given_name and family_name fields. This example needs more than a field rename. Existing clients still depend on name, some accounts have only one name, and older records won't contain the new fields.

A useful first version keeps name and adds optional fields. The frontend can use the new fields when present and fall back to name. Decide how empty strings differ from missing values. Include representative response examples in the brief, especially the old-record case.

Ask an agent to inspect the current contract and propose those examples before editing. Have a person review them. That is cheaper than fixing two implementations that disagree.

Give each repository its own accountable task

Hoplite projects can link multiple repositories, each with its own base branch. Under Settings → Project → Repository, use Add repository to attach another connected one.

That grouping does not let source control operate across repositories. Hoplite's source-control operations bind each request to the thread's configured repository. A practical workflow is one task and one pull request per repository, with the shared contract attached to each.

For the backend task, a brief could read:

Add optional given_name and family_name fields to the customer response. Preserve name and its existing behavior. Handle records without the new fields. Add contract tests for old and populated records. Open a draft PR and report any migration requirement before changing stored data.

The frontend task should name the same fields, describe fallback behavior, and point to the backend draft PR. Give both tasks the same version of the contract. If it changes, update both tasks before work continues.

Separate implementation order from deployment order

The agents can work in parallel once you agree on the contract, but you still need to deploy in order.

In this example, release the additive backend change first. Check that existing clients continue to work. Then release the frontend that uses the new fields. Removing name would be a later change, after every relevant consumer has migrated.

Write this sequence in the pull requests. Add a short rollback note. Rolling back the frontend should stay possible while the backend still provides both representations. A database change that destroys the old value breaks that rollback, so review it separately.

Do not let an agent merge a dependent change just because its own checks passed. Include the dependency's state in the acceptance criteria.

Test the combinations users can encounter

Repository-local tests cover only part of the release. Check the combinations that can exist during deployment:

• The old frontend with the updated backend.
• The updated frontend with the updated backend.
• The updated frontend receiving an older or incomplete response where fallback is required.

Use contract fixtures for fast feedback, then test a real integration environment with the intended commits. Record the backend and frontend commit IDs together. If the backend commit changes after testing, decide whether you need to test again.

Hoplite keeps a thread's conversation, changes, and pull requests together, and its PR rail shows linked checks and review comments. Cross-link the two PRs so a reviewer can follow the dependency without searching another person's chat history.

Close the change as a pair

Assign one person to verify the combined release. Each agent should summarize its changed behavior, commands run, failed checks, and remaining dependencies. The owner then checks the integration result and follows the release sequence.

For your first attempt, choose an additive API change with a straightforward fallback. Keep removals and destructive migrations out of that first run. Once the paired workflow works, you can reuse that review process for the next repository boundary.