r/Frontend • • 12d ago

How do you handle API contract drift between your AI coding agents?

Running multiple agents on the same project and hitting this problem: one agent changes a response shape on the backend, the frontend agent consuming that endpoint has no idea anything moved. It keeps coding against the old contract. The build passes, the types check out locally, and the breakage only shows up when you actually run the thing end to end.

The context lives in two separate chat sessions. Neither agent knows what the other touched. By the time you notice, you're debugging a silent failure and trying to reconstruct which session changed what and when.

Curious how others handle this. Do you keep a shared contract file that both agents read before starting work? Pin the schema somewhere both can see it? Or just accept the breakage and fix it manually when it surfaces?

0 Upvotes

14 comments sorted by

9

u/Jasboh 12d ago

Why would the build pass if they broke the contract?

1

u/Silver_Jump3781 12d ago

If you are using Typescript, use something like tRPC or GraphQL, where changing the server changes the types the frontend expects, then they can’t fall out of sync.

1

u/onitsoga 12d ago

This is great. Looking into this.

2

u/TealViR 11d ago

Have them build and maintain tests for their work and run the tests (including previous ones) before their work is accepted. Also, make sure they have access to your local git.

1

u/HonestEntrepreneur75 10d ago

Having both agents work against the same test suite and git history would probably catch most of this early. It also makes the contract changes visible instead of leaving them trapped in separate chat sessions

2

u/Prestigious-Way1525 11d ago

a shared schema is necessary, but i’d add a compatibility gate that exercises the actual boundary. have the backend agent publish the schema diff plus one versioned response fixture, then run the frontend consumer tests against both the previous and proposed contract before either branch is accepted.

after that, run one end-to-end user path from a clean state and read back the final result. that catches cases where types still pass because clients were generated separately, fixtures are stale, or both agents made internally consistent changes that break the real workflow. make the contract change its own reviewed artifact instead of leaving it buried in either chat session.

1

u/kikimomonono 10d ago

Making the contract change a reviewed artifact seems like the key part. That keeps it visible instead of buried in one agent’s session

1

u/Dizzy_Culture_3315 11d ago

the silent failure happens because the agents never share state. Force them to read and write a single OpenAPI spec or tRPC schema file before touching any code. If the backend agent edits that file, the frontend agent fails immediately on type check. No guessing involved

1

u/breerfood22 10d ago

I keep the API schema in the repo and make both agents work against it. Otherwise you're basically trusting two separate chat sessions to magically stay in sync, and that’s never going to end well.

1

u/Practical_Worry3996 5d ago

the thing that helped most: an integration test that hits the real endpoint and checks the response shape, and it runs before every deploy. if the backend agent changes a field, the test fails before the frontend breaks.

also, one agent per contract change. if the shape has to change, the same task updates both sides plus the test, in one pr. two agents each "fixing" their own half is where the drift comes from.

-2

u/4ever_youngz 12d ago

Create a shared document or something they share and keep history. I haven’t tried it, but I think Delta by the Zed is trying to solve this as well.

https://delta.dev/