Every Solo Agent Builder Eventually Reinvents a Worse Version of CI/CD

1. Điều không ai cảnh báo khi bạn build agent một mình

Sumaiya mở đầu bằng một điều mà theo chị không ai nói trước cho bạn khi bạn bắt đầu tự build agent một mình. Bạn nghĩ mình đang build prompt. Bạn nghĩ mình đang build skill, hoặc build workflow. Nhưng nếu bạn build đủ lâu, nhất là khi làm một mình, bạn sẽ bắt đầu build một thứ hoàn toàn khác. Một thứ trông giống CI/CD một cách đáng ngờ, chỉ có điều là tệ hơn, vì bạn dựng nó từ con số không, mỗi lần một failure.

Chị tự giới thiệu: chị là Sumaiya, và chị đang vận hành một agent system gồm mười chín skill chạy trên Claude Code. Các skill lo đủ việc: viết bài (writing), research, vault sync, analytics sync, hook, transcript, và nhiều thứ khác nữa.

Điều hữu ích nhất chị học được khi build hệ thống này không phải là cách viết prompt tốt hơn. Đó là nhận ra năm cơ chế kiểm soát (control) mà chị đang tự dựng lại một cách vụng về, và biết mình có thể làm gì thay vào đó. Cả talk xoay quanh năm thứ này.

2. Hệ thống đã dạy bài học: bảy handoff

Trước khi chỉ ra vấn đề, Sumaiya cho xem hệ thống đã dạy chị vấn đề đó. Đây là agent content system của chị, và nó là open source (link ở cuối trang). Hệ thống chạy hai tuần một lần, vào thứ Bảy. Nó đọc từ một knowledge vault, tạo một research brief, dựng content plan, sản xuất mười hai content piece, rồi chạy qua các lượt verifier, các reviewer gate, bước deduplication (loại trùng), và cuối cùng lưu output thành các file Markdown.

Nhưng chị nhấn mạnh: với talk này, thứ quan trọng không phải là nội dung mà hệ thống viết ra. Thứ quan trọng là hệ thống có bảy handoff (điểm bàn giao giữa hai bước):

1. Scheduler sang command.
2. Command sang research.
3. Research sang content plan.
4. Content plan sang production skill.
5. Production skill sang verifier.
6. Verifier sang reviewer.
7. Reviewer sang thư mục output.

Mỗi handoff là một chỗ mà hệ thống có thể nói dối bạn. Và nếu bạn build hệ thống một mình, sẽ không ai bắt được những lời nói dối đó ngoài chính bạn, mà thường là sau khi thiệt hại đã xảy ra rồi.

3. Năm thứ bạn sẽ tự phát minh lại

Đây là pattern Sumaiya muốn bạn để ý trong hệ thống của chính mình. Nếu bạn build agent độc lập, bạn sẽ dựng lại năm thứ sau, và thứ tự thường gần đúng như thế này.

Thứ nhất. Bạn đổi một prompt hoặc một skill, và có thứ gì đó ở phía sau (downstream) bị hỏng. Thế là bạn làm một cách để kiểm xem output có còn đúng hình dạng (shape) mong đợi không. Xin chúc mừng, bạn vừa phát minh lại regression testing.

Thứ hai. Bạn dựng một cron job hoặc một scheduled task. Một ngày nọ nó hỏng mà không báo gì (silently fails), và cả tuần sau bạn vẫn chưa nhận ra. Thế là bạn làm hệ thống cảnh báo (alert). Bạn vừa phát minh lại CI monitoring.

Thứ ba. Một skill đổi output schema của nó, và ba skill phía sau hỏng theo. Vì chuyện đó, bạn quyết định thêm bước validation ở ranh giới (boundary) giữa các skill. Bạn vừa phát minh lại contract testing.

Thứ tư. Một artifact trông như đã xong, nhưng không nên được ship. Thế là bạn thêm một checkpoint trước khi nó đi vào thư mục "ready". Bạn vừa phát minh lại staging environment.

Thứ năm. Có gì đó sai, nhưng bạn không tìm ra prompt nào, skill nào, hay handoff nào đã cho ra output tệ. Thế là bạn bắt đầu log mọi thứ. Bạn vừa phát minh lại audit trail.

4. Vì sao là "worse version", và failure nào mới nguy hiểm

Sumaiya giải thích chữ "worse version" trong tiêu đề. Lý do không phải vì agent là software build. Lý do là cuối cùng bạn cần đúng những bảo đảm vận hành (operational guarantee) y hệt như software. Thế nhưng agent system mặc định không cho bạn cái nào trong số đó, nên bạn tự dựng chúng một cách độc lập, thành phiên bản tệ hơn, mà thậm chí không nhận ra mình đang dựng.

Rồi chị đưa ra luận điểm trung tâm của talk: failure nguy hiểm trong một agent system không bao giờ là một output tệ. Output tệ rất dễ sửa. Bạn liếc qua là hiểu ngay đó là output tệ.

Failure nguy hiểm là một artifact bóng bẩy, nhìn lướt thì rất đẹp, nhưng sẽ không bao giờ qua được đúng những gate của bạn. Nó dùng sai voice pattern. Nó đưa ra một claim chưa được kiểm chứng. Nó lặp lại một góc nhìn (angle) cũ. Nó thiếu những section bắt buộc. Vậy mà nó vẫn được gắn nhãn "ready to publish". Đó là phiên bản agent của việc ship chỉ vì code đã compile, trong khi test chưa từng chạy.

Đây là thứ chị sẽ demo: không phải happy path, mà là ba cách agent có thể nói dối bạn, và cái gate để bắt từng cách.

5. Happy path: thứ mọi agent demo đều cho bạn xem

Chị bắt đầu từ happy path, vì đó là thứ mọi agent demo đều cho bạn xem. Chị chạy một phiên bản nhỏ, an toàn về quyền riêng tư (privacy-safe), của content engine pipeline. Đây không phải toàn bộ repo, mà là một bản chưng cất (distilled) của bài toán production.

Pipeline rất đơn giản: tạo một content artifact, chạy các gate, rồi hoặc cho qua (allow) hoặc chặn (block) output.

Nhìn vào output. File Markdown có caption, pinned comment, visual brief, verification log, vault asset, production note, và một trạng thái "ready". Nếu chị chỉ demo tới đây, hệ thống trông như đã xong. Artifact trông chuyên nghiệp. Nội dung đọc ổn. Đó chính là lý do agent demo dễ gây hiểu lầm: chúng luôn chỉ cho bạn xem happy path.

Nhưng chuyện gì xảy ra khi con đường không hề "happy", mà output vẫn trông như đã sẵn sàng?

6. Failure 1: voice drift

Failure đầu tiên là voice drift, giọng văn trôi đi. Nhìn vào nội dung: "Unlock the power of AI adoption. This game-changer will transform how teams operate in today's fast-paced enterprise landscape." Nếu bạn đã dành đủ thời gian trên LinkedIn, bạn đã thấy đúng câu này cả nghìn lần. Đó là thứ ngôn ngữ AI marketing chung chung. Nó không phải giọng của chị. Không phải giọng của bạn. Nó là giọng của chẳng ai cả.

Vậy mà naive mode vẫn lưu nó. Lý do: artifact có đủ mọi section bắt buộc, có trạng thái "ready", và trông hoàn chỉnh.

Giờ hãy xem chuyện gì xảy ra khi chị thêm đúng một boundary. Guarded mode chặn nó ở voice contract. Pipeline dừng lại trước khi artifact này lọt vào thư mục publish-ready.

Và đây là điểm mấu chốt: gate không làm nội dung tốt hơn. Nó chỉ không cho thứ sai đi tiếp.

Nếu bạn đang build một content system, đây là gate đầu tiên chị khuyên bạn nên có. Nếu bạn build một loại agent system khác, câu hỏi tương đương là: trong domain của bạn, "sai giọng" trông như thế nào?

7. Failure 2: missing verification

Failure thứ hai là thiếu kiểm chứng (missing verification). Bài viết này nói: "Teams with a clear semantic ownership model reduce AI rollout rework by thirty-seven percent." Ba mươi bảy phần trăm. Đây là một claim rất cụ thể. Con số đó từ đâu ra?

Mở verification log ra xem: trống trơn. Văn thì dùng được. Con số nghe hợp lý. Chính điều đó làm failure này nguy hiểm: một claim nghe rất tự tin, không có bất kỳ kiểm chứng hay nguồn tham chiếu nào, và naive mode vẫn lưu nó.

Guarded mode chặn nó. Nội dung mang claim không được ship nếu không có verification trail. "Tin tôi đi" không phải là một verifier.

Nếu agent system của bạn đưa ra claim về data, về user, về bất cứ điều gì, mà bạn không có một chuỗi validation, thì bạn đang ship những khẳng định chưa kiểm chứng trong một lớp vỏ trông rất chuyên nghiệp. Đó không phải là vấn đề của agent. Đó là vấn đề uy tín (credibility).

8. Failure 3: duplicate hook và audit trail

Failure thứ ba là duplicate hook, câu mở bài bị trùng. Sumaiya nói đây là failure chị thích nhất, vì nó thực tế nhất với solo builder.

Output là mới. Nội dung về mặt kỹ thuật vẫn mạch lạc. Nhưng cái hook, tức góc mở bài, gần như trùng với một thứ đã có trong lịch sử vault của bạn: "AI adoption fails when the dashboard looks right but the workflow is wrong." Angle đó đã được dùng rồi.

Nếu hệ thống của bạn cứ tạo ra những bản gần trùng nhau, hệ thống trông sẽ "tự động" một cách lộ liễu, kể cả khi từng bài riêng lẻ về kỹ thuật vẫn ổn. Khán giả của bạn sẽ nhận ra trước cả bạn.

Guarded mode chặn nó ở data contract. Và hãy để ý: nó còn ghi lại một audit record.

Audit record đó rất nhàm chán. Nhưng khi một scheduled run hỏng lúc hai giờ sáng, artifact cuối cùng thôi là không đủ. Bạn cần biết gate nào đã fail, contract nào bị vi phạm, và vì sao. Đó là audit trail, thứ "phát minh lại" thứ năm. Và đó cũng là thứ mà phần lớn solo builder thêm vào sau cùng, khi thiệt hại đã xảy ra rồi.

9. Pattern: vài cái gate nhàm chán

Vậy pattern ở đây là gì? Bạn không cần một platform. Bạn không cần một framework. Bạn không cần chờ hệ sinh thái (ecosystem) bắt kịp. Thứ bạn cần là vài cái gate nhàm chán:

• Pre-save output contract. Artifact có đúng hình dạng bắt buộc trước khi được lưu không?
• Voice contract, hay domain contract. Output có khớp với những quy tắc mà hệ thống của bạn được thiết kế quanh đó không?
• Verification contract. Nếu output đưa ra claim, những claim đó có truy được về một nguồn không?
• Deduplication check. Đây có thật sự là cái mới, hay hệ thống đang tự tái chế chính nó?
• Audit trail. Khi có gì đó hỏng, bạn có dựng lại được chuyện gì đã xảy ra mà không phải chạy lại toàn bộ pipeline không?

Trong software, chúng ta đã học được rằng không deploy chỉ vì code tồn tại. Trong agent system, chúng ta cần học không ship chỉ vì artifact trông hoàn chỉnh.

Vấn đề không nằm ở chỗ agent của bạn sẽ fail. Agent của bạn chắc chắn sẽ fail. Vấn đề là khi hệ thống của bạn định dạng (format) failure đó thật đẹp rồi ship nó xuống phía sau.

10. Mang về: map handoff, chọn chỗ đắt nhất, bắt gate phải nói "không"

Sumaiya kết bằng ba điều chị muốn người nghe mang về.

Một, map các handoff của bạn, từ input tới output cuối cùng. Mỗi mũi tên giữa hai bước đều có thể là chỗ output bị làm hỏng. Bạn không cần sửa hết. Bạn chỉ cần biết chúng nằm ở đâu.

Hai, chọn handoff đắt nhất. Không phải cái phức tạp nhất, mà là cái đắt nhất: chỗ mà data tệ có thể khiến bạn mất nhiều nhất. Đó có thể là một claim sai được publish công khai, một schema hỏng đổ dây chuyền xuống ba skill phía sau, hay một bài trùng lặp làm xói mòn lòng tin của khán giả. Đó là chỗ đặt gate đầu tiên của bạn.

Ba, bắt nó phải nói "không". Một gate chỉ log warning thì không phải là gate. Nó chỉ là một lời gợi ý. Gate phải chặn được artifact, không cho nó đi tiếp. Đó là khác biệt giữa một demo ấn tượng và một hệ thống vận hành được (operable system).

Câu cuối cùng chị để lại: trước khi bạn thêm một agent nữa, hãy thêm một boundary. Và chị cảm ơn mọi người đã theo dõi.