- Một trong những dự án ngôn ngữ mã nguồn mở lớn đang áp dụng quy định nghiêm ngặt cấm sử dụng LLM trong issue, Pull Request, bình luận trên bug tracker và bản dịch
- Việc sử dụng tiếng Anh chỉ là khuyến nghị chứ không bắt buộc; người đóng góp có thể viết bằng tiếng mẹ đẻ, còn người khác có thể tự dùng công cụ dịch mình chọn để hiểu nội dung
- Bun đã thêm parallel semantic analysis và multiple codegen units vào LLVM backend trong Zig fork riêng của mình, đạt mức cải thiện hiệu năng biên dịch Bun gấp 4 lần, nhưng hiện chưa có kế hoạch upstream vì lệnh cấm đóng góp do LLM viết
- Cách review của Zig không phải là từ chối PR chưa hoàn thiện, mà là giúp người đóng góp mới đi đến mức có thể merge được; dự án coi trọng sự trưởng thành của người đóng góp hơn từng đóng góp riêng lẻ
- Các PR chủ yếu do LLM viết khiến thời gian review không còn được dùng để tăng số người đóng góp mới đáng tin cậy, đồng thời tạo ra lựa chọn để maintainer tự chạy LLM giải quyết cùng vấn đề
Xung đột giữa chính sách và Bun fork
- Zig nêu rõ trong Code of Conduct rằng cấm sử dụng LLM trong issue, Pull Request, bình luận trên bug tracker và bản dịch
- Việc dùng tiếng Anh là khuyến nghị, và người đóng góp có thể viết bằng tiếng mẹ đẻ
- Người khác có thể tự dùng công cụ dịch mình chọn để hiểu nội dung
- Một dự án tiêu biểu viết bằng Zig là runtime JavaScript Bun, và Bun đã được Anthropic mua lại vào tháng 12/2025
- Bun vận hành Zig fork riêng và đã thêm “parallel semantic analysis and multiple codegen units” vào LLVM backend, đạt mức cải thiện hiệu năng gấp 4 lần khi biên dịch Bun
- Theo một Zig core contributor, bản vá này khó được chấp nhận ngay cả khi bỏ qua vấn đề LLM
- parallel semantic analysis là tính năng đã được lên kế hoạch từ lâu, nhưng nó ảnh hưởng đến chính ngôn ngữ Zig
Contributor Poker và review lấy người đóng góp làm trung tâm
- Bài Contributor Poker and Zig's AI Ban dùng contributor poker như một phép ẩn dụ then chốt để hiểu chính sách cấm nghiêm ngặt của Zig
- Các dự án mã nguồn mở thành công sẽ đến giai đoạn nhận được nhiều PR hơn khả năng xử lý
- Để tối đa hóa ROI, Zig chọn cách không từ chối PR chưa hoàn thiện mà hỗ trợ người đóng góp mới đưa công việc đến mức có thể merge
- Cách làm này được xem không chỉ là “điều đúng đắn” mà còn là “điều thông minh”
- Zig coi trọng người đóng góp hơn từng đóng góp riêng lẻ
- Mục tiêu hàng đầu của việc review và chấp nhận PR không phải là thêm mã mới, mà là giúp những người có thể trở thành người đóng góp đáng tin cậy và hiệu quả theo thời gian
- Mỗi người đóng góp là một đối tượng đầu tư của Zig core team
- Hỗ trợ từ LLM làm cấu trúc này bị phá vỡ
- Dù LLM có giúp tạo ra PR hoàn hảo, thời gian mà đội ngũ Zig bỏ ra để review vẫn không góp phần làm tăng số người đóng góp mới, tự tin và đáng tin cậy
- “contributor poker” xuất phát từ phép ví von rằng trò chơi này nhìn vào con người chứ không phải các lá bài
- Ý của nó gần với việc đặt cược vào người đóng góp hơn là vào nội dung của PR đầu tiên
- Nếu một PR phần lớn do LLM viết, maintainer của dự án sẽ có thêm lựa chọn là tự chạy LLM để giải quyết cùng vấn đề thay vì review và thảo luận về PR đó
1 bình luận
Ý kiến trên Hacker News
Theo https://kristoff.it/blog/contributor-poker-and-ai/, các đóng góp dựa trên LLM nhìn chung là tiêu cực
Các PR gửi vội vô giá trị đã làm tăng nhiễu nền bằng mã ảo giác, không biên dịch được hoặc không qua CI, thậm chí có cả người đóng góp lần đầu gửi PR 10.000 dòng
Cũng có những PR bề ngoài trông ổn và còn ghi rõ là không dùng LLM, nhưng trong thảo luận tiếp theo thì ngay lập tức lộ ra rằng tác giả đã lén tham khảo LLM và lặp lại các câu trả lời đầy lỗi
hooks thì không có cách gọn gàng để ép cài khi clone, nhưng GHA Workflows hoặc tính năng tương đương ở forge khác có thể làm được
Với dự án có quy mô và độ phổ biến nhất định, tôi xem đây là yêu cầu cơ bản
Một phần lớn vấn đề kiểu “AI không biết đóng góp” có vẻ có thể giảm bớt bằng kiểm tra tự động và cơ chế chặn tốt hơn
Ngoại trừ việc AI đã cho phép kiểu spam mới này xuất hiện, thì bản chất không phải là AI
Ngay cả không có AI, nếu người ta thuê hàng loạt lập trình viên offshore giá rẻ để sản xuất hàng loạt PR gửi vội chất lượng trung bình, hiệu ứng cũng sẽ như vậy
AI cũng có thể tạo ra mã tốt, nhưng như các công cụ khác, phải dùng cẩn trọng
Đây không phải là đóng góp được làm cẩn thận bởi người hiểu dự án và mục tiêu rồi dùng công cụ cho tốt, mà là spam
Có vẻ làn sóng ồn ào quanh chính sách AI bắt đầu khi các lập trình viên Bun nói rằng vì chính sách đó nên họ không thể upstream PR tối ưu hiệu năng
Nhưng lý do thực tế có vẻ là bản thân mã trong PR đó không ở trạng thái tốt và đưa vào độ phức tạp không lành mạnh https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Theo phần giải thích được trích dẫn, phân tích ngữ nghĩa song song từ lâu đã là kế hoạch rõ ràng của trình biên dịch Zig và ảnh hưởng lớn đến thiết kế của self-hosted Zig compiler, nhưng để triển khai đúng thì không chỉ cần thay đổi ở phần cài đặt trình biên dịch mà còn phải thay đổi cả ngôn ngữ Zig
Vì nó xung đột với lộ trình riêng của Zig nhằm đạt kết quả tốt hơn, đồng thời cản trở hướng tiếp tục cải thiện toàn bộ ngôn ngữ
Chính sách đã cấm rõ ràng mọi mã LLM, nên tất nhiên đó mới là “lý do thật sự”
Phía Zig có vẻ đang đi theo con đường của ZeroMQ https://zguide.zeromq.org/docs/chapter6
Tức là theo hướng “ép quyền sở hữu tập thể của dự án để tăng động lực kinh tế cho người đóng góp và giảm rủi ro bị các tác nhân thù địch chiếm quyền”
Một cộng đồng người đóng góp lành mạnh quan trọng hơn hiệu năng mã, số tính năng hay số dòng mã đơn thuần
Ngày nay “cộng đồng” zeromq khá thưa thớt, vẫn còn vài người tuyệt vời đang hoạt động nhưng các quy trình và kênh giao tiếp ở mức con người thì không được định nghĩa rõ ràng và cũng không được vận hành đầy đủ
libzmq và phần lớn các binding đã ổn định nên sự thiếu vắng hoạt động và tương tác con người này có thể phần nào chấp nhận được hoặc được biện minh, nhưng chính tầm nhìn tuyệt vời của Hintjens đã đưa zeromq đến đây, và sau khi mất ông ấy thì dự án cho cảm giác đang trôi dạt
Trớ trêu thay, trái với tầm nhìn lấy cộng đồng làm trung tâm, để có và giữ được cộng đồng dường như vẫn cần một lãnh đạo có sức hút và năng động, và điều này nói về bản tính con người nhiều hơn là về phát triển phần mềm
Liên hệ lại với Zig, Zig có giả định rằng họ không thiếu PR nên có thể sàng lọc trước để chỉ nhận đóng góp không dùng LLM
Với họ đó là lựa chọn tốt, và ý tưởng “contributor poker” cũng dễ hiểu
Nhưng nếu dòng người mới giảm đi thì cuộc chơi sẽ thay đổi, và khi đó nếu phía Zig vẫn muốn có người đóng góp mới, họ có thể phải giăng lưới rộng hơn
Chỉ là đến lúc ấy, việc mở cửa cho đóng góp có hỗ trợ LLM có thể đã quá muộn để cứu vãn
Điều tôi thắc mắc về đóng góp OSS do AI tạo ra là thế này
Nếu AI thực sự tăng năng suất lập trình viên nhiều đến vậy, thì tại sao maintainer của OSS lại muốn chèn một người đóng góp xa lạ vào giữa mình và LLM?
Maintainer có thể tự hỏi Claude Code là được
Mượn lời một đồng nghiệp: “Chúng tôi không cần trung gian để nói chuyện với mô hình AI, và viết code cũng không phải nút thắt cổ chai”
Họ dùng AI để tạo ra bản đầu tiên còn tệ, rồi tinh chỉnh prompt, sửa thủ công, bắt nó sửa phần khác, phát hiện tính năng liên quan để bổ sung, chạy benchmark để loại bớt tính năng nhỏ hoặc chọn một trong hai cách triển khai tương tự
Rồi tiếp tục sửa tay chỗ này chỗ kia, chạy bộ kiểm thử tự động được mở rộng để tìm các lỗi lạ trong cấu hình bất thường, rồi sửa bằng cả AI lẫn thủ công
Sau 20 giờ như vậy, bản cuối cùng chỉ còn 50 dòng và mỗi dòng có thể đã được viết lại 5 lần
Maintainer chỉ cần bỏ khoảng 1 giờ để xem bản cuối cùng
Điều đó hoàn toàn khác với việc bắt AI viết một bản vá trong 5 phút rồi gửi cho maintainer 1000 dòng còn không biên dịch nổi mà chính mình cũng không đọc
“Cái đó dễ quá, tôi cũng làm được”
Đúng, nhưng thực tế là bạn đã không làm
Nhưng đó không phải kiểu có thể chỉ ném cho nó chỉ thị cấp cao như với con người là xong
Tôi nghi những người khẳng định AI làm được chỉ với chỉ thị cấp cao thường đang làm các dự án “không cần suy nghĩ”, nơi lập trình viên đi sâu vào chi tiết cũng chẳng phải cân nhắc nhiều
Và cũng hy vọng không phải là nói lợi ích duy nhất của LLM chỉ là sinh ra đoạn mã mà người ta ngại tự gõ
Lời giải thích rằng “Zig coi trọng người đóng góp hơn là đóng góp. Mục đích chính của việc review và nhận PR không phải để thêm mã mới, mà là giúp họ trưởng thành thành những người đóng góp đáng tin cậy và hiệu quả theo thời gian. Hỗ trợ từ LLM phá hỏng hoàn toàn điều đó. Ngay cả khi LLM giúp nộp một PR hoàn hảo thì cũng vậy” là lý do hay nhất tôi từng thấy cho đến giờ
Tôi hoàn toàn ủng hộ quyết định của Zig và đánh giá cao tầm nhìn dài hạn của họ đối với cả cộng đồng lẫn dự án thực tế
Thành thật mà nói tôi không thấy LLM phù hợp đến vậy với công việc mang tính cộng tác hơn
Tương lai thay đổi ra sao thì còn phải xem, nhưng khi nhận PR do AI sinh ra, rốt cuộc nhiều khi tôi lại phải tự làm lại, trớ trêu là còn phải dùng LLM để làm lại nên ngày càng thấy mâu thuẫn
Dù vậy, ít nhất trong khoảng 5 năm tới tôi vẫn thấy chính sách của Zig là ý hay
Tôi nghĩ đó là cách nói ít mang tính thù địch nhất mà họ có thể dùng, và tôi tôn trọng đó là quyết định cho dự án của họ
Dù vậy tôi vẫn thấy nó đang trói dự án lại một cách không cần thiết
LLM là công cụ, và có thể giúp suy nghĩ, nghiên cứu và viết code
Có thể bị lạm dụng, nhưng ở nơi nó hữu ích thì nên chấp nhận
Việc không nhận PR của Bun vì những lý do khác là hoàn toàn ổn, nhưng cấm toàn bộ PR do LLM viết thì hạn chế quá mức và không cần thiết
Chỉ cần tập trung vào chất lượng công việc là được
Nếu maintainer tự dùng LLM để làm cùng việc đó thì có lẽ còn làm được với thiết kế tốt hơn và cách tiếp cận cẩn trọng hơn
Maintainer cần dành thời gian cho phát triển, chứ không phải chỉ review những PR ít công sức
Lũ lụt mã LLM đang làm cán cân nghiêng bất lợi cho maintainer, và tôi hoàn toàn hiểu vì sao họ muốn cấm hẳn
Ấn tượng tổng thể của tôi sau một thời gian chạy LLM và coding agent là đây là dụng cụ điện hay cần cẩu, chứ không phải công cụ ra quyết định
Những người trong tổ chức có khả năng hiểu khái niệm và hiểu kỹ thuật sâu sắc thì năng suất tăng bùng nổ
Ngược lại, người thiếu hiểu biết hoặc người mới, junior thì đang tạo ra thứ mã địa ngục chỉ cần thấy chạy được là nghĩ xong việc
LLM tạo ra khoảng cách tri thức trong tổ chức, và càng dùng nhiều thì khoảng cách đó càng rộng
Về sau có thể đến mức người ta không còn tin được vào sản phẩm đầu ra nội bộ vì mã được tạo ra
AI nhìn chung khuếch đại bộ kỹ năng, cả mặt tốt lẫn mặt xấu
Một ca sử dụng gần đây rất tuyệt là viết concept cho authentication daemon
Tôi trò chuyện với Codex, chọn lọc đề xuất, đối chiếu bằng tìm kiếm web thông thường, chốt bản nháp cuối rồi thảo luận với đồng nghiệp
Kiểu lập kế hoạch hội thoại có tích hợp tìm kiếm web như vậy cực kỳ hữu ích, và tôi cũng thấy review mã đã viết bằng AI là lợi ích thuần túy
Nhưng caveat cốt lõi của AI rốt cuộc vẫn là bạn phải thông minh hơn công cụ
Nếu Codex gợi ý dùng tech stack X, bạn phải tìm hiểu vì sao nó thực sự tốt, hiểu hoàn toàn và so sánh với giải pháp khác
Nhiều người bỏ qua bước này nên mới sinh ra vô số vấn đề, và đó là điều chí mạng
Sau khi cuộc trò chuyện kết thúc, bạn phải thông minh hơn AI, phải hiểu hoàn toàn những gì AI nói và có thể phê phán nó
Một khi kiến trúc đã chốt thì LLM làm phần triển khai khá tốt
Nhìn chung có thể khiến AI tạo ra mã rất tốt và được kiểm thử kỹ, thậm chí tốt hơn rất nhiều so với tự làm một mình trong cùng khoảng thời gian
Nhưng việc liên tục theo kịp hiểu biết về mọi thứ AI tạo ra vẫn là một thách thức
Lập luận rằng “nếu PR phần lớn do LLM viết, thì thay vì maintainer tốn thời gian review và thảo luận PR đó, sao không tự bật LLM của mình lên để giải quyết cùng vấn đề?” cũng áp dụng được cho bản thân mã nguồn mở
Nếu robot có thể tự viết trực tiếp, thì tại sao phải dùng dự án của người khác?
Nhất là nếu dự án mã nguồn mở đó còn được vibe coded
AI và công nghệ nói chung đang khiến cá nhân hóa trở nên rẻ và dễ hơn
Trước đây mọi người phải dùng hàng sản xuất đại trà đủ dùng cho tất cả, còn giờ đã có hy vọng sở hữu thứ gì đó thật sự xuất sắc chỉ dành cho riêng mình
Ngoài ra, nhiều người ở nhiều nơi cũng sẽ dùng LLM để làm lại các dự án mã nguồn mở, từ đó tác động đến kinh tế lao động
LLM có thể phun ra những thứ đó trong vài phút
Điều tôi muốn nhất là lịch sử sử dụng
Tôi muốn dùng phần mềm mà những người khác đã dùng trước tôi, nơi họ đã va phải bug và các góc cạnh sắc nhọn rồi mài nhẵn đi
Đại loại là ai còn mua đồ nữa khi có thể tải mô hình về, in ở nhà và tùy biến vô hạn
Lý do tồn tại của văn minh là để có thể giao phần lớn vấn đề của cuộc sống cho người khác xử lý, còn bản thân tập trung vào việc giỏi một thứ
Nếu bạn là nha sĩ hoặc điều hành một muffler shop thì thời gian mỗi ngày có hạn, và có lẽ bạn sẽ muốn trả tiền cho SaaS vendor hơn là đi học vibecoding rồi giám sát một thuộc cấp kỳ quặc, tốn công
Có ngoại lệ, nhưng vẫn chỉ là ngoại lệ
Nếu vendor làm ra sản phẩm hợp lý và có năng lực, tôi sẵn sàng trả tiền
Mã nguồn mở cũng vậy
Kể cả nếu LLM có thể ổn định tạo ra cả một hệ điều hành từ đầu, liệu tôi có thực sự muốn điều đó không?
Tôi không muốn bảo trì hệ điều hành, cũng không muốn quản lý ai đó đi bảo trì hệ điều hành, và ngay từ đầu tôi cũng không tin mình có một tầm nhìn nhất quán về hệ điều hành
Khi vượt qua một mức độ phức tạp nào đó thì khó mà mong robot đọc đủ suy nghĩ của tôi để cho ra kết quả chất lượng cao “xuất sắc chỉ dành cho riêng tôi”
Dự án Zig rõ ràng vượt xa phạm vi năng lực đó
Có người không kham nổi chi phí, và cả khi có quyền truy cập thì vẫn thường xuyên hoặc kéo dài gặp các vấn đề như Claude bị lỗi hoặc hiệu năng tổng thể giảm dần theo thời gian
Vài tháng trước khi tôi mới dùng Claude thường xuyên, chỉ trong một tuần đã dễ dàng tiến triển trên nhiều dự án, còn dạo này chủ yếu chỉ thấy spinner và chất lượng mã có cảm giác tụt mạnh, gần như không làm được gì
Tôi có vài repo khoảng 100 sao, chẳng có gì ghê gớm, nhưng đến tận năm ngoái vẫn thi thoảng nhận được PR, còn năm nay đến giờ thì gần như không có
Giả thuyết của tôi là LLM thích bám vào các dự án mainstream hơn
Khi nhiều lập trình viên giờ phụ thuộc nặng vào LLM, nó tạo ra thiên hướng bỏ qua phần lớn những gì tôi cung cấp
Lý do tái phát minh bánh xe bằng LLM ngày càng nhiều cũng là vì chi phí làm mới đã rẻ đi
Thế nên thay vì dùng một thứ obscure trên GitHub, chẳng hạn như đồ của tôi, người ta thấy dễ hơn nếu cứ sinh thẳng ra thứ mình cần
Tôi cũng thấy hiện tượng tương tự trong việc chọn dependency
Trừ khi có lý do cực kỳ tốt, còn không thì người ta có xu hướng cứ chọn thứ LLM đề xuất
Tôi đồng ý ở mức nào đó, nhưng không hoàn toàn
Đúng là ưu tiên nuôi dưỡng người đóng góp là điều đúng đắn
Nhưng tôi xem AI là một công nghệ hỗ trợ
Nó giống screen reader hay magnifying glass, tất nhiên vẫn có nhiều điểm khác
Có thể nghĩ về nó như bộ xương ngoài robot
Nó sẽ bị dùng cho việc xấu và việc ngu ngốc, nhưng cũng sẽ giúp những người trước đây không làm được có thể làm việc tốt hoặc trở nên có năng lực hơn
Với một số người, AI khiến họ có thể code thứ trước kia không làm được; với nhiều người, nó là cách để học code bằng cách quan sát những gì AI làm; với người khác nữa, nó giúp họ code nhanh hơn hoặc tốt hơn rất nhiều
Với một số người, một vài kỹ năng có thể mai một nhưng các kỹ năng khác lại phát triển
Nếu một bộ xương ngoài tử tế ra thị trường thì cũng sẽ có cùng các vấn đề như vậy, nhưng nhìn chung nó vẫn là công cụ trao quyền
Tôi không hiểu vì sao việc nuôi dưỡng một người đóng góp có dùng công nghệ hỗ trợ lại tệ hơn nuôi dưỡng người không dùng
Tất nhiên là có thể khó hơn
LLM không thông minh như những gì các vendor LLM từng quảng bá
Nếu thật sự như vậy thì chúng đã hoàn toàn tự trị và chúng ta đâu còn phải có cuộc trò chuyện này
Những ai mù quáng nộp mã do LLM tạo ra hoặc không công khai việc đã dùng nó thật sự nên dừng lại
Vấn đề còn lại là nó vẫn chỉ là công cụ
Ngay cả nếu bảo một lập trình viên bất kỳ “hãy làm Zig nhanh hơn bằng một PR one-shot” thì cũng không ra kết quả tốt
Trước đây các dự án OSS có cơ chế tự sàng lọc vì bạn phải tạo được working code, mà đạt đến mức đó thì thường nhờ đã học trong nhiều năm nên nhìn chung người ta làm đúng việc và cũng có kiểu reasoning riêng về tính năng hay nhu cầu
Ngày nay kể cả LLM có hoàn hảo và reasoning tốt đi nữa thì cuối cùng nó vẫn làm theo chỉ thị của người prompt
Nghĩa là cơ chế tự sàng lọc đó không còn nữa
Các lập trình viên Zig có lẽ cũng khó mà phân biệt chính xác cái nào là mã do LLM làm, cái nào là do người làm
Có thể mã do LLM sinh ra đã lọt vào rồi, nhưng ít nhất thì những người nộp mã đó vẫn phải xử lý code khá tốt
Tôi tò mò không biết cuối cùng liệu mọi thứ sẽ đi tới kiểu “chỉ con người có trusted badge of honor mới được commit”, hay tới mức “LLM reasoning đủ tốt để nói rằng ‘không, biến đi. Tính năng/kế hoạch/ý tưởng này là rác nên tôi không làm’”
Nếu làm vậy mà chẳng có cách nào thực sự trị được họ, thì tôi không biết điều gì sẽ ngăn họ lại