Everything as code: How we manage our company in one monorepo

Monorepo appeal, especially with AI tools

• Several commenters say LLM coding tools (Claude Code, etc.) made monorepos newly attractive: one place to index, single prompt with full backend/frontend/docs/PRDs/marketing context, single PR for full‑stack changes.
• Others note these tools can already work over multiple directories or a shared workspace, so choosing a monorepo purely for tooling is seen as a workaround rather than a necessity.
• Human benefits cited: easier cross‑repo refactors, one review per feature, less cognitive load than coordinating multiple PRs across repos.

Deployment, “atomic” changes, and compatibility

• Strong pushback on the blog’s implication of “one change, everywhere, instantly”:
  • Distributed systems deployments are never truly atomic: staggered server updates, old mobile clients, cached frontends, slow DB migrations, rollbacks, etc.
  • Backward/forward‑compatible APIs, multi‑version support, feature flags, and gradual rollouts are described as mandatory at any real scale.
• Some argue brief breakage can be acceptable for small teams with fast deploys; others call that assumption dangerous once uptime and old clients matter.
• Monorepo layout is repeatedly distinguished from deployment strategy: you can keep code in one repo and still deploy independently/versioned services.

Monorepo vs multirepo and scaling issues

• Pro‑monorepo camp: easier multi‑service feature work, simpler dependency changes, shared tools and types (often via OpenAPI/Protobuf).
• Pro‑multirepo camp: monorepos “don’t compose or scale,” encourage cross‑boundary coupling, and create org‑wide lockstep pressures. They prefer versioned APIs and libraries across repos, sometimes via binaries.
• Real‑world pain reports: huge CI configs, long pipelines, flakey e2e tests, and complex rollout logic once dozens of services live in one repo.

Git workflow, squashing, and feature flags

• Long subthread on commit strategy:
  • Some want “no dev branches,” everything off main with release branches plus cherry‑picks.
  • Others insist on PR branches, atomic commits, and rebasing; squashing is debated as “clean history” vs “information loss.”
• Feature flags are widely used with monorepos for deployment control, but several warn they easily create unreadable, long‑lived conditional “spaghetti” without strong discipline.

“Everything as code” scope and non‑devs

• Multiple readers note the setup is really “product + marketing as code,” not full company management (no visible HR, finance, contracts, infra as code).
• Some like the vision of putting more organizational processes in versioned text; others worry static‑site workflows are painful for non‑technical staff used to CMS tools.

AI authorship and trust

• Many comments claim the post itself reads like obvious LLM output and criticize undisclosed AI authorship as misleading.
• Others argue value matters more than origin, but acknowledge current AI prose has recognizable stylistic “tells” that erode reader confidence.

Security and access

• Question raised: does a monorepo mean every dev can download “everything”?
• Responses: at startups this is common and seen as normal; large companies may still use monorepos but restrict access via corp devices, remote dev environments, or Perforce‑style ACLs.