Tui Học AI – Bài 6 – “Tôi làm với 1 AI” → “Tôi điều phối nhiều AI song song”

Tui từng tin mở 5 tab Cursor là làm việc song song. Cho tới khi thấy màn hình của một anh tech lead: 3 session, mỗi session một vai, và một file bàn giao mà tui chưa từng nghĩ tới. Bài thứ sáu trong series.

Đọc lại bài viết trước đó tại: Tui Học AI – Bài 5 – “Tôi xài AI lẻ tẻ” → “Tôi đóng gói AI thành sản phẩm dùng chung”

1. Năm cái tab và 40 phút gỡ conflict

Chiều thứ Sáu nọ, tui nhận một feature thanh toán. Tui nghĩ mình khôn:

• Mở luôn 5 tab Cursor, chia việc cho cả đám.
• Tab viết endpoint.
• Tab viết validation.
• Tab viết test.
• Tab sửa đoạn service cũ.
• Tab còn lại để hỏi vặt.

Nghe rất “song song”. Thực tế thì suốt buổi chiều tui làm đúng một nghề: bưu tá. Copy output tab này, dán qua tab kia, kèm câu “dựa vào đoạn code này”. Tab nào cũng chỉ biết mỗi phần tui dán cho nó. Không tab nào biết bốn tab còn lại tồn tại.

Cuối ngày tui merge. Hai tab cùng sửa một file service, mỗi tab sửa một kiểu. Tui ngồi gỡ conflict hết 40 phút. Gỡ xong thì test đỏ, vì bản merge tay của tui giữ nhầm phía.

Tuần sau đó, tui ngồi cạnh một anh tech lead dự án khác.

• Màn hình ảnh chia ba: ba session Claude Code chạy cùng lúc.
• Một session đang viết code.
• Một session đang review đúng đoạn code session kia vừa viết.
• Session còn lại viết test.

Tui buột miệng: “Anh không sợ tụi nó giẫm chân nhau hả?”

Ảnh không trả lời liền. Ảnh mở cho tui coi hai thứ. Thứ nhất, mỗi session chạy trên một worktree riêng, không đứa nào đụng thư mục của đứa nào. Thứ hai, một file tên handoff.md. Session nào xong việc phải viết vào đó. Session nào nhận việc phải đọc nó trước khi gõ dòng đầu tiên.

Cùng là mở nhiều AI. Khác nhau ở chỗ một bên có bưu tá chạy giữa, một bên có nhạc trưởng đứng giữa. Bài này nói về bước chuyển đó.

2. Không phải mở thêm tab, là thiết kế cách chúng truyền việc

“Tôi làm với 1 AI” → “Tôi điều phối nhiều AI song song”

Năm bậc trước, dù bạn dùng AI giỏi tới đâu, mọi thứ vẫn là một cuộc hội thoại tại một thời điểm. Xong việc này mới tới việc kia. Mở thêm tab không đổi được điều đó. Bạn chỉ có nhiều cuộc hội thoại rời rạc, và chính bạn phải chạy qua chạy lại vác context giữa chúng.

Bậc sáu đổi vai của bạn.

• Nhiều session chạy cùng lúc, mỗi session một vai rõ, như một dàn nhạc có bè.
• Việc truyền từ session này sang session kia đi theo luật, không đi theo trí nhớ của bạn.
• Khi hai session cho ra hai hướng ngược nhau, có luật để phân xử.

Còn bạn đứng ở chỗ của nhạc trưởng: không chơi thay bất kỳ nhạc công nào, chỉ giữ nhịp, và ra quyết định ở vài điểm quan trọng.

Có một câu test gọn cho bậc này: session review của bạn biết được bao nhiêu về lý do mà session code đã chọn cách viết đó? Nếu câu trả lời là “nó chỉ thấy code”, bạn chưa ở bậc sáu. Bạn đang có nhiều AI, nhưng chưa có dàn nhạc.

Nói luôn một điều ngược tai: song song không tự động nhanh hơn. Tuần đầu tui thử, tổng thời gian còn chậm hơn làm một mình. Song song chỉ trả lãi khi có luật. Vậy soi cụ thể thế nào? Ba dấu hiệu chưa chuyển trước.

3. 3 dấu hiệu bạn chưa chuyển

1. Nhiều tab, nhưng tab nào cũng chung một vai

Soi lại 5 cái tab của tui hôm đó:

• Tab nào cũng là thợ code.
• Không tab nào được giao đứng phía đối diện để soi lỗi.
• Không tab nào giữ vai người thử phá.

Năm tab, một vai.

Nhiều tab cùng vai không phải song song. Đó là một người nói chuyện với năm cái gương. Output nhân lên, nhưng góc nhìn vẫn là một. Lỗi mà một tab bỏ sót, bốn tab kia bỏ sót y chang, vì tụi nó nhìn bằng cùng một con mắt bạn đưa cho.

2. Bạn là đường truyền duy nhất giữa các session

Dấu hiệu này soi được bằng bàn phím: đếm số lần bạn copy từ chat này dán qua chat kia trong một buổi. Hôm đó tui đếm lại lịch sử, hơn hai chục lần dán. Mỗi lần dán là một lần rơi rớt. Dán code nhưng quên dán cái ràng buộc đã chốt ở tab kia. Dán yêu cầu nhưng thiếu lý do vì sao đã bỏ hướng A chọn hướng B.

Hệ quả là session sau luôn làm việc với một nửa sự thật. Nó review rất tự tin trên cái nửa nó thấy. Nửa còn lại, chỗ bug hay trốn, nằm trong đầu bạn và trong cái tab bạn quên dán.

3. Hai session cãi nhau, bạn đứng hình

Session code chọn cách X. Session review phán X có vấn đề, đề nghị cách Y. Bạn ngồi giữa, đọc cả hai, thấy bên nào cũng có lý, rồi chọn đại một bên cho xong. Tuần sau gặp tình huống y hệt, bạn lại ngồi phân xử từ đầu, có khi chọn ngược lại.

Vấn đề không nằm ở chỗ hai AI mâu thuẫn. Mâu thuẫn là chuyện bình thường, reviewer với coder người thật cũng cãi nhau hoài. Vấn đề là bạn chưa có luật: loại mâu thuẫn nào để AI tự xử theo convention của dự án, loại nào phải đưa lên cho bạn quyết. Chưa có luật thì mỗi lần cãi là một lần tốn não lại từ đầu.

4. 3 dấu hiệu bạn đã chuyển

1. Mỗi session một vai, giao hẳn thành lời mở đầu

Người ở bậc sáu mở session nào là giao vai cho session đó ngay câu đầu tiên, và vai đi kèm giới hạn. Coder chỉ code trong phạm vi giao. Reviewer chỉ soi, cấm viết code mới. Tester chỉ viết test và báo kết quả. Đây là câu tui dùng mở session review, bạn lấy xài luôn được:

Prompt (mở session review):
Bạn là reviewer của feature auth-webhook.
Đọc file handoff/auth-webhook.md trước khi làm gì khác.
Sau đó review diff trên nhánh review-auth theo đúng các
ràng buộc ghi trong file đó. Chỉ soi và ghi nhận xét,
không viết code mới. Mỗi lỗi ghi rõ: file, dòng, lý do,
mức độ (chặn merge / nên sửa / góp ý).

Cái câu “chỉ soi, không viết code mới” nghe thừa mà không thừa. Thiếu nó, session review rất hay tự ý sửa luôn, và bạn quay về cảnh hai bản code lệch nhau không biết bản nào thật.

2. Mỗi session một khoảnh đất riêng

Hết cảnh hai session cùng cào một file. Mỗi session làm việc trên một worktree riêng: cùng một repo, nhưng mỗi session có thư mục riêng, nhánh riêng. Ai chưa xài git worktree thì hình dung nó như chia repo thành mấy khoảnh ruộng. Cùng một mảnh đất gốc, mỗi người cày một khoảnh, tới mùa mới gom về.

Lệnh chỉ có vậy: git worktree add ../review-auth review-auth. Từ lúc chuyển qua kiểu này, chuyện gỡ conflict 40 phút như buổi chiều đầu bài không quay lại nữa. Conflict lúc merge vẫn có thể có, nhưng là conflict bạn thấy trước và chủ động xử, không phải conflict rơi trúng đầu.

3. Bàn giao cả lý do, không chỉ code

Đây là dấu hiệu đắt nhất, và là cái file làm tui đứng nhìn màn hình anh tech lead lâu nhất. Bàn giao giữa hai session không phải một cục code dán qua. Là một file bốn phần:

# HANDOFF: auth-webhook

## Làm gì
Thêm endpoint nhận webhook từ cổng thanh toán,
verify chữ ký, ghi event vào bảng payment_events.

## Vì sao làm vậy
Verify chữ ký bằng thư viện chính chủ của cổng, không tự
so chuỗi, vì team từng dính lỗi bảo mật khi tự so.

## Ràng buộc
- Không đụng vào PaymentService hiện có
- Webhook phải idempotent: nhận trùng không ghi trùng
- Trả response dưới 3 giây, việc nặng đẩy vào queue

## Quyết định đã chốt
- Ghi bảng riêng payment_events, không ghi chung bảng orders
- Retry là việc của cổng thanh toán, mình chỉ trả mã chuẩn

Kể bạn nghe lần tui hiểu ra giá trị của phần “Ràng buộc”. Lần đầu áp dụng, tui làm biếng, chỉ dán code qua cho session review. Nó khen code sạch, cho qua hết. Ba hôm sau trên staging, webhook bị gửi trùng, event ghi trùng theo. Session review không sai. Nó không hề biết có ràng buộc idempotent, vì ràng buộc đó nằm trong đầu tui và trong session code.

Tui viết lại file handoff đủ bốn phần, đưa cùng đoạn code cho cùng session review đó. Lần này nó ghi ngay một dòng chặn merge: chưa thấy xử lý idempotent như ràng buộc trong handoff. Cùng một AI. Khác nhau đúng một file.

5. Bài tập tuần này

Ba mươi phút, và bạn chỉ cần hai session.

Chọn một việc nhỏ sắp làm: một hàm, một endpoint, một đoạn refactor gọn. Mở session thứ nhất, giao vai code. Mở session thứ hai, giao vai review bằng câu prompt mẫu ở trên.

• Luật chơi duy nhất: cấm copy output trực tiếp từ session này qua session kia.
• Mọi thứ đi qua một file handoff.md bốn phần: làm gì, vì sao, ràng buộc, quyết định đã chốt.
• Session code xong thì viết file.
• Session review đọc file rồi mới soi code.

Cái cần có sau 30 phút: một file handoff.md đầu tiên của bạn, và một bản review do session thứ hai viết. Đọc bản review đó, tự hỏi một câu: có nhận xét nào mà nếu thiếu file handoff nó không thể bắt được không? Nếu có, bạn vừa cảm được bậc sáu bằng tay, không phải bằng lý thuyết.

Tạm kết

Nếu bài này chỉ giữ lại một câu: điều phối nhiều AI không phải là mở nhiều tab, mà là thiết kế cách chúng truyền việc cho nhau.

Vai rõ để có nhiều góc nhìn thật, không phải năm cái gương. Đất riêng để không giẫm chân. Và bàn giao thì truyền cả lý do, vì lý do mới là thứ giúp session sau nhìn ra cái mà code không tự nói.

Nhớ buổi chiều 40 phút gỡ conflict đầu bài không? Feature thanh toán gần nhất, tui chạy lại đúng kiểu ba session của anh tech lead. Không nhanh hơn kiểu cũ bao nhiêu đâu, tui đo rồi, được chừng một buổi. Nhưng bản review lần đó bắt được hai lỗi mà chính tui đọc code không thấy. Cái đáng tiền của dàn nhạc không phải chơi nhanh hơn. Là nghe ra được nốt sai mà một cây đàn không bao giờ tự nghe thấy.

Hết bậc sáu, dàn nhạc của bạn đã chơi được, nhưng vẫn cần bạn đứng đó vẫy đũa. Bậc kế tiếp hỏi một câu đáng sợ hơn: khi bạn buông đũa đi ngủ mà dàn nhạc vẫn chơi, chuyện gì xảy ra lúc có đứa chơi sai? Đó là bài về thiết kế cho lúc hệ thống hỏng.

Cảm ơn bạn đã đọc bài viết này!

Written by chuotfx

Hãy ngồi xuống, uống miếng bánh và ăn miếng trà. Chúng ta cùng nhau đàm đạo về đời, về code nhóe!