We Built Multi-Repo Workspaces for AI Coding: A Practical Guide to Vibe Coding at Scale

Introduction

I’ve been coding with AI assistants for over two years now. At first, it was a novelty: ask GPT to write a Python script, copy-paste the result, tweak a few lines. But as my projects grew, I hit a wall. My codebase sprawled across five GitHub repositories—a backend in Go, a frontend in React, a shared library, a data pipeline, and a deployment config repo. Each time I asked an AI to fix a bug or add a feature, it only saw one repo at a time. The AI would hallucinate imports, misname functions from other repos, or suggest changes that broke cross-repo dependencies. It was like trying to build a house by looking at one brick at a time.

Then I heard about vibe coding—the idea that you can code at the speed of thought, letting AI handle the plumbing while you focus on the architecture. But vibe coding only works if the AI has context on your entire system. That’s why, earlier this year, my team and I built Multi-Repo Workspaces for AI coding. This feature lets you connect multiple repositories into a single workspace, so the AI can see, understand, and edit code across all of them at once. In this article, I’ll walk you through why we built it, how it works, and how you can use it to ship faster without losing your sanity.

What is a Multi-Repo Workspace?

A Multi-Repo Workspace is a virtual context that groups several Git repositories together. When you ask an AI coding assistant a question or request a change, it has access to the full file tree and code of all repos in the workspace. Think of it as a unified codebase view, even though your actual code lives in separate repos.

Before we built this, I had to manually paste snippets from multiple repos into the AI prompt. It was error-prone and slow. Now, I just link the repos and let the AI do the heavy lifting.

Why Multi-Repo Matters for AI Coding

Most real-world projects are multi-repo. Here are three concrete scenarios where a single-repo AI fails:

1. Microservices architecture — Each service has its own repo. Adding a new endpoint might require changes in the API gateway repo, the service repo, and the client SDK repo. Without multi-repo context, the AI can’t coordinate these changes.

2. Monorepo with shared libraries — Even if you use a monorepo tool like Nx or Turborepo, your shared packages often live in separate repos (e.g., on a private npm registry). The AI needs to see the library source to understand how to use it correctly.

3. Infrastructure as Code (IaC) — Your Terraform or Pulumi configs might be in a separate repo from your application code. When you deploy a new feature, you often need to update both the app and the infrastructure. Multi-Repo Workspaces let the AI see the whole picture.

I learned this the hard way. Last year, I spent three hours debugging a CI/CD pipeline failure because the AI suggested a change in my backend repo that required a new environment variable, but the deployment config repo hadn’t been updated. The AI didn’t even know the deployment repo existed. After that, I knew we had to build a multi-repo solution.

How We Built Multi-Repo Workspaces

We started with a simple premise: the AI should see your code the way you see it—as a whole system, not isolated islands. Here’s the technical approach we took:

Step 1: Repo Indexing

Each repository is cloned and indexed into a local vector database. We use a lightweight embedding model to capture the semantics of every file, but the key innovation is cross-repo dependency mapping. We parse import statements, package.json files, go.mod files, and Terraform modules to build a graph of dependencies across repos.

Step 2: Unified Prompt Context

When you ask a question, the system retrieves relevant files from all repos based on the query. The context window is optimized to include the most relevant cross-repo files—for example, if you ask “add a new API endpoint”, the system automatically includes the router file from the backend repo, the type definitions from the shared library repo, and the deployment template from the infra repo.

Step 3: Cross-Repo Edit Mode

When you request a change that spans multiple repos, the AI generates a plan that lists each repo’s changes. You can review and apply them one by one, or batch-commit with a single command. We added a diff viewer that shows changes across repos in a unified timeline, so you can see how everything fits together.

Practical Example: Adding a User Profile Feature

Let me walk you through a real use case. I have three repos:
- api-gateway (Go, handles routing and auth)
- user-service (Python, handles user data)
- web-frontend (React, client UI)

I want to add a “get user profile” endpoint that returns the user’s name and email. Here’s how I do it with Multi-Repo Workspaces:

1. Create a workspace and link the three repos.
2. Ask the AI: “Add a GET /profile endpoint that returns the authenticated user’s name and email. Update the frontend to show this data on the profile page.”
3. The AI responds with a plan:
4. In user-service: Add a new /profile route and handler.
5. In api-gateway: Add a proxy route to forward /profile to the user-service.
6. In web-frontend: Add a new Profile component and update the router.
7. I review the diffs for each repo. The AI correctly imports the auth middleware from the gateway repo, uses the correct service URL from the config, and follows the existing frontend patterns.
8. I apply the changes—three commits, one per repo. The feature works on the first try.

Without multi-repo context, I would have had to manually coordinate these changes, risking mismatched endpoints or broken imports.

Best Practices for Vibe Coding with Multi-Repo Workspaces

Based on my experience, here are some tips to get the most out of this approach:

1. Keep Repos Small and Focused

Multi-Repo Workspaces work best when each repo has a clear responsibility. If a repo contains both frontend and backend code, the AI might get confused. I follow the “one repo per microservice” rule.

2. Use Consistent Naming Conventions

If you name your API routes /api/v1/users in one repo and /users/v1 in another, the AI will struggle to connect them. I’ve found that using a shared OpenAPI spec (stored in a separate repo) helps the AI understand the contract across repos. ASI Biont supports connecting to OpenAPI specs via API—you can learn more at asibiont.com/courses.

3. Write Good READMEs

The AI reads README files to understand the project structure. I now write a short README in each repo that lists:
- The repo’s purpose
- Key entry points (e.g., main.go, index.ts)
- Dependencies on other repos

This dramatically improves the AI’s suggestions.

4. Review Cross-Repo Changes Carefully

Multi-Repo Workspaces are powerful, but they can also introduce subtle bugs. For example, the AI might change a shared type definition in one repo without updating the consumer in another. Always review the diff across all repos before committing.

Common Pitfalls and How to Avoid Them

I’ve made almost every mistake possible. Here are the top three:

Pitfall 1: Circular Dependencies

If repo A imports repo B, and repo B imports repo A, the AI can get confused and generate code that causes import cycles. Solution: Enforce a unidirectional dependency graph. I use a tool like depcruise to validate this.

Pitfall 2: Outdated Index

The AI’s context is based on the last indexed version of each repo. If you push changes to one repo but don’t re-index, the AI will work with stale code. Solution: Set up a webhook to re-index repos on every push. Most platforms (GitHub, GitLab) support this natively.

Pitfall 3: Prompt Ambiguity

If you say “add a new feature”, the AI doesn’t know which repo to start from. Solution: Always specify the primary repo for the change. For example: “In the user-service repo, add a new endpoint that returns user profile data. Then update the frontend repo to display it.”

The Future of Multi-Repo AI Coding

I believe that within the next year, multi-repo awareness will become a standard feature of all AI coding tools. The days of pasting snippets into a chat window are numbered. We’re moving toward a future where AI can understand your entire system—docs, tickets, logs, and code—and suggest changes that span the whole stack.

At ASI Biont, we’re already experimenting with multi-repo code reviews, where the AI flags conflicts between repos before you merge. We’re also working on “repo-aware” code generation that can create new microservices from scratch, including the CI/CD pipeline and deployment config, all in one shot.

Conclusion

Multi-Repo Workspaces are not a luxury—they’re a necessity for anyone using AI to code on real-world projects. They close the gap between the AI’s narrow view and the developer’s holistic understanding of the system. By giving the AI full context, you can ship features faster, reduce cross-repo bugs, and actually experience the flow state that vibe coding promises.

I built this feature because I needed it. If you’re struggling with AI that doesn’t understand your multi-repo setup, give it a try. Start by linking your three most important repos, ask a simple cross-repo question, and see how much smoother your workflow becomes. The era of single-repo AI coding is over. Welcome to the multi-repo future.