The more you let AI handle code, the more separate repositories become a "wall" — Why Shopify consolidated all its code into one monorepo, "World"

Part 1 of the series "Development Infrastructure Architecture in the AI-First Era" (all 3 parts)

It is no longer unusual for AI to write code. The practical debate has shifted to how much change AI can be entrusted with, and how much code and design information can be provided to AI for it to make correct decisions.

In May 2026, Shopify disclosed the operational results of its in-house AI coding agent, "River." Over the past 30 days, 59,918 sessions were executed, and River was a co-author on 3,536 pull requests. This accounts for approximately one in eight pull requests merged across Shopify.

This scale of utilization is not solely supported by models or prompts. In the spring of 2024, Shopify began building an infrastructure to integrate the code it ships into a monorepo called "World," and to reproduce local development, CI, and production environments using Nix.

This article will explain why multi-repository setups tend to pose challenges for AI agent utilization and then consider what we can learn from Shopify's "World." In conclusion, the key is not "putting everything into one repository," but enabling AI to consistently reference and verify code and knowledge within permitted boundaries.

Why Multi-Repository Setups Were Rational

Designing repositories to be separated by function or team offers clear advantages. It keeps the scope of responsibility small, allows for differentiated access rights, and enables each team to have its own release cycle. The ability to align system boundaries with organizational responsibilities is also a strength of multi-repository setups.

When different teams are responsible for the frontend, backend, inventory, and shipping, for example, being able to "only look at the scope necessary for one's own changes" reduces the cognitive load on humans. This rationality was also behind the widespread adoption of microservices and multi-repository setups.

Therefore, a multi-repository setup is not immediately an incorrect design simply because AI agents are used. Challenges tend to arise when entrusting AI with changes that span multiple boundaries.

Repository Boundaries Often Become Friction for AI Agents

When entrusting AI agents with full-stack changes, two main types of friction arise.

Inability to view necessary changes at once

For example, in Shopify development, storefronts, custom apps, and external integrations such as ERP/WMS might be managed in separate repositories. Even adding a single product attribute might require simultaneous changes to the storefront display, webhook data transformation, synchronization processes, and tests.

If AI can only access the storefront repository, changes on the screen might be correct, but the external integration side might remain with an outdated data structure. If the AI can view authorized repositories from the same workspace, it can search across affected areas. However, if necessary code is not included in the accessible scope, this deficiency cannot be solved by model performance alone.

Design intent and operational knowledge are separated from the code

AI needs more than just source code. It also requires design decisions, disaster recovery procedures, naming conventions, testing methods, and areas that should not be changed. If these are scattered across wikis, chats, and individual team members' memories, AI will make decisions based only on the code's form.

Choosing models with larger context windows alone will not solve this problem. If the necessary information is not available within the accessible scope, access is not permitted, or it is outdated, AI cannot compensate for it. The key is to place necessary knowledge close to the code and ensure it can be updated alongside changes.

Shopify Centralized Code and Knowledge into "World"

In the spring of 2024, Shopify explained that it decided on two things:

• Integrate all code shipped by Shopify into a single monorepo, "World."
• Build local development environments, CI, and production images with Nix to ensure reproducible execution environments.

This decision was based on the belief that "in the future, a larger proportion of code will be written by AI, and development infrastructure will serve as its foundation." This integration was not easy; according to Shopify, CI required an order of magnitude more processing power, and the merge queue, build cache, and testing infrastructure were all rebuilt.

This investment enabled "World" to achieve the following:

• Cross-cutting verification of changes ― Code, callers, tests, and documentation can be treated as a single unit of change.
• Reproducible execution environments ― Developers, CI, and production all use the same Nix-based environment, allowing AI to perform builds and tests under identical conditions.
• Knowledge updated alongside code ― Design intent, runbooks, development guidelines, AGENTS.md, skill definitions, etc., are all located within the same tree.
• Maintaining a single workspace for investigation paths ― You can trace from production logs to related code and the causative commit across the entire system.

What is noteworthy here is that it wasn't just about introducing a monorepo. Shopify built an integrated system that includes reproducible environments, fast CI, well-documented knowledge, and mechanisms for safely integrating changes. AI agents can function effectively precisely because all these elements are in place.

Shopify chose to absorb the overhead through investments in development infrastructure, rather than splitting the code again to alleviate the burden. The technical details of how "World" actually operates will be covered in Part 2.

Flagship's Assessment: Connecting Context While Upholding Inviolable Boundaries

As a single company, Shopify was able to integrate its code into one "World." As a company supporting multiple clients, we cannot adopt the same model directly.

Client-specific code has boundaries related to confidentiality, intellectual property, and access permissions. It is not advisable to pool client A's code and client B's code in the same place and allow the same AI unrestricted access. This is not a barrier to be removed by technology, but a boundary to be respected.

On the other hand, there is knowledge that can be reused across projects. For example, items to check first for Shopify migration, how to proceed with load testing, requirements often overlooked for Japan-specific member pages, and validation procedures for accessibility and multilingual support. If generalized without including specific confidential information, this can be cultivated as shared organizational knowledge.

We believe it is practical to design this concept in two layers:

• "In-Project World" confined within the contract ― For each project, we establish a single working scope comprising authorized repositories, design decisions, operational procedures, testing methods, and communication records. Workspaces, credentials, and AI sessions are separated per project to prevent mixing information from different projects.
• Flagship's cross-project knowledge layer ― We manage design patterns, checklists, prompts, and verification tools that are not client-specific as common assets. When standardizing in-project knowledge, confidential information is excluded, and after abstraction and review, it is distributed to necessary projects.

It is crucial not to conflate these two layers. Specific in-project code and information are not released externally. When moving to common knowledge, abstraction and review are performed. Providing AI with a broad context is not the same as granting unlimited access.

Here, it is necessary to consider three distinct stages. Placing multiple repositories in the same workspace allows AI to refer to them across boundaries. Integrating into a monorepo makes it easier to verify code, tests, and documentation as a single unit of change and CI. Furthermore, with a reproducible execution environment, AI itself can perform builds and tests, using the results for subsequent decisions.

If humans are instructing AI and reviewing results, one can start with the same workspace. In stages where AI autonomously performs changes, tests, and merges, the value of a monorepo and integrated verification infrastructure becomes significant.

At our company, we are also working to retain not only the results but also the decision-making process in the repository for column writing and daily technical discussions. There is much to learn from "World" in terms of placing knowledge close to code and updating it in a form that both humans and AI can reference.

Monorepo Is Not an End in Itself; Consider It with Operational Infrastructure

Monorepos are not a panacea. While integration can make dependencies more visible, it can also exacerbate challenges such as CI load, build times, access control design, code ownership, and merge conflicts.

Shopify chose to invest in infrastructure while maintaining integration to address these challenges. Cookpad, on the other hand, in improving its massive Rails application, focused on clarifying responsibilities and migrating to microservices while promoting measurement and visualization. Neither approach is universally correct; the appropriate boundaries vary depending on the system's change characteristics, organizational structure, and operational infrastructure.

When considering a monorepo, at least the following points should be confirmed:

• How frequently do changes spanning multiple areas occur?
• Can the integrated CI, build, and test processes be continuously improved?
• Can code ownership and access permissions be clearly maintained?
• Can design documents and operational procedures be updated alongside code changes?
• Is there a system in place for humans to review and verify changes executed by AI?

Most organizations do not need to migrate to a monorepo from the outset. First, identify changes that span multiple repositories, consolidate authorized code into project-specific workspaces, and document dependencies and testing procedures. If, even then, performing changes and verification separately remains a bottleneck, then it is practical to consider monorepo adoption and investment in CI infrastructure.

Summary

When entrusting AI agents with cross-cutting development, not only model performance but also the scope and freshness of code and knowledge accessible to the AI, and the verification environment, are crucial. Shopify's "World" can be seen as an example of an integrated approach encompassing a monorepo, reproducible environments, CI, and documented knowledge.

For our company, which supports multiple clients, the boundaries of contracts and confidentiality are fundamental prerequisites that must be upheld. Within that framework, we connect the necessary context within each project, and outside of projects, we cultivate generalized knowledge as shared assets. This two-tiered design is, we believe, the starting point for considering development infrastructure in the AI-first era.

Part 2 will delve into the mechanisms by which Shopify actually operates its monorepo, focusing on Tectonix, which manages the massive "World" locally with ease, and Nix, which reproduces the same execution environment everywhere.

References and Sources

• Under the River (Shopify Engineering, 2026)
• Cookpad's Microservices Strategy for its Core System ~ The 1.5-year Journey of the Odaiba Project ~ (Cookpad Developer Blog)
• Let's do something about a large Rails application. Let's start with measurement and visualization. (Cookpad Developer Blog)

The information in this article is current as of July 2026. The figures regarding Shopify's internal tools are based on performance data for the most recent 30 days published by Shopify.