Software factory: đừng chỉ build phần mềm, hãy nghĩ tới việc build nhà máy

Bài 18 trong bộ onboarding AgentKit v3. Đọc khoảng 12 phút. Bài này thiên về tư duy, ít lệnh. Đọc sau bài 13 và bài 17 sẽ thấy ăn khớp.

Mỗi lần có buzzword mới, tui đều có cảm giác "ủa, hoá ra cái mình làm bấy lâu có tên hả?". Prompt engineering, context engineering, harness engineering, rồi tuần này là software factory. Nghe hoành tráng như quảng cáo làm giàu tự động, nhưng lần này có cái đáng đào.

Cái đáng đào không phải "cho 20 agent chạy song song". Mà là câu hỏi sau khi automation chạy được: làm sao biết máy đang làm đúng và ngày càng hiệu quả hơn? Câu thứ hai mới phân biệt một chuỗi automation với một nhà máy vận hành lâu dài.

1/ Nhà máy phần mềm là gì

Một nhà máy thật có input, quy trình có công đoạn, kiểm soát chất lượng, output đạt chuẩn và vòng phản hồi để cải tiến. Thay nguyên liệu bằng requirements, công nhân bằng coding agent, bộ phận kiểm định bằng test và evaluation, thành phẩm bằng phần mềm là ra software factory.

Ý tưởng không mới (CI/CD, DevOps, IaC đều đi hướng đó). Cái mới là AI nhận được những công đoạn trước đây cần con người suy luận: nhận issue, đọc codebase, điều tra, viết code, test, mở PR.

Nhưng một coding agent biết viết code chưa phải nhà máy. Anh thợ mộc giỏi không tự nhiên biến xưởng thành nhà máy nội thất.

2/ Sáu thành phần một nhà máy cần

Bỏ tên công cụ đi, tui thấy hệ thống đủ trưởng thành cần ít nhất sáu thứ:

1. Nguồn công việc có cấu trúc. Task có vấn đề, trạng thái hiện tại kèm evidence, kết quả mong đợi, tiêu chí nghiệm thu, giới hạn không được vượt, mức rủi ro và quyền duyệt.

2. Hàng đợi và điều phối. Task có trạng thái, retry, timeout, tránh hai worker xử lý trùng. Nhãn in-progress trên GitHub chưa đủ để chặn race condition; cần nhận việc nguyên tử, idempotency, kiểm soát đồng thời. Bên trong một task thì agent cứ dùng loop thoải mái.

3. Môi trường thực thi độc lập. Worktree riêng kèm container hoặc sandbox. Nhớ: worktree tách thay đổi code, không phải cơ chế bảo mật. Agent vẫn đọc được secrets, SSH key, mạng của host thì tách worktree chẳng giải quyết gì. Áp dụng least privilege.

4. Kiểm chứng độc lập với bên implement. Đừng tin hoàn toàn test do chính agent viết (nó có thể viết hàm luôn trả true rồi viết test khớp). Nhiều lớp: lint, typecheck, unit, integration, dependency scan; rồi E2E và scenario hành vi; rồi invariant quan trọng (thanh toán không được tính phí hai lần).

5. Human approval theo rủi ro. Sửa tài liệu có thể tự qua cổng. Auth, billing, migration, hạ tầng production cần kiểm soát chặt. Tui gọi là earned autonomy: lúc đầu agent chỉ đề xuất, tích đủ lịch sử tốt trên một loại việc hẹp mới được tự merge, và quyền đó thu hồi được.

6. Feedback loop. Mỗi lần thất bại ghi nhận vì sao (yêu cầu mơ hồ, thiếu context, sai model, skill dở, test thiếu, hạ tầng lỗi), rồi sửa đúng thành phần. Sửa skill cũng cần versioning, benchmark trước sau và rollback, nếu không bạn có hệ thống tự làm mình tệ đi.

3/ Chuyện của người khác, đọc có phản biện

Tất cả số liệu dưới đây là do các bên tự công bố hoặc từ nghiên cứu quan sát, tui chỉ đọc lại, không kiểm chứng độc lập:

• Warp (Zach Lloyd, 18/06/2026): engineer chuyển từ làm sản phẩm sang xây hệ thống mà agent dùng để ra sản phẩm, gọi là factory engineering. Quy trình mẫu: Triage, Spec, Implement, Review, Verify, CI/CD, Ship, Monitor. Lưu ý Warp bán nền tảng Oz, nên đây cũng là cách họ định vị thị trường.

• StrongDM (Justin McCarthy, 02/2026): con người không viết và không review code, trách nhiệm dồn vào hệ thống kiểm chứng bằng scenario lưu tách khỏi codebase và các bản mô phỏng dịch vụ ngoài (Digital Twin Universe). Hay ở khâu verification, nhưng bản mô phỏng không đảm bảo giống production 100% và LLM-as-judge có độ tin cậy riêng. Con số "1.000 USD token mỗi engineer mỗi ngày" là cách đẩy thử nghiệm lên cực đoan, đừng coi là công thức.

• Uber (27/08/2026): hơn 70% PR có nguồn gốc từ agent, hơn 3.600 skill nội bộ. "Có nguồn gốc từ agent" không có nghĩa là không cần con người duyệt; họ vẫn mô tả human review và escalation.

• Nghiên cứu Harvard (Fiona Chen, James Stratton, 718 doanh nghiệp, quan sát): code tăng khoảng 30%, nhưng thời gian từ mở PR đến merge tăng khoảng 49%. Nghiên cứu quan sát không chứng minh nhân quả. Hàm ý: bottleneck dịch từ viết code sang verification.

• Microsoft Research / CRBugBench (10/2026): agent review tốt nhất bắt được 71,9% lỗi đã xác nhận trong năm bình luận ưu tiên hàng đầu. Đừng nhầm AI review với bảo đảm chất lượng; hai agent cùng hiểu sai yêu cầu vẫn đồng ý với nhau.

• Swan / Cygnet: bài học hay nhất là hệ thống biết dừng. Khi bước tạo bằng chứng kiểm chứng thất bại, nó chuyển lại cho engineer thay vì khăng khăng "task completed".

• Anthropic (13/10/2026): số lần merge vào monorepo tăng từ khoảng 2.500 lên hơn 30.000 mỗi ngày, source control thành bottleneck và họ phải xây hệ thống riêng (Scion). Đó là workload đặc biệt, không phải lý do để bạn bỏ Git.

4/ Chỉ số thực dụng

• Cost per accepted task: tổng chi phí thật để có một việc đã được kiểm chứng và chấp nhận, không phải số token, không phải số dòng code. Ví dụ giả định của tui: nhà máy A tốn 2 USD mỗi lần và đúng 50% thì 4 USD cho một kết quả tốt; nhà máy B tốn 3 USD và đúng 90% thì khoảng 3,33 USD. Model rẻ nhất chưa chắc cho hệ thống rẻ nhất.

• Human intervention rate: bao nhiêu lần phải can thiệp. Đừng tối ưu mù quáng, giảm can thiệp bằng cách bỏ kiểm chứng là giảm chất lượng.

5/ Áp dụng cho bạn, từng bước nhỏ

Đừng bắt đầu bằng 15 microservice để sửa typo README. Bắt đầu từ:

một GitHub repo + một coding agent trên cloud + một queue + một bộ test đáng tin + một người review.

1. Chọn một loại việc nhỏ, rủi ro thấp (tài liệu, bug nhỏ).

2. Viết issue đủ rõ, có tiêu chí nghiệm thu (xem cách AgentKit tạo issue ở bài 13).

3. Dựng môi trường thực thi độc lập theo bài 17 hoặc Cloud Harness ở bài 14.

4. Siết kiểm chứng bằng /ak-test: audit trước, rồi optimize.

5. Đo cost per accepted task và số lần can thiệp. Có số rồi mới tìm bottleneck.

6/ Trạng thái trong hệ sinh thái AgentKit

Kiến trúc năm lớp tui muốn hướng tới (công việc, kiến thức và quy trình, thực thi, kiểm chứng và quản trị, học từ vận hành) là định hướng, không phải tuyên bố mọi lớp đã hoàn thiện.

Disclaimer của tui: tui có lợi ích sản phẩm trong chủ đề này vì đang bán công cụ liên quan, nên cứ phản biện thoải mái.

Tóm lại

1/ Software factory không phải thi ai chạy nhiều agent hay đốt nhiều token nhất.

2/ Bottleneck dịch từ viết code sang verification. Đừng coi AI review là bảo đảm chất lượng.

3/ Nhà máy tốt biết dừng và giao lại cho người, kèm bằng chứng.

4/ Bắt đầu nhỏ, đo cost per accepted task, rồi mới mở rộng. Và đừng mải xây nhà máy mà quên mình định sản xuất cái gì.

Nguồn

• Software factory: Ủa, hoá ra cái tui đang làm bấy lâu nay có tên gọi như vậy à? (15/10/2026), bài gốc có đầy đủ link tới Warp, StrongDM, Uber, Swan, Anthropic, Microsoft Research và nghiên cứu Harvard.