Bài 8 — Tình huống thực chiến & lộ trình áp dụng cho team

Bài cuối gói mọi kiến thức vào các tình huống thật và một lộ trình đưa AI coding agent vào team mà không gây hỗn loạn.

Bốn tình huống thực chiến

Tình huống 1: Dev cá nhân, dự án cá nhân

Bạn build side project một mình. Ưu tiên tốc độ.

• Gõ nhanh: autocomplete (Copilot hoặc IDE AI-first).
• Task đa bước (thêm feature + test): Claude Code hoặc Cursor Agent.
• Kết luận: một plugin autocomplete + một agent là đủ.

Tình huống 2: Sửa bug trong codebase lớn, lạ

Bạn mới vào dự án 200k dòng, cần fix bug nhưng chưa thuộc code.

• Dùng agent có ngữ cảnh toàn dự án để "hỏi": Cursor (@) hoặc Claude Code (grep + đọc).
• Bắt agent viết test tái hiện bug trước khi sửa.
• Kết luận: ưu tiên công cụ hiểu codebase và chạy được test.

Tình huống 3: Task nền lặp lại, ít kiến thức ngầm

Nâng cấp thư viện toàn monorepo, hoặc viết test cho module cũ.

• Task tự chứa, kiểm chứng bằng build/test -> Devin (chạy nền) hoặc script hóa Claude Code/Aider.
• Kết luận: giao trọn gói, review PR cuối.

Tình huống 4: Team có quy ước nghiêm, cần audit

Công ty yêu cầu lịch sử commit sạch, kiểm soát chi phí và bảo mật.

• Aider cho commit từng bước minh bạch + chọn/tự host model.
• File quy ước dự án để đồng bộ chuẩn.
• Kết luận: minh bạch và kiểm soát quan trọng hơn tốc độ tối đa.

Lộ trình đưa vào team (6 bước)

• Thí điểm nhỏ: chọn 1–2 công cụ, một nhóm nhỏ, một loại task rõ ràng.
• Thiết lập nền tảng an toàn: nhánh riêng, review bắt buộc, file quy ước, chính sách secret.
• Viết quy ước dùng agent: khi nào được giao tự chủ, khi nào bắt buộc review kỹ, vùng cấm.
• Đo lường: thời gian hoàn thành task, tỉ lệ PR phải sửa lại, chi phí token/thuê bao.
• Chuẩn hóa stack: chốt tổ hợp autocomplete + agent hợp với team.
• Mở rộng dần: nhân rộng ra team lớn hơn kèm đào tạo.

Khung tư duy: Con người là Reviewer, không phải Typist

Vai trò của bạn dịch chuyển từ "người gõ code" sang "người định nghĩa vấn đề và review kết quả". Kỹ năng quan trọng nhất trở thành: viết yêu cầu rõ ràng, thiết kế tiêu chí kiểm chứng, và đọc diff nhanh mà sắc.

Checklist triển khai cho team

• [ ] Đã chọn công cụ theo tình huống, không theo hype?
• [ ] Có nền tảng an toàn (nhánh, review, secret, quy ước)?
• [ ] Có tài liệu "khi nào dùng công cụ nào"?
• [ ] Có chỉ số đo hiệu quả và chi phí?
• [ ] Đội đã được đào tạo cách giao việc + review?

Sai lầm thường gặp

• Triển khai đại trà ngay: chưa có quy ước và rào an toàn -> chất lượng giảm, mất niềm tin.
• Không đo lường: không biết công cụ có thật sự giúp hay chỉ tạo cảm giác nhanh.
• Ép cả team dùng một công cụ: khác nhau về task và thói quen; nên linh hoạt trong khung chung.
• Quên đào tạo kỹ năng review: agent càng mạnh, kỹ năng review càng là điểm nghẽn thật sự.
• Bỏ qua bảo mật/tuân thủ: một sự cố rò rỉ code/secret có thể xóa sạch mọi lợi ích tốc độ.

Kết khóa: không có công cụ tốt nhất tuyệt đối. Người giỏi là người biết định vị đúng công cụ theo tình huống, cấu hình ngữ cảnh tốt và vận hành an toàn — và giữ vai trò reviewer cuối cùng.

<!--les-append-->

Lộ trình đưa vào team: bốn bước, đừng nhảy bước

Lỗi phổ biến nhất là nhảy từ bước 1 sang bước 4. Kết quả: mỗi người dùng một cách, code không nhất quán, và sáu tháng sau không ai hiểu nửa codebase.

Quy tắc review cho PR có AI tham gia

Đội cần thống nhất bốn điều, và chúng đều đơn giản:

• Ghi rõ trong PR: phần nào AI viết. Không phải để đánh giá, mà để người review biết đọc kỹ chỗ nào.
• Người mở PR phải giải thích được mọi dòng. Đây là quy tắc trung tâm. "AI viết nên tôi không rõ" không phải câu trả lời được chấp nhận.
• PR do agent sinh phải đọc phạm vi trước logic. Xem bài 5.
• Test bị sửa thì phải nói rõ vì sao.

Quy tắc 2 là quy tắc giữ cho toàn bộ hệ thống này không sụp. Nó cũng là quy tắc tự nhiên giới hạn kích thước diff: bạn không giải thích được 800 dòng, nên bạn sẽ tự chia nhỏ.

Rủi ro dài hạn với đội: hai thứ

Kỹ năng người mới không hình thành. Một dev junior để AI viết code trong hai năm sẽ không học được cách gỡ lỗi, vì gỡ lỗi chỉ hình thành khi bạn tự viết ra bug và tự tìm. Cách phòng: junior tự viết phần lõi của mỗi tính năng, dùng AI cho phần quanh nó — và mỗi tuần có một buổi đọc code cùng nhau, không có AI.

Hiểu biết chung về codebase bị mỏng. Trước đây, code đi qua đầu ai đó. Bây giờ nó có thể không. Cách phòng: hai dòng lý do trong mỗi PR, và giữ thói quen review thật — không phải bấm duyệt.

Bốn tình huống, bốn cấu hình

Đo xem nó có giúp đội không

Sau ba tháng, xem bốn con số:

Dòng hai và dòng bốn là hai dòng quyết định. Merge nhanh hơn mà lỗi sản xuất tăng, hoặc junior không tiến bộ, thì đội đang mượn từ tương lai để chạy nhanh hôm nay.

Làm ngay

Xác định đội bạn đang ở bước nào trong bốn bước. Nếu bạn đã mở agent cho cả đội mà chưa có file hướng dẫn và quy tắc review, hãy lùi về bước 2 tuần này — lùi một bước bây giờ rẻ hơn nhiều so với dọn một codebase không nhất quán sau sáu tháng. <!--/les-append-->