Cuộc tranh luận về việc liệu có nên tồn tại quy trình xây dựng phần mềm được tự động hóa hoàn toàn bằng AI hay không cuối cùng cũng bùng nổ. Ngòi nổ chính là
@yetone khi duy trì magpie, dự án bị cộng đồng chê là "phục vụ kiểu đồ ăn nhanh" và "quá rủi ro để sử dụng".
Hầu hết mọi người đều đồng ý rằng việc dùng AI tự động hóa quá trình xây dựng phần mềm là xu hướng tất yếu. Vậy magpie đã hiện thực hóa điều này như thế nào? Tôi đã clone magpie về, phân tích 2.862 commit trong mười ngày qua và dùng OpenClaw để so sánh.
https://x.com/wquguru/status/2109458639501271530
1204 Phiên bản trong 19 Ngày
magpie là một local LLM gateway giúp kết nối các coding agent như Claude Code, Codex và Gemini CLI với bất kỳ model hoặc gói subscription nào. Từ commit đầu tiên vào ngày 22 tháng 9 đến nay, dự án đã đạt 9.474 sao chỉ trong 19 ngày. Trong số 2.862 commit, tài khoản của yetone chiếm tới 85%, đồng thời merge 383 PR từ cộng đồng.
Số lượng tag (tương đương với các phiên bản) đạt 1.204 trong 19 ngày, trung bình hơn 60 phiên bản mỗi ngày — một tần suất mà con người không thể tự làm thủ công nổi. Để so sánh, OpenClaw có 1.423 commit trong 19 ngày đầu tiên, 99% do đích thân Peter Steinberger thực hiện, với khoảng 10 tag.
magpie có số commit gấp đôi nhưng số phiên bản lại nhiều hơn cả trăm lần.
Điều tôi muốn làm rõ chỉ có một: Rốt cuộc thì AI đã khép kín vòng lặp trong dự án này như thế nào?
Một Bảng Định Tuyến và Một Cuốn Sổ Ghi Lỗi
File CLAUDE.md của magpie chỉ tham chiếu đến hai file: AGENTS.md và LESSONS.md.
AGENTS.md đóng vai trò như một bảng định tuyến. Nó không tự viết ra luật lệ, mà chỉ hướng dẫn các agent cần đọc tài liệu nào trước khi bắt tay vào việc: kiểm tra docs/subsystems/ trước khi sửa đổi subsystems, tuân theo docs/code-standards.md khi viết/review code, và xem docs/contributors.md khi review PR của cộng đồng.
Câu đầu tiên của LESSONS.md đã trả lời cho câu hỏi ban đầu:
Mã nguồn của magpie được viết, review, merge và phát hành bởi các agent. (Mã nguồn của magpie được viết, review, merge và phát hành bởi các agent)
Viết, review, merge, phát hành — tất cả đều do agent đảm nhiệm. Không có sự giám sát của con người, vậy tại sao nó không sập? Câu trả lời nằm ở file này. Với 479 dòng, nó thực chất là một cuốn sổ ghi lỗi, được agent viết lại mỗi đêm.
Đêm nào cũng vậy, agent sẽ rà soát toàn bộ commit trong ngày, tập trung vào ba trường hợp:
- Những bản sửa lỗi nào phải làm đi làm lại?
- Những thay đổi nào lẽ ra không nên được merge ngay từ đầu?
- Những bước kiểm chứng nào làm quá sơ sài?
Với mỗi vấn đề tìm được, nó sẽ ghi lại một nguyên tắc, lý do, kèm theo số commit và issue làm bằng chứng. Ví dụ:
Hãy tái hiện chính xác trường hợp của người báo cáo, trên đúng giao diện họ đang dùng, trước khi tuyên bố là đã sửa xong.
Issue 834 bị trả lại 4 lần (v0.1.920 → .925 → .931 → .938). Mỗi lần chỉ sửa được agent hiển thị trong ảnh chụp màn hình. Phát hiện 1× (2026-10-05).
Issue 834 bị làm lại tới bốn lần, mỗi lần chỉ sửa được agent xuất hiện trong ảnh chụp màn hình. Do đó, nguyên tắc đặt ra là: trước khi nói đã sửa xong, hãy tái hiện chính xác vấn đề trên đúng giao diện mà người báo cáo đang sử dụng.
Điểm mấu chốt nằm ở dòng cuối cùng: Seen 1×. Nếu cùng một bài học xuất hiện trong các buổi review của ba ngày khác nhau, nó sẽ được chuyển từ LESSONS.md sang code-standards.md, biến kinh nghiệm thành luật cứng. Mọi buổi review PR sau đó đều phải đối chiếu từng mục với các luật này.
Đã có tám nguyên tắc được thăng cấp theo cách này. Chẳng hạn như gom các bug tương tự nhau để sửa cùng lúc (bị bắt lỗi một lần vào các ngày 5, 6 và 7 tháng 10); test fail trên nhánh main thì phải coi là bug cần xử lý ngay; và phải nêu rõ đã test những gì, trên commit nào trước khi merge.
Tất nhiên, cuốn sổ ghi lỗi cũng lưu lại cả những việc làm tốt, được đánh dấu là Done right, để agent không chỉ đọc được "đừng làm thế này", mà còn biết "hãy làm thế kia".
Cuốn Sổ Ghi Lỗi Được Áp Dụng Vào Rạng Sáng Ngày 6 Tháng 10
Hệ thống này có được thiết kế ngay từ đầu không? Kiểm tra lịch sử commit của LESSONS.md, phiên bản đầu tiên là commit 303819c5, được tạo lúc 3:10 sáng ngày 6 tháng 10.
Trước đó một ngày, vào 5 tháng 10, magpie đã tung ra 168 phiên bản.
Phiên bản đầu tiên của LESSONS.md đã ghi nhận lại ngày hôm đó. Với 220 commit và khoảng 170 bản phát hành, có tầm 40 bản chỉ để vá lỗi cho các phiên bản vừa ra mắt trong cùng ngày hoặc ngày hôm trước. CI gần như luôn bị hủy bởi lần push tiếp theo. Một bài test chỉ fail trên Linux cứ đỏ lòm từ v0.1.877 đến v0.1.892 mà chẳng ai buồn ngó.
294 tag trong 51 giờ khiến không một luồng chạy nào kịp hoàn thành. (294 tag trong 51 giờ đồng nghĩa với việc không có luồng CI nào kịp chạy xong)
Thế nên phiên bản đầu tiên đã bổ sung một nguyên tắc: Trước khi gắn tag, CI của commit đó phải chạy xong và báo xanh. Các luồng chạy bị hủy do có push mới sẽ không được tính.
168 bản phát hành vào ngày đầu, 42 bản ngày thứ hai, 15 bản ngày thứ ba, rồi ổn định ở mức 15 đến 26 bản.
Không họp hành, không thông báo. Các buổi review hàng đêm phát hiện vấn đề, thêm nguyên tắc vào cuốn sổ ghi lỗi, và các agent đang làm việc sẽ đọc được rồi tự giảm tốc độ phát hành.
Bởi vậy, hơn hai mươi bản phát hành mỗi ngày gần đây bị đem ra phàn nàn thực chất là tốc độ sau khi đã đạp phanh.
Tiêu Chí Chấp Nhận PR
Tiếp theo, hãy xem xét các PR thực tế:
code-standards.md liệt kê sáu tiêu chí chấp nhận. Phải vượt qua tất cả mới được merge hoặc phát hành. Bỏ qua các bước kiểm tra thông thường như biên dịch trên ba nền tảng và test trong sandbox, có ba tiêu chí rất hiếm gặp ở các dự án bình thường:
- Regression Test: Đưa code cũ trở lại; bài test mới phải fail một cách rõ ràng, chỉ đích danh hành vi nào sai. Lỗi biên dịch hoặc test bị bỏ qua sẽ không được tính.
- Real Usage: Nếu thay đổi phần tích hợp với vendor, phải xác minh bằng tài khoản, cấu hình và phản hồi API thực tế. Tính năng chưa được test thì không được phép xây dựng tiếp hay quảng cáo là dùng được với người dùng.
- Các Bước Kiểm Tra Chưa Chạy Phải Được Liệt Kê:
Bước kiểm tra nào chưa chạy thì phải ghi rõ là chưa chạy, tuyệt đối không được bỏ sót. (Các bước kiểm tra chưa thực hiện phải được liệt kê là chưa chạy, không bao giờ được bỏ qua)
Tôi chọn ngẫu nhiên #1339 để xem comment để lại trước khi merge:
Red check nghĩa là regression test, Break check là cố tình phá code để xem test có bắt được lỗi không, và dòng cuối ghi Not run — tức là chưa được test trên phần cứng thật.
Lệnh merge có kèm --match-head-commit <reviewed sha>. Nếu có ai push thêm trong lúc đang review, lệnh merge sẽ fail, đảm bảo code chưa qua duyệt không lọt vào được.
Con Người Vẫn Nằm Trong Vòng Lặp
Tất nhiên, con người vẫn tham gia vào một số khâu, ít nhất là ở những mảng sau:
- Quyết định sản phẩm: "Không đảo ngược các quyết định có chủ đích." Những thứ như hành vi cuộn trang hay con trỏ chuột trên nút bấm không được phép thay đổi qua PR.
- Cổng an ninh: Nếu hệ thống cảnh báo rủi ro, phải chờ maintainer phê duyệt.
- Góp ý từ cộng đồng: 474 tiêu đề commit có nhắc đến người báo cáo từ X hoặc Discord, ví dụ JonahFu trên X, Jeremy.Zhou trên Discord.
Nói tóm lại, con người lo việc định hướng và gác cổng; còn viết, review, merge và phát hành thì giao hết cho agent.
Liệu yetone Có Giấu Giếm Gì Không?
Đến đây, có người sẽ hỏi: Liệu yetone có giấu bài gì không? Tôi cũng tò mò nên đã đào sâu hơn.
Quả thực, có vài thứ không nằm trong repo:
- Cơ chế kích hoạt buổi review hàng đêm không được ghi chép lại. Cả 4 workflow đều không được lên lịch sẵn.
- Tôi trích xuất thời gian của 7 lần cập nhật LESSONS.md: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Chúng khá rải rác, trông không giống cron job mà giống chạy thủ công trên máy cá nhân hoặc qua script tùy chỉnh hơn.
- Prompt dùng cho các buổi review hàng đêm cũng không có. Dùng agent nào, chạy bao nhiêu session song song — chẳng có tài liệu nào nhắc tới.
Trong quá trình tìm hiểu, tôi phát hiện thêm hai điểm nữa:
Thứ nhất, phương pháp này có sự đóng góp của cộng đồng. Tài liệu subsystem và quy trình review thay đổi ngữ nghĩa được đưa vào qua PR #889 của thành viên cộng đồng Junjie Zhou. Hai bảng ở đầu file code-standards.md được ghi nhận công khai trong commit 926bcaa3 là dựa trên sáu nguyên tắc review do Junjie Zhou đề xuất trên Discord.
Thứ hai, những lần tương tác giữa yetone và agent được lưu giữ nguyên vẹn trong commit. 52 tiêu đề commit chứa nguyên văn lời của yetone trong ngoặc đơn:
1(chủ dự án: Cái này xấu quá)2(chủ dự án: Sao chỗ này lại dùng native selector thay vì ComboBox trừu tượng của chúng ta?)3(chủ dự án: Sao lỗi này lại quay lại nữa? Chẳng phải đã bảo là nó chỉ nên hiện khi hover thôi sao? Lúc nào cũng hiện thì xấu lắm)4(chủ dự án: Trong lúc pr-preview, đôi khi không có dữ liệu để test. Bạn tạo giúp tôi vài dữ liệu giả nhé?)
Phần lớn chỉ là những câu phàn nàn ngắn gọn một dòng; phần còn lại do agent tự điền, thường kéo dài tới hàng trăm từ trong nội dung commit. Yêu cầu tạo dữ liệu giả sau đó đã trở thành bộ mock data dùng để ghi hình CI.
Con người chỉ ra chỗ sai; agent biến nó thành những thay đổi có thể kiểm chứng được. Vài chục tiêu đề commit này giải thích phương pháp luận rõ ràng hơn bất kỳ tài liệu nào.
Nếu Bạn Muốn Tự Xây Dựng Một Hệ Thống Tương Tự
Ai cũng viết được bảng định tuyến. Giá trị thực sự đáng để học hỏi là hệ thống sổ ghi lỗi. Một mục trong LESSONS sẽ trông như thế này:
1**<Nguyên tắc tóm gọn trong một câu>**2- <Commit/issue nào gây ra lỗi, hậu quả là gì>3- <Commit khắc phục>4- Done right: <Ví dụ về cách làm đúng>5- Seen N× (YYYY-MM-DD, YYYY-MM-DD).
Hãy để agent review commit hàng ngày vào mỗi tối, chỉ tập trung tìm lỗi làm đi làm lại, merge ẩu và kiểm chứng hời hợt. Nếu cùng một vấn đề xuất hiện trong ba ngày khác nhau, hãy chuyển nó vào tiêu chuẩn code. Khi nghiệm thu, nhớ liệt kê regression test, real usage và các mục chưa chạy vào nội dung commit cũng như comment PR.
Sau khi rà soát toàn bộ repo, điều khiến tôi ấn tượng nhất là ngưỡng Seen 3×. Lỗi lầm được ghi chép lại, agent đọc chúng mỗi khi khởi động, và nếu lặp lại cùng một lỗi ba lần, nó sẽ được nâng lên thành luật cứng — áp dụng triệt để triết lý "quá tam ba bận" (hay đúng hơn là ba lần vi phạm thì thành luật).
Vài Lời Kết...
Một năm trước, hay thậm chí nửa năm trước, năng lực của các model hiếm khi chạm tới mức tự động hóa chuẩn production. Nhưng giờ đây, đặc biệt là kể từ khi Opus 5.5 ra mắt, chúng ta có thể thấy — tương lai đã hiện diện ngay trước mắt.
Điều này làm tôi nhớ đến Yoyo của @yuanhao, một Agent đã tự lặp lại và tiến hóa hơn 200 ngày: https://yoyo-gasp.yolog.dev/, cũng rất đáng để bạn khám phá.
