Quy trình giữ cho một team agent không tự lừa chính nó

Viết quy trình ra file là điểm khiến cả cách làm này lặp lại được, đúng kiểu tôi thích. Lần sau mở dự án mới, tôi bê nguyên bộ này sang. Agent biết luôn nó là vai gì, đi qua bước nào, và "xong" nghĩa là gì. Tôi không phải dạy lại từ đầu.

Có một điểm tinh tế ở đây mà tôi sẽ quay lại ở bài 3: khi quy trình chỉ nằm trong file chữ, agent vẫn có thể lờ đi vài chỗ. File là chỉ dẫn, không phải hàng rào cứng. Nhưng ngay cả ở dạng file, viết ra vẫn tốt hơn nhiều so với nhắc miệng từng lần.

Chạy song song và giữ vòng lặp không chết

Một task một lần thì phí thời gian. Tôi thường chạy hai task song song. Khi xong một đợt hai task, orchestrator kéo tiếp hai task nữa từ backlog. Cứ thế cuốn chiếu.

Nghe đơn giản, nhưng có một chỗ kẹt mà ai chạy agent kiểu này cũng gặp: vòng lặp tự chết.

Xong một đợt, orchestrator dừng lại, hỏi "tiếp đi chứ?" rồi ngồi chờ tôi gõ. Nửa đêm tôi ngủ thì nó đứng yên tới sáng. Cả đêm trôi qua mà backlog vẫn còn nguyên một nửa. Đây là một trong những thứ làm tôi bực nhất khi mới làm.

Cách tôi vá nó nhỏ mà hiệu quả: cài một chỉ dẫn lặp ngay trong task list.

Chỉ dẫn đó nói orchestrator làm hai việc. Một, kéo đợt task tiếp theo. Hai, tự thêm lại đúng chỉ dẫn này vào cuối danh sách. Thế là sau mỗi đợt, nó tự nhắc mình kéo đợt sau, rồi lại tự nhắc tiếp. Vòng lặp chạy tới khi backlog cạn, thay vì khựng lại sau mỗi đợt chờ tôi đẩy.

Cái mẹo này biến cả đêm thành thời gian làm việc thật. Tôi đi ngủ với backlog đầy, sáng dậy phần lớn đã được gọt, code, test, nghiệm thu xong.

Nhưng tôi muốn nói thẳng một điều kiện đi kèm, vì nó dễ bị bỏ qua trong cơn phấn khích "để agent chạy qua đêm". Vòng lặp tự chạy chỉ an toàn khi quy trình ở trên đã chặt. Nếu bạn cho agent tự cuốn chiếu mà không có ai gác từng bước, nó sẽ cuốn luôn cả lỗi đi thật xa, và sáng ra bạn dọn còn mệt hơn. Tự động và kiểm chứng phải đi cùng nhau. Tự động mà thiếu kiểm chứng chỉ là tạo rác nhanh hơn.

Theo dõi task: GitHub Issues hay file

Vòng lặp tự chạy chỉ có ích khi tôi nhìn được nó đang làm gì. Tôi dùng một trong hai cách ghi trạng thái.

Cách thứ nhất là GitHub Issues. Hợp khi tôi muốn phối hợp công khai và muốn báo cáo của từng agent dính kèm vào từng task. Mỗi issue thành một hồ sơ đầy đủ: PM ghi yêu cầu, tiêu chí nghiệm thu, kịch bản test; SWE báo đã code xong; QA xác nhận kèm ảnh chụp kết quả. Mở một issue ra là đọc được cả lịch sử việc đó đi qua những tay nào, ai làm gì, vì sao đậu hay rớt.

Cách thứ hai là tracker bằng file. Nhẹ hơn nhiều. Trạng thái nằm luôn trong tên file.

Một task đi từ .todo.md sang .groomed.md sang .in-progress.md, rồi cuối cùng vào thư mục done/. Không cần dịch vụ ngoài, không cần mạng, chỉ là file trong repo. Nhìn tên file là biết task đang ở đâu trong vòng lặp.

Tôi chọn cách nào tùy mức công khai tôi cần. Dự án nhiều người nhìn vào thì GitHub Issues. Dự án tôi làm một mình, hoặc chưa chắc sống lâu, thì file cho nhanh gọn.

Nhưng đây là điểm quan trọng hơn cả hai lựa chọn: cái tracker chỉ là chỗ ghi trạng thái.

Cùng một vòng lặp PM, SWE, QA, về PM chạy y hệt dù tôi ghi trạng thái ở đâu. Công cụ theo dõi là cái sổ, còn cái tạo ra chất lượng là quy trình quanh nó, là việc tách vai và bắt mọi task đi đủ bước. Đổi tracker không đổi kết quả. Bỏ quy trình thì tracker xịn tới đâu cũng vô dụng.

Tới đây tôi đã kể xong cách làm: vai trò ở bài 1, quy trình ở bài 2. Bài 3 tôi đem nó ra thực chiến, qua các loại dự án khác nhau, kể cả một dự án tôi làm hỏng, rồi rút ra cái gì còn lại sau tất cả.