Tối thứ Sáu, tôi có một task tưởng nhỏ: đổi flow export report để thêm một cột mới. Code nằm trong repo quen, test có sẵn, requirement nghe rõ. Tôi giao cho agent làm phần mechanical, đi lấy nước, quay lại thấy nó sửa đúng chỗ cần sửa, nhưng tiện tay refactor luôn một helper dùng chung. Test vẫn pass. Diff nhìn cũng sạch. Vấn đề là helper đó đang được một job nightly dùng với input khác. Nếu merge ngay thì thứ Hai mới nổ.
Đó là lúc tôi ngừng xem AI coding như một “người viết code nhanh” và bắt đầu xem nó như một workflow cần guardrail. Agent có thể rất giỏi khi task đủ rõ, repo đủ chuẩn, context đủ dày, và feedback loop đủ ngắn. Nó cũng có thể phá code theo cách rất tự tin nếu mình giao việc mơ hồ, không giới hạn file scope, không có test gate, hoặc không review diff theo blast radius.
Series này viết cho phần ở giữa đó: dùng AI coding để ship code hằng ngày, không phải demo, không phải hype, không phải benchmark công cụ. Tôi không bàn giá. Tôi cũng không đi vào internals của tool hay kiến trúc agent. Mục tiêu là field guide: trước khi giao task thì chuẩn bị gì, trong lúc agent chạy thì kiểm soát gì, sau khi có diff thì review, test, merge, deploy ra sao.
Đối tượng
Series này dành cho dev đang làm trong repo thật:
- Có git branch, PR, CI, staging, production.
- Có code cũ, convention cũ, nợ kỹ thuật cũ.
- Có teammate đang sửa song song.
- Có deadline, incident, rollback, và những file “đừng đụng nếu không cần”.
Không cần dùng đúng tool tôi dùng. Các pattern ở đây áp dụng được cho nhiều AI coding assistant: IDE chat, CLI agent, background worker, PR agent, hoặc một script gọi model qua API. Điểm chung là agent có thể đọc code, sửa file, chạy command, và trả diff cho mình review.
Nguyên tắc của series
Thứ nhất, AI coding không thay thế ownership. Người merge vẫn chịu trách nhiệm. Agent có thể viết 80% diff, nhưng bạn vẫn phải hiểu diff đủ để bảo vệ production.
Thứ hai, context là input kỹ thuật, không phải lời nhắc xã giao. Một task brief tốt có repo state, file scope, acceptance criteria, test command, rollback note, và những thứ không được làm. Prompt kiểu “fix bug này” là giao việc thiếu spec.
Thứ ba, test không chỉ là safety net, mà là language để nói chuyện với agent. Khi test fail rõ, agent có objective feedback. Khi không có test, agent sẽ tối ưu theo cảm giác “code trông hợp lý”.
Thứ tư, review AI diff khác review human diff. Với human, bạn đoán intent từ conversation, ticket, commit history. Với agent, intent có thể trôi trong quá trình chạy. Review phải bám vào blast radius, side effect, và những thay đổi ngoài scope.
Thứ năm, deploy là một phần của AI coding. Nếu agent sửa code nhưng không biết cách verify ở staging, không biết log nào cần xem, không biết rollback ra sao, thì workflow chưa xong.
Cấu trúc 15 bài
| # | Title | Status |
|---|---|---|
| 1 | Setup repo để AI agent không phá code | Đã xuất bản |
| 2 | Viết task brief để AI coding ship đúng việc | Đã xuất bản |
| 3 | Context pack: docs, memory, tracker cho AI coding | Đã xuất bản |
| 4 | Chia việc cho nhiều agent mà không phá worktree | Đã xuất bản |
| 5 | Review code AI viết như reviewer thật | Đã xuất bản |
| 6 | Test strategy khi AI viết code | Đã xuất bản |
| 7 | Debug khi agent sửa sai | Đã xuất bản |
| 8 | Branch, commit, PR | Đã xuất bản |
| 9 | Tracker JSON và progress loop | Đã xuất bản |
| 10 | Safety khi dùng MCP, tools, API | Đã xuất bản |
| 11 | Budget cho context, cost, time | Đã xuất bản |
| 12 | Deploy pipeline không được mơ hồ | Đã xuất bản |
| 13 | Rollback và incident khi code đã ra production | Đã xuất bản |
| 14 | Case study ship một feature end-to-end | Đã xuất bản |
| 15 | Anti-pattern checklist trước khi ship | Đã xuất bản |
Cách đọc
Ba bài đầu là nền. Nếu repo chưa có rule rõ, task brief còn mơ hồ, hoặc context nằm rải rác trong Slack, hãy đọc tuần tự. Từ bài 4 trở đi có thể đọc theo vấn đề đang gặp.
Nếu bạn đang lead một team nhỏ, bài 1, 2, 5, 7, 13 là bộ tối thiểu. Chúng giải quyết các lỗi đắt nhất: agent sửa ngoài scope, requirement thiếu, worker đạp file nhau, diff được review quá nhanh, và deploy không có checkpoint.
Nếu bạn dùng AI coding một mình, bài 2, 3, 6, 8, 12 sẽ hữu ích hơn. Một người làm solo thường không thiếu quyền sửa code; họ thiếu feedback loop đủ sắc để agent không đi vòng.
Tôi sẽ giữ series này thực dụng. Mỗi bài có ví dụ cụ thể, có tradeoff, có những câu “đừng làm vậy” nếu cách đó từng gây lỗi. Không có phần kết kiểu cổ vũ dùng AI nhiều hơn. Dùng ít mà ship chắc vẫn tốt hơn dùng nhiều rồi mất một buổi gỡ diff.
Ranh giới
Series này không phải tài liệu tool-specific. Tôi sẽ tránh đi sâu vào internals của từng công cụ, tránh lặp lại kiến trúc agent, và tránh so sánh giá. Những thứ đó có series khác phù hợp hơn. Ở đây, câu hỏi chính luôn là:
- Task này có đủ rõ để giao chưa?
- Repo đã có guardrail chưa?
- Context nào agent cần trước khi sửa?
- Diff này có vượt scope không?
- Test nào chứng minh thay đổi đúng?
- Deploy xong cần nhìn gì để biết chưa làm hỏng production?
Nếu trả lời được sáu câu đó, AI coding bắt đầu giống một công cụ engineering nghiêm túc hơn là một buổi pair programming may rủi.