{"id":"2017950913437069744","url":"https://x.com/guidsen/status/2017950913437069744","text":"","author":{"name":"Guido Schmitz","username":"guidsen","avatarUrl":"https://pbs.twimg.com/profile_images/1599496314017964033/uVF3RI4r_200x200.jpg"},"createdAt":"Sun Feb 01 13:19:24 +0000 2026","engagement":{"replies":1,"retweets":1,"likes":3,"views":408},"article":{"title":"orchestrating AI coding agents across multiple repositories","previewText":"Most AI coding tools assume you have a monorepo. One codebase, one context, one agent that can see everything.\nThat's not reality for a lot of companies.\nReality is a 4-year-old iOS app in one repo,","coverImageUrl":"https://pbs.twimg.com/media/HAEzkSVXsAA7OqF.jpg","content":"Most AI coding tools assume you have a monorepo. One codebase, one context, one agent that can see everything.\n\nThat's not reality for a lot of companies.\n\nReality is a 4-year-old iOS app in one repo, an Android app in another, a web app somewhere else, and an API that ties them together. Each codebase is big. Each has its own patterns, its own history, its own mess. Merging them into a monorepo isn't happening.\n\nSo when you try to use AI coding tools, you hit a wall. You can get help in one codebase at a time. But the coordination — the actual hard part of shipping a feature across platforms — that's still on you.\n\nI think I've figured out an approach that solves this.\n\n## \nHow good teams actually work\n\nBefore jumping into the solution, it's worth looking at how this works when humans do it well.\n\nA PM or product owner creates a spec. They talk to design, figure out edge cases, define what the API needs to return. The spec becomes the contract.\n\nThen the iOS team, Android team, web team, and backend team all build against that spec. They might work in parallel. Backend often provides mock responses so mobile can start before the API is done. When everyone's finished, you integrate and test.\n\nThe key: everyone's building the same thing because they're all working from the same source of truth. The spec does the coordination.\n\nThe problem with AI coding tools isn't that they can't write code. It's that there's no AI equivalent of that coordinating PM. Each agent is isolated, context-limited, unaware of what needs to happen in the other repos.\n\n## \nThe AI PM architecture\n\nThe solution is to replicate that human workflow with AI.\n\nYou have one AI PM that owns the spec and coordinates everything. It doesn't write code itself. It does what a PM does: gathers requirements, creates specs, makes sure everyone's aligned, tracks progress.\n\nThen you have coding agents — one per codebase — that actually implement the feature. Each agent only sees its own repo, but they're all building from the same spec.\n\nThe AI PM spawns sub-agents scoped to each repo. The spec lives in files that all agents can read. The AI PM coordinates the workflow, collects questions, and tracks status.\n\n## From Figma to spec\n\nMost features start with a design. The AI PM needs to turn that into something coding agents can work with.\n\nScreenshots don't work well. Too much token overhead, too much ambiguity. The agent sees pixels but doesn't know intent. Is that spacing 8px or 12px? Is that a custom component or a standard button?\n\nInstead, the AI PM pulls from the Figma API and transforms the design into a structured format:\n\nThis maps directly to components. The iOS agent reads `type: button, variant: primary` and knows it's their `PrimaryButton`. Android knows it's `MaterialButton`. No interpretation needed.\n\nFor human verification, the AI PM also generates an ASCII wireframe:\n\nYou glance at the ASCII, confirm it matches the Figma, and move on. The coding agents consume the YAML.\n\n## \nThe interview phase\n\nDesigns don't capture everything. What happens when the item is out of stock? What if the user isn't logged in? What data does the API need to return?\n\nThe AI PM interviews you before any code gets written. It asks about edge cases, error states, UX flows, data requirements. The answers get baked into the spec.\n\nThis is the same thing a good PM does in a kickoff meeting. Get alignment upfront so you're not discovering requirements mid-implementation.\n\n## Validation before implementation\n\nHere's where it gets interesting.\n\nAfter the spec is ready, the AI PM doesn't just tell the coding agents to start building. First, each agent validates the spec against their codebase:\n\n- Can I find the right files to modify?\n\n- Do I understand the existing patterns?\n\n- Are there components I should reuse?\n\n- What's unclear or ambiguous?\n\nAll questions come back to the AI PM. You resolve them once, in the spec. Not four times, in four PRs.\n\nThis catches 80% of the issues that would otherwise block implementation halfway through.\n\n## \nParallel implementation\n\nOnce validation is done, everyone builds in parallel.\n\nThe backend agent builds the real API and generates an OpenAPI spec. Mobile and web agents build against mocks - they know the contract, they just don't have the real endpoints yet.\n\nWhen the backend agent signals that the API is ready, the other agents swap from mocks to real endpoints and run integration tests.\n\nNo one's blocked. No one's waiting. The mock-to-real handoff is coordinated by the AI PM.\n\n## The spec as contract\n\nThe core insight is that coding agents don't need to understand each other's code. They just need to implement the same spec correctly.\n\nThe spec is the contract. It defines what gets built, how it behaves, what the API returns. Each agent reads the spec, looks at their codebase, and figures out how to implement it in their context.\n\nThis is exactly how good human teams work. The AI PM just automates the coordination layer.\n\n## The file structure\n\nEach feature gets a spec folder:\n\nThe AI PM creates and updates these files. The coding agents read from them. Status is tracked so the AI PM knows who's done, who's blocked, and when to trigger the mock-to-real swap.\n\n## What this enables\n\nIf this works - and I'm building it out now to find out - it unlocks something significant.\n\nMulti-repo teams suddenly get the same AI leverage that monorepo startups have. You describe a feature, the AI PM specs it out, coding agents implement across all your platforms in parallel.\n\nThe coordination overhead that makes multi-repo development slow? Automated.\n\nThe context-switching between codebases? Handled by agents that each know their own repo deeply.\n\nThe \"we built different things\" problem? Eliminated by a shared spec.\n\nThat's a huge unlock for any team stuck with multiple repositories.\n\n## \nWhat I'm still figuring out\n\nI'm not claiming this is solved. There are open questions:\n\n- How well does Figma API → structured spec actually work in practice\n\n- What happens when agents disagree on feasibility?\n\n- How do you handle features that require coordinated refactoring?\n\n- What's the right granularity for specs — screen level, flow level, feature level?\n\nI'm going to build this out and see what breaks.\n\nIf you've tried something similar, or if you see holes in this approach, I'd love to hear from you."},"adhxContext":{"savedByCount":1,"publicTags":[],"previewUrl":"https://adhx.com/guidsen/status/2017950913437069744"}}