Cổng đôi AI review code và kiểm duyệt con người để giữ chất lượng phần mềm

Vì sao chỉ dựa vào AI để review code vẫn chưa đủ để đảm bảo chất lượng?

AI review code rất giỏi bắt lỗi lặp lại, vi phạm quy ước và rủi ro kỹ thuật phổ biến, nhưng nó không hiểu mục tiêu nghiệp vụ của bạn. Một đoạn code có thể chạy đúng, sạch về cú pháp, mà vẫn sai logic hoặc sai yêu cầu thực tế. Vì vậy chất lượng cần thêm một lớp con người để phán đoán ngữ cảnh.

Khi một doanh nghiệp thuê ngoài phát triển web hoặc ứng dụng di động, câu hỏi thường gặp nhất không phải "đội ngũ có biết dùng AI không", mà là "làm sao tôi biết code họ giao thật sự tốt". Đây là câu hỏi đúng. Công cụ AI ngày nay có thể viết code rất nhanh, nhưng tốc độ đó cũng tạo ra một rủi ro mới: khối lượng code tăng lên nhanh hơn khả năng kiểm tra của con người. Nếu không có cơ chế kiểm soát rõ ràng, năng suất cao chỉ đồng nghĩa với việc lỗi cũng được tạo ra nhanh hơn.

Một số đơn vị giải quyết vấn đề này bằng cách thêm một bot review tự động và coi như xong. Cách làm đó có ích nhưng không đủ. AI review giỏi ở những việc có khuôn mẫu: phát hiện biến không dùng, hàm quá dài, lỗi rò rỉ tài nguyên, mẫu code dễ gây lỗi bảo mật, thiếu xử lý trường hợp ngoại lệ. Nó nhất quán, không mệt mỏi, không bỏ sót vì buồn ngủ lúc cuối ngày. Nhưng AI không biết rằng quy tắc tính phí của bạn có một ngoại lệ đặc thù cho khách hàng doanh nghiệp, hay rằng một trường dữ liệu tưởng như thừa thực ra phục vụ một báo cáo pháp lý. Những điều đó nằm trong ngữ cảnh nghiệp vụ, và ngữ cảnh là thứ AI không tự có.

Cách tiếp cận thực tế là tách rõ hai loại lỗi. Loại thứ nhất là lỗi có khuôn mẫu, máy bắt tốt hơn người. Loại thứ hai là lỗi về ý định và ngữ cảnh, người bắt tốt hơn máy. Một quy trình chất lượng nghiêm túc không chọn một trong hai, mà ghép cả hai thành hai cổng nối tiếp. Code phải đi qua cổng AI trước, rồi mới tới cổng con người. Mỗi cổng chịu trách nhiệm cho phần việc mà nó làm tốt nhất, và không cổng nào được phép thay thế cổng kia.

Cổng thứ nhất: AI review code lọc ra điều gì trong thực tế

Cổng AI chạy tự động ngay khi có thay đổi code, trước khi bất kỳ ai bỏ thời gian đọc. Nó quét toàn bộ phần thay đổi, đối chiếu với quy ước dự án, và đánh dấu các vấn đề kỹ thuật có khuôn mẫu rõ ràng. Mục tiêu của cổng này là dọn sạch lớp lỗi cơ học để con người không phải tốn sức vào chúng.

Trong thực hành, cổng đầu tiên thường tập trung vào vài nhóm vấn đề cụ thể. Về phong cách và cấu trúc, nó kiểm tra việc đặt tên, độ dài hàm, code trùng lặp và những đoạn quá phức tạp khó bảo trì. Về độ bền, nó tìm các trường hợp chưa xử lý lỗi, giá trị null có thể gây sập, vòng lặp tốn tài nguyên, hay truy vấn cơ sở dữ liệu kém hiệu quả. Về bảo mật, nó nhận diện các mẫu nguy hiểm quen thuộc như chèn dữ liệu chưa kiểm tra vào truy vấn, lộ thông tin nhạy cảm trong log, hay phụ thuộc thư viện đã có lỗ hổng công bố.

Điểm mạnh của cổng này là tính nhất quán và quy mô. Một người review giỏi vẫn có thể bỏ sót một biến viết sai khi đọc bản thay đổi dài vào cuối ngày. Máy thì không bỏ sót những thứ nằm trong tập quy tắc của nó, dù bản thay đổi lớn hay nhỏ. Khi khối lượng code tăng do dùng AI để viết, đúng lúc đó một cổng kiểm tra tự động nhất quán trở nên cần thiết hơn bao giờ hết.

Nhưng phải thành thật về giới hạn. AI review tạo ra cả cảnh báo sai (đánh dấu thứ thực ra ổn) lẫn bỏ sót (không thấy lỗi nằm ngoài khuôn mẫu của nó). Nếu một đội ngũ tin tuyệt đối vào cổng đầu tiên, họ sẽ vừa lãng phí thời gian sửa những cảnh báo không cần thiết, vừa giao đi những lỗi mà máy không thể nhìn thấy. Vì thế cổng AI không bao giờ được coi là phán quyết cuối cùng. Nó là bộ lọc đầu vào: làm sạch phần dễ, nâng phần khó lên đúng tầm để con người xử lý. Vai trò của nó là chuẩn bị, không phải kết luận.

Cổng thứ hai: phần việc mà kiểm duyệt con người phải chịu trách nhiệm

Cổng con người đánh giá những điều máy không thể: code này có làm đúng việc cần làm không, có khớp với yêu cầu nghiệp vụ không, và có gây hệ quả ngoài ý muốn ở chỗ khác không. Người kiểm duyệt đọc thay đổi cùng với mục tiêu của tính năng, cân nhắc các cảnh báo từ cổng AI theo ngữ cảnh, rồi quyết định cho qua hay trả lại.

Khác biệt cốt lõi là người kiểm duyệt làm việc với ý định, không chỉ với cú pháp. Một hàm có thể hoàn hảo về mặt kỹ thuật mà vẫn giải quyết sai bài toán. Một thay đổi có thể vượt qua mọi kiểm tra tự động nhưng lại phá vỡ một giả định ngầm ở module khác mà chỉ người hiểu hệ thống mới biết. Một cách xử lý dữ liệu có thể đúng về kỹ thuật nhưng vi phạm kỳ vọng của khách hàng về quyền riêng tư. Đây là những phán đoán cần hiểu cả sản phẩm lẫn người dùng, và đó là lý do bước này không thể tự động hóa hoàn toàn.

Người kiểm duyệt cũng đóng vai trò phán xử đối với chính cổng AI. Khi cổng đầu tiên đánh dấu một vấn đề, người kiểm duyệt quyết định đó là rủi ro thật cần sửa, hay là cảnh báo sai có thể bỏ qua một cách có chủ đích và ghi lại lý do. Việc phán xử này quan trọng: nó ngăn đội ngũ trở thành nô lệ của công cụ, mù quáng sửa mọi thứ máy nói chỉ để cổng chuyển sang màu xanh. Mục tiêu là code tốt, không phải bảng điều khiển sạch.

Để bước này có giá trị thật, người kiểm duyệt cần đủ thời gian và đủ ngữ cảnh. Một quy trình bắt người ta duyệt hàng nghìn dòng trong vài phút chỉ tạo ra cái dấu cao su, không phải sự kiểm soát. Cách làm bền vững là giữ mỗi lần thay đổi ở quy mô vừa phải để có thể đọc kỹ, kèm mô tả rõ ràng về việc thay đổi đó nhằm đạt điều gì. Khi đó người kiểm duyệt không phải đoán ý định, mà tập trung vào việc thẩm định nó. Trong nhiều đội ngũ, người trực tiếp viết và người kiểm duyệt là hai người khác nhau, để có một góc nhìn độc lập thực sự thay vì tự duyệt chính mình.

Quy trình nối hai cổng: tiêu chuẩn cho qua và quy tắc chặn

Hai cổng chỉ phát huy tác dụng khi được nối bằng một quy trình rõ ràng: code đi qua cổng AI trước, kết quả được đưa kèm tới người kiểm duyệt, và chỉ những thay đổi vượt qua cả hai mới được hợp nhất. Điều quyết định chất lượng nằm ở tiêu chuẩn cho qua và quy tắc chặn được định nghĩa trước, không phải quyết định tùy hứng từng lần.

Một dòng chảy điển hình diễn ra như sau. Lập trình viên hoàn tất một thay đổi và gửi đi. Cổng AI chạy ngay, tạo ra danh sách phát hiện được phân theo mức độ. Các vấn đề nghiêm trọng, ví dụ một mẫu bảo mật nguy hiểm, sẽ chặn cứng: thay đổi không thể đi tiếp cho đến khi được xử lý. Các vấn đề nhẹ hơn được đưa lên như ghi chú để người kiểm duyệt cân nhắc. Sau đó người kiểm duyệt vào cuộc, đọc thay đổi cùng ngữ cảnh nghiệp vụ và các ghi chú của máy, rồi đưa ra một trong ba kết luận: chấp nhận, yêu cầu sửa, hoặc chấp nhận có điều kiện kèm ghi chú lý do. Chỉ sau khi cổng con người đồng ý thì thay đổi mới được hợp nhất vào nhánh chính.

Điểm mấu chốt là phân biệt giữa chặn cứng và cảnh báo mềm. Nếu mọi phát hiện đều chặn, đội ngũ sẽ bị tê liệt và bắt đầu tìm cách lách. Nếu không có gì chặn, cổng trở thành trang trí. Cách cân bằng là dành cơ chế chặn cứng cho một nhóm hẹp các rủi ro thật sự không thể nhân nhượng, thường là về bảo mật và mất dữ liệu, và để mọi thứ còn lại cho phán đoán của người kiểm duyệt. Ranh giới này nên được viết ra và thống nhất từ trước, để không ai phải tranh cãi vào đúng lúc cần giao hàng.

Quy trình tốt còn thừa nhận một thực tế quan trọng: cổng AI và cổng con người cần học từ nhau. Khi người kiểm duyệt liên tục bỏ qua một loại cảnh báo nào đó, đó là tín hiệu cần chỉnh lại quy tắc của cổng đầu tiên. Khi một loại lỗi liên tục lọt qua cả hai cổng và chỉ bị phát hiện sau khi lên sản phẩm, đó là tín hiệu cần bổ sung kiểm tra mới. Hệ thống hai cổng không phải là thứ dựng một lần rồi để yên, mà là một vòng lặp được tinh chỉnh theo những lỗi thực tế đã gặp.

Không chỉ là chất lượng: tài sản mà cổng đôi để lại cho bảo mật và bảo trì

Ngoài việc bắt lỗi, hệ thống hai cổng còn để lại một tài sản dài hạn: một hồ sơ có thể truy vết về việc mỗi thay đổi đã được kiểm tra ra sao, ai đồng ý cho qua, và vì sao một cảnh báo nào đó được chấp nhận. Hồ sơ này chính là thứ giúp việc bảo mật và bảo trì phần mềm trở nên bền vững theo thời gian, thay vì phụ thuộc vào trí nhớ của một người.

Về bảo mật, cổng đôi giải quyết một nỗi lo rất thực khi thuê ngoài phát triển: làm sao biết code nhận về không chứa lỗ hổng ẩn. Cổng AI quét các mẫu nguy hiểm đã biết một cách nhất quán trên toàn bộ code, còn cổng con người đánh giá những rủi ro phụ thuộc ngữ cảnh, chẳng hạn liệu một quyền truy cập có thật sự cần thiết hay đang quá rộng. Không lớp nào tự mình đủ, nhưng cùng nhau chúng tạo ra một mức kiểm soát mà một bên đơn lẻ khó đạt được. Quan trọng không kém, mỗi quyết định đều để lại dấu vết, nên khi có sự cố bảo mật về sau, đội ngũ có thể lần ngược lại thay đổi liên quan thay vì dò dẫm trong bóng tối.

Về bảo trì, giá trị tích lũy theo thời gian. Phần mềm tồn tại lâu hơn nhiều so với lúc viết ra nó. Sáu tháng sau, một lập trình viên khác, có thể không phải người viết ban đầu, sẽ cần sửa hoặc mở rộng cùng đoạn code đó. Khi mỗi thay đổi đi kèm một hồ sơ rõ ràng về việc nó làm gì và vì sao được chấp nhận, người đến sau hiểu hệ thống nhanh hơn và ít vô tình phá vỡ thứ gì đó hơn. Đây là khác biệt thầm lặng giữa một codebase mà ai cũng sợ động vào và một codebase có thể phát triển an toàn.

Cuối cùng, cần nhìn nhận cổng đôi một cách trung thực. Nó không khiến phần mềm hoàn hảo, và không có quy trình nào làm được điều đó. Một số lỗi vẫn sẽ lọt qua, vì đó là bản chất của việc xây dựng phần mềm. Điều cổng đôi mang lại là một cách kiểm soát chất lượng có kỷ luật và lặp lại được, không phụ thuộc vào việc một cá nhân giỏi vào đúng ngày tỉnh táo. Với doanh nghiệp đang cân nhắc đối tác phát triển, câu hỏi đáng giá hơn cả "đội ngũ có dùng AI không" chính là "đội ngũ kiểm soát chất lượng phần mềm họ giao như thế nào". Một quy trình hai cổng được định nghĩa rõ ràng là một trong những câu trả lời cụ thể nhất cho câu hỏi đó.