Viết 261 dòng đặc tả và bài kiểm thử chỉ để bàn giao một phần việc vỏn vẹn 25 dòng cài đặt là một phép tính lỗ rõ ràng trên mọi bảng dự toán. Khi bắt đầu thiết kế quy trình phối hợp giữa hai AI agent, mục tiêu ban đầu của tôi là tối ưu hạn mức: để agent nhanh và dồi dào gánh bớt khối lượng thực thi, giữ agent đắt giá cho phần phán đoán. Nhưng bất ngờ lớn nhất sau lượt chạy trọn vẹn đầu tiên không nằm ở tốc độ hoàn thành công việc, mà nằm ở việc kết quả chạy thật đã bóc trần những dòng năng lực được ghi sai trong bảng phân công do người lập kế hoạch quá tin vào tài liệu.
Vì sao tôi tách phần phán đoán ra khỏi phần chạy việc
Ranh giới phân chia công việc giữa hai agent bắt đầu từ một câu hỏi duy nhất: kết quả hoàn thành có thể kiểm chứng tự động bằng một lệnh chạy, hay vẫn cần đến sự phán đoán?
Những việc có thể kiểm chứng bằng lệnh — từ đọc mã nguồn, sửa file, cho đến chạy bộ kiểm thử — được chuyển toàn bộ cho agent thực thi đảm nhận, bất kể khối lượng đó lớn hay tẻ nhạt đến đâu. Ngược lại, phần việc đòi hỏi phán đoán, phân tích kiến trúc và rà soát kết quả được giữ lại ở agent lập kế hoạch. Trong trải nghiệm chọn model cho coding agent, việc biến một câu hỏi phán đoán thành một bài kiểm tra có thể chạy được chính là đòn bẩy lớn nhất của toàn bộ quy trình.
Lần chạy thật đầu tiên: giao đi 15 test đỏ, một lượt là xanh
Khi bước vào lượt chạy thật đầu tiên của quy trình hai agent, bên lập kế hoạch chuẩn bị một bộ hồ sơ giao việc gồm 261 dòng, chia thành 93 dòng đặc tả yêu cầu và 168 dòng test đỏ, để bàn giao phần việc chỉ khoảng 25 dòng cài đặt.
Agent thực thi nhận đề bài và làm xanh toàn bộ 15 test ngay trong lượt chạy đầu tiên, đạt tổng thời gian 0,03 giây. Nó không sửa, không bỏ qua, không đánh dấu chấp nhận lỗi, và không xóa bất kỳ bài test nào để đạt được kết quả đó. Toàn bộ quá trình diễn ra trọn vẹn trong 15 lượt gọi công cụ liên tục, không cần phê duyệt từng bước, và tự động tạo commit git sau khi hoàn tất.
Tỉ lệ 261 trên 25 là một khoản lỗ
Đặt 261 dòng tài liệu bên cạnh 25 dòng code cài đặt, đây rõ ràng là một khoản lỗ về mặt hạn mức. Chi phí token bỏ ra để agent lập kế hoạch viết gần ba trăm dòng đặc tả và kiểm thử lớn hơn rất nhiều so với lượng hạn mức dùng để tự tay viết 25 dòng code đó.
Từ trải nghiệm này, một ngưỡng vận hành thực tế đã được xác lập: những phần việc dưới khoảng 100 dòng hoặc nằm gọn trong một file thì nên tự làm trực tiếp, không cần viết đặc tả hay bàn giao. Việc bàn giao chỉ thật sự hợp lý khi khối lượng công việc được ủy thác lớn gấp 3 đến 4 lần dung lượng bản đặc tả mở khóa nó.
Lượt chạy đầu tiên dù chịu tỉ lệ lỗ nhưng vẫn hoàn toàn đáng giá, bởi dự án trước đó chưa hề có bất kỳ bài test nào, và bộ kiểm thử vừa tạo ra đã trở thành một tài sản lâu dài cho mã nguồn. Ngay sau đó, một chỉnh sửa nhỏ phát sinh đã được thực hiện trực tiếp mà không cần lập đặc tả, đúng theo ngưỡng vận hành vừa được thiết lập.
Con số ngân sách tôi tự đặt ra là con số không đo được
Khi xây dựng kế hoạch, tôi từng đặt ra mục tiêu phân bổ ngân sách 70/15/15. Nhưng khi đưa vào vận hành thực tế, con số này trở nên hoàn toàn không thể đo đếm.
Nguyên nhân là agent thực thi không hiển thị bất kỳ đồng hồ đo hạn mức nào trong suốt phiên làm việc, khiến việc đối soát tỉ lệ sử dụng là điều bất khả thi. Con số 70/15/15 vì vậy không thể trở thành một chỉ số định lượng để theo dõi trên báo cáo, mà chỉ còn là một hướng tư duy để người vận hành chủ động nghiêng về khi phân luồng tác vụ.
Ba dòng năng lực tôi ghi sai vì tin bảng thay vì tin lượt chạy
Khi đối chiếu bảng phân công lý thuyết với thực tế vận hành, có ba dòng năng lực đã bị ghi sai do người lập kế hoạch tin vào tài liệu tự khai thay vì kiểm chứng qua lượt chạy thật.
Chức năng chụp màn hình hoàn toàn không khả dụng ở chế độ đang chạy. Khả năng điều khiển trình duyệt tương tác chỉ tồn tại ở một chế độ vận hành khác. Và các năng lực đọc ảnh, tệp PDF cùng video mới chỉ dừng lại ở mức tự khai báo chứ chưa từng được đưa vào sử dụng thực tế.
Những gì thực sự được chứng thực qua lượt chạy bao gồm: thao tác dòng lệnh trong shell, làm việc với git, chỉnh sửa file và khả năng thực thi đa bước tự động. Trong nguyên tắc phân luồng công việc giữa các agent, hai giới hạn cơ học cần được tính đến khi lập kế hoạch: thao tác chỉnh sửa chỉ áp dụng một file mỗi lượt gọi, và thao tác đọc file bị phân trang ở mức khoảng 800 dòng / 46 KB. Do đó, việc tổ chức cấu trúc thành nhiều file nhỏ luôn hiệu quả hơn việc dồn vào vài file quá lớn.
Bàn giao không kèm bằng chứng thì tôi không nhận
Một nguyên tắc cốt lõi được rút ra sau lượt chạy: mọi biên bản bàn giao từ agent thực thi bắt buộc phải đi kèm bằng chứng kiểm chứng đầy đủ, bao gồm mã commit SHA, tên nhánh, lệnh kiểm chứng, khoảng 20 dòng output nguyên văn, và thống kê thay đổi qua lệnh git diff --stat.
Bên nhận bàn giao sẽ tự chạy lại lệnh kiểm chứng thay vì chỉ tin vào báo cáo văn bản. Yêu cầu này xuất phát từ thực tế có 3 bài test từng vượt qua kiểm thử nhưng vì lý do sai lệch. Mẫu bàn giao buộc agent thực thi phải tự giải thích bằng lời của chính nó lý do vì sao mỗi bài test đó hiện tại đã đạt chuẩn vì đúng bản chất.
📥 Tải miễn phí
Khung Bàn Giao Việc Giữa Hai AI Agent
Con chạy việc bắt lỗi của người viết đề bài
Trong quá trình thực hiện, nhật ký ghi nhận trở ngại đã phát hiện một sai sót thuộc về chính người viết đề bài chứ không phải phía thực thi.
Đó là sự thiếu nhất quán khi ghi mã commit gốc giữa hai file tài liệu khác nhau. Nhờ việc đọc toàn bộ hồ sơ công việc từ đầu đến cuối trong một lượt duy nhất, agent thực thi là bên duy nhất có vị trí để nhận ra sự mâu thuẫn này và phản hồi lại, giúp người lập kế hoạch kịp thời hiệu chỉnh.
Vậy khi nào giao đi, khi nào tự làm
Sau lượt chạy đó, tôi rút được xuống còn hai câu hỏi, và thứ tự giữa chúng mới là phần quan trọng.
Câu thứ nhất quyết định ai làm: phần việc này xong hay chưa xong có kiểm được bằng một lệnh chạy, hay phải có người ngồi xuống phán đoán? Thứ kiểm được bằng lệnh thì giao đi, không cần cân nhắc nó lớn hay tẻ nhạt tới đâu — tẻ nhạt không phải lý do để giữ lại, tẻ nhạt chính là lý do để giao. Còn thứ phải phán đoán mới biết đúng sai, kiểu kiến trúc này có chịu nổi thay đổi sắp tới không, chỗ kia có lỗ hổng không, phát hiện vừa rồi là thật hay báo động giả, thì giữ lại, bất kể nó nhỏ đến mức nào.
Câu thứ hai quyết định có đáng giao hay không, và đây đúng là câu tôi đã bỏ qua. Viết đề bài tiêu đúng cái hạn mức mà tôi đang cố tiết kiệm. Nên bây giờ, trước khi ngồi viết, tôi ước lượng hai con số: phần việc sắp giao đi lớn cỡ nào, và cái đề bài cần viết để nó không bị hiểu sai lớn cỡ nào. Hai con số xấp xỉ nhau nghĩa là tôi đang lỗ — và tới lúc nhận ra thì tôi đã viết xong phần việc đó rồi, chỉ là viết bằng một định dạng bất tiện hơn.
Ngưỡng tôi đang dùng khá thô: phần cài đặt dưới khoảng 100 dòng, hoặc gọn trong một file, thì tự làm luôn, không đề bài, không bàn giao. Giao đi khi phần việc lớn cỡ gấp ba đến bốn lần cái đề bài mở khoá nó.
Có đúng một ngoại lệ mà tôi chấp nhận trả giá, là khi thứ giao đi để lại một tài sản còn dùng được lâu về sau. Tỉ lệ 261 dòng đổi lấy 25 dòng là một khoản lỗ, và tôi vẫn làm, vì trước đó dự án không có lấy một bài kiểm thử nào. Tôi không trả tiền cho lần cài đặt ấy. Tôi trả tiền cho mọi lần sửa sau nó.
Còn một chỗ dễ nhầm nữa, và tôi đã nhầm: đừng lập luận chuyện giao việc theo hướng "nó làm được còn mình thì không". Phần lớn thời gian, đó là chuyện tiền chứ không phải chuyện năng lực. Nhầm chuyện tiền thành chuyện năng lực thì hỏng cả hai đầu — vừa giữ lại thứ lẽ ra nên giao đi, vừa giao đi thứ mà nó thật ra không làm được.
Khung làm việc này mới chỉ được vận hành thực tế trên một gói công việc, trong một ngày, bởi một người, trên một dự án duy nhất. Ba dòng năng lực về xử lý hình ảnh và điều khiển trình duyệt vẫn chưa được kiểm chứng thực tế, và bài toán chi phí cũng chưa thể đo đếm chính xác do agent thực thi không hiển thị đồng hồ đo hạn mức.
Bài học lớn nhất sau lần chạy không nằm ở việc tạo ra một bản kế hoạch hoàn hảo trên lý thuyết. Giá trị thực sự đến từ việc đưa quy trình vào một lượt chạy thật, để chính kết quả thực thi bóc tách những giả định sai lầm của người lập kế hoạch, biến những va chạm thực tế thành các nguyên tắc vận hành vững chắc cho những lần giao việc tiếp theo.
