Bỏ qua điều hướng
EN
Tất cả bài viết

Khi Claude viết gần hết code: Anthropic bỏ git, tự xây hệ quản lý mã Scion

Số lần merge vào monorepo của Anthropic tăng từ 2.500 lên hơn 30.000 mỗi ngày vì agent viết code. Git không theo kịp, nên 7 kỹ sư cùng Claude xây Scion trong 5 tháng.

5 phút đọc

Mục lục

Bài viết trên blog kỹ thuật của Anthropic ngày 13/10/2026 mở đầu bằng một nhận định đáng suy ngẫm: ở Anthropic, viết code không còn là nút thắt. Claude giờ viết phần lớn code của công ty, và thứ chậm nhất trở thành hạ tầng dành cho lập trình viên vốn được thiết kế cho tốc độ của con người. Cụ thể, hệ quản lý mã nguồn đã thành "nút thắt phát triển lớn nhất". Giải pháp của họ là , một hệ thống quản lý phiên bản tự xây, thay hoàn toàn cho của công ty.

Redesigning source control at Anthropic
Ảnh: Anthropic

Git gặp giới hạn ở quy mô của agent

Các con số Anthropic công bố cho thấy quy mô vấn đề:

  • Số lần merge vào tăng từ khoảng 2.500/ngày (tháng 5/2026) lên hơn 30.000/ngày (tháng 9/2026), tức hơn 10 lần.
  • Lịch sử nhánh chính gần 100 GB, một bản working copy nén nặng hơn 25 GB.
  • checkout code khoảng 25 triệu lần mỗi ngày. Nếu kiểu thông thường, lưu lượng sẽ vượt 600 PB mỗi ngày.
  • Lúc cao điểm, họ phải vận hành vài trăm nội bộ, và việc vận hành ngày càng khó khi tốc độ merge tăng.

Git được thiết kế với giả định mỗi máy có một bản sao đầy đủ và làm việc offline. Giả định đó đúng với con người, nhưng thành gánh nặng khi hàng chục nghìn và cùng kéo code liên tục.

Scion được thiết kế thế nào

gồm client scn và ba tầng server: scion-daemon, scion-cache và scion-server. Các nguyên tắc chính:

  • Client luôn online: client không giữ toàn bộ lịch sử mà lấy dữ liệu từ server khi cần.
  • Server làm việc nặng: lịch sử, , , merge và đều chạy trên server. Client chỉ giữ một có giới hạn, dựng file ra đĩa và theo dõi thay đổi.
  • Quản lý mã như một : nhiều job như tự động hay chỉ cần gọi , không cần repo cục bộ.
  • Mở rộng theo chiều ngang: dữ liệu được đánh địa chỉ theo nội dung () và phân tán, không có nên không cần bảo trì repo.
  • Commit rẻ, không khoá: diễn ra trên server nên không có bước push. Ngoài nhánh main và nhánh release, Anthropic hạn chế dùng .
  • Working copy thưa hoặc ảo: có thể lấy hay ghi thay đổi qua mà không cần checkout.

Đơn vị dữ liệu là . Thay vì trỏ tới cả cây thư mục như của , mỗi chỉ liệt kê các file thay đổi so với parent đầu tiên, kèm con trỏ tới . Blame, lịch sử theo đường dẫn hay của đồ thị là "dữ liệu dẫn xuất", được tính đệ quy từ giá trị của parent. Nhờ đó đội có thể thêm loại dữ liệu mới mà không phải sửa client. Việc di chuyển một chỉ là một thao tác trên một dòng .

Kết quả

  • Hạ tầng nhỏ hơn 200 lần so với hệ thống cũ, tính theo và bộ nhớ.
  • Checkout nhanh hơn hai bậc độ lớn, chỉ còn tính bằng giây thay vì phút.
  • Tỉ lệ trúng trên 99% ở mỗi tầng, và tiết kiệm được 25% .
  • Pipeline nạp dữ liệu được Claude Mythos Preview viết lại, dùng ít bộ nhớ hơn 20 lần và chạy nhanh hơn 4 lần.

Một quyết định đáng chú ý là Anthropic không dùng với khoá toàn cục như thông lệ. Ở quy mô , hàng đợi kiểu đó không chạy nổi, nên họ đầu tư vào kiểm thử tự động sau merge và trước khi deploy. Thay đổi đồng thời vẫn có thể xung đột, nhưng theo Anthropic, Claude thường sửa xung đột nhanh hơn thời gian con người kịp nhận ra nó.

Bài học về cách làm việc với AI

  • Đội nhỏ vẫn đi nhanh: 7 người đã xây , công cụ review code Antique và khoảng nửa tá hệ thống liên quan, rồi hoàn tất chuyển đổi trong 5 tháng, giữa lúc lượng merge tăng 10 lần.
  • Vai trò kỹ sư thay đổi: kỹ sư vẫn quyết định thiết kế và thường phải nói "không" với Claude. Họ review ý định của thay đổi thay vì soát từng dòng code.
  • Chất lượng tốt lên: Claude giúp dựng mô phỏng kín (), , và tìm ra các tối ưu mà chuyên gia có thể mất nhiều ngày mới thấy.
  • Bảo mật từ đầu: phân quyền đến từng thư mục. Công cụ review có thể đặt luật duyệt theo ngữ nghĩa, ví dụ tách thay đổi chỉ sửa comment khỏi thay đổi đụng tới logic nhạy cảm.
  • Vận hành bằng : các instance Claude "siêu fan" chạy trên Claude Tag theo dõi từng thành phần như scion-daemon hay của Antique để phát hiện bất thường nhỏ.

Anthropic ghi nhận Piper của Google và của Meta là tiền thân. Đặc biệt, (phần server của ) đã đi đầu nhiều kỹ thuật mà dùng lại, nhất là mô hình dữ liệu .

Có dùng được không?

không mã nguồn mở và không nhằm thay cho số đông, vì nó gắn chặt với hệ thống review, tìm kiếm code và riêng của Anthropic. Thay vào đó, Anthropic chia sẻ cách nghĩ để cộng đồng áp dụng một phần vào , và cho biết muốn hợp tác với , cùng cộng đồng mã nguồn mở.

Vì sao đáng chú ý

Đây là một trong những mô tả cụ thể nhất về việc hạ tầng phần mềm phải thay đổi ra sao khi AI viết phần lớn code. Hầu hết chúng ta chưa phải lo 30.000 lượt merge mỗi ngày, nhưng xu hướng thì đã rõ. Merge queue khoá toàn cục, phải checkout toàn bộ repo hay review từng dòng code là những thói quen sinh ra cho tốc độ của con người. Khi làm việc song song với số lượng lớn, đó sẽ là những chỗ đầu tiên vỡ. Trong thực tế, ta có thể học theo bằng cách dùng , , kiểm thử sau merge và luật review dựa trên mức độ rủi ro của thay đổi.


Nguồn: Anthropic Engineering – Redesigning source control at Anthropic.

Bài này thế nào?

Bài viết có hữu ích với bạn?

Đánh giá giúp mình biết nên viết thêm về chủ đề nào.

Đang tải đánh giá…
Chọn số sao từ 1 đến 5

Bình luận

Đăng nhập để bình luận không cần nhập tên và được duyệt nhanh hơn.

0/2000
Đang tải bình luận…

Đọc tiếp

Bài số № 75PRO

Dự án cuối loạt nâng cao: eval agent đổi trả có người dùng giả, red team và pass^k — kèm chuẩn bị phỏng vấn Evals Engineer

Dự án tổng hợp: eval agent đổi trả có công cụ, người dùng giả, ba grader (outcome, không nói dối, an toàn trước prompt injection), pass^k, bootstrap theo cụm, chi phí trên mỗi task thành công và báo cáo phát hành; kèm câu hỏi phỏng vấn Evals Engineer thường gặp.

21 phút đọc

Bài số № 74PRO

Vận hành eval ở quy mô lớn: phân tầng suite, cache, chạy song song có thử lại, manifest phiên bản, task flaky và ngân sách

Khi bộ eval có hàng nghìn task chạy mỗi đêm, eval trở thành hạ tầng. Phân tầng smoke/regression/full, runner có cache, giới hạn đồng thời và thử lại, manifest phiên bản để tái lập, xử lý task flaky, ước lượng ngân sách và tổ chức quyền sở hữu eval.

22 phút đọc

Bài số № 73PRO

Eval online: lấy mẫu trace có trọng số, tín hiệu người dùng, A/B test đúng cách và biểu đồ kiểm soát chất lượng

Bộ eval offline tốt nhất vẫn chỉ là mẫu của quá khứ. Chạy judge trên traffic thật và hiệu chỉnh trọng số, tín hiệu ngầm của người dùng, A/B test có cỡ mẫu, kiểm tra SRM và tránh bẫy nhìn trộm, biểu đồ kiểm soát phát hiện chất lượng trôi.

23 phút đọc