Godot sẽ không còn nhận các đóng góp mã do AI viết

 (pcgamer.com)
2 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Công cụ game engine mã nguồn mở Godot quyết định cấm mã do AI viết và các bản gửi từ AI agent trong chính sách đóng góp, khi các Pull Request do AI tạo ra làm tăng gánh nặng rà soát
  • Các maintainer cho rằng việc xem xét PR do AI tạo ra khiến công việc review vốn đã tẻ nhạt trở nên tốn sức hơn, đồng thời cũng làm suy yếu hiệu quả nuôi dưỡng người đóng góp mới thành maintainer tương lai
  • Chính sách mới sẽ từ chối rõ ràng mã do AI viết, Pull Request do AI agent gửi, và văn bản do AI tạo ra trong giao tiếp giữa con người
  • Người đóng góp chỉ có thể dùng AI như công cụ hỗ trợ cho những “menial things” và phải công khai việc sử dụng; dịch máy dựa trên nguyên văn do con người viết vẫn được chấp nhận
  • Godot Foundation cho biết sẽ tạm thời vận hành theo hướng thận trọng vì các công cụ AI thay đổi quá nhanh, và sẽ đánh giá lại chính sách khi tình hình thay đổi

Thay đổi trong chính sách đóng góp của Godot

  • Sau nhiều tháng thảo luận, Godot Foundation và các maintainer đã quyết định sửa đổi hướng dẫn cho người đóng góp để hạn chế các bản gửi liên quan đến AI
  • Các đối tượng bị hạn chế gồm mã do AI viết, Pull Request do AI agent gửi, và văn bản do AI tạo ra trong giao tiếp giữa con người
  • Godot là game engine mã nguồn mở được sử dụng trong các trò chơi như Slay the Spire 2 và The Case of the Golden Idol

Gánh nặng bảo trì do AI Pull Request tạo ra

  • Các maintainer đã thảo luận từ tháng 2 về cách ứng phó với làn sóng AI slop Pull Request ngày càng tăng
  • Dòng PR này đã trở thành trạng thái “increasingly draining and demoralizing” đối với các reviewer của dự án
  • Godot Foundation cho rằng đây không phải vấn đề nhất thời, và muốn vừa giảm gánh nặng cho maintainer vừa duy trì con đường giúp người đóng góp mới phát triển thành maintainer tương lai

Vấn đề khi review không còn dẫn tới mentoring

  • Việc có nhiều PR đang chờ xem xét tự thân có thể được xem là dấu hiệu cho thấy sự quan tâm đến việc sử dụng và đóng góp cho Godot đang tăng lên
  • Tuy nhiên, khi các đóng góp do AI viết hoặc gửi ngày càng nhiều, động lực để các maintainer dành thời gian review PR đang suy giảm
  • Nếu phản hồi cho PR không còn giúp mentoring các maintainer tương lai tiềm năng mà lại “bị máy hấp thụ”, thì rất khó để biện minh cho việc dành thời gian rảnh vào công việc review

Các hạn chế cụ thể trong chính sách mới

  • Chính sách đóng góp của Godot sắp bổ sung nội dung từ chối rõ ràng AI-authored code
  • Người đóng góp chỉ được dùng hỗ trợ từ AI cho những “menial things” và phải công khai việc sử dụng
  • Foundation cho biết “AI không thể chịu trách nhiệm, và chúng tôi không thể tin rằng những người dùng AI nhiều hiểu mã của họ đủ để tự sửa nó”
  • Văn bản do AI tạo ra trong giao tiếp giữa con người cũng sẽ bị từ chối
    • Foundation mô tả điều này là “a basic principle of respect”
    • Dịch máy dựa trên văn bản gốc do con người viết vẫn tiếp tục được cho phép

Hướng vận hành của chính sách

  • Godot Foundation tập trung vào việc bổ sung rào cản đối với các đóng góp kiểu “slop” với ít nỗ lực
  • Việc giúp maintainer có thể tiếp tục review mã và giúp người đóng góp mới trưởng thành thành maintainer tương lai cũng là mục tiêu của chính sách
  • Mọi đóng góp đều phải đến từ con người có trách nhiệm với mã của mình và có thể tự sửa nếu có lỗi
  • Foundation cho biết hiện các công cụ AI thay đổi mỗi ngày, vì vậy sẽ duy trì chính sách thận trọng vào lúc này và đánh giá lại theo các thay đổi sau này

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Chính sách này là công bằng. Việc bị yêu cầu phải rà soát kỹ một bức tường văn bản do AI viết dài lê thê thật sự rất khó chịu, gần như là một cuộc tấn công từ chối dịch vụ vào tinh thần con người
    Tuy vậy, có lẽ nó cũng không ngăn được việc lập trình dựa trên AI. Theo hướng tiêu cực, người gửi có thể thêm các dấu hiệu văn phong để trông giống con người hơn, khiến phần cốt lõi và quy mô đóng góp vẫn y nguyên nhưng phong cách lại trở nên kỳ quặc
    Theo hướng tích cực, nó có thể dẫn đến các commit và bình luận gọn gàng kiểu “đây là đoạn mã, đây là lý do thay đổi, và đây là tác động”. Dù có do AI tạo ra thì những đóng góp nhỏ như vậy vẫn dễ kiểm chứng hơn nhiều, và cũng có thể hình thành chuẩn về quy mô đóng góp phù hợp hoặc những thay đổi cần review nghiêm ngặt hơn
    Cá nhân tôi thì nếu nội dung giống trường hợp sau, việc có phải do AI tạo ra hay không cũng không quá quan trọng

    • Theo kinh nghiệm review của tôi thì phần lớn người đóng góp không đọc chính sách, và đặc biệt những người tạo PR AI thật nhanh lại càng như vậy. Chính sách mới có lẽ cũng không thay đổi được điều này bao nhiêu
      Nếu thực sự nhận được các “commit và bình luận gọn gàng” thì đúng là như mơ
    • Vấn đề là nhiều đóng góp do AI tạo ra được làm một cách lười biếng mà không qua kiểm tra tử tế. Nếu đó là một đóng góp đã được xác minh độ chính xác, thử nghiệm xem có thật sự chạy không, kiểm tra tác dụng phụ, chỉnh lại độ dễ đọc, và tuân thủ hướng dẫn của dự án thì sẽ khó phân biệt với đóng góp hoàn toàn do con người làm ra, nhưng có quá nhiều người không bỏ công như vậy nên đa số không đạt được mức đó
    • Cụm từ “tấn công từ chối dịch vụ vào tinh thần con người” có thể là một ví dụ của thiết kế đối kháng có chủ ý. Muốn tóm tắt một lượng đầu ra khổng lồ thì rốt cuộc người dùng sẽ bị ép dùng công cụ dựa trên LLM
      Trong bối cảnh đó, việc đẩy lùi các đóng góp AI là hợp lý, và với phần mềm đã chứng minh được giá trị lớn như Godot thì lại càng như vậy
    • Nhân Linux kernel trước đây cũng từng có quy tắc tương tự, với dưới 200 dòng cho mỗi patch. Cũng có thể áp dụng các giới hạn như 400 ký tự/10 dòng cho mỗi git commit và mô tả pull request, tối đa 3 commit cho pull request ban đầu, 20 dòng cho phần mô tả pull request, và không quá 3 pull request mở cùng lúc
    • Nếu một commit do AI viết mà vẫn đọc như thể do con người viết, thì nhà phát triển đã làm đúng phần việc của mình và cũng chẳng có gì cần phải gắn nhãn
      Nếu commit do AI viết không khác gì về bản chất thì cũng không có lý do để từ chối, nên tôi nghĩ mục tiêu không phải là ngăn cấm việc lập trình dựa trên AI

  • Thật thú vị khi một bên thì định giá của các công ty AI đang dựa vào giả định rằng trong tương lai gần mọi đoạn mã và mọi sản phẩm số sẽ được AI viết ra, còn bên kia thì gần như mọi dự án mã nguồn mở phổ biến lại đang cố chặn các đóng góp AI. Hai điều này khó mà cùng tồn tại
    Cá nhân tôi cũng sau khi dùng rất nhiều trong các dự án mã nguồn mở của mình thì đang trải qua kiểu dư chấn AI. Trong lúc dùng thì có cảm giác mình có được sức mạnh ghê gớm, làm trong vài giờ những tính năng vốn phải mất vài tuần, nhưng sau một thời gian nhìn lại mã thì thấy những vết nứt tinh vi và sự thiếu nhất quán mà công cụ để lại, khá là khó xử
    Giờ tôi cố dùng nó ít hơn cho phát triển tính năng lớn, và thiên về những chỗ có thể đặt hàng rào kiểm soát nghiêm ngặt hơn như lập kế hoạch, gỡ lỗi, hoặc refactor phạm vi hẹp. Dù vậy công việc vẫn nhanh hơn, nhưng gần với mức 1,5 đến 3 lần chứ không phải 10 lần
    Mức độ tập trung tinh thần cần cho việc viết code giảm đi, nhưng lại sinh ra một kiểu mệt mỏi mới khi cứ phải trò chuyện với máy và không biết chỉ dẫn ngôn ngữ tự nhiên sẽ bị diễn giải ra sao. Nó giống như đang vận hành một cỗ máy liên tục thay đổi dây nối bên trong bằng tổ hợp nút bấm, nên không thấy thỏa mãn

    • Theo truyền thống, đóng góp mã nguồn mở là thứ mang tính tự chọn lọc. Muốn tạo PR thì phải có chút quan tâm đến dự án, và để có đóng góp có giá trị thì cần hiểu codebase, hiểu tập quán, và ít nhiều phải tương tác với dự án
      Điều mà AI làm được là cho phép những người hoàn toàn không gắn bó với dự án cũng có thể tạo đóng góp. Giờ đây, chỉ riêng việc ai đó tạo PR không còn đủ để vượt qua ngưỡng “người này có mức độ quan tâm nào đó đến thành công của dự án” nữa
      Nếu dùng đúng thì AI là bộ khuếch đại, nhưng từ góc nhìn của maintainer mã nguồn mở, họ rất dễ bị nhấn chìm trong lượng lớn “đóng góp” giá trị thấp do những người chẳng hề quan tâm đến dự án đổ vào
    • Phép so sánh với ma túy khá phù hợp. Ban đầu là cảm giác “mình có năng lực siêu phàm”, sau đó là cơn dư chấn kiểu “à, hóa ra mình vừa tạo ra một mớ hỗn độn”
      Đặc biệt do xu hướng nịnh nọt của AI nên nó cứ liên tục nói “ý tưởng hay đấy!”, trong khi tôi thừa biết phần lớn ý tưởng của mình chẳng có gì ghê gớm
      Khi thấy những câu chuyện kiểu vừa trông con vừa vibe coding trên điện thoại, nó thậm chí gần như nghe giống một dạng cưỡng bức
    • Từ lâu, di chuyển nhanh là một hào lũy lớn, nhưng giờ thì di chuyển nhanh đã trở nên dễ dàng. Hào lũy mới có thể là chất lượng
      Ngay từ đầu, việc nhanh trong mã nguồn mở vốn cũng chẳng có nhiều ý nghĩa, và điều đó có lý do của nó
    • Tôi cũng đã chuyển khá nhiều sang góc nhìn này. Công cụ AI thế hệ hiện tại vẫn có vẻ còn rất thiếu nếu thực sự muốn dùng sản phẩm đầu ra của nó
      Cấu trúc dopamine khiến người ta quá dễ với tay đến AI mỗi khi làm việc hay bắt đầu dự án mới cũng là một vấn đề
      Hiện tôi đang cố tái huấn luyện bộ não của mình để quay lại ưu tiên tự viết phần lớn mã thay vì mở Claude trước. Đây chỉ là giai đoạn tạm thời hay sau này sẽ cần kiểu hội nhóm ẩn danh dành cho người nghiện LLM thì thời gian sẽ trả lời
    • Giả định rằng mọi đoạn mã và mọi sản phẩm số rồi sẽ sớm do AI viết ra là câu chuyện mà các công ty AI muốn người ta tin để bán xẻng. Khi nhận ra giả định đó là ảo tưởng thì việc hai điều này không tương thích cũng chẳng còn lạ nữa

  • Có những danh sách tập hợp phần mềm không có AI. Sẽ hay nếu có thể lập chỉ mục hay vẽ biểu đồ xem chúng thay đổi ra sao theo thời gian
    https://codeberg.org/brib/slopfree-software-index
    https://noai.starlightnet.work/list.html

    • Tôi đã làm một bộ lọc chỉ hiển thị các kho GitHub được đăng trên Hacker News mà không có dấu vết do AI viết
      https://hcker.news/?ai=exclude&include_domains=github.com
    • Một thử nghiệm thú vị. Tôi tò mò vì sao điều đó lại trở thành tiêu chí cho những danh sách như thế
      Xét về mặt chức năng thì tôi không nghĩ ra nhiều lý do cho chính sách no-AI. Ai làm hay cái gì làm thì nếu chạy được vẫn là chạy được
      Dù có tránh được rác do AI tạo ra thì cũng không thể tránh được rác do con người tạo ra hoặc con người+AI tạo ra mà vẫn lọt qua bộ lọc
      Dù vậy, tôi hoàn toàn có thể nghĩ ra các lý do phi chức năng như nguồn gốc, tính chịu trách nhiệm, bằng chứng lao động, khuyến khích con người trực tiếp viết mã, hay theo dõi một cách thực chứng cách con người phát triển codebase

  • Điều cốt lõi nằm ở nhận định của Foundation: “Nếu phản hồi cho PR không còn được dùng để cố vấn cho một người có thể trở thành maintainer trong tương lai, mà chỉ bị máy móc hấp thụ, thì sẽ khó biện minh hơn rất nhiều cho việc dùng thời gian rảnh để review PR”

    • contributor poker của Zig ngày càng nghe như một ý tưởng nhìn xa trông rộng
    • Điều tệ hơn là phản hồi đó có lẽ còn bị đưa vào đợt huấn luyện LLM tiếp theo. Rốt cuộc nó lại trở thành một dạng lao động miễn phí khác cho các công ty AI

  • Nếu chưa hiểu thì cứ xem mấy cái này
    https://github.com/godotengine/godot/pull/115280
    https://github.com/godotengine/godot/pull/116410
    Với một dự án vốn đã khổ sở vì quá nhiều PR cần review ngay cả trước thời AI, thì bắt maintainer tiếp tục xử lý thêm những thứ như thế này là không công bằng
    Vì vậy, thay đổi chính sách thực sự lớn là phần không còn cho phép người đóng góp mới đảm nhận các tính năng lớn hay các đợt refactor

    • Ví dụ đầu tiên không chỉ mang tính AI-driven, mà người đó còn rất nhỏ tuổi
      Chỉ từ thông tin còn lại trong repository cũng có thể lần ra biệt danh và tài khoản mạng xã hội, và đó vẫn là một đứa trẻ thậm chí còn chưa tới tuổi teen. Có vẻ em ấy vẫn chưa có kiến thức nền tảng để hiểu vấn đề hay cấu trúc xã hội liên quan
    • “Đóng góp này là một phần của dự án môn học ở đại học yêu cầu phải có đóng góp open source thực tế” — trường đại học đó thật sự rất ngớ ngẩn. Có cách nào biết trường nào đang khiến sinh viên đi spam các dự án open source không
    • Thật sự rất kỳ lạ. Động cơ thực sự của người đóng góp đó là gì nhỉ

  • Đây đúng là một ví dụ cho định luật Brandolini hoạt động nguyên vẹn
    Bác bỏ điều nhảm nhí tốn công hơn gấp 10 lần so với việc tạo ra nó. Review code là một hình thức bác bỏ, và việc kiểm chứng tính đúng đắn của một mệnh đề cũng vậy
    Tạo ra mệnh đề thì dễ, nhưng để bác bỏ thì phải chứng minh đúng sai hoặc tìm ra mâu thuẫn. Năng lượng của các maintainer open source vốn đã thiếu thời gian đang bị tiêu hao một cách không cần thiết, nên tôi hoàn toàn đồng ý với việc tiết kiệm năng lượng để dùng vào chỗ hiệu quả hơn

  • AI đã vô tình phát hiện ra một trong những tài nguyên đắt giá nhất của ngành. Đó chính là thời gian rảnh của những người tối về còn đi maintain open source sau khi đã làm xong công việc chính

  • Foundation đã chỉ ra điều vốn luôn là sự thật, chỉ là AI khiến nó lộ rõ hơn. Dù là AI hay bất kỳ người đóng góp nào, đều có khả năng sau này không thể tự bảo trì patch mà họ gửi lên
    Điểm mấu chốt không phải bản thân việc dùng AI, mà là đó là một trong các dấu hiệu cho thấy người gửi không hiểu mình đang nộp cái gì. Việc phá vỡ quy ước đặt tên biến, thay đổi API không nên đụng vào, hay mắc các lỗi ngôn ngữ non tay — tất cả đều có thể là lý do để từ chối patch ngay cả khi nó chạy được
    Một cách lách là đánh dấu từ chối PR vì AI, rồi yêu cầu tác giả chỉ ra một phần mà họ đặc biệt tự hào và giải thích bằng lời của chính họ, chứ không phải bằng một bức tường văn bản AI, rằng họ đã làm gì và vì sao nó tốt. Tác giả phải thể hiện được gu và quan điểm mà AI không có

    • AI của năm 2026 có thể bịa ra văn bản trông như có quan điểm một cách khá thuyết phục. Cách này sẽ không giúp phân biệt AI và tác giả là con người

  • Có cảm giác ở đây nhiều người đang phản ứng với tiêu đề hơn là đọc chính sách thực tế. Trong chính sách có nói lý do quan trọng là họ dùng việc review PR để đào tạo người đóng góp mới và tìm ra các maintainer tiềm năng trong tương lai
    Bất kể chất lượng đóng góp AI ra sao, điểm này có vẻ rất khó phản bác
    Trừ khi bạn tin rằng AI sẽ khiến toàn bộ khái niệm đóng góp hay bảo trì open source trở nên không cần thiết; nhưng nếu vậy thì có lẽ hợp lý hơn là fork Godot rồi để các agent làm việc trên đó, thay vì gửi PR lên Godot

  • Các AI contributor có thật sự nghĩ rằng họ đang giúp ích không. Họ không nhận ra rằng kiểu “công việc” đó đang phá hỏng dự án sao
    Tôi không hiểu vì sao lại tốn tiền cho thứ chẳng ai muốn và sẽ bị từ chối. Là họ không có sở thích gì khác, hay là những instance OpenClaw được tạo ra rồi bị bỏ quên đang tự do lang thang và hành động theo ý mình

    • Thời mà đóng góp FOSS chỉ thuần túy xuất phát từ việc giải quyết vấn đề cá nhân, lòng vị tha hay sự tò mò đã qua rồi. Đã hơn 10 năm kể từ khi các công ty bắt đầu xem trang GitHub của ứng viên khi tuyển dụng
      Những người này đang thu hoạch đóng góp vào các dự án FOSS lớn như một cách đánh bóng CV. Điều tương tự cũng xảy ra với việc báo cáo lỗ hổng
      Những người tạo hàng loạt có thể thật sự nghĩ rằng mình đang giúp, hoặc cũng có thể biết rằng “đóng góp” của mình gây lỗ ròng cho dự án. Nhưng khi có động lực kinh tế trực tiếp và hoàn cảnh bấp bênh, thì các ngoại tác sẽ bị đẩy xuống ưu tiên thấp hơn
    • Ngay cả trong nhóm “AI contributor” cũng có nhiều mức độ. Gần đây tôi phát hiện một case biên hiếm trong một công cụ open source viết bằng Rust, mà vì tôi không quen ngôn ngữ này nên để tạo ra một thay đổi nhỏ gọn gàng và đúng chất Rust có lẽ phải mất hơn một tuần
      Claude làm xong trong 1 giờ, còn tôi chỉnh lại 3–4 lần để bớt tường chữ và khớp với phong cách của dự án gốc. Phương án còn lại chỉ là bỏ mặc nó hoặc mở issue rồi đẩy gánh nặng cho maintainer
      Vì vậy tôi nghĩ mình đã giúp được. Case biên này cũng là thứ tôi phát hiện khi vọc homelab như một thú vui
    • Tôi đã thử đóng góp bằng AI. Brew và far2 đã nhận phần việc của tôi, còn maintainer của KDE spectacle thì không trả lời
      Cả hai PR đều nhỏ và không khác gì PR do người viết. Tôi vẫn tin đó là những bổ sung có giá trị, và rõ ràng một số maintainer cũng nghĩ vậy
    • Nó phần nào giống với việc dùng AI trong nghệ thuật. Không phải là người ta muốn tạo ra, mà họ muốn có trạng thái “đã làm” và có được địa vị xã hội mà họ tin đi kèm với nó
      Họ không muốn code hay làm sản phẩm tốt hơn, mà muốn có “số dòng code”, “commit”, và một trang GitHub xanh đẹp dù không hiểu chi tiết