Khắc phục vấn đề "AI Slop" bằng cách ghi nhận công lao của người đánh giá

Khắc phục vấn đề "AI cẩu thả" bằng cách ghi nhận công sức của người đánh giá Ba lượt AI bỏ sót một lỗi mà bạn có thể tìm thấy bằng cách cuộn lên Dan Apushkinsky Ngày 02/10/2026 2 1 Chia sẻ Đã duyệt Gần đây, tôi đã xem xét một PR (Pull Request). Hãy xem bạn có thể phát hiện ra lỗi không: # Branch C không có máy in user = new Person(...) ... user thực hiện một số thao tác ... if user not in branch_c: user.print_document() ... 50 dòng logic thư viện ... ### Mã mới được thêm vào PR: + staff = new Person(...) ... staff thực hiện một số thao tác ... + staff.print_document() Rõ ràng tôi không làm việc tại một thư viện – tôi đã thay thế các lời gọi thực tế. Nhưng nó thực sự đơn giản như vậy. Dòng `# Branch C doesn’t have a printer` cũng không được thêm vào đây để giải thích ngữ cảnh, nó nằm ngay trong mã. Mọi thử nghiệm chúng tôi thực hiện đều sẽ vượt qua, nhưng ngay khi triển khai lên branch C, chúng tôi sẽ bắt đầu thấy lỗi. Có lẽ một codebase tốt hơn sẽ không để xảy ra loại lỗi này. Nhưng thôi, đừng đổ lỗi cho tôi – các codebase sản phẩm hiếm khi hoàn hảo, và theo những gì tôi đã thấy, cái này cũng không quá tệ. Tuy nhiên, việc sao chép và dán thủ công thông thường đã có thể ngăn chặn điều này. Việc cuộn lên cũng đã có thể ngăn chặn điều này. Thay vào đó, một AI đã viết mã, một mô hình AI đã xem xét nó, một người đánh giá đã dán nó vào một AI để xem xét, và sau đó đóng dấu chấp thuận. Tôi được chỉ định là người đánh giá (con người) thứ hai. Lần này tôi tình cờ đọc mã, nhưng tôi phải thừa nhận – hầu hết các lần, tôi sẽ chỉ dán PR vào AI và bỏ sót cùng một lỗi hiển nhiên. Mục đích của một người đánh giá là gì? Thực sự? Tôi luôn được dạy rằng người đánh giá sở hữu mã nhiều như tác giả. Và tôi luôn cố gắng kiểm tra một loạt các điều: liệu nó có hoạt động không, có phù hợp không, liệu có ai hiểu được nó trong một năm nữa không. Nhưng có một điều tôi chưa bao giờ phải kiểm tra trước đây – liệu tác giả có bao giờ tự đọc nó không. Điều đó được đảm bảo. Bạn không thể gõ `staff.print_document()` mà không nhấn Ctrl+F và tìm một ví dụ về cách nó được sử dụng. Tuy nhiên, ngày nay, mọi người có thể xuất bản mã mà họ chưa từng thấy trước đây. Người đánh giá có thể là người đầu tiên thực sự đọc mã. Lỗi tôi thấy không đòi hỏi bất kỳ kiến thức đặc biệt nào để phát hiện. Việc AI bỏ sót nó thực sự khá sốc đối với tôi. Nhưng đồng thời, việc có một vòng tròn các AI đọc cùng một mã, với các lời nhắc gần như giống hệt nhau, thường chạy cùng một mô hình, và mong đợi khám phá ra điều gì đó khác biệt là vô nghĩa. Chúng tôi đã nhầm lẫn một lượt AI thứ hai (và thứ ba, thứ tư) với một đánh giá của con người chỉ vì đó là một con người sao chép và dán PR vào công cụ AI yêu thích của họ. Tại thời điểm nào thì bạn nên loại bỏ con người khỏi vòng lặp và tiết kiệm thời gian cho mọi người? Loại bỏ con người? Tôi đã nói chuyện với một vài nhóm tại các công ty khác nhau trong năm qua, và hơn một nhóm đã loại bỏ hoàn toàn yếu tố con người. Một số sẽ để AI đưa ra phán đoán – liệu thay đổi này có đủ rủi ro để cần một người đánh giá không? Cá nhân tôi, tôi vẫn ủng hộ việc có người đánh giá cho phần lớn công việc. Có lẽ tôi đang tụt hậu. Dù sao đi nữa, đây không phải là một bài viết blog về việc quyết định bạn muốn bao nhiêu yếu tố con người. Vấn đề là một khi bạn đã quyết định con số đó, dù là 0%, 100% hay một con số nào đó ở giữa, thì bạn nên thực hiện theo hướng đó một cách có chủ đích. Ngày nay, nhiều người trong chúng ta đang ở trong tình trạng "vùng đất không người". Chúng ta vẫn có yêu cầu về người đánh giá từ trước đây – nhưng con người chỉ là một đại diện cho một đánh giá AI khác. Loại bỏ AI? Thoạt nhìn, một giải pháp hấp dẫn có thể là cấm sử dụng AI trong các đánh giá cho đến khi người đánh giá tự đọc tài liệu ít nhất một lần. Tuy nhiên, không thể kiểm soát những gì một người thực hiện trên thiết bị đầu cuối của riêng họ, và ngay cả khi có thể, điều đó có lẽ cũng không giải quyết được nguyên nhân gốc rễ thực sự. Có rất ít điều gây khó chịu hơn việc xem xét một yêu cầu kéo (PR) hoặc một tài liệu mà bạn biết rằng mình sẽ dành nhiều thời gian để đọc hơn cả thời gian tác giả đã dành để viết. Họ dành 5 phút để ra lệnh cho AI, chỉ để bạn dành một giờ để xem xét. Đến một lúc nào đó, bạn trở thành người gián tiếp xây dựng tính năng đó. Và những giờ bạn dành để xem xét mã – bạn không bao giờ nhận được bất kỳ sự công nhận nào. Dán các yêu cầu kéo vào AI không phải là sự lười biếng. Đó là một quyết định hợp lý nếu bạn ưu tiên thời gian của mình. Theo kinh nghiệm của tôi, hiếm khi có người muốn gian lận hệ thống. Hầu hết mọi người đều muốn làm công việc tốt, trung thực và được công nhận. Họ chỉ không muốn làm công việc vô hình, không được ghi nhận. **Đưa lên bảng công việc** Giải pháp cho vấn đề này đã khiến tôi băn khoăn trong vài tuần, nhưng tôi thực sự nghĩ rằng nó khá đơn giản: thêm các đánh giá (review) như các nhiệm vụ phụ (subtask) vào bảng công việc (sprint board) của bạn. Trước kỷ nguyên AI, việc quản lý chi phí phát sinh đó sẽ rất khó khăn. Ngày nay, AI có thể làm điều đó cho bạn – tích hợp nó vào quy trình yêu cầu kéo (PR pipeline) của bạn, để nó tự động tạo phiếu công việc (ticket). Và tôi biết, tôi biết. Thêm nhiệm vụ giữa chu kỳ chạy nước rút (mid-sprint) là một thực hành không tốt. Nhưng bỏ qua điều đó. Thời thế đã thay đổi. Trừ khi bạn muốn làm chậm quá trình triển khai sản phẩm – và không ai muốn điều đó – bạn sẽ phải kéo những nhiệm vụ đó vào chu kỳ chạy nước rút hiện tại. Một phiếu đánh giá (review ticket) thực hiện hai việc. Thứ nhất, nó buộc bạn phải ước tính thời gian thực hiện. Chắc chắn – nó có thể chỉ là một điểm (1 pointer), nhưng việc dành 30 giây để ước tính nó là một tín hiệu cho thấy đó là một việc thực sự mà chúng ta coi trọng. Thứ hai, nó làm cho chi phí trở nên rõ ràng. Khi một tính năng 3 điểm tạo ra một đánh giá 3 điểm, nỗ lực đó cuối cùng sẽ hiển thị song song với chính công việc tính năng. Và lần đầu tiên, người đánh giá sẽ không còn bị phạt vì đã thực hiện đúng trách nhiệm của mình. Bây giờ bạn có thể đúng khi chỉ ra – làm thế nào việc thêm người đánh giá vào bảng chạy nước rút lại là một giải pháp? Mọi người vẫn có thể sử dụng AI để tiết kiệm thời gian. Câu trả lời là đây là một đòn phối hợp. Việc ghi nhận công lao cho người đánh giá giúp bạn xây dựng một văn hóa nhóm nơi bạn được khen thưởng khi dành thời gian cho các đánh giá và tìm ra vấn đề sớm. Thêm các đánh giá vào bảng chạy nước rút là đặt thêm một rào cản phải được phá vỡ để văn hóa của bạn không bị biến thành sự cẩu thả do AI. Vì vậy, hãy trao cho mọi người sự công nhận xứng đáng khi xem xét các yêu cầu kéo (PR) một cách đúng đắn, và lần tới khi ai đó nhấn nút chấp thuận, điều đó thực sự sẽ có ý nghĩa. Cảm ơn đã đọc. Nếu bài viết này thú vị, hãy đăng ký – tôi sẽ viết thêm những bài như thế này. Đăng ký 1Ngay cả việc sử dụng các mô hình khác nhau cũng có thể không quan trọng lắm – một nghiên cứu năm 202