Tại sao tôi không còn muốn nhận Pull Request (PR) của bạn nữa?

21 tháng 4, 2026·6 phút đọc

Tác giả chia sẻ quan điểm về việc thay đổi cách thức đóng góp vào dự án phần mềm mã nguồn mở trong kỷ nguyên AI. Với sự hỗ trợ của LLM, việc viết mã không còn là nút thắt, khiến việc duyệt PR từ người lạ trở nên kém hiệu quả hơn so với việc tự triển khai. Thay vì gửi code, cộng đồng có thể hỗ trợ tốt hơn thông qua phản hồi, báo lỗi hoặc chia sẻ ý tưởng.

Tôi thực sự trân trọng khi bạn đang thích phần mềm mà tôi bảo trì và muốn giúp đỡ. Nhưng chúng ta cần suy nghĩ lại về sự hợp tác này, bởi vì tôi cảm thấy chúng ta đang ngày càng lãng phí thời gian của nhau.

Tại sao tôi không muốn hợp nhất PR của bạn

Vì tôi không thực sự biết bạn, tôi luôn phải giả định rằng bạn có thể đang cố gắng lén lút đưa vào một thứ gì đó độc hại cùng với các thay đổi của mình. Điều này khiến việc xem xét và hợp nhất chúng trở nên rủi ro hơn so với việc tôi tự triển khai chúng.

Bên cạnh đó, mã nguồn có rất nhiều khía cạnh mang tính cá nhân và chủ quan. Bạn có thể có những sở thích nhất định về định dạng, phong cách, cấu trúc, các thư viện phụ thuộc và cách tiếp cận, còn tôi có cách của riêng tôi. Sau đó, chúng ta thường cần đồng bộ hóa về mặt xem xét, chạy CI, giải quyết xung đột khi gộp (merge conflicts), v.v. Và rồi là quá trình qua lại liên tục giữa người đóng góp và người bảo trì, điều này chỉ làm chậm mọi thứ.

Ngay cả trước khi có LLM, việc viết mã không phải là nút thắt cổ chai chính của tôi. Tuy nhiên, viết mã tốn thời gian, nên một PR vững chắc, hoạt động tốt và dễ xem xét thường đáng giá với rủi ro và sự bất tiện nhỏ đi kèm.

Nhưng khi LLM trở nên khá giỏi trong việc triển khai các tính năng, sự đánh đổi đó hầu như không còn đúng nữa. Mặc dù tôi vẫn cần xem xét mã do LLM tạo ra, nhưng nói chung tôi không phải lo lắng về việc nó độc hại như cách mà mã của một người đóng góp không rõ lai lịch có thể mang lại. Tôi đã đưa nhiều sở thích và hướng dẫn phong cách lập trình của mình vào LLM. Và tôi có thể lặp lại nhanh chóng theo tốc độ của riêng mình mà không cần phải đồng bộ hóa với con người khác có thể đang ở múi giờ khác.

Vì những lý do này, việc tôi tự thực hiện các thay đổi mã (với sự trợ giúp của LLM) sẽ dễ dàng hơn nhiều.

Bản chất của phát triển phần mềm đã thay đổi

Ngày càng rõ ràng rằng "mã nguồn" bây giờ ít mang tính "nguồn" (source) hơn và mang tính "mã" (code) hơn — một lớp được hình thức hóa ở giữa nằm giữa các ý tưởng trong đầu nhà phát triển và hướng dẫn để máy tính thực thi. Nó luôn luôn như vậy, nhưng bây giờ, với việc mã nguồn dễ dàng được tạo ra tự động hơn, điều này chỉ trở nên rõ rệt hơn.

Có rất nhiều phản ứng khác nhau về các tác nhân lập trình (coding agents) hiện nay, từ việc cấm đoán đến việc tuyên bố rằng lập trình đã chết và "vibecoding" là tương lai. Cá nhân tôi, với tình hình hiện tại, tôi đứng ở somewhere ở giữa. Tôi đưa ra thiết kế, sau đó để tác nhân của mình thực hiện phần viết thực tế, và sau đó tôi xem xét và tinh chỉnh kết quả.

Tôi có thể tạo ra một lượng lớn mã, nhưng tôi bị kẹt ở:

  • Hiểu — đọc mã hiện có để có thể suy luận về nó;
  • Thiết kế — đưa ra các thay đổi và kiến trúc phù hợp;
  • Xem xét — đảm bảo rằng mã đang làm những gì tôi muốn.

Mã trong PR của bạn không giúp tôi nhiều ở bất kỳ điều nào trong số này. Vì vậy, hãy bỏ qua việc đó — đừng cố gắng triển khai các thay đổi mã với mục tiêu hợp nhất chúng vào cơ sở mã.

Bạn có thể giúp đỡ như thế nào thay vào đó

Khi phần "viết mã" trở nên ít giá trị hơn, tất cả các cách khác giúp người bảo trì trở nên có giá trị tương đối cao hơn.

Đưa ra phản hồi

Khi tôi bận rộn triển khai các tính năng, tôi thường không có nhiều thời gian để thực sự sử dụng chúng, hoặc nghiên cứu kỹ lưỡng cách cải thiện chúng. Người dùng cho tôi biết điều gì hoạt động tốt và điều gì có thể được cải thiện sẽ rất hữu ích.

Thảo luận ý tưởng

Tôi không biết mọi thứ, và việc thảo luận với những người có kinh nghiệm và góc nhìn khác nhau có thể giúp tôi hiểu tôi nên xây dựng cái gì và như thế nào.

Báo cáo và điều tra lỗi

Một báo cáo lỗi tốt là 3/4 việc sửa lỗi đó. Nếu bạn phát hiện ra vấn đề, hãy mô tả nó tốt, và thậm chí thực hiện việc gỡ lỗi để tìm ra cách tái hiện nó và chính xác vấn đề nằm ở đâu. Sau đó thảo luận các giải pháp tiềm năng.

Tạo mẫu thay đổi

Hãy gửi cho tôi một PR tham khảo và/hoặc câu lệnh (prompt) bạn đã sử dụng để tạo ra nó. Có, tôi biết tôi vừa nói tôi không muốn PR của bạn. Vì vậy, hãy để tôi giải thích. Với LLM, việc để LLM của riêng tôi thực hiện thay đổi và sau đó tự xem xét nó trở nên dễ dàng hơn.

TUYÊN NHIỆM — việc sử dụng mã cho mục đích minh họa vẫn có ý nghĩa. Một cái nhìn nhanh về mã triển khai một cái gì đó có thể hữu ích, ngay cả khi tôi không kết thúc việc hợp nhất nó. Và nếu bạn chia sẻ "nguồn" thực sự (prompt) để tạo ra "mã" đó, tôi có thể tái sử dụng và tinh chỉnh nó, tiết kiệm thời gian.

Review code và chỉ ra vấn đề

Vì tôi đang bị kẹt ở khâu xem xét, một cặp mắt thêm sẽ rất giúp đỡ.

Fork code và báo cáo lại

Đừng ngại fork mã và thay đổi nó theo cách bạn muốn. Việc phải đưa ra các thiết kế hỗ trợ nhiều trường hợp sử dụng, hình thành sự đồng thuận, tranh luận về kết quả tốt nhất, tìm kiếm sự thỏa hiệp, v.v. rất tốn thời gian.

LLM cho phép một mức độ tùy biến phần mềm lớn. Bạn có thể thực hiện các thay đổi bạn muốn một mình nhanh hơn và dễ dàng hơn bao giờ hết, và sau đó rebase chúng (hoặc không) lên trên upstream theo tốc độ của riêng bạn.

Chỉ cần fork thôi. Thêm hỗ trợ cho trường hợp sử dụng của riêng bạn, làm mọi việc theo cách của bạn, không xin phép cũng không xin tha thứ. Là một người bảo trì, điều này cũng giúp tôi tiết kiệm thời gian. Và cuối cùng, có lẽ cả hai chúng ta có thể học được điều gì đó từ phiên bản của bạn đi theo con đường riêng của nó.

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗