Tôi Không Phải Là Một "Kentauro Ngược": Khi AI Đổ Bộ Vào Dự án Mã Nguồn Mở

Công nghệ12 tháng 6, 2026·8 phút đọc

Miguel Grinberg chia sẻ quan điểm về làn sóng các Pull Request được tạo bởi LLM trong các dự án mã nguồn mở của ông. Ông kiên quyết từ chối trở thành một "Kentauro ngược" – người dành thời gian để rà soát mã do máy tạo ra – và áp dụng các quy tắc khắt khe để đảm bảo sự tham gia thực sự của con người.

Tôi Không Phải Là Một "Kentauro Ngược": Khi AI Đổ Bộ Vào Dự án Mã Nguồn Mở

Tôi Không Phải Là Một "Kentauro Ngược": Khi AI Đổ Bộ Vào Dự án Mã Nguồn Mở

Khoảng một năm trước, tôi đã viết trên blog này về việc lập trình cùng các Mô hình Ngôn ngữ Lớn (LLM) sẽ không hiệu quả với tôi, ngay cả khi không có những lo ngại về đạo đức hay môi trường ngăn cản tôi sử dụng chúng. Tôi sẽ không lặp lại các lập luận đó vì quan điểm của tôi vẫn chưa thay đổi. Tuy nhiên, điều đã thay đổi là số lượng đóng góp tôi nhận được cho các dự án mã nguồn mở đã tăng lên, và gần như tất cả chúng hiện nay đều được tạo ra bởi LLM.

Miguel GrinbergMiguel Grinberg

Gánh nặng của "Kentauro ngược"

Hôm kia, tôi có một suy nghĩ rất chán nản về vấn đề này. Tất cả những người này gửi các Pull Request (PR) vội vã đến các dự án của tôi đang thúc đẩy tôi dành ngày càng nhiều thời gian để xem xét và hợp nhất mã được "thải ra" bởi các cỗ máy. Cory Doctorow gọi những người thực hiện chức năng này là "Kentauro ngược" (reverse centaurs). Ông gọi đây là "những con người yếu ớt và dễ bị tổn thương bị điều khiển bởi những cỗ máy vô cảm và tàn nhẫn". Thật đau đớn!

Liệu tôi có đang trở thành một Kentauro ngược không? Liệu mục đích mới của tôi với tư cách là một kỹ sư phần mềm dày dạn kinh nghiệm và nhà phát triển mã nguồn mở là dành cả ngày để xem xét mã của LLM, bất chấp việc tôi đã quyết định rằng mình không cần hay muốn công nghệ này này? Như bạn có thể đoán từ tiêu đề, tôi sẽ không bao giờ trở thành một Kentauro ngược. Hãy để tôi nói về cách tôi chống lại những lực lượng muốn biến tôi thành như vậy.

Từ niềm tự hào đến cờ đỏ

Ngày xưa, trước khi có LLM, việc nhận được một Pull Request bất ngờ từ một lập trình viên đồng nghiệp là nguồn niềm hào hứng và tự hào. Nó có nghĩa là một người ngẫu nhiên đã quyết định rằng việc đầu tư thời gian và công sức để cải thiện một dự án của tôi là đáng giá, và chia sẻ kết quả đó không chỉ với tôi mà với tất cả người dùng.

Ngày nay, một PR không được yêu cầu là một "cờ đỏ". Quá nhiều người lười biếng đưa ra lệnh cho công cụ tạo mã LLM và yêu cầu nó thay đổi hành vi của một trong các dự án mã nguồn mở của tôi để đáp ứng nhu cầu cụ thể của họ, mà không quan tâm hay cân nhắc đến những gì đang bị thay đổi hoặc nó có thể ảnh hưởng đến người dùng khác như thế nào. Đôi khi những thay đổi này có lý và cải thiện dự án, nhưng thường thì chúng không như vậy. Tuy nhiên, những người gửi lại ít khi quan tâm, họ chỉ dán một mô tả dài do LLM tạo ra và gửi PR qua, để lại cho tôi nhiệm vụ phải tìm ra xem thay đổi đó có hợp lý không hay chỉ là rác rưởi.

Buy Me a CoffeeBuy Me a Coffee

Chiến lược kháng cự

Tôi đã quyết định rằng tôi có những việc quan trọng hơn để làm với cuộc đời mình là dành cả ngày để xem xét mã được sản xuất bởi LLM. Nếu bạn muốn đóng góp cho một trong các dự án của tôi, tôi mong bạn là người đóng góp trực tiếp, và có sự quan tâm thực sự đến việc cải thiện dự án của tôi.

Hướng dẫn đóng góp mà tôi đưa vào trong tất cả các dự án mã nguồn mở của mình đều có những hướng dẫn này cho người đóng góp:

Nếu bạn quan tâm đến việc đóng góp một thay đổi cho dự án này, vui lòng trước tiên giới thiệu thay đổi bạn muốn thực hiện cho người bảo trì trong một vấn đề (issue). Các Pull request được gửi mà không có thảo luận trước trong một issue có thể bị đóng theo quyết định của người bảo trì.

Khi người bảo trì chấp nhận thay đổi được đề xuất của bạn và cho phép bạn làm việc với nó, hãy thoải mái gửi một pull request.

Với quy trình này, tôi có thể biết người đóng góp và đề xuất của họ trước khi có sự đầu tư thời gian lớn ở cả hai phía, vì vậy đó là lợi ích cho tất cả mọi người.

Mặc dù vậy, tôi vẫn nhận được các PR không được yêu cầu, vì vậy rõ ràng một số người dùng (hoặc có khả năng hơn là LLM của họ) không đọc hướng dẫn đóng góp. Nhiệm vụ ban đầu của tôi khi một PR bất ngờ mới đến là xác định xem có con người đằng sau nó hay không, và may mắn là điều này rất dễ dàng để tìm ra chỉ trong vài giây. Nếu tôi không thấy bằng chứng của sự tham gia của con người, thì tôi không quan tâm, vì vậy PR sẽ bị đóng ngay lập tức mà không cần đặt câu hỏi.

Bạn có thể lập luận rằng với thái độ này, tôi có thể bỏ lỡ những cải tiến hữu ích hoặc bản sửa lỗi cho các dự án của mình, và tôi đoán rằng điều đó là có thể. Tôi thực sự không có cách nào để biết mà không dành thời gian xem xét các PR không được yêu cầu này để tách cái tốt ra khỏi cái xấu. Khi tôi chắc chắn rằng mọi đóng góp đều có nỗ lực của một con người đằng sau nó, công việc xem xét này là chính đáng và tôi thậm chí còn thích nó. Trong thế giới đầy rẫy rác rưởi ngày nay, đây là công việc của Kentauro ngược và nó không dành cho tôi, vì vậy tôi chỉ chú ý đến những PR đến từ những người đóng góp nhiệt thành.

Lời khuyên cho cộng đồng

Lời khuyên của tôi nếu bạn chỉ có thể code với sự giúp đỡ của một LLM và cần các bản sửa lỗi hoặc cải tiến trong một dự án của tôi là đừng lãng phí token của bạn vào một PR, vì tôi sẽ bỏ qua nó. Thay vào đó, hãy mô tả vấn đề trong một issue, và để tôi xử lý công việc. Tôi không muốn một cuốn tiểu thuyết được tạo bởi LLM với các chương, gạch đầu dòng và biểu tượng cảm xúc, chỉ cần một mô tả đơn giản về vấn đề bằng giọng nói của chính bạn. Vì bạn sẽ tiết kiệm được một số token đắt tiền đó, bạn cũng có thể xem xét việc quyên góp, điều đó có khả năng thúc đẩy tôi ưu tiên vấn đề của bạn!

Đây là một câu hỏi mà tôi luôn tự hỏi bản thân, và tôi vẫn chưa có câu trả lời rõ ràng. Tôi vẫn viết rất nhiều code, cả cho công việc và vì niêu vui, nhưng trong vài năm gần đây tôi ít quan tâm hơn đến việc chia sẻ những thứ tôi tạo ra. Tôi vẫn còn đủ hứng thú để giữ cho các dự án mã nguồn mở hiện tại của mình được cập nhật, nhưng tôi có một loạt dự án gần đây mà tôi không thể tự mình làm cho chúng công khai.

React BookReact Book

Cảm nhận của tôi là có ít sự quan tâm hơn đến mã nguồn mở, và nói chung là lập trình. Lý do chính tôi thích lập trình là vì nó là một thử thách, và tôi nghĩ rằng thực tế đây cũng là lý do tại sao nhiều người thích đưa tiền cho một phòng thí nghiệm AI và để máy móc phun ra code cho họ, ngay cả khi có rủi ro code đó kém chất lượng.

Xu hướng này sẽ tiếp tục đến mức không ai còn viết code nữa và chỉ có máy móc làm việc đó không? Tôi hy vọng là không, nhưng chúng ta sẽ phải chờ xem. Tôi sẽ tiếp tục phản đối một tương lai trong đó tất cả chúng ta phải là những Kentauro ngược, với những cỗ máy (và các chủ tỷ phú của chúng) gọi các shots.

Cảm ơn bạn đã ghé thăm blog của tôi! Nếu bạn thích bài viết này, vui lòng xem xét việc hỗ trợ công việc của tôi và giữ cho tôi tỉnh táo với một khoản quyên góp nhỏ một lần qua Buy me a coffee. Cảm ơn bạn!

Nếu bạn muốn hỗ trợ loạt bài hướng dẫn React Mega-Tutorial của tôi trên blog này và làm phần thưởng có quyền truy cập vào hướng dẫn hoàn chỉnh ở định dạng sách và / hoặc video, bạn hiện có thể đặt hàng trực tiếp từ trang Courses của tôi hoặc từ Amazon.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗