Going Multi-Repo: Contracts are a way forward
I found myself doing some mundane greenfield database/api/ui buildout at work recently. In the process, I was navigating two distinct git repos, one I wholly controlled (but had existing customers on live existing routes), but the other was part of a monorepo owned and run by an entire frontend-dev cohort.
In the process of building out my little fiefdom in the FE domain, I realized the back and forth between two distinct claude code instances was not productive.
In the past, I've tried having one CC over both repos, having one CC dig through an adjacent folder/repo, and a few other hybrid mashups that aren't materially different in effect.
The outcome has been a chicken-and-egg problem. Deciding what happens in the backend vs the frontend before either of them are pinned down, in terms of requirements and actual testable code.
I'm a backend dev at heart, and look at the frontend as an un-centerable div that I don't want to wrestle with.
With this in mind, I've started a ui-contract.md doc in my PRs that I keep up to date with the work that I'm building around the database and APIs. That is to say, its something like, "backend does this, the frontend is expected to run this way.".
Then when I went to build the frontend against the functioning backend, it iterated a few times, and eventually I paired off a backend-contract.md, that said in effect, "the frontend does this, the backend is expected to handle these things.".
Its taken a few iterations, dirty branches, misunderstood prompt corrections that cascade, and other classic CC hi-jinx (lets not talk about git worktrees). But... it seems to be working, better than all the bad ways I've tried before.