Dev Tool Stack 2026: Từ Cursor, Claude Code Đến Quy Trình Code Review Với AI

Có lần một bạn junior hỏi mình: anh còn tự viết code không, hay đưa hết cho AI? Mình còn viết. Ít hơn nhiều.

Hai-ba năm nay thời gian trong ngày dịch chuyển hẳn. Từ tự tay gõ từng dòng sang ra quyết định, review, và chỉnh hướng cho agent. Phần khó không nằm ở chỗ chọn tool. Nằm ở chỗ vạch ranh giới: việc gì giao cho AI, việc gì tự giữ.

Đồ nghề mỗi ngày

Cursor là editor chính cho phần lớn việc viết code tương tác. Mình cần context đầy đủ của codebase, xem diff ngay tại chỗ, sửa qua sửa lại trong cùng một phiên làm việc. Cái mình thích nhất ở Cursor là nó hiểu context nhiều file cùng lúc, không phải mô tả lại thủ công mỗi lần hỏi.

Claude Code đóng vai khác hẳn. Đây là chỗ mình giao các task có phạm vi rõ ràng, chạy trong terminal, có thể để chạy nền trong lúc làm việc khác. Ví dụ: viết test cho một module, refactor một phần code theo convention mới, hoặc research một đoạn codebase lạ trước khi bắt tay vào sửa. Nó được dùng công cụ — đọc file, chạy lệnh, chạy test — nên tự kiểm chứng được phần việc của chính nó trước khi báo lại. Khác hẳn kiểu đoán ra code rồi đưa cho mình.

Gemini CLI để dành cho các tác vụ cần context window cực lớn. Đọc toàn bộ một service lớn để tóm tắt kiến trúc. Đối chiếu nhiều file log dài để tìm pattern bất thường. Không phải tool dùng hàng ngày. Nhưng lúc cần “nuốt” một lượng thông tin lớn trong một lần thì không có gì thay được.

Quy trình review PR trước khi merge

Trước khi một PR được merge, mình đi đúng ba bước.

1. AI review trước: chạy một pass review tự động, tập trung vào lỗi logic, edge case bị bỏ sót, và các pattern không nhất quán với phần còn lại của codebase. Bước lọc nhanh. Phần lớn lỗi hiển nhiên bị bắt ở đây — những lỗi mình dễ bỏ sót vì đã quá quen mắt với đoạn code vừa viết.
2. Tự review lại bằng mắt: đọc lại toàn bộ diff một lượt, chú ý nhất vào các đoạn liên quan trực tiếp đến tiền, dữ liệu khách hàng, hoặc thay đổi schema. Bước này mình không bao giờ bỏ qua, bất kể AI đã nói gì ở bước một.
3. Peer review với đồng đội: với các thay đổi rủi ro cao — migration, thay đổi API contract, logic thanh toán — vẫn cần một người khác trong team xác nhận. AI không thay thế được trách nhiệm giải trình của con người trong một thay đổi production.

Ba bước đó xếp thành một đường thẳng, và mình không nhảy cóc bước nào.

flowchart TD
    A["PR mở"] --> B["1. AI review tự động<br/>lỗi logic, edge case, pattern lệch"]
    B --> C["2. Tự đọc lại toàn bộ diff<br/>tiền, dữ liệu khách hàng, schema"]
    C --> D{"Rủi ro cao?<br/>migration, API contract, thanh toán"}
    D -->|Có| E["3. Peer review với đồng đội"]
    D -->|Không| F["Merge"]
    E --> F

Mình coi AI như một reviewer rất chăm, nhưng thiếu ngữ cảnh nghiệp vụ. Nó chỉ ra được “đoạn này thiếu xử lý null”. Nó không biết trường đó được phép null khi khách đặt tour theo nhóm mà chưa chọn đủ thành viên. Tốc độ phát hiện lỗi tăng lên thật. Còn trách nhiệm cuối cùng thì vẫn nằm ở người bấm merge.

Chỗ nào để AI tự chạy, chỗ nào tự tay

Phần này mình nghĩ quan trọng nhất. Cũng là phần dễ bị lạm dụng nhất nếu không có kỷ luật rõ ràng.

Giao cho AI nhiều hơn:

• Viết test case cho logic đã có sẵn và rõ ràng — function thuần, không side-effect phức tạp.
• Refactor cú pháp, đổi tên biến, chuẩn hoá code style theo convention đã thống nhất.
• Viết tài liệu, README, comment giải thích cho code cũ chưa có docs.
• Research, đọc hiểu một phần codebase lạ trước khi mình tự tay sửa.

Tự tay kiểm soát chặt, hạn chế để AI tự quyết định:

• Logic động đến tiền: tính giá, áp dụng khuyến mãi, xử lý refund, đối soát thanh toán.
• Race condition, concurrency, transaction boundary trong database. Lớp bug này cực khó thấy khi review nhanh, mà hậu quả thì nặng — mình có hai bài riêng về cache invalidation và race condition thanh toán.
• Thay đổi schema production hoặc migration chạy trên dữ liệu thật. Luôn tự tay viết, tự tay review từng dòng SQL, không bao giờ để agent tự ý chạy migration lên môi trường có dữ liệu thật.
• Quyết định kiến trúc ảnh hưởng dài hạn — chọn pattern, chọn công nghệ. AI đề xuất phương án được. Người quyết vẫn là mình, vì mình là người bảo trì nó hai năm sau.

Hai cột việc này nhìn thì rõ, nhưng ranh giới giữa chúng mờ hơn tưởng.

flowchart LR
    T["Task cần làm"] --> Q{"Chạm vào tiền, schema,<br/>concurrency hay kiến trúc dài hạn?"}
    Q -->|Không| AI["Giao cho AI<br/>test, refactor, docs, research"]
    Q -->|Có| HAND["Tự tay viết và review"]
    AI --> CK["Agent tự kiểm chứng<br/>test, type-check, build"]
    CK --> PR["PR nhỏ, review được trong một lần đọc"]
    HAND --> PR

Chỗ mình không nhượng bao giờ: các thao tác có thể gây thiệt hại — xoá dữ liệu, deploy, migration — luôn phải có một bước dừng lại để con người xác nhận trước khi thực thi.

Mấy thói quen khi làm việc với agent

• Mô tả rõ phạm vi trước khi giao task. Một task mơ hồ kiểu “sửa cho tốt hơn” luôn dẫn đến kết quả lan man, agent tự ý refactor những phần không ai yêu cầu.
• Yêu cầu agent tự kiểm chứng trước khi báo kết quả — chạy test, chạy type-check, build thử — thay vì nhận code rồi tin mù quáng.
• Giữ task đủ nhỏ để review được trong một lần đọc. PR do AI sinh ra mà quá lớn thì người review khó review kỹ, dẫn đến review hời hợt và bỏ sót lỗi.
• Lưu lại ngữ cảnh quan trọng ở dạng văn bản — README, comment, ghi chú quyết định kiến trúc. Để agent lần sau không phải đoán lại từ đầu, và để chính mình sau vài tháng cũng không quên lý do đằng sau một quyết định.
• Không bao giờ để agent tự quyết định việc gì cần user xác nhận.

Bộ tool, và cái còn thiếu

Bộ tool hiện tại giúp mình làm được nhiều việc hơn trong cùng một khoảng thời gian. Bản chất công việc thì chưa đổi: hiểu đúng vấn đề, ra quyết định đúng, và chịu trách nhiệm cho quyết định đó.

AI chạy tốt nhất khi được giao việc có phạm vi rõ ràng và được kiểm chứng kỹ. Còn cái nút bấm ra code đúng mà không ai review lại thì vẫn chưa có. Mình cũng chưa thấy nó sắp có.