Rà soát mã thời AI không nên biến mất. Điều cần thay thế là quy trình đọc từng dòng mang tính trình diễn, trong đó tác tử viết mã, AI rà soát, tác tử sửa lại và con người chỉ đọc lướt trước khi hợp nhất. AI có thể đảm nhiệm các kiểm tra lặp lại, nhưng con người vẫn phải đánh giá chủ đích, chia sẻ hiểu biết về hệ thống và chịu trách nhiệm cho quyết định cuối cùng.
Sáu tháng trước, tác giả của bài viết gốc cho rằng đã đến lúc loại bỏ việc rà soát mã. Sau khi quan sát các nhóm kỹ thuật áp dụng AI vào thực tế, ông thừa nhận mình đã xác định sai thứ cần thay thế. Theo The New Stack, việc đọc từng dòng thay đổi mã có thể đang mất dần vai trò, nhưng hoạt động rà soát vẫn cần được giữ lại.
Đề xuất ban đầu đã bỏ sót nội dung gì
Năm lớp tin cậy ban đầu kiểm tra khá tốt việc một thay đổi có đúng và phù hợp với mục tiêu đã nêu hay không. Mô hình này không trả lời được câu hỏi quan trọng hơn: nhóm có nên xây dựng thay đổi đó ngay từ đầu hay không.
Mô hình dùng năm lớp tin cậy theo nguyên lý những lát phô mai có lỗ. Mỗi lớp đều không hoàn hảo, nhưng khi xếp đủ lớp, các lỗ hổng khó trùng nhau.
- So sánh nhiều phương án, bằng cách để nhiều tác tử thực hiện cùng một thay đổi rồi xếp hạng kết quả theo số kiểm thử vượt qua, kích thước phần mã thay đổi và số phụ thuộc được thêm vào.
- Dùng rào chắn xác định, gồm công cụ kiểm tra quy tắc mã, kiểu dữ liệu và hợp đồng. Đây là các điều kiện có thể kiểm chứng, không phải ý kiến để tác tử tranh luận.
- Đặt tiêu chí chấp nhận do con người xác định, nghĩa là mô tả trạng thái hoàn thành trước khi mã được viết.
- Giới hạn quyền, quy định tác tử được phép thay đổi những phần nào khi chưa có con người phê duyệt.
- Xác minh đối kháng, giao cho một tác tử không có quyền ghi nhiệm vụ tìm cách phá vỡ phần triển khai.
Cả năm lớp đều bỏ qua phán đoán của con người về việc có nên xây dựng thay đổi đó hay không, cùng cuộc trao đổi nơi phán đoán ấy hình thành. Chúng có thể xác minh kết quả, nhưng không tự quyết định liệu kết quả đó có đáng được xây dựng.
Rà soát mã không chỉ để tìm lỗi
Nghiên cứu tại Microsoft và Google cho thấy tìm lỗi chỉ là một phần của rà soát mã. Hoạt động này còn giúp nhóm truyền đạt kiến thức, duy trì cách hiểu chung về hệ thống và thảo luận các quyết định kỹ thuật.
Năm 2013, Alberto Bacchelli và Christian Bird nghiên cứu hoạt động rà soát mã tại Microsoft và phân loại 570 bình luận rà soát. Có 44% nhà phát triển xếp việc tìm lỗi là lý do quan trọng nhất để rà soát, nhưng chỉ 14% bình luận thực tế nói về lỗi.
Năm năm sau, Caitlin Sadowski cùng các cộng sự phân tích chín triệu thay đổi đã được rà soát tại Google và đi đến kết luận tương tự. Phát hiện lỗi chỉ là một phần nhỏ trong công việc mà hoạt động rà soát thực sự đảm nhiệm.
Rà soát mã giúp cả nhóm xây dựng mô hình chung về hệ thống. Đây cũng là lúc kiến thức về kiến trúc, quyết định kỹ thuật và những giới hạn không được ghi thành văn chuyển từ người này sang người khác. Addy Osmani mô tả vấn đề vào tháng 6 rằng chi phí viết đã trở nên rẻ, còn chi phí để hiểu vẫn giữ nguyên. AI làm tăng tốc độ tạo mã, nhưng không tự làm giảm công sức cần thiết để hiểu hệ thống.
Các nhóm đã ngừng đọc từ trước
Dữ liệu được dẫn trong các báo cáo năm 2025 và 2026 cho thấy sản lượng mã tăng không đồng nghĩa với độ ổn định cao hơn. Khi lượng thay đổi tăng nhanh, con người khó duy trì cách rà soát dựa trên việc đọc toàn bộ từng dòng.
Báo cáo kỹ thuật năm 2026 của Faros AI bao quát dữ liệu của 22.000 nhà phát triển thuộc hơn 4.000 nhóm. Báo cáo ghi nhận số sự cố trên mỗi yêu cầu hợp nhất tăng 242,7%, số lỗi trên mỗi nhà phát triển tăng 54% và số lần phải khởi động lại công việc tăng 13,8%. Số PR được hợp nhất mà không qua bất kỳ hoạt động rà soát nào, dù bởi con người hay tác tử, tăng 31,3%.
Báo cáo về phát triển phần mềm có AI hỗ trợ năm 2025 của DORA mô tả cùng một sức ép: mức độ ứng dụng AI tăng thì sản lượng bàn giao tăng, nhưng độ bất ổn trong bàn giao cũng tăng. Biểu đồ tốc độ và biểu đồ sự cố có thể cùng đi lên mà không mâu thuẫn.
Những kỹ sư vẫn dành mức công sức cũ cho rà soát phải xử lý lượng mã do AI tạo ra ngày càng lớn. Đây không chỉ là vấn đề chất lượng. Một người phải đổi ngữ cảnh liên tục giữa nhiều tác tử và dùng trí nhớ để đọc những phần thay đổi dài.
Thực tế này cũng giải thích vì sao tranh luận về việc AI phá vỡ rà soát mã không thể chỉ xoay quanh khả năng tìm lỗi của mô hình. Câu hỏi lớn hơn là nhóm sẽ bảo toàn hiểu biết chung bằng cách nào.
Vì sao rà soát bằng AI trở thành màn kịch
Rà soát bằng AI trở thành màn kịch khi công cụ kiểm tra mã nhưng không có bối cảnh về những quyết định tạo ra mã. Mô hình có thể phát hiện mẫu lỗi, nhưng không biết phương án nào đã bị loại bỏ, vì sao nhóm chấp nhận một đánh đổi hoặc tính năng có đáng xây dựng hay không.
Cách khắc phục có vẻ hiển nhiên là cho AI đọc phần mã thay đổi. AI không mệt, có thể đọc mọi dòng và áp dụng cùng một tiêu chuẩn vào mọi yêu cầu hợp nhất.
Nhưng AI không chứng kiến các quyết định dẫn đến phần mã đó. AI cũng không thể chịu trách nhiệm khi quyết định gây ra sự cố.
Đây không phải vấn đề chỉ cần một mô hình tốt hơn. Công cụ đang nhìn sai đối tượng, vào sai thời điểm và không có dữ liệu về điều đã được quyết định. Phần mã thay đổi cho biết mã đã đổi thế nào, nhưng không thể tự cho biết vì sao nhóm chọn hướng đó.
AI nên đảm nhiệm các thao tác kiểm tra lặp lại. Con người cần giữ quyền phán đoán, giải quyết bất đồng và nhận trách nhiệm.
Năm lớp mới của hoạt động rà soát
Mô hình mới phân chia hoạt động rà soát thành năm lớp: tranh luận giữa các tác tử, ghi lại quyết định, mã hóa quy tắc, thảo luận của con người và xác định trách nhiệm. Mỗi lớp tiếp quản một nhiệm vụ mà việc đọc mã từng dòng từng đảm nhiệm.
| Lớp | Nguồn gốc | Nhiệm vụ tiếp quản |
|---|---|---|
| 1. Tranh luận giữa các tác tử | Đưa xác minh đối kháng lên trước và gộp việc so sánh nhiều phương án | Xem xét giải pháp thay thế |
| 2. Ghi lại quyết định | Mở rộng tiêu chí chấp nhận để bao gồm cả chủ đích | Chuyển giao kiến thức |
| 3. Mã hóa quy tắc | Biến lỗi lặp lại thành rào chắn xác định | Tìm lỗi và giữ tính nhất quán |
| 4. Thảo luận | Lớp mới được bổ sung | Quyết định có nên xây dựng hay không |
| 5. Chịu trách nhiệm | Phát triển từ hệ thống phân quyền | Quyết định ai được ký duyệt |
Cấu trúc năm lớp trong bảng được viết lại từ đề xuất của The New Stack và giữ nguyên thứ tự của mô hình mới.
Để các tác tử tranh luận trước khi có yêu cầu hợp nhất
Các tác tử nên so sánh phương án và ghi lại bất đồng trước khi yêu cầu hợp nhất được tạo. Lúc đó, thay đổi hướng đi còn ít tốn kém và con người có thể tập trung vào những quyết định mà các mô hình không tự giải quyết được.
Nếu một AI viết mã và AI khác rà soát, chuỗi bình luận trong yêu cầu hợp nhất là nơi quá muộn để hai bên bắt đầu trao đổi.
Kết quả của lớp này không phải một phán quyết. Nó là bản ghi cho biết phương án nào được đề xuất, phương án nào bị bác bỏ và lý do. Một người đối diện phần thay đổi dài 4.000 dòng khó biết nên tập trung vào đâu. Bản ghi về những điểm hai mô hình bất đồng sẽ chỉ ra nơi cần đến phán đoán của nhóm.
Cách làm này có thể triển khai bằng hai trình rà soát sử dụng các mô hình khác nhau, kèm một kỹ năng ghi lại điểm bất đồng để đưa vào yêu cầu hợp nhất. Các công cụ nguồn mở như PR-Agent, chế độ kiến trúc sư của Aider, AutoGen và CrewAI đã hỗ trợ phần lớn quy trình phối hợp nhiều tác tử.
Với nhóm đang tìm hiểu nền tảng trước khi triển khai, phần giải thích về cách tác tử AI viết mã hoạt động giúp làm rõ ranh giới giữa tạo mã, kiểm tra và ra quyết định.
Ghi lại chủ đích khi công việc đang diễn ra
Nhóm cần ghi lại hai loại thông tin trong quá trình làm việc: chủ đích giải thích vì sao thay đổi được thực hiện và tiêu chí chấp nhận mô tả hệ thống phải hoạt động thế nào. Hai loại thông tin này cung cấp bối cảnh mà phần mã thay đổi không thể hiện được.
Yêu cầu viết toàn bộ đặc tả trước khi tác tử bắt đầu làm việc nghe có vẻ an toàn, nhưng đặc tả mất thời gian và thiếu vòng phản hồi. Nó được viết trước khi quá trình triển khai tạo ra kiến thức mới, nên nhanh chóng lệch khỏi công việc thực tế. Ngành phần mềm đã rời mô hình tuần tự kiểu này từ 20 năm trước.
Chủ đích không có tiêu chí thì không thể kiểm tra, còn tiêu chí không có chủ đích thì không thể dùng để phán đoán. Cặp thông tin này áp dụng được cho cả bản sửa lỗi một dòng lẫn tính năng dài 1.000 dòng.
Những quyết định đó đã xuất hiện trong phiên làm việc. Mỗi khi tác tử đặt câu hỏi, hoặc kỹ sư phản đối và sửa hướng thực hiện, một tiêu chí mới được hình thành. Nhóm có thể dùng một kỹ năng tác tử để ghi lại quyết định ngay lúc phát sinh rồi đưa chúng vào yêu cầu hợp nhất.
Biến bình luận lặp lại thành rào chắn
Những yêu cầu kỹ thuật được lặp lại qua nhiều lần rà soát nên trở thành quy tắc kiểm tra tự động. Cách làm này dành thời gian thảo luận của con người cho các câu hỏi cần phán đoán thay vì buộc nhóm nhắc lại cùng một quy ước.
Bình luận rà soát có hai loại. Câu hỏi liệu có nên làm khác đi cần đến phán đoán. Yêu cầu dùng kiểu dữ liệu tiền tệ thay vì số thực thì không cần tranh luận lại trong mọi yêu cầu hợp nhất.
Loại thứ hai nên được đưa vào sổ đăng ký các mẫu mã AI thường làm sai. Khi được viết thành quy tắc bất biến, chúng có thể được kiểm tra trên mọi thay đổi. Nhiều nhóm đã có sẵn các quy tắc như vậy, nhưng chúng đang nằm rải rác trong lịch sử bình luận và trí nhớ của kỹ sư:
- Dùng kiểu dữ liệu tiền tệ cho mọi giá trị có đơn vị tiền.
- Không ghi trực tiếp vào bảng người dùng.
- Chỉ dùng trình ghi nhật ký có cấu trúc, không in trực tiếp.
- Mọi nhánh xử lý lỗi phải phát ra một bộ đếm.
Mỗi bình luận mà nhóm phải lặp lại là một rào chắn chưa được viết thành quy tắc. Nhóm có thể lấy 1.000 bình luận gần nhất, tìm 20 yêu cầu lặp lại nhiều nhất rồi chuyển chúng thành điều kiện kiểm tra tự động.
Hướng tiếp cận này phù hợp với bài toán xác minh 2.000 yêu cầu hợp nhất mỗi tháng, nơi tăng thêm người đọc từng dòng không thể mở rộng tốt bằng việc mã hóa các quy tắc đã thống nhất.
Để con người thảo luận về quyết định
Thời gian của con người nên tập trung vào chủ đích, kiến trúc và các đánh đổi mà tác tử không thể tự giải quyết. Nếu tự động hóa loại bỏ cả cuộc trao đổi này, nhóm có thể giữ được khả năng tìm lỗi nhưng mất dần hiểu biết chung về hệ thống.
Rà soát mã thường là thời điểm được lên lịch duy nhất để kỹ sư trao đổi về hệ thống. Khoảng trống này dễ bị bỏ qua vì ít nhóm xem rà soát mã là một cuộc họp về kiến trúc.
Peter Naur, người nhận Giải Turing, viết trong tác phẩm “Lập trình như quá trình xây dựng lý thuyết”:
“Một chương trình chết khi nhóm lập trình viên nắm giữ lý thuyết về nó tan rã.”
Trong tổ chức hiện đại, điều đó có thể xảy ra sau tái cơ cấu, nghỉ việc hoặc thay người. Nếu hiểu biết chung chưa từng được xây dựng, nhóm có thể rơi vào trạng thái ấy mà không cần bất kỳ ai rời đi.
Lớp thảo luận vẫn dùng cùng yêu cầu hợp nhất và cùng công cụ, nhưng đổi chủ đề của cuộc trao đổi. Nhóm tập trung vào những quyết định mà các tác tử đã phát hiện nhưng không thể tự giải quyết. Việc đọc và kiểm tra từng dòng được giao cho máy. Đây là thay đổi hành vi lớn nhất trong năm lớp, nên cần bắt đầu ở phạm vi nhỏ.
Xác định người chịu trách nhiệm
Tự động hóa không loại bỏ trách nhiệm. Nhóm vẫn phải chỉ rõ ai sở hữu các quy tắc kiểm tra, ai duy trì cách hiểu chung về hệ thống và ai ký duyệt quyết định cuối cùng.
Mô hình không có danh tiếng nghề nghiệp, không chịu trách nhiệm pháp lý và không thể bị yêu cầu giải trình theo cách một kỹ sư có thể làm.
Trách nhiệm từng thuộc về người viết mã. Sau đó, nó chuyển một phần sang người rà soát và phê duyệt. Khi quy tắc bất biến đảm nhiệm việc xác minh, trách nhiệm nằm ở nhóm xây dựng, duy trì và cập nhật các quy tắc đó.
Quyền sở hữu vì thế không còn đồng nghĩa với việc đọc từng dòng. Nhóm nên xác định trách nhiệm trước khi một sự cố buộc tổ chức phải làm rõ.
Dẹp màn kịch, không dẹp hoạt động rà soát
Rà soát mã thời AI nên chuyển việc đọc nhất quán, tìm mẫu lỗi và thực hiện kiểm tra lặp lại cho máy. Con người vẫn phải đánh giá chủ đích, cân nhắc phương án, duy trì hiểu biết chung và nhận trách nhiệm.
Muốn thay thế việc đọc từng dòng mà không làm mất giá trị của rà soát, công cụ và văn hóa phải thay đổi cùng nhau. Quyết định cần được ghi lại trên yêu cầu hợp nhất, rào chắn phải đủ mạnh để tạo niềm tin, còn cuộc trao đổi của nhóm phải chuyển từ câu hỏi mã có đúng cú pháp sang câu hỏi nhóm có đang xây đúng thứ hay không.
Nhóm có thể bắt đầu bằng một yêu cầu hợp nhất gần nhất, ghi lại điểm các tác tử bất đồng và chọn một bình luận lặp lại để biến thành quy tắc kiểm tra chung.
