Hình ảnh minh họa về quy trình code review và AI

Có lẽ chúng ta không nên review toàn bộ code?

Khi trí tuệ nhân tạo (AI) tạo ra code nhanh hơn khả năng con người có thể review, câu hỏi đặt ra không phải là làm sao để review nhanh hơn, mà là tại sao chúng ta lại dồn quá nhiều trách nhiệm vào code review đến vậy. Theo Rachel Laycock, CTO tại Thoughtworks, thay vì cố gắng duy trì một quy trình vốn đã lỗi thời, các đội ngũ nên chuyển trọng tâm sang các hoạt động hợp tác như pair programming, thiết kế tập thể và mã hóa các ràng buộc kiến trúc. Bài viết đề xuất mô hình "review theo ngoại lệ" để giải phóng năng suất của kỹ sư và xây dựng sự hiểu biết hệ thống thay vì chỉ đọc diff.

Vấn đề: Code review trở thành điểm nghẽn mới

Rachel Laycock, CTO tại Thoughtworks, đã có một buổi thảo luận thú vị với Brian Houck từ DX tại hội thảo Code Remix, nơi cả hai bày tỏ quan điểm trái ngược về tương lai của code review. Brian chỉ ra những con số đáng kinh ngạc: tại Meta, số dòng code đáng kể trên mỗi diff do con người thực hiện đã tăng 106% trong một năm, trong khi dữ liệu của DX cho thấy kích thước pull request trung bình tăng 64%.

Với sự hỗ trợ của AI, lượng code được tạo ra đang vượt xa khả năng review của con người. Điều này khiến code review truyền thống trở thành một nút thắt cổ chai và là rào cản lớn cho tốc độ phát triển phần mềm.

Code review không chỉ để tìm lỗi

Brian lo ngại rằng việc tự động hóa code review có thể làm mất đi những giá trị khác của nó. Quan điểm này được Rachel chia sẻ: code review không chỉ đơn thuần là tìm lỗi. Nó là cách để:

• Chia sẻ kiến thức trong nhóm.
• Đào tạo kỹ sư junior từ kinh nghiệm của người đi trước.
• Xây dựng quyền sở hữu tập thể đối với codebase.
• Phổ biến sự hiểu biết về kiến trúc hệ thống.

Tuy nhiên, câu hỏi cốt lõi của Rachel là: "Tại sao chúng ta phải đợi đến lúc code review mới thực hiện những điều đó?"

Nguyên tắc "Dịch chuyển sự đánh giá sang trái" (Shift the judgment left)

Một trong những nguyên tắc quan trọng nhất tại Thoughtworks là rút ngắn vòng phản hồi (shorten feedback loops). Nếu phản hồi có giá trị, đừng loại bỏ nó, mà hãy đưa nó đến gần hơn với quyết định mà nó đang phục vụ.

Thay vì chờ đến cuối quy trình để review, hãy thực hiện các hoạt động này ngay từ đầu:

• Khám phá các giải pháp thay thế: Nên làm điều này trước khi bắt tay vào implement, thay vì sau khi đã hoàn thành.
• Truyền đạt kiến thức: Hãy pair programming. Làm việc cùng nhau, lý luận và giải quyết vấn đề trong thời gian thực sẽ dạy bạn nhiều hơn là đọc giải pháp cuối cùng của người khác.
• Đào tạo kỹ sư junior: Cho họ làm việc trực tiếp với các kỹ sư giàu kinh nghiệm trong lúc họ đang tư duy. Pair programming hoặc các buổi thiết kế nhóm với bảng trắng là lựa chọn lý tưởng.
• Xây dựng quyền sở hữu tập thể: Tổ chức các nhóm để mọi người thực sự cùng xây dựng và vận hành phần mềm, thay vì dựa vào pull request để thông báo cho mọi người về thứ mà người khác đã tạo ra. Pair programming, mob programming hay các buổi thiết kế nhóm là chìa khóa.
• Đảm bảo sự thống nhất về kiến trúc: Cùng nhau thiết kế và sau đó mã hóa các ràng buộc quan trọng dưới dạng các hàm kiểm tra tính phù hợp (fitness functions).
• Kiểm tra các vấn đề cơ bản: Formatting, linting, lỗ hổng bảo mật đã biết hay các lỗi có thể kiểm tra một cách xác định, hãy để công cụ tự động hóa xử lý. Đã đến năm 2026, chúng ta không nên tranh cãi về khoảng trắng trong code nữa.

Nếu một agent có thể tạo ra lượng code gấp mười lần nhưng mọi dòng code vẫn phải xếp hàng chờ một kỹ sư cấp cao kiểm tra, thì chúng ta không tạo ra một tổ chức kỹ thuật mạnh gấp mười lần, mà chỉ tạo ra một tồn đọng khổng lồ và một điểm nghẽn mới.

Chiến lược "Review theo ngoại lệ" (Review by exception)

Điều này không có nghĩa là không ai cần review code nữa. Vẫn có những thay đổi đòi hỏi sự xem xét của một con người giàu kinh nghiệm, ví dụ như:

• Một thay đổi kiến trúc nền tảng quan trọng.
• Thay đổi vượt qua một ranh giới bảo mật nhạy cảm.
• Một thay đổi có phạm vi ảnh hưởng (blast radius) rất lớn.
• Một phần không quen thuộc trong hệ thống quan trọng.
• Hoặc đơn giản là khi cả nhóm cảm thấy "Chúng tôi không tự tin về phần này".

Đây chính là những nơi mà trí tuệ con người thực sự có giá trị. Nhưng điều đó rất khác với việc yêu cầu một con người kiểm tra mọi thay đổi chỉ vì đó là quy trình chúng ta vẫn làm từ trước đến nay.

Việc tìm ra một AI agent đóng giả làm người review để duy trì quy trình cũ với tốc độ nhanh hơn không phải là giải pháp. Đó là tự động hóa một nghi lễ mà không hề đặt câu hỏi tại sao nghi lễ đó lại tồn tại.

Mối lo về "khoản nợ nhận thức" (cognitive debt)

Một điểm mà Rachel đồng tình với Brian là mối lo về khoản nợ nhận thức: phần mềm ngày càng phát triển trong khi những người chịu trách nhiệm về nó lại càng hiểu ít hơn về lý do tại sao nó hoạt động như hiện tại. Tuy nhiên, cô cho rằng việc bắt buộc tạo pull request không phải là một biện pháp bảo vệ hiệu quả cho vấn đề này.

Nếu các agent sẽ tạo ra phần lớn implementation, chúng ta cần phải có chủ đích hơn trong việc duy trì sự hiểu biết của con người thông qua:

• Thiết kế hợp tác (collaborative design).
• Pair programming.
• Các ranh giới hệ thống tốt.
• Kiến trúc có thể thực thi được (executable architecture).
• Chia sẻ trách nhiệm vận hành.

Chúng ta cần các kỹ sư hiểu về hệ thống, chứ không chỉ hiểu về các diff.

Kết luận: Đã đến lúc thay đổi tư duy

Có lẽ AI đang phơi bày một sự thật: chúng ta đã dồn quá nhiều trách nhiệm lên vai của code review - từ kiểm soát chất lượng, kiểm tra bảo mật, rà soát kiến trúc, đến cơ chế đào tạo và chia sẻ kiến thức. Cách làm này từng hiệu quả khi con người chỉ có thể tạo ra code với một tốc độ nhất định. Nhưng giới hạn đó đang biến mất.

Vì vậy, câu hỏi cốt lõi không phải là làm thế nào để review code nhanh hơn, mà là: Tại sao chúng ta phải đợi đến code review mới có những cuộc trò chuyện quan trọng?