Skip to content
Go back

Why a Monorepo Isn't Enough: CLI as the Missing Layer

Published: Dec 30, 2025
Updated: Dec 31, 2025
Vancouver, Canada

Kasava recently pitched a seductive vision: ‘Everything as Code.’

The premise is simple. Put the entire company—product, docs, strategy—into one Git repository. Give your AI agents full context. Ship changes instantly. They call the monorepo ‘the company.’

I appreciate the instinct. Centralizing context makes AI smarter. But a repository is just a place where files live. It is not how a company runs.

As one Hacker News commenter immediately noted:

‘Hardly managing the whole company. Financials? HR? Contracts?’

Exactly.

A monorepo is a container for artifacts. It is not an operating system. To run a company, you need verbs, not just folders.

Nouns vs. Verbs

The mistake lies in confusing storage with operation.

Kasava argues that ‘nearby context’ solves the problem. If the AI sees the invoice folder, it can manage finances. But context is not control.

A directory of Markdown files works for static content. It fails when you need:

  • Approvals
  • Permissioned access
  • Payment workflows
  • Audit trails
  • Policy enforcement

A repo can store the results of these actions. It cannot run them.

This validates the architecture I proposed in Run Your Company on the Command Line. You cannot manage a complex system by editing text files directly. You need an interface layer that enforces rules.

Storage is Git. Interface is CLI.

The CLI is the Operating System

LLMs are powerful, but they are not substitutes for business logic.

If you ask an agent to ‘update pricing,’ you don’t want it freestyle-editing pricing.md. You want it to trigger a deterministic process.

The agent shouldn’t be a writer; it should be an operator.

Instead of ‘Claude updated the marketing site,’ the operational reality should look like this:

company pricing set-limit --plan professional --repositories 50
company pricing apply --staged

The CLI handles the validation, the permissions, and the logic. It then updates the underlying file in the monorepo.

The file remains the source of truth. The CLI ensures the truth is valid.

The ‘Atomic’ Myth

Kasava claims the monorepo allows ‘one change, everywhere, instantly.’ This is the ‘atomic commit’ trap.

In real systems, atomic deployment is a lie. Frontends drift from backends. Mobile apps linger on old versions for weeks. Database migrations fail.

If you teach your organization that ‘one commit updates everything,’ you teach them the wrong reflex.

The goal isn’t atomic deployment. The goal is reversible state.

This is why I use Git. Not because it magically deploys the whole company in sync, but because it provides a safety net.

‘If an agent overwrites a file… you run git revert.’

That is the only ‘atomic’ property that matters: the ability to undo a mistake instantly.

The Synthesis

Kasava is right about context. AI loves a monorepo because it can see everything. Keep the monorepo as your library.

But do not confuse the library with the office.

Management requires a programmable interface that turns messy human operations into stable commands.

  1. Use the monorepo to store state (Context).
  2. Use the CLI to execute work (Verbs).

The repo is where the company lives. The CLI is how the company moves.

Content Attribution: 50% by Alpha, 50% by Claude
  • 50% by Alpha: Original draft and core concepts
  • 50% by Claude: Content editing and refinement
  • Note: Estimated 50% AI contribution based on 40% lexical similarity and 40% content condensation.