Anthropic Bỏ Git, Dựng Scion Để Gánh 30.000 Lần Merge Mỗi Ngày. Nhưng Câu Hỏi Hay Nhất Thì Bài Viết Của Họ Lại Không Trả Lời.

Tháng 5/2026, kỹ sư Anthropic merge khoảng 2.500 thay đổi mỗi ngày vào repo chính. Đến tháng 9, con số đó là 30.000 — tăng 12 lần chỉ trong bốn tháng. Git, chạy theo cách thông thường, không được thiết kế cho mức đó. Thế là một đội bảy người dành năm tháng xây lại từ đầu, đặt tên là Scion, và ngày 13/10 Anthropic công bố một bài viết dài giải thích vì sao và làm như thế nào. Số liệu throughput thì ấn tượng thật. Nhưng phần họ không nói tới — chuyện gì xảy ra khi một merge bị sai — mới là phần mình nghĩ một tech lead nên lo.

Vấn đề không phải Git chậm. Vấn đề là giả định gốc của Git.

Anthropic nói thẳng nguyên nhân gốc: “Git giả định client làm việc offline và cần một bản sao đầy đủ của repository. Vì gần như toàn bộ client của chúng tôi là agent và job, chúng tôi thiết kế client và protocol của Scion xoay quanh một server luôn kết nối được.” Vậy là xong, cả luận điểm nằm gọn trong một câu. Git ra đời năm 2005, cho con người commit từ laptop, thỉnh thoảng mất mạng. Client thật sự của Anthropic năm 2026 là các instance Claude và job CI chạy trong data center, mạng luôn ổn định, clone và sync liên tục, chưa bao giờ offline. Vậy mà mọi client đó vẫn phải trả giá cho khả năng hoạt động offline — một tình huống chẳng bao giờ xảy ra với chúng.

Quy mô khiến chuyện này thành cụ thể, không còn trừu tượng. Lịch sử nhánh main khoảng 100 GB; một bản working copy nén lại vẫn hơn 25 GB. Riêng CI thực hiện khoảng 25 triệu lần checkout mỗi ngày — nếu chạy Git theo cách bình thường, đó là hơn 600 petabyte traffic mỗi ngày. Lúc cao điểm, Anthropic phải chạy vài trăm Git mirror nội bộ chỉ để theo kịp. Đây không phải chuyện tối ưu hiệu năng. Đây là một kiến trúc đã chạm trần thiết kế của chính nó.

Scion thực chất là gì

Scion không phải một phiên bản Git chạy nhanh hơn. Nó là một mô hình hoàn toàn khác, gần với Piper nội bộ của Google hay Sapling/Mononoke của Meta hơn là bất cứ thứ gì mang tính phân tán. Đơn vị cốt lõi không phải commit object — mà là “changeset”, được tạo ngay trên server và có mặt ở mọi nơi ngay khi nó tồn tại, lưu các thay đổi file tương đối so với parent đầu tiên, trỏ tới blob storage bằng content-addressed pointer. Không có packfile, không cần bảo trì repository — vì chẳng client nào giữ bản sao đầy đủ để mà bảo trì.

Đường đọc dữ liệu là cache ba tầng: scion-daemon ở cấp node, scion-cache trong bộ nhớ theo khu vực, và scion-server — nguồn xác thực cuối cùng, chạy trên Spanner và blob storage. Cả ba tầng đều trả lời cùng một bộ RPC, nên client không cần biết (và không cần quan tâm) tầng nào thực sự phục vụ request — cứ hỏi, rồi sẽ có nơi phía trên trả lời, với tỷ lệ cache hit trên 99% ở mọi tầng. Ngay cả ref cũng nhẹ: chỉ là một compare-and-swap trên một dòng Spanner, vì không có gì trong hệ thống phụ thuộc vào ref cache cục bộ để tìm hay tạo dữ liệu.

Kết quả Anthropic báo cáo: checkout của CI từ vài phút rút xuống còn vài giây — “nhanh hơn hai bậc độ lớn” — giải phóng khoảng 25% năng lực CPU của CI. Hạ tầng mới dùng ít hơn khoảng 200 lần CPU và bộ nhớ so với cụm Git-mirroring cũ. Và có một chi tiết nói lên khá nhiều về hướng đi sắp tới: chính Claude (tên nội bộ “Mythos”) đã viết lại pipeline chuyển dữ liệu từ Git sang Scion, dùng ít hơn 20 lần bộ nhớ và chạy nhanh hơn 4 lần so với bản con người viết ban đầu.

Merge queue bị bỏ — có chủ đích

Đây mới là quyết định thiết kế đáng để một tech lead dừng lại suy nghĩ kỹ. Anthropic không chỉ làm merge nhanh hơn — họ bỏ luôn cổng chặn. Nguyên văn của họ: “Một merge queue đúng nghĩa không còn hợp lý ở quy mô agent. CI còn có nghĩa gì khi hàng trăm, thậm chí hàng nghìn thay đổi có thể merge trong lúc test vẫn đang chạy?” Và ở chỗ khác: “Claude thường sửa xung đột nhanh hơn tốc độ con người kịp nhận ra có xung đột.”

Nói thẳng ra: thay đổi được merge vào main trước, test chạy sau, chứ không phải trước. Đây là một đánh đổi thật và có lý ở mức 30.000 merge/ngày — một merge queue tuần tự kiểu truyền thống sẽ trở thành nút thắt throughput từ lâu trước khi đạt tới con số đó. Nhưng nó đảo ngược một thuộc tính an toàn mà đa số tổ chức kỹ thuật coi là không thể thương lượng: main phải luôn là nhánh build được. Bài viết của Anthropic không hề cho thấy chuyện gì xảy ra khi một lần test sau-merge bắt được lỗi. Ở quy mô đó, bao nhiêu merge lỗi lọt vào main trong khoảng thời gian giữa lúc merge và lúc test chạy xong? Chúng được phát hiện, bisect, và gỡ bỏ như thế nào? Có đường revert tự động không, hay phải chờ con người nhận ra? Câu “Claude sửa xung đột nhanh hơn con người nhận ra” chỉ nói về xung đột merge kiểu văn bản — hai thay đổi đụng cùng dòng code. Nó không nói gì về một merge sạch về mặt văn bản nhưng lại gây ra lỗi logic — đúng kiểu lỗi quan trọng nhất một khi bạn bỏ cổng chặn trước-merge.

Chỗ Anthropic nói thật — và chỗ họ chỉ im lặng

Phải công nhận: Anthropic khá thẳng thắn về giới hạn của chính thông báo này. Nguyên văn: “Scion hoàn toàn không phải là một lựa chọn thay thế phù hợp cho git để dùng chung.” Và: “rất khó để đưa Scion ra dưới dạng hữu ích rộng rãi cho các tổ chức khác. Nó khác biệt đáng kể so với git, nghĩa là các công ty sẽ phải di chuyển toàn bộ vòng đời phát triển phần mềm” — code review, code search, CI, quản lý danh tính và quyền truy cập, tất cả đều xây riêng cho Scion và không mang đi nơi khác được. Không có mã nguồn công khai, cũng không có kế hoạch mở mã. Anthropic cũng nói rõ rằng bài toán kinh tế token của một công ty AI như họ không đại diện cho tình huống của bất kỳ tổ chức nào khác — một lời nhắc đáng giá, tránh để người đọc coi đây như một bản thiết kế chung cho mọi công ty.

Còn điều đơn giản là bị thiếu, chứ không phải được cảnh báo trước, là bất kỳ câu chuyện tương thích nào với Git: có đội nào trong nội bộ vẫn làm việc hằng ngày trên Git hay không, cộng tác viên bên ngoài hoặc dependency mã nguồn mở có tương tác được với một repo Scion hay không, và rollback trong thực tế trông như thế nào. Không điều nào trong số này được nói là đã giải quyết hay cố tình loại trừ — nó đơn giản là không xuất hiện trong bài viết.

Scion đi theo một lối mà các công ty khác đã từng đi: Google rời Perforce sang Piper, Meta rời Mercurial sang Sapling, cùng lý do, cùng quy mô. Anthropic gia nhập danh sách đó là một tín hiệu thật, cho thấy mô hình client-server luôn kết nối đúng là hướng đi hợp lý một khi client chính của bạn là máy móc, chứ không còn là con người cầm laptop. Nhưng nếu tổ chức của bạn còn cách xa con số 30.000 merge/ngày, bài học thực tế không phải là “tự xây VCS riêng”. Nó hẹp hơn nhiều: khi khối lượng code do agent viết tăng lên, hãy nhìn vào những chỗ CI và hệ thống quản lý mã nguồn của bạn đang giả định nhịp độ con người — build ban đêm, merge queue tuần tự, checkout thủ công trên máy dev — rồi tự hỏi giả định nào sẽ vỡ trước. Với đa số team, điều đó sẽ lộ ra ở năng lực CI và throughput của merge queue, rất lâu trước khi nó trở thành lý do để thay cả Git.