The repository boundary changes the work
I originally treated the choice between one repository and two as an organizational preference. Working with an AI coding assistant made the boundary operational.
A feature rarely stops at the frontend or backend. A new field can affect a schema, migration, API contract, validation rule, query, form, and E2E test.
When those parts live in separate workspaces, the assistant sees only half the change unless I repeatedly provide context. The missing half becomes an assumption.
Mandor Plate keeps the full path in one Turborepo. The goal is not to make the repository large. It is to make one feature traceable.
The path an assistant needs to see
For a typical dashboard feature, the useful dependency path is:
This graph matters more than the number of packages. The assistant needs to discover where a term is defined, where it is enforced, and which tests prove its behavior.
A shared contract gives the feature one vocabulary. If organizationId changes, repository search can reveal both producers and consumers without crossing a repository boundary.
One workspace is not enough
Putting code in one folder does not automatically create good context. A monorepo can still be difficult to navigate when ownership and dependency direction are unclear.
I keep a few rules explicit:
- The API owns domain behavior and persistence.
- The web app owns presentation and user workflow.
- Shared contracts contain data agreements, not domain services.
- Packages expose public entry points instead of deep imports.
- Root commands run checks across affected packages.
These rules reduce the number of plausible places where a change could belong. That helps humans first; AI benefits from the same clarity.
Vertical slices produce better feedback
I ask the assistant to complete one vertical slice rather than generate several disconnected layers.
The work starts with the contract, continues through the API and database, and ends with the UI and tests. Each step leaves evidence for the next one.
contract -> API rule -> migration -> web mutation -> UI state -> E2E
This sequence exposes incomplete work early. A UI that compiles but sends the wrong shape fails against the shared contract or API before it is treated as finished.
Root-level lint, typecheck, unit, and E2E commands give the assistant a common definition of done. Without executable feedback, more context only helps it make larger unverified changes.
The costs are real
A monorepo increases the amount of code available to every tool. Unfocused prompts can lead an assistant to touch unrelated packages simply because they are nearby.
Build configuration also becomes part of the product. Task dependencies, caching, environment variables, and package boundaries need maintenance.
The remedy is not to hide the repository again. I constrain work by feature path, name the owning package, and require the relevant checks before expanding scope.
Separate repositories remain reasonable when teams, release cycles, access controls, or runtime ownership are genuinely independent. AI convenience should not override those boundaries.
What I learned
The main advantage is not that AI can edit more files. It is that the assistant can inspect the evidence connecting those files before editing them.
A useful context boundary combines colocated code with clear ownership, shared terminology, and executable checks.
Without those constraints, a monorepo only gives the assistant a larger search space. With them, it becomes a map from a product change to a verified implementation.