Cấm mã do LLM tạo trong các dependency

• git-annex đã dành khoảng 100 giờ trong tháng qua để kiểm tra nhằm bảo đảm có thể build mà không cần dependency chứa mã do LLM tạo
• Công việc này cho thấy thực tế là phải liên tục theo dõi toàn bộ cây dependency, chứ không chỉ từng đoạn mã riêng lẻ, qua đó làm tăng đáng kể gánh nặng bảo trì
• Trong quá trình kiểm tra, đã phát hiện các trường hợp như việc hoàn tác không kèm giải thích đối với những thay đổi lớn do LLM tạo, thay đổi 10.000 dòng trong codebase 26.000 LOC, và một commit message dài 1.489 dòng nhưng thiếu nhất quán
• Việc thu thập thêm thông tin về chất lượng của các dependency là điểm tích cực, nhưng vẫn còn góc nhìn hoài nghi về phản ứng ở cấp tổ chức như Software Freedom Conservancy hay FSF
• Dù LLM có thể giúp dễ dàng thêm cấu hình hoặc thay đổi định dạng, những commit như vậy có thể tạo ra chi phí trực tiếp đối với niềm tin khi cộng tác và sự tham gia vào dự án

---

Kiểm tra dependency của git-annex

• git-annex đã dành khoảng một tháng, tương đương khoảng 100 giờ, để kiểm tra nhằm bảo đảm có thể build mà không cần các dependency chứa mã do LLM tạo
• Cho đến nay, có vẻ mục tiêu này đã đạt được
• Có trang liên quan là git-annex no LLM code
• Cốt lõi của vấn đề nằm ở gánh nặng phải liên tục xem xét toàn bộ cây dependency của chương trình

Các trường hợp và tác động được phát hiện trong quá trình kiểm tra

• Những trường hợp được xác nhận không chỉ là vấn đề sở thích đơn thuần, mà dẫn đến vấn đề về bảo trì và niềm tin
  • Một thay đổi do LLM tạo có quy mô lớn bị hoàn tác trong bản phát hành tiếp theo mà không có bất kỳ lời giải thích nào
  • Có thay đổi 10.000 dòng được đưa vào một codebase 26.000 LOC, còn commit message là nội dung dài 1.489 dòng nhưng thiếu nhất quán
  • Có một prompt LLM yêu cầu sao chép mã từ dự án khác, và có vẻ may mắn là đã tránh được vi phạm bản quyền
• Công việc lần này đã mang lại thêm thông tin về chất lượng của các dependency, và thông tin này có thể ảnh hưởng đến các lựa chọn trong tương lai
• Software Freedom Conservancy dường như đã bỏ qua vấn đề này trong khuyến nghị về AI tạo sinh dựa trên LLM, và cũng chưa chắc FSF sẽ làm tốt hơn
• Trong bối cảnh những thay đổi này, việc tham gia các cộng đồng liên quan đang được cân nhắc lại, nhưng công việc và hỗ trợ người dùng vẫn tiếp tục
• Việc đưa cho LLM các prompt như Add fourmolu config and restyled, neat, format a module rồi commit kết quả có thể trông dễ dàng, nhưng cần cân nhắc tác động trên diện rộng của hành động đó

[GN⁺]

Các ý kiến trên Lobste.rs

• Hôm nay tôi mới biết git-annex được viết bằng Haskell, hay thật

  Hôm nay trên tàu điện ngầm về nhà, người ngồi cạnh tôi xem YouTube Shorts với âm lượng tối đa; trong một toa tàu yên tĩnh và chật kín thì đó là ô nhiễm tiếng ồn, rất khó chịu
  Điều còn khó chịu hơn là video anh ta xem hoàn toàn là video chất lượng thấp do AI tạo ra

  Giai thoại trong bài này về việc tác giả của các dependency tạo ra những thay đổi khó hiểu bằng LLM khiến tôi thấy rất đồng cảm
  Phần gây bực bội nhất trong việc lạm dụng LLM là nó phá hỏng tương tác giữa con người với nhau
  Trước đây, dù phải review một đề xuất được nghĩ chưa chín trong công ty, ý tưởng cốt lõi vẫn lộ rõ nên dễ chỉ ra và góp ý; còn giờ thì ai cũng có thể đưa một thay đổi sơ sài vào LLM để biến nó thành một kết quả trông có vẻ được tổ chức tốt, nhưng khi review thì đầy lỗ hổng
  Tương tự, nó cũng có thể tạo ra mã xấu nhưng nhìn bề ngoài có vẻ tốt

  Đây không phải lời phàn nàn mới, nhưng nó ngày càng bắt đầu khiến tôi khó chịu
  Tôi có cảm giác chúng ta đang mất đi một phần cốt lõi của sự kết nối giữa con người vốn làm cho công việc và cuộc sống trở nên vui vẻ, trọn vẹn

  • Tôi thích việc đồng nghiệp thành thật nói “cái này do 🤖 làm”, vì nhờ vậy tôi biết trước nên kỳ vọng mức review nào
    Thường thì đó là tài liệu về quá trình họ dùng để học thêm về codebase, nên tôi có thể tin rằng đồng nghiệp đã đọc đầu ra của LLM và muốn được xác nhận rằng họ đã học đúng

  • Tôi cho rằng thứ LLM đã thay đổi là giá tương đối của chất lượng
    Ví như nhà cửa: trước đây một căn McMansion tệ hại, dột mái và nền móng kém có giá 1000X, còn một căn nhà tốt không có rắc rối ẩn giấu có giá 2000X

    Giờ đây, về lý thuyết, công nghệ LLM có thể giúp người lành nghề giao bớt một số việc máy móc và dễ kiểm chứng, hạ giá căn nhà tốt xuống 1500X
    Nhưng căn McMansion tệ hại thì đã rơi xuống 100X

    Vì vậy rất có khả năng các McMansion chất lượng thấp sẽ đẩy bật công việc chất lượng cao theo một cách xấu xí
    Tôi không có ý làm khó những người thợ thủ công hạ giá căn nhà tốt từ 2000X xuống 1500X, nhưng nếu những căn nhà thô kệch giá 100X đẩy những thứ tốt hơn ra khỏi thị trường và tạo ra thị trường chanh, khách hàng có thể trở nên nghi ngờ phần mềm nói chung nhiều hơn nhiều
    Thị trường chanh rất xấu xí ở chỗ người mua không có cách nào phân biệt chất lượng với rác rưởi
    Ví dụ nổi tiếng nhất trong phần mềm là cuộc sụp đổ trò chơi điện tử năm 1983, khi rất nhiều khách hàng bị một làn sóng game rác khổng lồ làm cho thất vọng và ngừng mua

• Tôi thấy lập trường này hoàn toàn hợp lý
  Cá nhân tôi nghĩ theo thời gian phần lớn việc này sẽ trở thành công dã tràng, và trong việc dùng phần mềm của mình thì tôi không quá bận tâm, nhưng xét từ góc nhìn chủ quan, nó hoàn toàn chính đáng và thú vị, và tôi thấy việc người này làm vậy là tốt

  Cũng như những người lạc quan về AI hay thổi phồng, phía chống AI cũng có xu hướng nói quá kịch tính về các mặt tiêu cực
  Bản thân bài này khá gần với một ngoại lệ, nhưng nếu bỏ phần khái quát vội vàng ở đoạn cuối thì toàn bộ ý định và thông điệp có lẽ đã mạnh hơn nhiều

  Dù vậy, tôi thích đọc những bài như thế này và tìm ra phần thú vị trong cảm xúc của chúng
  Sẽ thú vị nếu có một cơ sở dữ liệu về mã 100% không phải LLM được biết đến cuối cùng cho từng dự án
  Một cơ sở dữ liệu về slop có ảnh hưởng cũng sẽ thú vị; ở đây điều quan trọng là “có ảnh hưởng” theo cả nghĩa tích cực lẫn tiêu cực, còn “slop” nghĩa là đầu ra chưa được review

  Có thể giả vờ bằng cách đại khái lấy kho lưu trữ GitHub vào đầu năm 2023, nhưng nếu đó là snapshot của commit cuối cùng theo từng dự án chứ không phải một snapshot tại một thời điểm cụ thể đơn giản thì sẽ thú vị hơn
  Có vẻ sẽ có nhiều kết quả thú vị từ bộ dữ liệu này, và nó cũng hữu ích cho những người như trong bài này muốn xây dựng một hệ sinh thái chỉ bằng phần mềm không phải LLM

  Chắc bạn cũng đoán được, tôi là người dùng LLM
  Dù vậy tôi nghĩ mình thuộc phía hợp lý
  Nếu tò mò thì bạn có thể đọc bài trên website của tôi, nhưng tôi cam kết phần nội dung bài blog được con người viết 100%
  Tôi nghĩ đọc các ý kiến trái chiều là một trong những cách tốt nhất để học hỏi và trưởng thành, nên tôi thích tham gia những nỗ lực kiểu này

  • Có một dự án khá gần với việc theo dõi phiên bản không phải LLM cuối cùng theo từng dự án
    Đó là https://codeberg.org/ethical-foss/open-slopware do những người có xu hướng chống AI nhiệt thành vận hành
    Một số dự án có “phiên bản hoặc commit ID chưa bị nhiễm cuối cùng”, nhưng không bao phủ mọi dự án

• Lý do tôi gửi bài này là vì tôi thích việc tác giả tự mình tìm các commit cụ thể gợi ý việc dùng LLM trong dependency, rồi lập một trang tổng hợp những gì tìm được

  Cá nhân tôi không chắc có nên gắn tag vibecoding hay không, vì bài này nói về cộng đồng và thông lệ hơn là về vibe coding

• Có đoạn nói rằng “tôi biết có thể ở thời điểm này mình đang cố ngăn một làn sóng đang ập tới”

  Nếu compiler mà dự án phụ thuộc vào bị ảnh hưởng thì không thể thắng được
  Tôi cũng đang kiểm soát thiệt hại, nhưng cuối cùng sẽ đến lúc phía cứ khăng khăng dùng phương án thay thế còn tệ hơn, nên buộc phải nhượng bộ

• Đây là một vấn đề khó
  Dù phân tích kỹ đến đâu, rất có khả năng khó tránh được mã LLM
  Ví dụ, mã được đưa vào qua tự động hoàn thành code sẽ không bị phát hiện

• Tôi cho rằng thời điểm niềm tin bị phá vỡ không phải là khi các thư viện này bắt đầu dùng LLM, mà là khi họ chấp nhận và tích hợp những thay đổi khổng lồ kèm theo các commit message khó đọc và vô dụng

  Đây là thất bại về kỹ nghệ phần mềm độc lập với việc có dùng LLM hay không

  Nói thêm, tôi thích Joey Hess và phần mềm của ông ấy, và tôi nghiêng về phía cho rằng đóng góp mã nên được đánh giá dựa trên ưu điểm của kết quả, bất kể nó được tạo ra bằng công cụ nào

• Cách giải thích hơi đáng thất vọng
  Commit persistent có vẻ không phải do LLM viết
  Tôi mong mọi người đừng nói mọi commit có “Co-authored-by” đều là do LLM tạo ra

  Link yesod đầu tiên là thay đổi CI, nên tôi nghĩ khó coi đó là mã mà ta phụ thuộc vào
  Nghe nói đó là “commit do LLM tạo với commit message dài 1489 dòng” nên tôi tưởng bản thân commit sẽ điên rồ lắm, nhưng thực tế đó là một lần squash merge hợp lý, chỉ là diff cực lớn mà thôi

  Commit cabal nói rằng LLM chỉ tạo test, và tôi cũng nghi ngờ liệu có nên coi đó là mã mà mình phụ thuộc vào hay không
  Commit git cũng chỉ là CI

  Tôi không nghi ngờ rằng một số dependency này có dùng LLM, nhưng khó có thể nói các bằng chứng được đưa ra là đủ vững
  Ngược lại, đây là công việc tốn nhiều công sức hơn tôi kỳ vọng rất nhiều, và việc có những thứ cụ thể để chỉ ra làm lý do không dùng dependency nào đó là điều tốt