Is Turborepo Is the New Collaboration Surface?

We've all done the monolith. It shipped fast - until it didn’t. Tight coupling, scary deploys, one blast radius. Team pace slowed. Collaboration suffered.

Then we swung to microservices. Now it’s N repos, N pipelines, version drift, glue code, and a calendar full of “deploy alignment meetings.” The blast radius shrank; the coordination cost exploded. Team pace also slowed. Collaboration also suffered.

A Turborepo is maybe best of both: one repo, many boundaries. Shared code, types, and rails, faster buidlers, etc. Or not. It's up to you.

But in 2025 it's not just about that anymore. Soon the primary contributors to the codebase won't be human. They'll be agents.

And turborepo brings together what agents are starved for: Context - the atomic unit of agent collaboration.

It turns the repo into the collaboration surface—for humans and agents.

Here’s how I use it: start by building context before code, raise high guardrails, ship with preview‑driven development, and keep docs as the agent contract—inside the repo.

Start With Agents Before You Code

Agents begin in product, not in code.

I'm kicking off every feature with research agents, not drawing/typing/searching tools. I'm looking for the best-in-class implementation research report. With that I'll do the same for a repo-aware refinement pass. The goal is clarity on options and trade-offs and a phased intent you’d be proud to bring into a design/eng room.

• Use ChatGPT Deep Research to find best-in-class implementations, open-source primitives, and hidden “gotchas.”
• Produce a concise product doc suitable for a design+engineering discussion.
• Re-run Deep Research with the GitHub connector on so it understands your folders, types, and envs.
• Lock the intent into Skateboard → ATV → Cadillac so phase 1 is shippable even if phase 3 never happens.
• Keep this stage code-free; we’re shaping work, not writing it.

The output is a "PRD" that either can go to something like v0.app or a code agent for further refinement.

Here's an example of a real research chat

Guardrails Make Agents Effective (High Walls, Not “No Tests”)

Code agents/LLMs forget all context as they rabbit-hole. High walled guardrails make them rediscover affected areas instantly. The "higher the walls" the less likely they are to get lost.

I think it's extremely important to have a single source of truth for types, so the compiler turns that into a map that explodes when the agent messes up. Because we're all ultimately working with the web, then to achieve that our only option is typescript. So we need a single source of truth from DB to UI.

• Use one type truth. I'm using Drizzle schema → drizzle-zod → Zod Select/Insert/Update Schemas → tRPC → UI Library.
• Ban re-declared types across client/server; changes in DB must light up dependent UI/API.
• Encode preferences as ESLint rules: beyond "no any", "no eslint-disable", "no ts-ignore", eagerly encode all learnings as ESlint rules so the agents see they mess up often. Eg, I have a rule that bans shadow- on elements without bg- in react native.
• Run 4× variants in parallel; let types/lint fail the weak ones fast.
• Treat intelligence as disposable; integration discipline is the moat.

The idea is to let the agent know when it's veering off course. Allowing yourself to easy discard the ones that messed up to much and "choose your own adventure" to success.

You can get a sense of from my agent instructions -- though it's not a perfect example.

Preview-Driven Development

A lot of people have discovered the CLI agents seem to perform better than the IDE agents. But I think they have a fatal flaw: they painfully process tokens in serial.

It's hard (for a multitude of reasons) to run them in parallel. Conductor.build is the only one I've seen attempting this well. You need to bootup a sandboxed environment that's isolated and the best/fastest/most integrated version of that I've seen are microVMs in the cloud. Codex web and Vercel's preview builds connected via github is the ultmate way to scale this out infinitely.

Every viable branch ships to a Preview URL with its own logs. Gate previews on correctness, then click-test behavior and pick a winner quickly.

• Branch per variant; each PR auto-deploys a Preview with isolated logs/env.
• Gate previews on type/lint/format so all candidates are baseline-correct.
• Use a second model as code-reviewer to surface perf/security/readability issues.
• Click-test flows, inputs, console cleanliness, perf, and logs across previews.
• Merge the best behavior, not the prettiest diff; close the rest.
• Let code review agents pipe code feedback back to the agents. Burn more GPUs

Docs = The Agent Contract (Lives in the Repo)

All context matters and most of it is split in tools because we have weird habits build for a different era. With disposible intelligence, we cannot isolate context we need to expose it.

We need the agent to find relevant context and hiding it in Jira, or Figma, or Linear, or Google Docs, is prioritizing Human-first dev not ai-first dev.

All of those tools are just well organized markdown files with a dashboard. Throw the dashboard away and keep the markdown. Get as much content as you can in the markdown file it so a "junior dev on a plane with no Wi-Fi" has what they need to ship phase 1. Keep it beside the code and keep it current.

• Promote the refined research into /project-plan/feature-name.md using a repo template.
• I get the code agent to write this for me from the research doc by asking explicitly: "To write an implementation doc that will be executed offline by a junior dev—be exhaustive.”
• Run dry-plan passes (no writes) to surface questions and document options/decisions.
• Use GitHub-flavored checklists split into Skateboard/ATV/Cadillac with file/symbol links.
• Drop reference artifacts into __mocks__/feature-name/ (e.g., v0 output) and say “match look/flows; integrate with our types.”
• Keep OpenAPI specs, env samples, UX notes in the repo; agent checks items off as it lands changes.
• Update the doc first, then code—always.

1<!-- <TEMPLATE>
2# Major task
3
4{{description}}
5
6## User Narrative
7
8{{user_narrative -- describe how a user would use this feature. Assume user is tired and want to get things done quickly.}}
9
10## Implementation Details
11
12{{details}}
13
14### Phases Breakdown
15
161. {{phase 1 -  the "Skateboard version"}}
17
18- {{break down of important details}}
19- ...
20
212. {{phase 2 -  the "ATV version"}}
22
23- {{break down of important details}}
24- ...
25
263. {{phase 3 -  the "Cadillac version"}}
27
28- {{break down of important details}}
29- ...
30
31## Task Breakdown
32
33### Phase 1 - Skateboard
34
35- [ ] {{task1}}
36  - [ ] {{task1.1}}
37  - [ ] {{task1.2}}
38- [ ] {{task2}}
39  - ...
40- ...
41
42### Phase 2 - ATV
43
44- ...
45
46### Phase 3 - Cadillac
47
48- ...
49
50</TEMPLATE> -->
51

The Monorepo Is Your Collaboration Surface (Your New “App”)

Stop scattering context across SaaS silos. Collapse planning, mocks, docs, and code into the monorepo so humans and agents operate in one coherent world. The less surface-switching, the faster the compounding.

• Treat Figma as v0 code, Linear/Jira as markdown, your wiki as /docs, and your site as an app in apps/.
• Use packages/validators for Zod from the DB; packages/ui with .web/.native twins; packages/api for tRPC routers.
• Make the repo the answer to “Where is it?”—planning, prompts, runbooks, docs, and code all here.
• Optimize for agent legibility: clear folders, consistent naming, strict rules at the root.
• Culture shift: your monorepo isn’t just code—it’s the shared workspace where people and models collaborate.

Parting Thoughts

Agents aren’t magical coworkers; they’re only as good as the repo you hand them. Put research, prompts, types, tests, and docs in one place and let the monorepo be the app. Ship Skateboard → ATV → Cadillac, keep previews fanned out, and merge the best behavior—not the prettiest diff. If a junior on airplane Wi‑Fi can land phase 1 from your repo, your agents will too. Intelligence gets cheaper every quarter; integration is what compounds.

Make the repo legible, and everything else accelerates.