Thực nghiệm Dynamic Workflows trong Claude Code cho task multi-file development

1. Mục tiêu

Trong bài viết này, tôi thực nghiệm tính năng Dynamic Workflows trong Claude Code bằng cách thực hiện một task phát triển phần mềm có phạm vi nhiều file. Mục tiêu là đánh giá xem Claude Code có thể tự chia nhỏ công việc, điều phối nhiều subagent, áp dụng thay đổi code và tự kiểm chứng kết quả hay không.

2. Môi trường thực hiện

• Tool: Claude Code
• Mode: Dynamic Workflows
• Effort: ultracode
• Repository: adyen-node-api-library

3. Thiết lập Claude Code và bật Dynamic Workflows

Mở Claude Code trong thư mục project, đăng nhập tài khoản, kiểm tra model và bật chế độ ultracode:

/login
/model
/config
/effort ultracode

Sau khi bật ultracode, Claude Code có thể tự quyết định sử dụng Dynamic Workflows cho các task phức tạp. Với quest này, tôi chủ động yêu cầu Claude dùng workflow bằng /effort ultracode.

4. Prompt đã sử dụng

Kiểm tra toàn bộ src/ của project bằng các subagent song song, tập trung 3 nhóm: src/httpClient/ (nuốt exception, thiếu await, rò rỉ stream), src/security/nexoCrypto.ts (sai IV/padding, HMAC không constant-time), và src/services/* (Promise không await, lỗi không lan truyền).
Với mỗi bug High/Medium: viết một unit test tái hiện bug (FAIL trước), sửa code,rồi chạy `npm test` đến khi test chuyển PASS. Các agent review chéo để loại false positive. Cuối cùng đảm bảo build + test + lint đều xanh, và tóm tắt: các bug đã sửa, test đã thêm, thời gian và token đã dùng.

5. Quá trình Claude tạo workflow và subagents

Sau khi nhận prompt, Claude không xử lý tuần tự như một phiên chat thông thường. Thay vào đó, Claude tạo một workflow script để chia task thành nhiều phase.

Các phase chính được tạo:

Trong /workflows, mỗi phase có số lượng agent riêng. Một số agent chạy song song để kiểm tra các nhóm file khác nhau. Các agent không chỉ tìm lỗi mà còn check kết quả của nhau trước khi Claude tổng hợp báo cáo cuối.

6. Xác minh kết quả cuối và cách xử lý lỗi

Kết quả đã được kiểm chứng trong phiên làm việc (tất cả qua cổng BUILD/LINT/TEST)

7. Đánh giá hiệu quả

• Về độ hiệu quả: Dynamic Workflows thế mạnh thật sự không nằm ở việc “tìm ra bug” — một lần quét đơn lẻ cũng làm được — mà ở độ tin cậy. Việc bắt mỗi phát hiện đi qua ba góc nhìn đối kháng và yêu cầu đa số đồng thuận đã lọc được cả nhiễu dương tính giả lẫn nhiễu âm tính. Kỷ luật FAIL-trước-PASS-sau biến mỗi tuyên bố “đây là bug” thành bằng chứng kiểm chứng được, đồng thời để lại một bộ test hồi quy vĩnh viễn.
• Về chi phí: Lần thử nghiệm này tiêu tốn gần 700k token đầu ra trải trên 31 agent, cho một phạm vi chỉ ba tệp. Tỉ lệ token trên mỗi bug là rất lớn. Thời gian tính toán thực của workflow vào khoảng mười lăm phút, nhưng tổng thời gian kiểm tra kéo dài nhiều giờ vì kẹt giới hạn phiên qua đêm — một rủi ro vận hành không thể bỏ qua với các workflow dài.
• Về thời gian: Thời gian thực thi workflow hết gần 15p nhưng kẹt session limit nên tổng là 5h40p. Đây là rủi ro khi dùng gói Claude pro, workflow dài có thể bị cắt ngang, để lại kết quả nửa vời.
• Về hạn chế kiến trúc: khả năng song song hoá chỉ phát huy ở giai đoạn phát hiện. Giai đoạn sửa lỗi và kiểm thử buộc phải diễn ra tuần tự, bởi việc nhiều tác tử cùng thao tác trên một cây mã nguồn và cùng một tiến trình kiểm thử sẽ tất yếu dẫn đến xung đột. Sự cố giới hạn phiên còn làm lộ ra một điểm yếu sâu hơn: chất lượng đầu ra phụ thuộc chặt chẽ vào tính trọn vẹn của giai đoạn kiểm chứng. Một khi quá trình này bị gián đoạn giữa chừng, xác suất bỏ sót lỗi gia tăng đáng kể.

Tóm lại: Đây là công cụ mạnh nhưng tiêu tốn rất nhiều token nên đánh giá dùng cho những vấn đề khó để tránh lãng phí.

8. Kế hoạch áp dụng vào workflow dự án hiện tại

Tôi đề xuất áp dụng Dynamic Workflows vào team theo 3 cấp độ:

Giai đoạn 1: Audit không sửa code

Dùng workflow để kiểm tra schema mismatch, dead code, validation thiếu, hoặc logic save chưa đồng bộ. Output là report, chưa auto apply code.

Giai đoạn 2: Fix có giới hạn scope

Cho workflow sửa trong một thư mục nhỏ hoặc một module cụ thể. Mọi thay đổi phải đi qua git diff, lint/build/test và review của developer.

Giai đoạn 3: Tạo workflow tái sử dụng

Với các task lặp lại như audit màn edit design, kiểm tra permission, hoặc sinh test cho API, lưu workflow thành command trong .claude/workflows/ để cả team dùng lại.

9. Nhận xét cá nhân

Tôi thấy Dynamic Workflows đặc biệt phù hợp với các task kiểu “rộng nhưng có pattern”, ví dụ kiểm tra nhiều file theo cùng một rule, migration schema, sinh test hoặc review code trước khi merge.

Tuy nhiên, Dynamic Workflows là công cụ thay thế review của developer. Cách dùng hợp lý là để Claude làm vòng audit/fix ban đầu, sau đó developer kiểm tra diff, chạy test và quyết định merge. Nếu dùng đúng scope, đây là một công cụ tốt để cải thiện tốc độ phát triển mà vẫn giữ được kiểm soát chất lượng. Lưu ý đánh giá lợi ích mang lại vì nó tiêu tốn lượng token rất lớn.