Cách mình sài AI để coding như nào?

Xưa mình chuyển tay bằng Ctrl + C

Xưa mình xài Claude Code, hoặc Codex. Đang làm task, hết quota một cái là mình Ctrl + C, bật qua con khác, bảo nó đọc lại nội dung session của con trước rồi làm tiếp.

Nghe thì đơn giản. Nhưng làm vài lần là thấy cực. Mà cực nhất không phải chuyện thao tác, là chuyện tiền. Một session đã chạy rất dài, con mới vào phải đọc lại từ đầu để hiểu, riêng cái lượt đọc đó đã tốn một mớ token rồi. Chưa làm được gì hết mà đã tốn.

Con mới không thật sự ở trong session cũ. Nó có thể đọc lại những gì mình đưa, nhưng vẫn mất thời gian để hiểu project, hiểu mình đang sửa cái gì, vì sao lại chọn hướng đó. Có lúc con trước đã làm dở một đoạn, con sau vào đọc không kỹ rồi sửa ngược lại. Hoặc nó làm tiếp được, nhưng mình lại phải ngồi giải thích từ đầu như đang handover cho người khác.

Cái bất tiện nhất là mình thành người chuyển task bằng tay. Hết quota thì mình đổi cửa sổ, gom context, chép qua, chờ nó đọc, rồi mới làm tiếp. Nếu chỉ có một việc nhỏ thì không sao. Nhưng lúc đang chạy một task dài, có plan, code, review, sửa lỗi, rồi lại cần thêm người xem một góc khác, cách này bắt đầu rối.

Mình cũng từng nghĩ chuyện này chỉ là mua thêm quota thôi. Nhưng không hẳn. Có thêm quota mà vẫn để một con vừa lên plan, vừa code, vừa tự review thì vẫn có chỗ không ổn. Nhất là khi mình dùng nhiều CLI agent trên cùng máy rồi.

Mình build một app quản lý tài khoản cho đỡ cực

Sau đó mình có build một app quản lý đa tài khoản tên là AI Account Management. Link ở đây nha: https://github.com/hoangpm96/ai-switcher/releases/latest.

Ban đầu mình build nó khá thực dụng thôi. Mình có nhiều account, không muốn mỗi lần đổi account lại phải tự nhớ đang xài cái nào, quota còn ra sao, rồi config lại từng chỗ. Có cái quản lý ở giữa thì đỡ cực hơn.

Nhưng cái làm mình đổi cách dùng lại không phải bản thân cái app. Là lúc mình tận dụng được việc agent bên này gọi CLI agent bên kia, cộng thêm chuyện chia việc.

Thay vì coi mỗi con AI là một cửa sổ chat để thay nhau làm một task, mình bắt đầu coi tụi nó là nhiều người trong một team nhỏ. Có người điều phối, có người code phần dài, có người xử lý task ngắn mà nặng edge case, có người review, có người vào sân khi hết quota.

Mình có một skill tên là delegate trong bộ BA-Kit mình bán. Thật ra mình chưa giới thiệu nó nhiều, cũng chưa có video chính thức hướng dẫn cách dùng, nên chắc nhiều bạn chưa xài tới. Nó không phải kiểu cài vào rồi tự nhiên mọi thứ chạy ngon. Nó là một bộ hướng dẫn để con điều phối biết phải nhìn gì, chia việc ra sao, gọi agent nào trong trường hợp nào.

Vì sao mình để Claude Code với Opus làm người điều phối

Mình thường để Claude Code chạy model Opus làm người điều phối. Mình cảm giác con này lên plan, rồi chia việc khá ổn. Chưa kể nó hiểu context tốt, hay là do mình nói chuyện với nó dễ hiểu hơn cũng nên.

Một task lớn thường không chỉ có chuyện “viết code này”. Nó có thể cần đọc repo, hiểu chỗ đang lỗi, lên plan, tách phần nào độc lập được, phần nào phải làm trước, rồi sau đó mới giao code và review. Nếu người điều phối không nắm được mạch đó thì nó chia task nhìn có vẻ hợp lý nhưng thực tế lại đụng nhau.

Ví dụ, một agent đang refactor xuyên nhiều file thì không nên cùng lúc để con khác sửa một business rule nằm đúng trong luồng đó mà không biết nhau. Hoặc có task chỉ cần một function backend ngắn, nhưng lại nặng edge case. Nếu giao nhầm cho con đang phải ôm cả context rộng thì nó vừa chậm vừa tốn quota.

Opus ở đây không phải chỉ ngồi viết code. Nó đọc đầu bài, đọc skill delegate, nhìn các agent mình đang có, rồi quyết định nên tách hay không. Việc nhỏ, rõ, ít rủi ro thì có thể giao thẳng. Việc dài thì nó lên plan trước. Việc cần review thì nó chừa một ghế khác để review, không tự vừa làm vừa kết luận là ổn rồi.

Định danh sẵn từng con, rồi để nó tự đọc quota

Mình khai báo sẵn cho Opus biết trên máy có những AI coding agent nào. Claude Code, Codex, agy, OpenCode. Toàn là CLI.

Nếu mình có hai account Claude Code và hai account Codex thì mình định danh sẵn từng cái luôn. Ví dụ claude-k, claude-a, codex-1, codex-4. Đừng để nó chỉ biết chung chung là “có Claude” hoặc “có Codex”. Vì lúc cần gọi việc, nó phải biết chính xác đang gọi account nào, account đó còn quota không, và phù hợp với loại việc nào.

Khi nhận một task, Opus sẽ phân tích trước. Nếu cần, nó đọc lại hướng dẫn trong skill để biết kiểu task này nên chia như thế nào. Sau đó nó gọi một script để nắm quota của mấy con kia. Rồi mới tự chia việc theo yêu cầu mình đưa.

Cách này nghe có vẻ nhiều bước hơn Ctrl + C. Nhưng thực tế đỡ mất công hơn nhiều. Mình không cần tự nhớ hôm nay Codex nào còn quota, Claude nào vừa chạy một chuỗi dài, OpenCode đang usable hay không. Con điều phối có đủ thông tin thì nó tự chọn ghế phù hợp.

Dĩ nhiên mình vẫn xem lại khi task quan trọng. Không phải để AI tự chia gì cũng được. Nhưng ít nhất mình không còn phải làm người trực tổng đài, chuyển từng đoạn context qua lại nữa rồi.

Bảng phân ghế mình đang chạy

Mình xài gói 20X/5X Claude và có hai account Codex, nên hiện tại mình ưu tiên Claude nhiều hơn. Đây là bảng mình đang chạy. Máy bạn có agent khác, quota khác thì bảng cũng khác thôi.

| Loại việc | Giao cho | Vì sao |
|—|—|—|
| Plan, spec, PRD, tech-design | Claude Fable | Hết quota mới lùi về Opus, không lùi xuống model rẻ hơn với tài liệu cần duyệt. |
| UX/UI, user flow, copy, phân tích theo vai người dùng | Claude Opus | Cần hiểu trải nghiệm, context và cách người dùng đi qua flow. |
| Code product dài, context rộng, refactor xuyên nhiều file | Claude Opus | Giữ mạch xử lý rộng tốt hơn, phù hợp phần code cần hiểu nhiều chỗ. |
| Code product ngắn, atomic, nặng edge case, backend logic | Codex Sol, effort cao | Task rõ biên nhưng cần soi logic kỹ. |
| Viết checklist, test case | Codex gpt-5.6-sol | Loại việc cần liệt kê đủ case, không được sót nhánh. |
| Audit code, review spec/plan, viết gate script | Codex | Tách người làm với người kiểm, có thêm góc nhìn khác. |
| Khi Codex hết quota hoặc mình chỉ định thẳng | OpenCode | Ghế dự bị, chỉ vào sân khi cần. |
| Review phụ | Gemini | Flash cho lượt nhanh, Pro cho việc rủi ro cao. |

Điểm mình cần nhất từ bảng này là quyết định nhanh. Khi nhận việc, không phải ngồi suy nghĩ lại từ đầu xem “con nào mạnh hơn”. Mình nhìn hình dạng công việc trước: cần plan hay code, dài hay ngắn, context rộng hay hẹp, sai có tốn nhiều vòng fix không.

Tên model sau này có thể đổi. Quota cũng đổi. Nhưng kiểu phân ghế thì vẫn giữ được.

Vì sao Opus và Codex vẫn là hai tay code chính

Opus và Codex vẫn là hai tay code chính của mình. Không phải vì mấy con khác không làm được gì, mà vì đây là chỗ mình không muốn tiết kiệm sai.

Code sai một chỗ là kéo theo cả chuỗi: logic sau đó lệch, test lệch, review thêm lượt, fix thêm lượt. Thà tốn thêm ít tiền còn hơn code sai rồi review lại fix cũng tốn một mớ token.

Mình để Opus xử lý code dài, context rộng, refactor xuyên nhiều file. Loại này cần hiểu cả mạch. Nếu nó chỉ nhìn một file rồi sửa thì dễ tạo ra một đoạn code đúng cục bộ nhưng lệch với phần còn lại.

Còn Codex Sol effort cao thì mình hay giao task ngắn, atomic, nhưng nặng edge case hoặc backend logic. Ví dụ một rule cần xử lý đủ case, một API cần validate kỹ, một đoạn logic không dài nhưng sai là khó tìm. Cái hay của task atomic là giao xong cũng dễ review hơn.

OpenCode vẫn có giá trị, nhưng với mình nó là ghế dự bị. Nó chỉ vào sân khi Codex hết quota mà việc vẫn phải chạy, hoặc khi mình chỉ định thẳng dùng nó. Mình không tự động đẩy phần lõi qua đó chỉ vì thấy còn quota.

Mấy việc gen hình thì mình làm hơi khác. Mình đẩy account Codex lên 9router để ra API, rồi gọi qua một function tạo ảnh theo style mình định sẵn. Như vậy lúc cần hình cho bài, prototype hay tài liệu thì mình không phải đổi sang một quy trình khác hoàn toàn.

Người code và người review phải là hai con khác nhau

Quy tắc này mình giữ khá chặt: người code và người review phải là hai model hoặc agent khác nhau.

Một con vừa làm xong rồi tự review lại phần của nó thì vẫn có ích. Nhưng nó rất dễ bỏ qua đúng kiểu lỗi mà nó vừa tạo. Không phải vì nó cố tình thiên vị. Chỉ là cách nó hiểu bài toán, cách nó suy luận và những giả định ban đầu của nó vẫn còn đó.

Nên Opus code thì Codex review. Codex code thì Opus, hoặc một con khác, đọc lại. Gemini có thể vào review phụ nếu mình cần thêm một lượt nhanh. Có lúc mình cho agy vào join để debate, nhất là khi hai hướng xử lý đều có lý do mà mình chưa chắc nên chọn bên nào.

Checklist với test case thì mình dành hẳn cho Codex gpt-5.6-sol viết. Loại việc này không cần văn hay, nó cần liệt kê đủ case và không bỏ sót nhánh nào. Con nào hay soi edge case thì giao đúng chỗ đó. Mà cũng tiện, người viết test không phải người viết code thì tự nhiên có thêm một lớp kiểm nữa.

Review cũng không cần làm quá nặng cho mọi task. Task nhỏ, output rõ thì chỉ cần một lượt kiểm đúng trọng tâm. Nhưng với plan, spec, code product hoặc thay đổi có rủi ro, mình muốn có một người khác nhìn vào.

Cách này tốn thêm token thật. Nhưng ít nhất lỗi được nhìn bằng một góc khác. Và khi reviewer nói còn lỗi, người code có đầu việc cụ thể để fix, không phải hai con thay nhau nói chung chung là “cần cải thiện”.

Plan code phải là một file cụ thể

Cái này lúc mới dùng nhiều agent mình không nghĩ là quan trọng: plan code phải là một file cụ thể.

Không phải plan nằm trong chat, không phải một đoạn tóm tắt rải ở nhiều session. Một file thật sự trong repo hoặc chỗ mình đã định sẵn. Trong đó ghi tổng quan đang làm gì, phạm vi nào, các đầu việc cần làm, thứ tự nếu có phụ thuộc, và những chỗ chưa chốt.

Làm xong đầu việc nào thì check vào file đó. Chưa xong thì để nguyên. Nếu phát hiện thêm việc mới thì thêm vào. Nếu có quyết định quan trọng, ghi ngắn lý do luôn.

Vì khi nhiều agent thay phiên nhau, mỗi con đều có thể vào giữa chừng. Opus có thể lên plan rồi hết quota. Codex vào xử lý một phần. Một agent khác review, phát hiện lỗi. Sau đó Claude khác quay lại làm tiếp. Nếu không có file plan, agent mới phải đọc lại session, đọc diff, đoán xem những gì đã xong, rồi mới dám động vào.

Còn có file đó thì con khác vào làm tiếp chỉ cần đọc là biết tổng quan đang làm gì, làm tới đâu, tiếp theo làm gì. Nó giảm chuyện làm trùng, giảm chuyện bỏ sót, và quan trọng là giảm context phải chép qua.

À, cùng mục đích đó thì mình còn xài cả kg với codegraph nữa, để agent tìm đúng chỗ cần đọc thay vì quét cả repo. Đỡ tốn token hơn hẳn. Phần này dài, có thời gian mình sharing sau nha.

Nó cũng giúp mình kiểm. Nhìn file là biết task đang kẹt ở đâu. Kẹt vì chưa rõ yêu cầu, vì code chưa xong, vì review chưa qua, hay đơn giản là agent kia hết quota. Nếu mọi thứ chỉ nằm trong các session thì đến mình còn khó nhớ, chưa nói gì con khác.

Bốn mươi phút mất trắng vì chẩn đoán sai

Mình từng mất khoảng 40 phút vì chẩn đoán sai một CLI đứng im. Lúc đó là OpenCode. Nhìn bên ngoài thì nó giống đang chạy chậm: tiến trình vẫn còn sống, không báo lỗi, nhưng cũng không ra output.

Mình retry rồi chờ tiếp. Sau đó mới biết bản chất là OpenCode đã hết quota tuần và treo im, không báo lỗi rõ. Bốn mươi phút đó coi như mất trắng.

Cái khó là ba triệu chứng nhìn khá giống nhau, nhưng xử lý lại ngược nhau:

• Tiến trình đã chết, output rỗng, có thể là session khác trên cùng máy đã giết nó. Retry không giải quyết gì, phải chuyển sang agent khác.

• Tiến trình còn sống nhưng đứng im, nhiều model đều có hiện tượng tương tự, thì có thể là hết quota tuần. Chờ thêm cũng không tự hết.

• Báo lỗi rõ ngay từ đầu thì model đó không được phục vụ. Đổi model là được, không cần đổi cả công cụ.

Chỗ này script đọc quota của mình cũng chịu. Nó chỉ thấy được mấy account đi qua app quản lý tài khoản, tức là Claude với Codex. Còn OpenCode thì nó không nhìn thấy quota, nên con điều phối tưởng là vẫn dùng được.

Nên từ vụ đó, trước khi mở một chuỗi việc dài trên CLI mà script không đọc được quota, mình chạy smoke test 30 giây bằng model rẻ trước. Chỉ một prompt ngắn để xem nó còn trả lời không. Mất 30 giây vẫn rẻ hơn ngồi nhìn một tiến trình treo 40 phút rồi.

Mấy quy tắc nhỏ mình tự đặt cho mình

Ngoài bảng phân ghế và file plan, mình có vài quy tắc nhỏ. Không phải cái nào cũng áp dụng y chang cho mọi task, nhưng nó giúp mình đỡ bị quota kéo đi theo cảm tính.

• Thà tốn thêm ít tiền ở phần code chính còn hơn để code sai, rồi mất thêm token cho review và fix. Chỗ cần chắc thì đừng cố rẻ quá.

• Dụ người quen hoặc công ty mua cho account 5X, 20X. Dĩ nhiên mình phải cho ngược lại họ cái gì đó rồi, chứ không phải tự nhiên ai cũng đi mua account cho mình.

• Người code và người review phải khác model hoặc agent. Nếu cần thì thêm agy vào debate, nhưng debate để lộ góc nhìn khác chứ không phải để kéo dài cho vui.

• Không để context quan trọng chỉ nằm trong chat. Plan, trạng thái task, đầu việc đã xong, lỗi reviewer bắt được đều phải có chỗ ghi lại.

Mình không đặt quy tắc kiểu tuyệt đối là task nào cũng phải ba con vào. Làm vậy lại thành nặng. Mục tiêu là dùng đủ người cho đúng việc, không phải dựng một team đông chỉ để làm một việc nhỏ.

Nếu bạn muốn thử, bắt đầu từ đâu

Skill delegate trong BA-Kit của mình chỉ là một version đơn giản thôi. Nó giúp có khung ban đầu, nhưng không thể biết máy bạn đang có gì, quota của bạn ra sao, hay loại việc bạn hay làm nhất là gì.

Nếu muốn thử, mình nghĩ bạn nên cho AI đọc xem trên máy mình đang có những AI agent nào trước. Định danh từng con. Nếu có nhiều account cùng một CLI thì đặt tên rõ. Đừng để nó tự đoán claude-k với claude-a là gì.

Sau đó thêm công thức chia việc của riêng bạn. Bạn có thể chỉ có một Claude, một Codex và một con dự bị thôi cũng được. Quan trọng là ghi rõ task nào giao ai, khi nào đổi sang ghế dự bị, task nào bắt buộc phải có review khác model.

Rồi tạo một file plan cho task kế tiếp. Không cần làm một hệ thống lớn ngay. Cứ thử một task có vài đầu việc, check dần trong file, để một agent khác vào làm tiếp. Bạn sẽ thấy ngay chỗ nào đang mất thời gian: quota, context, cách chia task, hay review.

Có mấy thứ chỉ dùng mới biết không hợp. Nên mình nghĩ cứ để AI đọc tình trạng thật trên máy bạn, định danh chúng, rồi thêm công thức của riêng mình vào thì xài mới ổn nha.

Kết lại

Giờ mình không còn coi chuyện hết quota là Ctrl + C rồi chạy qua con khác nữa. Mình vẫn có thể đổi agent, nhưng đổi theo plan, theo quota và theo ghế đã định sẵn.

Claude Code với Opus đang là người điều phối mình thấy hợp. Opus và Codex là hai tay code chính. Các con khác có ghế riêng để review, dự bị hoặc cho thêm góc nhìn. Còn file plan là thứ giữ cho cả chuỗi không bị đứt khi nhiều agent thay nhau làm.

Bạn không cần có đúng bộ tool như mình. Nhưng nếu đang xài nhiều AI CLI rồi, thử định danh chúng, chia ghế, cho chúng đọc quota và giữ plan trong một file cụ thể. Làm vậy đỡ cực hơn nhiều rồi.