Bridges

The frontend and the backend. The monolith and the microservice. The SDK and the API. The schema and the generated client. Some of the most error-prone work is often at the boundary between systems.

Coding agents are typically scoped to work in a single repository at once, but why not expand their permissions to work across multiple repositories when needed? That is where human teams lose time. Not because either side is impossible, but because the connection between contexts is easy to misunderstand.

The agent’s advantage is not just that it can edit two codebases. Its that it can see the assumptions that connects them. It can notice when a backend change has a frontend consequence, when a schema or contract isn't symmetrically enforced, and when documentation falls out of sync.

Architectures create boundaries for ownership, cohesion, and distribution. Don't let those boundaries apply to your agents too. Agents are just as useful straddling the edges between projects. As a developer, you want a coding agent to absorb as much context as possible from the code itself rather than your imperfect memory of how it works. Sometimes that means letting your agent visit both sides of the bridge.