5 điểm bởi GN⁺ 2026-03-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • Cách xử lý ticket Django bằng LLM không mang lại nhiều ích lợi, và sẽ hữu ích hơn nếu đem nguồn lực đó quyên góp trực tiếp cho Django Software Foundation
  • Django là một dự án có tiêu chuẩn chất lượng rất cao và coi trọng tính ổn định dài hạn, nên cần sự thấu hiểu sâu sắc vượt xa việc chỉ sinh mã
  • Nếu LLM tạo mã thay tác giả rồi còn xử lý cả phần mô tả PR và phản hồi review, sẽ phát sinh vấn đề khó đánh giá liệu người đóng góp có thực sự hiểu hay không
  • Đóng góp mã nguồn mở lấy giao tiếp giữa con người và hợp tác cộng đồng làm cốt lõi; nếu LLM che khuất điều đó, niềm tin với reviewer sẽ suy yếu
  • Để đóng góp cho Django, quá trình tự học và tự thử nghiệm để tích lũy hiểu biết là điều bắt buộc, và đây cũng là con đường dẫn tới sự trưởng thành của một lập trình viên

Giới hạn của việc đóng góp cho Django thông qua LLM

  • Việc dùng LLM để giải quyết ticket Django không thực sự giúp ích cho cộng đồng
    • Khi gửi PR bằng mã do LLM tạo ra và xử lý phản hồi theo cách đó, rất khó xác định mức độ hiểu biết của người viết
    • Từ góc nhìn của reviewer, điều này giống như đang trò chuyện không phải với một con người mà với “vỏ bọc của sự thấu hiểu giả tạo”
  • Django có tệp người dùng quy mô lớn, chu kỳ thay đổi chậm, và yêu cầu chất lượng của một dự án sẽ kéo dài hơn 20 năm
    • Vì những đặc tính đó, sự thấu hiểu sâu sắc và đóng góp có trách nhiệm quan trọng hơn việc sinh mã tự động đơn thuần

Cách sử dụng LLM đúng đắn

  • LLM nên được dùng như một công cụ hỗ trợ cho việc thấu hiểu
    • Cách làm phù hợp là tự viết phần giải thích bằng ngôn ngữ của mình trước, rồi dùng LLM để trau chuốt cách diễn đạt
    • Khi gặp khó khăn trong giao tiếp, có thể tích cực tận dụng LLM, nhưng phải nêu rõ việc đã sử dụng nó
  • Khi đóng góp cho Django, người đóng góp phải tự mình hiểu vấn đề, cách giải quyết và phản hồi review
    • Mã được tạo ra mà không có sự thấu hiểu có thể làm tổn hại chất lượng của toàn bộ dự án

Hợp tác mã nguồn mở lấy con người làm trung tâm

  • Đóng góp cho Django là một trải nghiệm mang tính cộng đồng, bao gồm cả sự minh bạch và tính dễ tổn thương của con người
    • Nếu LLM che lấp tính người này, việc cộng tác sẽ trở nên khó khăn
    • Reviewer có động lực khi được giao tiếp dựa trên “sự thấu hiểu thật sự của con người”
  • LLM chỉ nên được dùng như phương tiện hỗ trợ, và không được thay thế vai trò cốt lõi của người đóng góp

Bản chất và giá trị của việc đóng góp cho Django

  • Django là một dự án có 20 năm lịch sử và tầm nhìn dài hạn, nên mọi đoạn mã được thêm vào đều phải được hiểu một cách sâu sắc
    • Để có được sự thấu hiểu đó cần thời gian, thử nghiệm và học hỏi
  • Đóng góp cho Django không chỉ là việc có tên trong danh sách, mà là một trải nghiệm đem lại sự trưởng thành với tư cách lập trình viên
    • Việc học được trong quá trình đóng góp giá trị hơn rất nhiều so với chuyện tên bạn xuất hiện trong danh sách

Đề xuất dành cho cộng đồng

  • Không nên lạm dụng LLM để che giấu bản thân và sự thiếu hiểu biết của mình
    • Cộng đồng Django muốn hợp tác với những con người thực sự
  • Nếu muốn hỗ trợ Django, cách hiệu quả nhất là đầu tư thời gian và tiền bạc hoặc quyên góp cho Django Software Foundation

1 bình luận

 
GN⁺ 2026-03-18
Ý kiến trên Hacker News
  • Tôi cho rằng LLM có thể gây ra vấn đề trong bất kỳ codebase nào có người review
    Nếu dùng LLM mà không hiểu ticket, giải pháp hay phản hồi trong PR thì sẽ gây hại cho toàn bộ dự án
    Đóng góp mã nguồn mở là một hành vi mang tính cộng đồng, nhưng LLM lại che khuất sự minh bạch và tính dễ tổn thương của con người
    Ở góc độ reviewer, cảm giác như đang nói chuyện với một “chiếc mặt nạ” của con người nên đây là một trải nghiệm làm mất động lực
    Vì vậy LLM nên chỉ được dùng như công cụ hỗ trợ, chứ không nên trở thành phương tiện thay thế
    Gần đây ngay trong các team cũng thấy PR do AI viết tăng vọt, và cả Claude hay Codex cũng thay luôn việc trả lời feedback review
    Nếu văn hóa này bén rễ, có lẽ nó sẽ dẫn tới sự sụp đổ niềm tin và tinh thần sa sút trên toàn ngành

    • Tính năng tự động hoàn thành bằng AI của Jira đã biến hệ thống ticket thành thiên đường spam
      Thứ tăng lên không phải năng suất mà chỉ là “cảm giác như làm nhanh hơn”
      Trên thực tế, vì các tổ chức không đo năng suất một cách bài bản nên không ai biết hiệu ứng ròng của những tính năng này là gì
    • Trước đây người ta tin rằng PR được gửi lên với thiện chí, nhưng giờ thì phần lớn trông như do AI viết
      Việc sử dụng AI trên diện rộng đang bào mòn niềm tin
    • LLM đối với đóng góp mã nguồn mở giống như tác động của Photoshop lên Tinder
      Bề ngoài có thể đẹp hơn nhưng sự chân thật thì biến mất
    • Những PR dựa trên AI như vậy thực tế vẫn có khi vượt qua review và được merge code
      Rốt cuộc code vẫn được thông qua, nên tôi cũng tự hỏi liệu mọi người có thực sự không bất mãn hay không
  • Những đồng nghiệp giỏi nhất mà tôi từng làm việc cùng luôn khiến reviewer dễ phê bình
    Họ ghi rõ giả định, phần mình chưa biết và cả những lần thử sai, rồi giải thích sao cho reviewer dễ phản biện
    Nếu là PR cho thấy sự khiêm tốn và tự phản tỉnh như vậy thì dù có LLM tham gia tôi cũng không lo
    Vấn đề là những người trước đây còn gửi lên cả code không build nổi thì giờ lại dùng LLM để sản xuất thêm nhiều PR tệ hại
    Vì thế tôi không đồng ý với câu “code chạy được là được, ai viết không quan trọng”

  • Tình hình hiện giờ gần như vượt ngoài tầm kiểm soát
    Đặc biệt khi hoạt động GitHub trở thành tiêu chí đánh giá trong tuyển dụng, người ta bắt đầu dùng LLM để ngụy tạo lịch sử đóng góp
    Nếu PR được thông qua dù thực ra họ không hiểu dự án thì coi như xong

    • Tuy vậy, tôi nghĩ bài viết chưa giải thích đủ ‘vì sao’ hiện tượng này lại là vấn đề
      Một lập trình viên giỏi dùng LLM thì không phải vấn đề
      Vấn đề là những người vốn đã yếu nay nhờ LLM mà nộp được nhiều code chất lượng thấp hơn
    • Thực ra đây không phải vấn đề của AI mà là vấn đề của con người
      Trước đây cũng đã có những người copy-paste từ StackOverflow rồi nộp code mà chẳng hiểu gì
      AI chỉ đơn giản là khuếch đại điều đó thôi
    • Nếu tôi là người tuyển dụng, tôi sẽ nhìn vào tỷ lệ bị từ chối so với được chấp nhận của các PR
      Nếu ai đó rải PR tương tự khắp nhiều repo và phần lớn đều bị từ chối thì đó là dấu hiệu quá rõ
      Rốt cuộc chúng ta phải quay lại với văn hóa đóng góp coi trọng chất lượng hơn số lượng
    • Thay vì trách con người, cần thay đổi cấu trúc khuyến khích của hệ thống
      Nhận ra vấn đề thì dễ, nhưng tạo được đồng thuận và giải pháp thực chất thì khó, và dân kỹ thuật thường yếu ở phần đó
    • Nói đùa thôi, nhưng có vẻ sắp tới sẽ tràn ngập các startup reviewer AI
  • Tôi thích ý tưởng quyên góp tiền hơn
    Có vẻ những người đóng góp cốt lõi cho Django sẽ sử dụng nguồn tài trợ hiệu quả hơn là token
    Các dự án khác thì đã áp dụng những biện pháp như công khai việc dùng AI, tạm dừng nhận đóng góp từ bên ngoài, hoặc hạn chế việc tạo issue
    PR chất lượng thấp giờ được tạo ra quá dễ dàng, làm xâm phạm thời gian và sự tập trung của cộng đồng
    Vì vậy có lẽ cần chuyển sang mô hình cộng tác khép kín hơn
    Tôi cũng thấy ấn tượng với quyết định của Debian khi xử lý vấn đề này một cách thận trọng

    • Tôi từng viết một bài luận về chủ đề này
      Thay vì mua token, tôi nghĩ tốt hơn là cứ quyên góp tiền trực tiếp cho những người đóng góp cốt lõi và để họ tự quyết định cách sử dụng
  • Tôi rất đồng cảm với câu “việc reviewer phải nói chuyện với một chiếc mặt nạ con người là hao mòn tinh thần
    Một trong những phần thưởng của mã nguồn mở là sự giao lưu giữa con người với nhau, và khi điều đó biến mất thì mọi thứ chỉ còn như lao động đơn thuần
    Cuối cùng sự kiên nhẫn của tất cả mọi người đều giảm đi, và niềm vui hợp tác cũng biến mất

    • Trước đây trên Reddit cũng từng có những phản ứng kiểu “let me google that for you”, nhưng con người vẫn muốn tương tác mang tính con người
      Giống như trò chuyện với người bán thịt quen ở cửa hàng, ai cũng muốn xây dựng mối quan hệ
    • Trong học thuật cũng có những thảo luận tương tự
      Viết bài báo đã dễ hơn nhờ LLM, nhưng kiểm chứng và review vẫn khó và tốn thời gian
      Vì vậy cần có cách ghi rõ việc dùng AI, hoặc đánh dấu PR bằng thuật toán phát hiện AI
      Cuối cùng điều đó có thể buộc mọi người phải dịch câu trả lời của LLM sang ngôn ngữ của chính mình
    • Có thể đã quá muộn, nhưng giá mà GitHub cho phép thiết lập “có cho phép AI PR hay không” thì tốt biết mấy
      Tuy nhiên trên thực tế thì luôn có những người phớt lờ quy tắc
  • Dạo này mọi đổi mới đều vận hành theo hướng khiến người ta theo đuổi phần thưởng ngắn hạn
    Cấu trúc khuyến khích không ủng hộ những người có tầm nhìn dài hạn
    Chỉ cần nhìn qua lý thuyết trò chơi một lần là khó mà phủ nhận thế giới được thiết kế như vậy

    • Lạm phát tiền tệ của chính phủ đã khiến con người bám chặt vào lợi nhuận ngắn hạn để sinh tồn
    • Nhưng lý thuyết trò chơi không thể giải thích trọn vẹn những tương tác liên tục như trong đời sống
      Vì vậy nó có giới hạn khi dùng để đánh giá chiến lược dài hạn
  • Đây là một thông điệp hay, nhưng có lẽ những người làm mọi thứ bằng LLM sẽ còn chẳng đọc nổi những bài như thế này
    Với tư cách là người bảo trì mã nguồn mở, chính tôi cũng khó phân biệt được code có phải do AI viết hay không

    • Cách nói “những người làm mọi thứ bằng LLM” có phần cường điệu
      Trên thực tế gần như không có lập trình viên chuyên nghiệp nào như vậy
    • Việc phát hiện thông tin sai lệch hay ảo giác có thể là bước đầu để nhận diện những sản phẩm được tạo hoàn toàn bởi LLM
  • Tôi còn nghĩ hay là cứ tạo hẳn một dự án mã nguồn mở dành riêng cho LLM
    Kiểu gom lại toàn bộ code do LLM tạo ra và định nghĩa rõ giao thức đóng góp
    Tuy vậy, rất nhiều đóng góp từ LLM có lẽ chỉ nhằm làm đẹp portfolio

    • Thực tế OpenClaw là một dự án thử nghiệm kiểu như vậy
      Nó có hàng nghìn người đóng góp và hàng chục nghìn commit
    • Những dự án như vậy cũng có thể đóng vai trò honeypot cho code LLM chất lượng thấp
    • Nói đùa thôi, nhưng nếu là “Moltbook meets GitHub” thì biết đâu lại thành công ty kỳ lân
  • AI thường không thực sự nâng cao năng suất, mà chỉ đẩy gánh nặng kiểm chứng sang cho người khác
    Kết cục là maintainer phải gánh thêm việc, còn người đóng góp thì chỉ lấy công trạng

  • Tôi cũng từng dùng LLM để tạo patch cho các dự án như Django
    Nếu không có LLM thì có lẽ tôi thậm chí đã không thử
    Nhưng tôi vẫn tự review kết quả và cũng tự viết test

    • Vấn đề không phải là có dùng LLM hay không, mà là người đóng góp có hiểu nội dung hay không
      Dạo này từ code, phần mô tả PR cho đến phản hồi review đều do LLM làm thay
      Đến mức từ góc độ reviewer phải nghĩ rằng “hay là cứ để mình dùng LLM review luôn cho rồi?”
      Vì vậy LLM nên là công cụ hỗ trợ, chứ không phải phương tiện thay thế