Mọi thứ dưới dạng mã: Cách vận hành cả công ty bằng một monorepo duy nhất

 (kasava.dev)
3 điểm bởi GN⁺ 2026-01-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kasava quản lý toàn bộ quy trình phát triển sản phẩm trong một monorepo duy nhất, tích hợp toàn bộ mã nguồn, tài liệu, marketing và dữ liệu vận hành
  • Mọi thay đổi đều được phản ánh bằng một commit duy nhất, theo cấu trúc mà backend, frontend, website và tài liệu được cập nhật đồng thời
  • Công cụ AI tham chiếu trực tiếp mã nguồn, tài liệu và website để thực hiện kiểm tra tính nhất quán, tự động cập nhật tài liệu, rà soát nội dung, v.v.
  • Sử dụng CLAUDE.md, Selective CI/CD, cấu trúc dự án npm độc lập để giảm thiểu độ phức tạp của kho lưu trữ quy mô lớn
  • Cách tiếp cận này củng cố văn hóa phát triển AI-native, xóa bỏ ranh giới giữa sản phẩm, nội dung và vận hành, giúp triển khai và cộng tác nhanh hơn

Ý nghĩa của phát triển AI-native và monorepo

  • Kasava hợp nhất mọi thành phần nền tảng vào một kho Git duy nhất, không chỉ gồm mã nguồn mà còn cả tài liệu, marketing, email và tài liệu gọi vốn
    • Ví dụ: cấu trúc gồm hơn 5.470 tệp TypeScript như frontend/, backend/, website/, docs/, marketing/, external/
  • AI có thể truy cập đồng thời mã nguồn và tài liệu để thực hiện tự động hóa dựa trên ngữ cảnh
    • Việc sửa tài liệu, thay đổi giá trên website, kiểm tra bài blog đều có thể được xử lý trong một cuộc hội thoại duy nhất với AI
  • Mọi thay đổi đều được triển khai theo cùng một quy trình Git (git push)
    • Mã nguồn, nội dung, tài liệu và marketing đều đi qua cùng một quy trình review, CI/CD và kiểm toán
  • Cách làm này tăng tốc độ và tính nhất quán, đồng thời định hình văn hóa “quản lý mọi thứ dưới dạng mã”

Vì sao hợp nhất vào một kho lưu trữ duy nhất

  • Thay đổi nguyên tử xuyên biên giới (Atomic Changes)
    • Khi sửa backend API, định nghĩa kiểu ở frontend và tài liệu được cập nhật trong cùng một commit
    • Ví dụ: khi thêm tính năng tích hợp Asana, backend, frontend, tài liệu và website được gộp vào một PR duy nhất
  • Nguồn chân lý duy nhất (Single Source of Truth)
    • Chỉ với một billing-plans.json để định nghĩa giới hạn gói cước, mọi dịch vụ đều tham chiếu vào đó
    • AI tự động kiểm tra tính nhất quán giữa backend, frontend và website
  • Refactor xuyên dự án
    • Có thể tìm kiếm và chỉnh sửa toàn bộ mã nguồn, tài liệu, thậm chí cả ví dụ trong blog ngay trong IDE
  • Công cụ và pipeline dùng chung
    • Đơn giản hóa việc quản lý bằng CI/CD, phụ thuộc và môi trường tìm kiếm dùng chung

Cấu trúc kho lưu trữ và các thành phần

  • Ứng dụng cốt lõi:
    • frontend/ dựa trên Next.js 16 + React 19, backend/ sử dụng Cloudflare Workers + Hono + Mastra
    • Khi API thay đổi, có thể chia sẻ tính an toàn kiểu dữ liệu và utility kiểm thử
  • Marketing:
    • Gồm website/, marketing/blogs/, investor-deck/, email/
    • Blog, email và tài liệu gọi vốn đều được quản lý phiên bản như mã nguồn, có thể rollback bằng git revert
  • Tài liệu:
    • docs/ là tài liệu công khai dựa trên Mintlify, docs-internal/ là tài liệu kiến trúc nội bộ
    • Có thể tìm kiếm cùng với mã nguồn, duy trì thông tin luôn mới theo thời gian thực thay vì dùng wiki
  • Dịch vụ bên ngoài:
    • Bao gồm các dịch vụ triển khai bên ngoài như tiện ích mở rộng Chrome, Google Docs Add-on, GCP Functions
    • Nhờ chia sẻ hợp đồng API, thay đổi có thể được phản ánh đồng thời
  • Hạ tầng phát triển:
    • Gồm máy chủ mô phỏng và công cụ kiểm thử cho phát triển cục bộ như github-simulator/, infra-tester/, scripts/

Cách vận hành và văn hóa phát triển

  • Không dùng workspace
    • Giữ mỗi thư mục như một dự án npm độc lập để tránh xung đột phụ thuộc
  • Selective CI/CD
    • GitHub Actions được kích hoạt theo đường dẫn để chỉ chạy các bài kiểm thử liên quan
  • Quy tắc CLAUDE.md
    • Mỗi thư mục chính đều ghi lại stack kỹ thuật, lệnh và quyết định kiến trúc
    • Trợ lý AI đọc nội dung này để hiểu ngữ cảnh của dự án
  • Thiết lập công cụ nhất quán
    • Duy trì các cấu hình dùng chung như .prettierrc, .eslintrc, tsconfig.json

Thách thức và cách ứng phó

  • Kích thước kho lưu trữ: thời gian clone hiện tại khoảng 20 giây, chưa có vấn đề về hiệu năng Git
    • Tài sản dung lượng lớn dự kiến sẽ được tách sang R2/S3
  • Thời gian build: mỗi dự án build độc lập, tái build nhanh nhờ Turbopack, Wrangler, WXT
  • Ranh giới quyền hạn: đội ngũ nhỏ có thể truy cập toàn bộ, khi cần có thể áp dụng CODEOWNERS và bảo vệ nhánh
  • Chuyển đổi ngữ cảnh: việc chuyển qua lại giữa nhiều ngôn ngữ (TypeScript, Apps Script, MJML) được giảm tải nhờ CLAUDE.md và định dạng thống nhất

Kết luận

  • Monorepo của Kasava không chỉ là một xu hướng đơn thuần mà là công cụ tối đa hóa năng suất thông qua hợp nhất ngữ cảnh
  • Backend, frontend, tài liệu và marketing cùng vận hành trong một thay đổi duy nhất, đồng thời AI kiểm tra chúng theo thời gian thực
  • Kết quả là “monorepo không phải ràng buộc mà là đòn bẩy tăng tốc (force multiplier)”

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-01-01
Ý kiến Hacker News

  • Cái này không phải là quản lý toàn bộ công ty, mà chỉ giống như một sản phẩm duy nhất (monorepo)
    Không có tài chính, HR, hợp đồng, ảnh đội ngũ hay những thứ tương tự; chỉ là cấu trúc frontend + backend với một thư mục marketing được đưa vào theo cách hơi khác thường

    • Nếu xem bài được liên kết thì có thể thấy công ty này về thực chất là doanh nghiệp một người
      Vì vậy có thể nhét mọi thứ vào một repo, nhưng trong hoàn cảnh như vậy thì giá trị của những “insight” rút ra được cũng đáng để nghi ngờ
    • “AI! AI!”
    • Trong repo thậm chí cũng không có cả mã hạ tầng (IaC)
    • Tôi muốn thấy một ví dụ thực sự đưa mọi thứ vào GitHub repo
      Ví dụ bao gồm cả artifact được mã hóa, theo kiểu “chỉ CEO nắm giữ khóa mã hóa dưới dạng vật lý”
      Sẽ hay nếu GitHub thêm khái niệm private folder, nhưng đó là vấn đề ACL nên có lẽ là đòi hỏi hơi quá

  • Tôi ủng hộ triết lý monorepo và không có development branch
    Nhưng phát triển và phát hành vẫn phải được tách bạch
    Cần có khả năng cắt ra các bản phát hành ổn định rồi cherry-pick, và độ ổn định API giữa frontend và backend bắt buộc phải được duy trì

    • Cũng có người hỏi “không có development branch” nghĩa là gì
      Nếu phát triển trực tiếp trên nhánh main thì họ thắc mắc làm sao quản lý song song các công việc ở nhiều quy mô khác nhau
    • Cũng có người hỏi những trường hợp cụ thể nào cần đến cherry-pick
      Người này đang vận hành hơn 3 sản phẩm trong một monorepo, nhưng nói rằng triển khai theo đơn vị release ổn định vẫn không có vấn đề gì
    • Có người nói họ dùng feature flag để kiểm soát thời điểm triển khai
    • Người khác thì thích duy trì các nhánh cũ
      Họ không thích git squash và cho rằng cách làm forking cho lập trình viên môi trường tự do hơn

  • Câu “chỉ cần một thay đổi là mọi nơi được cập nhật cùng lúc” là một ảo tưởng nguy hiểm
    Với các hệ thống có DB hay API, lúc nào cũng phải tính đến khả năng tương thích ngược
    Trong tổ chức có nhiều team, sẽ có trường hợp một team không thể xác minh nâng cấp và khiến cả hệ thống bị kẹt lại
    Vì vậy rollout dần dần là điều bắt buộc

    • Hoàn toàn đồng ý. Ở công ty nhỏ (Kasava) thì ổn, nhưng với SaaS toàn cầu thì chỉ vài phút downtime cũng đã là chí mạng
      Bản thân monorepo không xấu, nhưng chuyện “một thay đổi là mọi thứ được deploy ngay lập tức” là bất khả thi
      Vì schema DB và code không thể thay đổi đồng thời
      Những bài như thế này trông giống blog do AI viết, và có lẽ cũng gần như không có khách hàng thực tế
    • Cũng có phản biện rằng nơi lưu code (repo) và cách triển khai phải được tách riêng
      Đừng nhầm vấn đề tổ chức với vấn đề kỹ thuật; nên điều phối bằng chính sách giữa các team và năng lực lãnh đạo
    • Có người nói họ dùng monorepo kết hợp với tự động sinh mã (openapi-generator) để phản ánh ngay các thay đổi API giữa các service
      Và họ cũng nói thêm rằng đây là cách tiếp cận chỉ phù hợp với team nhỏ
    • Với nhận định “điểm mạnh là gom AI context vào một chỗ”, cũng có ý kiến rằng chỉ cần clone nhiều repo thành workspace là được
    • Ngược lại, cũng có ý kiến cho rằng tình huống tệ hơn là mọi service đều giữ version riêng và không chịu cập nhật

  • Trước đây tôi ghét monorepo, nhưng sau khi dùng Claude Code thì đã đổi ý
    Khi frontend và backend ở cùng một repo, việc đồng bộ dễ hơn

    • Có người nói mở Claude từ thư mục cha vẫn hoạt động tốt, nhưng điểm hay là có thể thay đổi cả hai phía trong một commit duy nhất
    • Cũng có phản ứng rằng “nếu lý do dùng monorepo chỉ là để bớt vài cờ lệnh thì nghe hơi buồn cười”
    • Tôi cũng đã refactor sang monorepo vì quá khó nối nhiều công cụ LLM lại với nhau
    • Vì vấn đề hoisting của React Native nên họ tránh yarn workspace, nhưng việc đưa PRD hay tài liệu kế hoạch vào repo lại hữu ích để cung cấp ngữ cảnh cho AI
    • Thực ra Claude Code có thể xử lý nhiều thư mục cùng lúc, nên monorepo không hẳn là bắt buộc

  • Bài viết này tạo cảm giác như do AI viết
    Thật mệt mỏi khi ngày càng khó tìm được nội dung do con người viết

    • Nếu chạy qua GPTZero thì gần như toàn bộ có vẻ là nội dung do AI tạo ra
      Những câu như “This isn’t just for…” hay “The Challenges (And How We Handle Them)” là giọng văn AI rất điển hình
    • Ngược lại, cũng có ý kiến cho rằng “nghe người ta than phiền bài AI cũng phát chán rồi”
      Đại ý là dù không hoàn hảo thì chẳng phải vẫn tốt hơn bài do con người viết sao

  • Đoạn “bảo Claude cập nhật trang giá” nghe khá kỳ lạ
    Quản lý trang marketing trong cùng một repo mà lại giao cho LLM việc đáng ra chỉ cần đọc dữ liệu từ file config là xong thì khó mà thuyết phục

    • Có ý kiến chỉ ra rằng AI đang biến thành sự nghiện ngập hoặc phụ thuộc
    • Cũng có phản bác rằng “code review vẫn tồn tại”
      Có AI không có nghĩa là con người không còn kiểm tra nữa

  • Việc bỏ “frontend, backend, website” vào cùng một repo khá rối rắm
    Gộp theo đơn vị commit thì có vẻ hay, nhưng 3 repo riêng vẫn hoàn toàn quản lý được
    Muốn vận hành monorepo đúng cách thì chi phí duy trì là khá lớn

  • Bài viết có vẻ do AI viết, nhưng ý tưởng mở rộng IaC đến mức cực đoan thì bản thân nó lại khá thú vị
    Vì thế cảm giác khá phức tạp

    • Điều đáng ngạc nhiên là phần lớn bình luận dường như không nhận ra dấu hiệu do AI viết
      Có lẽ khi kiểu phong cách LLM này trở nên quen thuộc với công chúng hơn, những bài hiện nay sẽ bị thấy là quê mùa
    • Cũng có ý kiến rằng chỉ cần thay những cụm như “Why This Matters” thôi cũng đỡ hơn
    • Cũng có người nói rằng dùng AI nhưng không ghi rõ, lại đăng dưới tên con người thì tạo cảm giác thiếu trung thực về mặt trí tuệ

  • Nếu để website công ty trong cùng một repo thì sẽ dễ tìm tài liệu branding và giọng điệu thương hiệu hơn
    Vì vậy cũng thuận lợi cho việc tự động tạo slide cho khách hàng hoặc video demo
    Xa hơn nữa, việc đưa cả tài liệu, bug, issue vào cùng một chỗ cũng khá thú vị

  • Trước đây tại startup Pangea họ đã làm một cấu trúc tương tự
    Nhìn chung là tốt, nhưng không phải hoàn hảo

    • Khi cố quản lý mọi thứ bằng repo, việc thay đổi feature flag trở nên chậm, và việc giữ tính bất biến của branch cũng khó
    • Khi số service lên khoảng 20 thì GitLab CI trở nên chậm và phức tạp
    • Kiểm thử E2E vừa chậm vừa thiếu ổn định nên pipeline hay bị hỏng
      Dù vậy họ vẫn đạt được kết quả như chuyển sang ARM và giảm 70% chi phí compute
      Liên kết Pangea
    • Đáp lại, cũng có người hỏi liệu họ có dùng các công cụ monorepo như turbo, buck, Bazel hay không
      Vì nếu không có những công cụ đó thì sớm muộn cũng sẽ chạm trần về khả năng mở rộng của CI