Kỹ năng sử dụng Claude Code thay đổi hoàn toàn quy trình Code Review của tôi

Tôi lại đang than phiền. Lần nữa.

Code review đang nuốt chửng thời gian của tôi, và vấn đề ngày càng trở nên tồi tệ hơn. Chúng tôi tung ra các tính năng mới nhanh hơn, đồng nghĩa với việc có nhiều code hơn, trong đó có rất nhiều phần nằm trong các lĩnh vực mà tôi không hiểu sâu. Sự phát triển dựa trên các tác nhân AI (Agentic development) rất tuyệt vời về mặt năng suất, nhưng lại không hề dễ chịu cho người vẫn phải hiểu những gì đã được xây dựng.

Amitai, một đồng đội, đã quá mệt mỏi vì nghe tôi than vãn. Anh ấy gửi cho tôi một liên kết.

Mẹo số 26

Bài viết đó là 45 Claude Code Tips: From Basics to Advanced (45 mẹo Claude Code: Từ cơ bản đến nâng cao) của @ykdojo. Mẹo số 26 nói về việc review PR (Pull Request) một cách tương tác:

"Claude Code rất tuyệt vời cho việc review PR. Quy trình khá đơn giản: bạn yêu cầu nó lấy thông tin PR bằng lệnh gh, sau đó bạn có thể thực hiện bài review theo cách mình muốn.

Bạn có thể thực hiện một bài review tổng quát, hoặc đi qua từng file, từng bước một. Bạn kiểm soát tốc độ. Bạn quyết định mức độ chi tiết muốn xem xét và mức độ phức tạp muốn làm việc. Có thể bạn chỉ muốn hiểu cấu trúc chung, hoặc có thể bạn muốn nó chạy thử luôn.

Sự khác biệt chính là Claude Code đóng vai trò như một người review PR tương tác, không chỉ là một cỗ máy 'một phát xong' (one-shot). Một số công cụ AI tốt ở việc review một lần (bao gồm cả các mẫu GPT mới nhất), nhưng với Claude Code, bạn có thể trò chuyện."

Tôi đã thử nó một lần. Rồi lần nữa. Sau đó, tôi biến nó thành một "kỹ năng" (skill) của riêng mình.

Tại sao tôi vẫn đọc code

Trước khi đi vào quy trình làm việc, tôi muốn giải quyết vấn đề "voi trong phòng".

Code review trong kỷ nguyên Agentic thực sự gây tranh cãi. Một số người nghĩ nó đang trở nên lỗi thời. Tôi thì không.

Các tác nhân AI viết rất nhiều code. Chúng cũng tạo ra rất nhiều "rác": những giải pháp chưa tối ưu, các mẫu mã không chuẩn, những thứ không phù hợp với quy ước của nhóm, và đôi khi chỉ đơn giản là lỗi (bug). Trách nhiệm vẫn thuộc về chúng ta. Thậm chí Boris Cherny, người tạo ra Claude Code, cũng nói rằng ông vẫn đọc code mà mình tạo ra.

Còn một lý do thực tế: người viết code có thể đi nghỉ tuần sau. Tôi cần có khả năng sở hữu nó, thay đổi nó và bảo vệ nó. Điều đó chỉ xảy ra nếu tôi thực sự hiểu nó trong quá trình review.

Tại PhaseV, CoPilot chạy tự động review trên mọi PR. Ngoài ra, tôi còn chạy thủ công các bài review kiểu one-shot bằng Codex và các kỹ năng có sẵn của Claude Code. Chúng phát hiện ra những vấn đề thực sự. Nhưng review tự động không giống như hiểu code. Điều đó vẫn cần con người.

Quy trình hoạt động

Nhóm chúng tôi viết các commit để kể câu chuyện về một sự thay đổi. Mỗi commit là nguyên tử và tập trung vào một mục đích.

Tôi gõ lệnh /review-pr-interactive kèm số PR. Từ đó:

• Claude kiểm tra nhánh (branch) và tóm tắt mục tiêu của PR.
• Nó liệt kê mọi commit với mô tả một dòng.
• Nó bắt đầu với commit đầu tiên: giải thích những gì đang diễn ra, đánh dấu những gì đáng chú ý, và hỏi ý kiến của tôi trước khi chúng ta chuyển sang bước tiếp theo.
• Tôi tự đọc commit. Nếu nó lớn hơn dự kiến, tôi yêu cầu Claude đề xuất thứ tự đọc các file trước khi tìm hiểu sâu.
• Chúng ta cùng quyết định điều gì đáng để bình luận.
• Claude sử dụng GitHub CLI để đăng bình luận chính xác vào dòng liên quan.

Sau đó chúng ta chuyển sang commit tiếp theo.

Khi tôi gặp thứ gì đó không nhận ra, tôi hỏi Claude và học điều mới, sau đó thường đăng lên Twitter dưới hashtag #TIL (Today I Learned - Hôm nay tôi đã học được).

Tại sao là "Skill" thay vì chỉ là Prompt?

Lúc này bạn có thể hỏi: tại sao phải chính thức hóa điều này thành một "skill"? Bạn có thể chỉ cần nói với Claude những gì bạn muốn mỗi lần thôi mà.

Câu trả lời là sự nhất quán. Mỗi khi tôi bắt đầu một bài review, Claude đã biết các quy ước của nhóm chúng tôi, giọng điệu chúng tôi dùng cho các bình luận, những gì được tính là "Nitpick" (soi mói chi tiết thừa thãi), và rằng nó nên đợi sự chấp thuận của tôi trước khi đăng bất cứ thứ gì. Tôi không phải giải thích lại. Tôi không quên nhắc đến điều gì. "Skill" là kiến thức tích lũy từ mọi phiên làm việc không suôn sẻ trước đó.

Một ví dụ cụ thể: trước khi tôi viết skill, Claude mất khoảng 3 lần thử mỗi phiên để tìm ra đúng lệnh gh để thêm bình luận vào một dòng cụ thể trong PR. Bây giờ nó được viết vào skill, và nó làm đúng ngay lần đầu.

Nó cũng giảm thiểu năng lượng kích hoạt. Gõ /review-pr-interactive 847 là rất trôi chảy. Viết một lời nhắc chi tiết từ đầu thì không.

Những gì chúng tôi thêm vào theo thời gian

Sau khi sử dụng nó hàng ngày, chúng tôi đã tinh chỉnh skill để phù hợp với cách nhóm làm việc:

• Định nghĩa trọng tâm — đặt những gì quan trọng nhất ngay từ đầu cho loại PR này.
• Gắn nhãn Nitpick — việc đánh dấu vấn đề phong cách là ổn, nhưng hãy đánh dấu rõ ràng chúng là Nitpick.
• Boy Scout commits — chúng tôi cho phép dọn dẹp những thứ không liên quan trong một commit riêng biệt nằm trong PR. Không cần PR riêng, chỉ cần giữ cô lập nó.
• Không tự động bình luận — Claude chờ sự chấp thuận rõ ràng của tôi trước khi đăng bất cứ thứ gì.

Một điều riêng lẻ chúng tôi phải định hình: hành vi của Claude khi phê duyệt một PR. Ban đầu, nó sẽ viết một bài tiểu luận dài tóm tắt mọi thứ mà PR làm như một phần của thông điệp phê duyệt. Rất kỳ lạ. Người tạo PR biết họ đã xây dựng gì. Chúng tôi định nghĩa trong skill rằng một lời "LGTM" đơn giản là đủ, hoặc một ghi chú ngắn về bất kỳ điều gì thực sự nổi bật.

Điều khiến tôi ngạc nhiên

Tôi mong đợi điều này giúp tiết kiệm thời gian. Nó đã làm đúng.

Điều tôi không mong đợi là nó khiến tôi hiện diện hơn trong bài review, không phải ít hơn. Với các công cụ tự động one-shot, tôi đọc một danh sách các phát hiện và chuyển tiếp. Với quy trình này, tôi thực sự đang ở trong code: đọc, đặt câu hỏi, đưa ra các quyết định quan trọng. AI xử lý phần khung sườn (scaffolding). Tôi mang đến sự thấu hiểu.

Cảm giác đó là sự phân chia lao động đúng đắn.

---

Bạn đang xử lý code review như thế nào khi AI viết ngày càng nhiều hơn trong cơ sở code của bạn?