4 điểm bởi GN⁺ 2025-11-27 | 2 bình luận | Chia sẻ qua WhatsApp
  • Một PR quy mô lớn dài 13 nghìn dòng đã được gửi lên để bổ sung thông tin gỡ lỗi DWARF v5 cho trình biên dịch native của OCaml, hỗ trợ gỡ lỗi ở mức mã nguồn bằng GDB·LLDB trên macOS và Linux
  • Phần triển khai bao gồm breakpoint theo hàm·theo dòng, theo dõi tham số và biến cục bộ, hiển thị thông tin kiểu cơ bản, hỗ trợ AMD64·ARM64 v.v.
  • Tác giả cho biết đoạn mã này là kết quả được tạo ra với sự cộng tác của các mô hình AI như Claude Sonnet 4.5 và ChatGPT 5(Codex), còn bản thân chỉ chỉ huy·rà soát AI thay vì trực tiếp viết mã
  • Các maintainer của OCaml đã từ chối hợp nhất và đóng PR với lý do vấn đề bản quyền, thiếu thảo luận thiết kế, gánh nặng bảo trì, độ khó khi rà soát mã do AI tạo
  • Cuộc thảo luận lần này là một ví dụ cho thấy những thách thức mới của cộng đồng mã nguồn mở xoay quanh chất lượng·bản quyền·quy trình cộng tác của mã do AI tạo ra

Tổng quan về PR hỗ trợ gỡ lỗi DWARF v5

  • PR bổ sung thông tin gỡ lỗi DWARF v5 cho trình biên dịch native của OCaml để cho phép gỡ lỗi ở mức mã nguồn trong GDB và LLDB
    • Thiết lập breakpoint theo tên hàm·tệp·dòng, hiển thị tên biến, cung cấp thông tin kiểu
    • Hỗ trợ kiến trúc AMD64·ARM64, không hỗ trợ nền tảng 32-bit
  • Triển khai hỗ trợ DWARF đầy đủ trên cả macOS(Mach-O) và Linux(ELF) bằng tái định vị tương đối theo section
  • Bổ sung plugin LLDB (ocaml_lldb.py) để cung cấp lệnh in giá trị OCaml (ocaml print)
  • Bài kiểm thử gồm 9 hạng mục để xác minh chức năng·kiểu·gỡ lỗi theo dòng

Chi tiết triển khai

  • Nâng cấp từ DWARF v4 lên v5 và dùng DW_FORM_string để tránh lỗi liên kết
  • Hỗ trợ nhiều compilation unit (CU) và loại bỏ trùng lặp bảng chuỗi
  • Phản ánh theo dõi biến cục bộ·tham số, lexical block, thông tin kiểu cơ bản vào cấu trúc DWARF
  • Mô-đun Var_lifetime theo dõi vòng đời biến, còn trường fun_var_info truyền thông tin biến xuyên suốt pipeline biên dịch
  • Biểu diễn scope lồng nhau thông qua DW_TAG_lexical_block
  • Script kiểm thử xác minh breakpoint và hiển thị kiểu trong GDB·LLDB

Tranh cãi về mã do AI tạo ra

  • Tác giả cho biết: “Claude Sonnet 4.5 viết phần lớn và ChatGPT 5(Codex) đã rà soát”
    • Ông giải thích rằng mình “chỉ hướng dẫn và rà soát AI, không trực tiếp viết lấy một dòng nào”
  • Tên Mark Shinwell được ghi là tác giả trong một số tệp, làm dấy lên tranh cãi về nguồn gốc bản quyền
  • Tác giả khẳng định qua một báo cáo phân tích riêng rằng “cấu trúc·cách đặt tên·hệ thống kiểu khác với triển khai OxCaml, nên không phải sao chép”

Phản ứng của các maintainer

  • gasche: chỉ ra rằng hơn 13 nghìn dòng mã được gửi lên mà không có thảo luận thiết kế, nên gánh nặng rà soát·bảo trì là rất lớn
    • Quyết định không thể hợp nhất vì mã do AI viết “khó rà soát hơn và có rủi ro pháp lý”
  • dra27: chỉ trích cách diễn đạt “AI hiểu mã”, nhấn mạnh rằng LLM không phải là hiểu mà là công cụ sinh mẫu
  • bluddytmcgilchrist: cho rằng mã DWARF nên được tách thành thư viện riêng; nếu đưa vào bên trong trình biên dịch thì gánh nặng bảo trì sẽ tăng lên
  • Khi tranh luận trở nên gay gắt, PR đã bị khóa ở trạng thái ‘too heated’

Các điểm tranh luận về AI và cộng tác mã nguồn mở

  • Tác giả nhấn mạnh đây là một thử nghiệm phát triển dựa trên AI, nói rằng mình muốn “chứng minh AI có thể hoàn thiện mã chất lượng cao”
  • Các maintainer chỉ ra sự thiếu vắng chính sách rõ ràng về “chất lượng·bản quyền·quy trình rà soát của mã do AI tạo”
  • Trường hợp này đã khơi lại thảo luận về quy trình và tiêu chuẩn cần có khi tích hợp phát triển có AI hỗ trợ vào các dự án mã nguồn mở

2 bình luận

 
iolothebard 2025-11-27

Nhưng mà… người gửi PR thì hoàn toàn không hiểu.
Vì vậy… bác bỏ PR này. (cộc cộc cộc)

 
GN⁺ 2025-11-27
Ý kiến trên Hacker News
  • Tò mò không biết các maintainer của OCaml có được đào tạo đặc biệt để xử lý những người khó nhằn hay không
    Sự kiên nhẫn và trưởng thành của họ thật sự đáng kinh ngạc. Nếu là tôi chắc đã chặn kiểu Torvalds từ lâu rồi

    • Ở tập đoàn lớn nơi tôi làm việc, nếu hoài nghi AI thì gần như bị coi như kẻ bị cô lập
      Lãnh đạo có niềm tin gần như tôn giáo vào AI, nên muốn mọi kỹ sư dùng AI nhiều nhất có thể
      Review code cũng ngày càng do AI đảm nhiệm. Nhưng trong trường hợp này thì có vẻ họ tử tế không phải vì lý do đó
    • Nếu là maintainer của một dự án mã nguồn mở lớn thì có lẽ tự nhiên sẽ được rèn kiểu đó
    • Có vẻ người đóng góp không có ý xấu. Có lẽ đã có cách để chuyển hướng năng lượng đó theo hướng xây dựng
      Ví dụ như tách PR ra hoặc hướng họ sang đề xuất thiết kế
    • Có những người dường như đã bị AI làm hỏng cách suy nghĩ
      Maintainer tốt bụng quá mức, nhìn họ lãng phí thời gian cho những người như vậy thật bức bối
    • Đọc lại thread mà thấy khâm phục
      Cách các maintainer phản hồi bằng logic và sự đồng cảm, không cảm tính, đúng là giao tiếp kiểu sách giáo khoa
      Dù vậy cũng băn khoăn liệu sự tử tế này có vô tình củng cố thêm ảo tưởng hay không
  • Có người còn có vẻ thiếu tự nhận thức hơn cả LLM
    Việc hỏi AI xem commit do AI tạo ra có chính đáng không thật sự vô lý
    Dù vậy ít nhất anh ta cũng thành thật. Câu “Tôi sẽ bảo trì đống rác này, nhưng phải trả tiền” mới là đỉnh điểm

    • Ấn tượng là cộng đồng đã bình tĩnh đưa ra phản hồi mang tính xây dựng
      Nhờ vậy tôi cũng thấy muốn đóng góp cho hệ sinh thái OCaml
    • Tôi nghĩ anh ta không chỉ ngớ ngẩn mà còn có thể là một tay troll cao thủ
    • Chính đoạn đó mới thật sự là quả anh đào trên chiếc bánh
  • Với câu hỏi “Tại sao tác giả của file đã gửi lại là Mark Shinwell?”
    anh ta trả lời “AI quyết định vậy, tôi không hỏi” — câu đó tóm gọn tất cả

    • Càng buồn cười hơn vì trước đó anh ta còn nói “AI hiểu rất sâu đoạn code này, cứ thử thách đi”
    • Nó làm tôi nhớ đến ý rằng một lập trình viên giỏi phải suy nghĩ đồng thời ở nhiều tầng trừu tượng
      Thế hệ AI này thì đến mức tối thiểu của tư duy đa chiều cũng không có
      Ai cũng đoán được sẽ bị hỏi vì sao lại có phần bản quyền ở đó, vậy mà còn chẳng chuẩn bị nổi câu trả lời
    • Dù là mã nguồn mở, tôi vẫn thấy kiểu đóng góp này rất xa tinh thần mã nguồn mở về mặt tinh thần
      Gánh nặng review cuối cùng bị đẩy hết sang maintainer, còn trách nhiệm bảo trì thì người đóng góp không gánh
    • Ban đầu tôi tưởng là trò đùa, không ngờ lại là thật
    • Tôi còn đi tìm GitHub profile của anh ấy xem có phải Mark Shinwell thật đang ở đây không
  • CV của người này đúng là huyền thoại
    Đi qua các ngân hàng Phố Wall, làm giám đốc công nghệ ở Deutsche Bank, bán license cho EA,
    từng định viết cuốn “Hardcore Erlang”, gọi vốn crypto 2 triệu USD chỉ trong 2 ngày, v.v.
    Hoặc là thiên tài, hoặc là tay chém gió thế kỷ
    Liên kết liên quan: blog cũ, CV PDF, phỏng vấn, trang chính thức, tin hủy sách Erlang

  • Dù là code do AI tạo ra, nếu cộng đồng đã bỏ thời gian trao đổi và phản hồi
    mà tác giả lại copy-paste nguyên xi một đoạn dài do AI viết thì theo tôi đủ lý do để chặn ngay
    Cư xử như bot spam thì bị đối xử như bot spam là điều hiển nhiên

    • Trước đây có đồng nghiệp dán ticket Jira vào ChatGPT rồi copy câu trả lời để gửi PR
      Mỗi lần tôi hỏi thì câu trả lời mang đúng giọng điệu GPT điển hình
      Cuối cùng tôi tự thử nghiệm thì ra gần như giống từng từ một,
      và từ đó tuyên bố sẽ không review code của anh ta nữa
  • Ngay khi xuất hiện câu “Đây là phần phân tích bản quyền do AI viết” thì đã quá giới hạn rồi
    Nếu là tôi thì lúc đó đã ban khỏi repo luôn

    • Mức độ trưởng thành cảm xúc của các maintainer thật sự đáng nể
    • Tôi nghĩ đây chỉ là trò hề, cười cho qua là được
  • Tôi cũng từng có kinh nghiệm đóng các PR do AI tạo ra ở nhiều dự án mã nguồn mở
    Những người đóng góp kiểu này bị từ chối ở một dự án là lại chuyển sang chỗ khác
    Gánh nặng review tăng lên, còn người đóng góp thật sự thì ngày càng ít đi
    Dù vậy xem những cuộc thảo luận như thế này trên HN theo thời gian thực vẫn rất thú vị

    • PR lần này cuối cùng đã bị đóng và khóa. Các maintainer đã kiên nhẫn phản hồi nhưng
      tác giả hoàn toàn không bị thuyết phục bằng lý lẽ. Có lẽ các dự án khác cũng sẽ chống đỡ kiểu này thôi
    • Maintainer mã nguồn mở dù chỉ để không bị chế giễu trên HN hay Reddit cũng sẽ chống lại làn sóng này
      Điều đáng lo hơn là phía phần mềm doanh nghiệp
  • Tôi muốn hỏi những người ủng hộ AI
    Nếu bạn thuyết trình bằng bài do AI viết rồi bị đặt câu hỏi thì bạn sẽ trả lời thế nào?
    Đây chính là tình huống đó

    • Nếu nói từ góc nhìn bênh AI, vấn đề không phải AI mà là thái độ nộp thứ mình không hiểu
      Ném ra một PR 13k dòng mà không hiểu gì là sai, có hay không có AI cũng vậy
      AI chỉ là công cụ; dùng máy CNC hay dùng cưa thì điều quan trọng vẫn là hiểu kết quả mình tạo ra
    • Câu trả lời “AI quyết định vậy, tôi không hỏi” đã nói lên tất cả
    • Kiểu thái độ “Tôi không có tiền nên không trả lời được. Trả tiền thì tôi đi hỏi AI” thật khó tin
    • Thậm chí còn có câu đùa rằng giới chính trị gia xưa nay vẫn làm vậy
    • Cũng có câu kiểu “AI hiểu hoàn hảo câu hỏi của bạn. Hãy chứng minh nó sai đi”
  • Trong số các PR do AI tạo mà tôi từng thấy, đây là trường hợp độc đáo nhất
    Đa số là code hỏng do người mới viết, còn lần này thì phức tạp và thực sự chạy được
    Tác giả Joel Reymont là lập trình viên có 30 năm kinh nghiệm, có tài khoản HN từ năm 2008, đúng nghĩa kỳ cựu
    Sự kiên nhẫn của các maintainer OCaml thật đáng nể, và cuối cùng ông ấy đã chốt lại quan điểm bằng một bình luận rất con người,
    nói rằng sẽ thôi không đóng góp cho OSS bằng AI nữa
    Dù vậy, những PR kiểu này vẫn là sự lãng phí thời gian của tất cả mọi người,
    và đến giờ tôi chưa thấy trường hợp nào được dùng một cách hiệu quả, có ích

  • Đúng là một PR đáng kinh ngạc
    Link tới commit đó

    • Cũng có người đùa rằng ít nhất riêng phần thay đổi đó thì có lẽ không phải AI viết /s