GHC và làn sóng đóng góp bằng AI: Chính sách mới nói gì?

GHC, trình biên dịch của ngôn ngữ Haskell, vừa chính thức hóa chính sách dành cho các đóng góp có sự trợ giúp của mô hình ngôn ngữ lớn (LLM). Đây không phải lệnh cấm, mà là một bộ quy tắc rõ ràng về việc được làm gì, phải khai báo gì và ai chịu trách nhiệm cuối cùng. Câu chuyện này đáng chú ý với cộng đồng mã nguồn mở Việt Nam, nơi các công cụ như GitHub Copilot hay Claude đang ngày càng phổ biến trong quy trình làm việc.

Bối cảnh: khi việc sinh mã trở nên quá dễ

Vấn đề cốt lõi của GHC không phải là AI tốt hay xấu, mà là chi phí đánh giá mã. Dự án hiện có hơn 6.500 ticket đang mở, trong khi số người có khả năng review lại rất hạn chế. Một bản vá được tạo ra trong hai mươi phút vẫn có thể khiến người duy trì mất hai giờ để hiểu.

Minh họa về đóng góp mã nguồn mở

Thuật ngữ mà dự án LLVM dùng là "đóng góp mang tính khai thác" (extractive contribution): người đóng góp nhận lợi ích từ việc gửi mã, còn dự án phải bỏ nhiều công sức để review và tích hợp hơn giá trị thực mà bản vá mang lại. Vấn đề này đã tồn tại từ trước khi có LLM — ai cũng có thể gửi một bản vá 2.000 dòng mà bản thân chẳng hiểu rõ. Điều LLM thay đổi là tốc độ tạo ra những bản vá như vậy.

Nội dung chính sách: bốn nguyên tắc và một khuyến nghị

Chính sách mới không đưa ra quan điểm toàn cầu về lợi ích hay tác hại của LLM, mà chỉ định nghĩa kỳ vọng với người đóng góp và người đánh giá.

• P1 — Ưu tiên con người và cộng đồng: Được phép dùng LLM để tìm hiểu mã nguồn, dịch văn bản hay điều tra lỗi, nhưng các cuộc trao đổi trực tiếp với người review phải do con người thực hiện. Không được chuyển văn bản do AI tạo ra như một sự thay thế cho phán đoán của chính mình.

• P2 — Giúp việc review trở nên dễ dàng: Người đóng góp phải bỏ nhiều công sức hơn mức người review cần để hiểu. Bản vá phải có mục tiêu rõ ràng, thiết kế được giải thích, ví dụ và kiểm thử đi kèm, chia thành các phần dễ tiêu hóa. Một bản vá biên dịch được nhưng buộc người review phải tự dựng lại lý luận thì không đạt yêu cầu.

• P3 — Tác giả là con người, chịu trách nhiệm đầy đủ: Mọi đóng góp cần một tác giả con người cụ thể, người hiểu và có thể giải thích từng dòng mã, từng câu tài liệu. Vật liệu do AI tạo vẫn được chấp nhận nếu người đóng góp đã xem xét kỹ đến mức có thể chịu trách nhiệm.

• P4 — Khai báo việc dùng LLM trực tiếp: Nếu LLM tạo ra bất kỳ phần nào của mã, tài liệu hay kiểm thử được gửi lên, điều đó phải được nêu rõ — thường bằng dòng Assisted-By: trong mô tả MR hoặc trong commit. Không cần công khai prompt hay kể lại mọi tương tác; việc dùng riêng để khám phá hay gỡ lỗi không bắt buộc phải khai báo.

• P5 — Nên tự viết phiên bản cuối cùng: Đây là khuyến nghị mạnh, không phải yêu cầu bắt buộc. Viết lại bản cuối thường là cách đơn giản nhất để đảm bảo tác giả đã suy nghĩ thấu đáo từng dòng và loại bỏ phần thừa. Các ghi chú kiến trúc (GHC Notes) được đặc biệt lưu ý vì chúng lưu giữ lý luận thiết kế có thể còn quan trọng nhiều năm sau.

Làm việc với trình biên dịch GHC

Vì sao không cấm tuyệt đối?

Dự án OpenJDK chọn hướng cứng rắn hơn: loại bỏ mọi vật liệu do LLM tạo ra, toàn phần hay một phần. Nhưng chính OpenJDK cũng thừa nhận không thể phân biệt đáng tin cậy giữa nội dung máy tạo và người viết. Điều này tạo ra nghịch lý: người khai báo trung thực có thể bị từ chối ngay, trong khi người dùng cùng công cụ nhưng im lặng lại không thể bị phát hiện.

GHC chọn con đường khác: khai báo giúp người review có thêm ngữ cảnh, nhưng không tự động loại bỏ đóng góp. Các dự án khác cũng chia rẽ tương tự — GCC từ chối các đóng góp có ý nghĩa pháp lý chứa vật liệu do AI tạo; Linux kernel cho phép nhưng yêu cầu thẻ Assisted-by:; Clojure từ chối mã do LLM sinh; Agda từng tranh luận nhưng không thông qua lệnh cấm.

Chính sách cũng cần được cập nhật

Một điểm đáng suy ngẫm: các quy định gắn chặt với chất lượng của mô hình hiện tại sẽ nhanh chóng lỗi thời. Dự án curl là ví dụ điển hình — sau khi đóng chương trình bug bounty vào đầu năm 2026 vì ngập báo cáo kém chất lượng liên quan đến AI, đến tháng 4, tỷ lệ báo cáo lỗ hổng được xác nhận đã trở lại mức 15–16%, tương đương mức lịch sử. Chỉ trong khoảng hai tháng, chất lượng đầu vào đã thay đổi đáng kể.

Với đội ngũ ở Việt Nam đang xây dựng các dự án mã nguồn mở hoặc đóng góp cho dự án quốc tế, bài học rút ra khá thực tế: công cụ AI là trợ thủ hợp lệ, nhưng trách nhiệm vẫn nằm ở con người. Hiểu rõ bản vá của mình trước khi gửi đi là tiêu chuẩn tối thiểu, bất kể bạn viết tay hay dùng trợ lý lập trình.

Đóng góp cho cộng đồng Haskell

Tiêu chuẩn không thay đổi: người đóng góp hiểu công việc của mình, bản vá có thể review được, và thay đổi cải thiện GHC mà không tạo thêm gánh nặng bảo trì nhiều hơn những gì nó loại bỏ.