- Trong thời đại AI viết mã, cách review pull request (PR) cần phải thay đổi từ gốc, và quy trình review hiện tại không phù hợp với workflow lập trình bằng AI
- Khi reviewer hỏi “tại sao lại làm như vậy?”, lập trình viên lại đi hỏi AI rồi dán câu trả lời vào, tạo ra sự kém hiệu quả khi con người chỉ đóng vai trò người trung gian (middleman)
- Cần đưa nhật ký ra quyết định (decision log) của AI vào source control cùng với mã để reviewer có thể trực tiếp kiểm tra ngữ cảnh
- Workflow trong đó AI trực tiếp nhận comment của reviewer và tự động tạo patch cùng phản hồi đã có thể thực hiện ngay bây giờ bằng cách kết hợp webhook GitHub/GitLab với máy chủ MCP
- Tài liệu thiết kế và sơ đồ kiến trúc cũng cần được đưa vào source control dưới các định dạng mà LLM có thể phân tích như Markdown hoặc Mermaid, vì “context is king”
Vấn đề của code review trong thời đại AI
- Khi đặt câu hỏi trong lúc review PR, câu trả lời trả về thường trông như do AI tạo ra, bởi chính AI là bên đã viết mã
- Với câu hỏi như “tại sao lại chọn thư viện này?”, lập trình viên con người không thể tự trả lời, mà phải hỏi lại AI rồi sao chép câu trả lời để chuyển tiếp
- Trước thời AI, người ta hỏi trực tiếp lập trình viên (người viết mã), chứ không hỏi quản lý của họ, nên cần loại bỏ người trung gian
- Mọi tác giả của đoạn mã đều phải tham gia review, và cách tiếp cận dùng một AI agent riêng để suy diễn ngược lý do sau khi sự việc đã xảy ra là hoàn toàn sai lầm
Sự cần thiết của nhật ký ra quyết định
- Khi hỏi con người “tại sao?”, thực chất là đang hỏi về quá trình suy nghĩ nội bộ không được đưa vào PR
- Chain-of-thought của AI có thể được kiểm toán từ bên ngoài (externally auditable), và lịch sử tương tác với AI cũng có thể được kiểm toán, nên cần đưa ngữ cảnh này vào review và source control
- Không cần commit mọi token được tạo ra trong quá trình làm PR; lấy cảm hứng từ khái niệm episodes của Random Labs, chỉ cần bao gồm transcript của các lần gọi công cụ thành công và các kết luận
- Cách này cũng có thể mở rộng trong môi trường agent swarm, bằng cách liên kết nhật ký ra quyết định ở giai đoạn trước PR và thực hiện format cuối cùng
Giới hạn của comment inline
- Thay đổi file nguồn thì dù chỉ sửa comment cũng vẫn cần chạy lại pipeline build (linting, compile, test)
- Transcript ra quyết định lớn hơn rất nhiều so với dung lượng thường được cho phép trong comment inline thông thường
- Comment hiện tại chỉ giải thích mã đang hoạt động như thế nào, chứ không giải thích quá trình đã dẫn tới quyết định đó
Workflow review tích hợp AI
- Khi reviewer để lại comment, AI của lập trình viên cần có thể trực tiếp nhận lấy và tự động tạo patch cùng phản hồi
- Điều này hiện đã có thể triển khai bằng webhook GitHub/GitLab và máy chủ MCP
- Tương tự như Devin AI hoặc Claude Code via GitLab Duo
- Có thể cấu hình để lập trình viên phải cho phép AI trước, hoặc để AI tự đánh giá rồi hành động ngay
- Lập trình viên con người vẫn hoàn toàn có thể tự mình comment và chỉnh sửa như bình thường
- Điều này có thể giảm đáng kể tình trạng comment review chỉ được phản ánh sau vài giờ hay vài ngày, hoặc thậm chí không được phản ánh
Yêu cầu công cụ dành cho reviewer
- Reviewer cũng cần có khả năng đặt câu hỏi trực tiếp cho AI khi xem xét PR, giống như khi khám phá codebase
- Việc check-in nhật ký ra quyết định cùng với mã là yếu tố cốt lõi để đạt được mục tiêu này
- Vẫn dùng giao diện PR hiện có, nhưng bên cạnh đó cần tích hợp một cửa sổ để trò chuyện với Codex hoặc Claude như trong môi trường phát triển IDE
- Hiện vẫn chưa có công cụ nào thật sự gọn gàng, nên sẽ rất tốt nếu ai đó làm ra nó
- Trong lúc xem diff, reviewer có thể hỏi đáp riêng với AI về thư viện lạ, ngôn ngữ không quen, hay best practice, rồi mới quyết định có cần để lại comment review hay không
- Nếu cần để lại comment, đó là tín hiệu cho thấy trong nhật ký ra quyết định đang có một khoảng trống (gap), và cần cập nhật log trước khi phê duyệt PR
Tầm quan trọng của tài liệu thiết kế và ngữ cảnh
- Trong review tích hợp AI, việc reviewer trực tiếp đề xuất patch cũng trở nên dễ dàng hơn rất nhiều
- Cần thêm tài liệu thiết kế, hồ sơ quyết định (decision records), và sơ đồ kiến trúc vào source control dưới các định dạng LLM có thể phân tích như Markdown hoặc Mermaid
- “Context is king”
10 bình luận
Lý do PR chết có lẽ không phải vì bản thân PR, mà là vì cách giao tiếp quá cẩu thả của các vibe coder.
Đã implement theo flow nào, còn có những cách khác nào và vì sao không chọn, vì sao
package.lockphải thay đổi. Chẳng phải tất cả đều là những thứ cần phải nói trước hay sao? Những coder lẽ ra chỉ cần viết vào PR Description nhưng lại cố tình bắt người khác phải hỏi mới đáng bị khai tử hơn.Tôi đồng ý. Trước đây, PR mang lại cảm giác rằng tôi tự chịu trách nhiệm cho thành quả mình tạo ra,
nhưng PR của một vibe coder thì giống như kiểu "tôi cũng chẳng biết mình đã làm ra cái gì, nhưng dù sao cũng có kết quả rồi nên anh cứ đánh giá và tìm vấn đề đi".
Tôi đồng ý.
Mọi thứ đang chuyển theo hướng nói trước nhưng về sau lại không chịu trách nhiệm.
Tôi đồng cảm. Khó chịu đến mức phát bực.
Tôi đồng ý.
Một PR thay đổi tới 500 file, vậy mà người gửi lại than phiền vì không được review trong vòng 30 phút. Phần mô tả thì chỉ viết chừng năm sáu dòng cho xong, rồi chẳng lẽ cứ thế tin và bấm duyệt sao...?
Đã test hết rồi chứ?
Ừ
Rồi, cố làm cho tốt nhé
Cứ suốt ngày bảo là chết rồi.
Cứ thế này thì chết hết mất!
Có vẻ như ngày càng có quá nhiều bài viết với tiêu đề kiểu cái gì đó đã chết chỉ cần có chuyện gì xảy ra
nên cảm giác khá mệt mỏi.
Tôi cũng nghĩ là nên thôi đừng giết nữa.
"Đã chết; vạn tuế"
Kiểu bài viết như vậy đúng là đang xuất hiện quá nhiều. Nhưng tôi công nhận là AI đang thay đổi mọi thứ.