Tách lập kế hoạch khỏi thực thi, chia việc theo mức độ phụ thuộc và giữ quyền nghiệm thu để AI làm nhanh mà không làm lệch.
Hãy hình dung một doanh nghiệp phân phối đang muốn làm cổng tra cứu đơn hàng cho đội bán hàng. Đây là tình huống giả định, nhưng bài toán rất quen: nhân viên phải gọi xuống kho để hỏi hàng đã xuất chưa; khách lại gọi nhân viên để hỏi xe đang ở đâu.
Người phụ trách công nghệ giao cho một AI agent: “Làm trang tra cứu đơn hàng, giao diện dễ dùng.” Một agent khác được yêu cầu: “Bổ sung API trả trạng thái giao hàng.” Cả hai cùng làm, màn hình xuất hiện rất nhanh.
Rồi đến lúc ghép lại.
Giao diện hiểu “đã giao” là xe đã rời kho. API hiểu “đã giao” là khách đã nhận hàng. Một bên dùng mã vận đơn, bên kia dùng mã đơn bán hàng. Agent làm giao diện tự tạo dữ liệu mẫu để tiếp tục; agent làm API đổi cấu trúc phản hồi vì thấy hợp lý hơn.
Không ai đứng yên. Nhưng cả nhóm đang chạy theo hai bản đồ khác nhau.
Tôi nhìn vấn đề này như chuyện sửa một căn nhà: thêm thợ không giúp công trình nhanh hơn nếu chưa thống nhất bức tường nào được đập, đường điện nào phải giữ và ai được chốt thay đổi. Với AI agent — hệ thống có thể dùng công cụ để thực hiện nhiệm vụ — câu hỏi cũng vậy:
Trước khi hỏi có thể chạy bao nhiêu agent, hãy hỏi tất cả đang làm theo bản vẽ nào.
Thêm người thi công chỉ có ích khi cả đội thống nhất bản vẽ và ranh giới công việc.
1. Lập kế hoạch là một pha có ranh giới, không phải lời nhắc “hãy suy nghĩ kỹ”
Trong tình huống trên, công việc đầu tiên không nên là sửa mã nguồn. Nó nên là làm rõ hệ thống hiện có và điều đội bán hàng thực sự cần biết.
Agent được giao đọc cấu trúc dự án, lần theo nơi lưu trạng thái đơn hàng, xác định quy tắc phân quyền và liệt kê những câu hỏi còn bỏ ngỏ. Đầu ra là một phương án để con người xem xét, không phải một loạt thay đổi đã xảy ra.
Đó là sự khác biệt giữa lập kế hoạch và thực thi. Claude Code có Plan Mode để đọc mã và đề xuất kế hoạch trước khi được duyệt thực hiện thay đổi. Hướng dẫn chính thức về lập kế hoạch trước khi chỉnh sửa.
Với doanh nghiệp, tôi đề xuất thiết kế pha này theo nguyên tắc: được khảo sát, chưa được tác động vào hệ thống vận hành. Chỉ cho phép các công cụ và tài khoản phù hợp với việc đọc; không cấp đường đi thuận tiện để sửa dữ liệu, cài thêm gói hay triển khai dịch vụ.
Một dòng trong prompt nói “không được thay đổi gì” chưa thay thế được kiểm soát quyền. Ngay cả công cụ tưởng như chỉ để khảo sát cũng cần được xét xem có tạo tác động bên ngoài không.
Trưởng nhóm sau đó có thể phát hiện một điều rất nhỏ nhưng quyết định toàn bộ thiết kế: đội bán hàng không cần xem vị trí xe theo thời gian thực. Họ chỉ cần biết đơn đã xuất kho, đang giao hay đã được khách xác nhận nhận hàng.
Loại bỏ một yêu cầu chưa cần thiết ở bước này thường dễ hơn tháo một tính năng đã cắm vào nhiều phần của hệ thống.
2. Bản đặc tả tốt phải nói cả điều không làm
“Giao diện đẹp, dữ liệu chính xác, bảo mật tốt” là mong muốn. Chưa phải tiêu chí để nghiệm thu.
Phát triển theo đặc tả nghĩa là thống nhất một mô tả đủ rõ về kết quả và giới hạn trước khi giao AI triển khai. Không cần biến việc nhỏ thành bộ hồ sơ dày. Với cổng tra cứu đơn hàng, một trang Markdown có thể bắt đầu như sau:
Bản đầu tiên vẫn có thể sai. Người phụ trách kho cần xem định nghĩa trạng thái; người phụ trách bán hàng cần xem thao tác tra cứu; kỹ thuật cần kiểm tra dữ liệu có thực sự đáp ứng không. Nếu nhóm chưa thống nhất ai có quyền chốt những câu hỏi đó, hãy bắt đầu từ việc làm rõ mục tiêu, phạm vi và người quyết định của dự án AI.
Sau mỗi vòng trao đổi, cập nhật bản đặc tả và đánh dấu phiên bản đã được duyệt. Lưu nó trong kho mã nguồn hoặc nơi quản lý tài liệu của dự án. Khi tiếp tục công việc, agent phải nhận đúng phiên bản này thay vì tự suy diễn từ một đoạn hội thoại cũ.
Đây là cách tạo bộ nhớ dự án dùng chung: quyết định quan trọng được giữ lại dưới dạng có thể đọc, đối chiếu và cập nhật.
Đặc tả không bảo đảm AI hết sai. Nó giúp cả người và AI có một điểm tựa để nhận ra sai lệch. Nếu phát sinh yêu cầu theo dõi GPS, nhóm biết đó là thay đổi phạm vi cần duyệt, không phải một “cải tiến nhỏ” agent được tự thêm.
Cổng duyệt nằm trước thực thi. Phát hiện thay đổi phạm vi thì quay lại đặc tả, không âm thầm mở rộng công việc.
3. Chia việc theo sự phụ thuộc, không theo số cửa sổ đang mở
Khi đã có bản vẽ, bước tiếp theo là xem những phần việc nào thực sự có thể tiến hành cùng lúc.
Trong sửa nhà, sơn hai phòng riêng có thể làm song song. Nhưng không thể đóng trần trước khi thống nhất đường điện đi phía trên. Trong phát triển phần mềm, hai tác vụ nằm ở hai file khác nhau vẫn có thể phụ thuộc vào cùng một quy tắc nghiệp vụ.
Với cổng tra cứu đơn hàng, có thể phân loại như sau:
Song song giữa giao diện và API không phải điều cấm. Nếu hợp đồng dữ liệu đã rõ, hai bên có thể triển khai riêng, dùng dữ liệu mẫu bám sát hợp đồng. Nhưng dữ liệu mẫu chỉ giúp làm việc sớm; kiểm thử với API thật mới chứng minh hai phần ghép được với nhau.
Ngược lại, khi định nghĩa “đã nhận hàng” vẫn chưa chốt, mở thêm agent chỉ làm nhiều giả định được viết thành mã nhanh hơn.
Một câu hỏi thực dụng trước khi chia việc là: nếu tác vụ A đổi kết quả, tác vụ B có phải làm lại không? Nếu có, cần chốt điểm bàn giao hoặc xếp thứ tự trước. Góc nhìn này nối với câu hỏi rộng hơn về ai giữ nhịp khi nhiều AI agent cùng làm việc: số lượng không thay thế được cơ chế phối hợp.
4. Mỗi agent cần một vùng trách nhiệm và một điều kiện bàn giao
“Agent A làm giao diện, agent B làm phần còn lại” nghe rõ nhưng vẫn rất rộng. Agent A có thể sửa luôn dữ liệu để giao diện chạy được; agent B có thể đổi cấu hình mà A đang dùng.
Phiếu giao việc nên có ít nhất: mục tiêu, tài liệu chung, vùng được sửa, vùng không được sửa, cách kiểm tra và điều kiện phải dừng.
Ví dụ cho một phần việc minh họa:
text
Mục tiêu: cải thiện thẻ hiển thị đơn hàng theo đặc tả đã duyệt.
Tham chiếu: bản đặc tả v1 và hợp đồng dữ liệu hiện hành.
Được sửa: thành phần thẻ đơn hàng và kiểm thử đi kèm.
Không được sửa: API, phân quyền, mô hình dữ liệu, cấu hình dùng chung.
Kiểm tra: trạng thái bình thường, thiếu thời điểm cập nhật, trạng thái lạ.
Dừng và báo lại nếu: cần thêm trường API hoặc đổi quy tắc nghiệp vụ.
Bàn giao: danh sách file đã đổi, kết quả kiểm thử, vấn đề chưa giải quyết.
Chạy nhiều agent trên cùng thư mục có thể giúp thử ý tưởng, nhưng ranh giới bằng lời không ngăn được việc sửa chồng lên nhau. Với thay đổi cần kiểm soát, nên cân nhắc mỗi agent một nhánh và một thư mục làm việc riêng. Git worktree cho phép một kho mã nguồn có nhiều thư mục làm việc, phục vụ việc làm trên các nhánh khác nhau. Tài liệu chính thức về Git worktree.
Hãy coi đó là các bàn thi công riêng, chưa phải các công trình hoàn toàn độc lập. Worktree không tự tách cơ sở dữ liệu, tài khoản dịch vụ hay tài nguyên bên ngoài. Các nhánh không xung đột dòng mã vẫn có thể mâu thuẫn về nghiệp vụ.
Vì vậy, vẫn cần một người chịu trách nhiệm ghép thay đổi và kiểm tra toàn bộ luồng. Không agent nào được “tiện tay” mở rộng phần việc để làm cho bản trình diễn trông hoàn chỉnh hơn. Khi đưa luồng này vào kho mã nguồn doanh nghiệp, cần giữ nguyên tắc không tự động hóa nhanh hơn năng lực kiểm soát.
Tách vùng làm việc giúp giảm va chạm. Kiểm thử tích hợp và người nghiệm thu mới quyết định kết quả có dùng được hay không.
5. Đừng nghiệm thu bằng ảnh chụp màn hình
Trở lại cổng tra cứu đơn hàng. Màn hình đẹp là một đầu ra, nhưng không đủ để chứng minh bài toán kinh doanh đã được giải quyết.
Người nghiệm thu cần đi qua cả một hành trình: đăng nhập bằng tài khoản bán hàng, tra đúng đơn thuộc phạm vi phụ trách, đọc trạng thái, thử mã đơn không tồn tại và thử truy cập đơn ngoài quyền. Đồng thời, phải kiểm tra những luồng cũ liên quan có còn hoạt động hay không.
Một quy trình gọn có thể gồm năm bước:
Đối chiếu phạm vi: từng agent có sửa đúng vùng được giao không?
Xem thay đổi: đọc chênh lệch mã nguồn, chú ý cấu hình và quy tắc nghiệp vụ.
Kiểm tra từng phần: chạy các kiểm thử phù hợp với mỗi phần việc.
Ghép và kiểm tra đầu cuối: dùng hệ thống thật trong môi trường thử nghiệm, không chỉ dữ liệu mẫu.
Nghiệm thu rồi phát hành: ghi lại phiên bản, người duyệt và phương án quay lui; không coi việc commit là đã sẵn sàng triển khai.
Khi đánh giá hiệu quả, tôi sẽ không bắt đầu bằng số agent đã chạy hay số dòng mã được tạo. Tôi sẽ theo dõi thời gian từ yêu cầu đến bản được nghiệm thu, số việc phải mở lại, lỗi phát hiện khi ghép và tổng công sức rà soát. Chi phí công cụ cũng cần tính cùng phần công sức sửa lại.
Nếu từng agent hoàn thành nhanh nhưng đội kỹ thuật mất cả buổi tháo các giả định sai, năng suất toàn hệ thống chưa chắc đã tăng.
Bắt đầu nhỏ: một bản đặc tả, hai phần việc, một người nghiệm thu
Doanh nghiệp không cần bắt đầu bằng một đội agent đông đảo. Hãy chọn một thay đổi có phạm vi hẹp và có thể kiểm tra được.
Trước tiên, yêu cầu AI khảo sát và viết kế hoạch trong phạm vi chỉ đọc. Tiếp theo, để người hiểu nghiệp vụ duyệt mục tiêu, điều không làm và tiêu chí hoàn thành. Chỉ khi thấy hai phần việc đủ độc lập, mới giao hai agent thực hiện trong các vùng trách nhiệm riêng. Cuối cùng, ghép kết quả và kiểm tra một hành trình người dùng trọn vẹn.
Nếu chưa tách được hai phần việc độc lập, dùng một agent theo thứ tự là lựa chọn hợp lý, không phải dấu hiệu doanh nghiệp chậm ứng dụng AI.
Vai trò của người phụ trách lúc này không chỉ là viết prompt. Đó là giữ cho yêu cầu, quyền hành động, điểm bàn giao và tiêu chí nghiệm thu khớp với nhau.
Lập kế hoạch giúp tránh làm sai việc. Phân công rõ giúp tránh sửa chồng việc. Nghiệm thu giúp biết việc đã thực sự xong. Tốc độ nên đến sau ba điều đó, không thay thế chúng.
Trong quy trình của bạn, điểm nào đang thiếu nhất: bản đặc tả chung, ranh giới giao việc hay người chịu trách nhiệm nghiệm thu toàn bộ?
Một cách thử nhỏ: chọn một thay đổi, chốt điều không làm và tiêu chí nghiệm thu trước khi giao AI thực hiện. Chỉ chạy song song khi hai phần việc có điểm bàn giao rõ; dữ liệu mẫu không thay thế kiểm thử tích hợp. Trong đội của bạn, điều gì thường khiến công việc phải làm lại: yêu cầu chưa rõ, sửa chồng phạm vi hay thiếu người nghiệm thu toàn bộ?