AI Software Factory là một dây chuyền sản xuất phần mềm được chuẩn hoá tới mức AI có thể đảm nhận phần lớn công đoạn thực thi — từ viết đặc tả, sinh mã, viết kiểm thử, kiểm tra chất lượng đến triển khai — trong khi con người giữ vai trò quyết định ở những điểm không được phép sai.
Nói cách khác: đó không phải "dùng AI để viết code nhanh hơn", mà là thay đổi cách tổ chức sản xuất phần mềm để đầu ra trở nên đều, đo được và lặp lại được. Bài viết này mô tả kiến trúc, đường ống, chi phí, chỉ số và lộ trình triển khai của mô hình đó trong điều kiện doanh nghiệp Việt Nam năm 2026.
Vì sao mô hình "mỗi lập trình viên ngồi với AI" không đủ
Ba năm qua, hầu hết doanh nghiệp mua ghế Copilot hoặc mở tài khoản cho nhân viên dùng AI. Kết quả thường gặp:
- Cá nhân nhanh hơn, tổ chức không nhanh hơn. Một người viết mã 30% nhanh hơn, nhưng thời gian chờ review, chờ test, chờ deploy vẫn giữ nguyên — và đó mới là phần chiếm phần lớn chu kỳ.
- Chất lượng không đều. Cùng một yêu cầu, năm người cho ra năm kiến trúc khác nhau, không ai kiểm chứng được vì không có chuẩn chung.
- Tri thức bay hơi. Câu lệnh hay, quy ước ngầm, cách xử lý lỗi đặc thù nằm trong đầu từng người hoặc trong các cửa sổ chat đã đóng.
- Không đo được. Không ai trả lời được: tháng này AI viết bao nhiêu phần trăm mã, bao nhiêu phần phải sửa lại, chi phí trên mỗi đầu việc hoàn thành là bao nhiêu.
Nhà máy giải quyết đúng bốn điểm đó. Nó biến năng suất cá nhân thành năng lực của hệ thống.
Bốn cấp độ trưởng thành
| Cấp | Tên gọi | Ai viết mã | Ai kiểm chất lượng | Đặc điểm |
|---|---|---|---|---|
| 1 | Trợ lý trong IDE | Người viết, AI gợi ý từng đoạn | Người | Phụ thuộc kỹ năng từng cá nhân |
| 2 | Vibe coding | AI viết gần hết, người gõ yêu cầu | Người thử bằng tay | Rất nhanh với bản mẫu, rủi ro cao với hệ thống thật |
| 3 | Agentic coding | Agent tự chạy nhiều bước trong repo | CI + người review | Cần kho mã sạch và test tốt mới hiệu quả |
| 4 | Software Factory | Nhiều agent song song theo đặc tả | Cổng kiểm chứng tự động + người quyết định | Đầu ra đều, đo được, mở rộng được |
Điểm khác biệt căn bản giữa cấp 3 và cấp 4 không nằm ở mô hình AI mạnh hơn, mà ở chỗ chất lượng được kiểm chứng bằng máy nhiều hơn bằng mắt người. Nếu chưa có hệ thống kiểm thử tự động đủ tốt, việc nhân số agent lên chỉ nhân số lỗi lên.
Phân biệt với những thứ gần giống
| Tiêu chí | Copilot trong IDE | Vibe coding | Low-code / No-code | Gia công truyền thống | AI Software Factory |
|---|---|---|---|---|---|
| Ai viết phần lớn mã | Người | AI | Nền tảng | Đội gia công | AI, theo đặc tả |
| Kiểm soát chất lượng | Người | Gần như không | Giới hạn bởi nền tảng | Quy trình của bên bán | Cổng tự động + người duyệt |
| Tài sản tri thức | Trong đầu người | Trong chat | Trong nền tảng độc quyền | Trong hợp đồng | Trong kho mã, đặc tả, bộ kiểm thử |
| Tốc độ | +20–40% | Rất nhanh giai đoạn đầu | Nhanh với bài toán chuẩn | Chậm, phụ thuộc người | Nhanh và đều |
| Rủi ro chính | Không đều | Nợ kỹ thuật ẩn | Khoá nhà cung cấp | Mất kiểm soát tiến độ | Chi phí hạ tầng & kỷ luật |
Cần nói rõ: AI Software Factory không loại bỏ lập trình viên. Nó đổi việc của họ từ "gõ mã" sang "viết đặc tả, thiết kế ràng buộc, đọc diff, quyết định kiến trúc". Tỷ lệ thời gian thay đổi rõ rệt: ở nhà máy trưởng thành, phần lớn thời gian kỹ sư dành cho đặc tả và review, không phải gõ phím.
Kiến trúc tham chiếu: 5 lớp
Năm lớp xếp chồng, lớp trên chỉ chạy được khi lớp dưới đã vững. Thứ tự vận hành: Tri thức → Ngữ cảnh → Điều phối → Kiểm chứng → Vận hành, rồi quay lại cập nhật lớp Tri thức sau mỗi vòng.
Lớp 0 — Tri thức
Đây là lớp bị bỏ qua nhiều nhất và cũng là lớp quyết định thành bại. Nếu tổ chức không viết ra được "chúng tôi làm phần mềm theo cách nào", AI sẽ tự chọn cách của nó — và mỗi lần chọn một kiểu.
Nội dung tối thiểu:
- Quy ước mã nguồn: đặt tên, cấu trúc thư mục, xử lý lỗi, log, phân quyền, migration cơ sở dữ liệu.
- Bản ghi quyết định kiến trúc (ADR): vì sao chọn công nghệ này, vì sao không chọn cái kia. AI đọc ADR để không đề xuất lại phương án đã bị loại.
- Mẫu dùng lại: mẫu một module chuẩn, mẫu một API, mẫu một trang, mẫu bộ kiểm thử. Mẫu tốt hơn lời mô tả.
- Danh mục công nghệ được phép dùng (tech radar): thư viện đã duyệt, thư viện cấm, phiên bản tối thiểu.
- Từ điển nghiệp vụ: "đơn hàng", "liệu trình", "hoa hồng" nghĩa là gì trong hệ thống này.
Lớp 1 — Ngữ cảnh
Agent không giỏi đoán. Nó giỏi đọc. Lớp ngữ cảnh quyết định agent đọc đúng thứ.
- Tệp đặc tả cho từng đầu việc: mục tiêu, phạm vi, ngoài phạm vi, tiêu chí nghiệm thu, ràng buộc kỹ thuật.
- Bản đồ kho mã (repo map) cập nhật tự động: module nào ở đâu, phụ thuộc nào được phép.
- Tệp hướng dẫn cho agent đặt ngay trong kho mã, mô tả cách build, cách chạy test, điều cấm.
- Kho tri thức nội bộ (RAG) chứa tài liệu nghiệp vụ, biên bản họp, quy trình — để AI trả lời theo sự thật của doanh nghiệp, không theo phỏng đoán.
Lớp 2 — Điều phối
Thay vì một agent làm tất cả, nhà máy chia vai:
| Vai | Việc | Quyền hạn |
|---|---|---|
| Planner | Đọc đặc tả, chia thành các lô nhỏ, chỉ ra tệp sẽ chạm | Chỉ đọc, không sửa mã |
| Implementer | Sinh mã trong một nhánh riêng, chạy build & test cục bộ | Sửa mã trong phạm vi đặc tả |
| Tester | Viết kiểm thử cho hành vi, chạy lại, báo cáo | Thêm tệp kiểm thử |
| Reviewer | Đọc diff, đối chiếu đặc tả, phát hiện vi phạm quy ước | Chỉ bình luận, không sửa |
Nguyên tắc vận hành quan trọng nhất: mỗi agent làm việc trong một bản sao riêng của kho mã (worktree/container), không tranh nhau một thư mục. Song song hoá chỉ an toàn khi các nhánh không chồng lấn tệp.
Lớp 3 — Kiểm chứng
Không có lớp này thì không có nhà máy, chỉ có vibe coding quy mô lớn. Cổng kiểm chứng tối thiểu:
- Biên dịch/kiểm kiểu thành công, không có cảnh báo mới.
- Chạy toàn bộ kiểm thử hiện có, không được giảm độ phủ.
- Kiểm thử mới cho hành vi mới, và kiểm thử mới phải thất bại khi cố tình làm sai (kiểm tra chất lượng kiểm thử).
- Quét lỗ hổng phụ thuộc và lộ khoá bí mật.
- Kiểm tra giấy phép thư viện mới được thêm.
- Đánh giá tự động (eval) cho các luồng có AI tham gia quyết định.
Lớp 4 — Vận hành
Nhà máy chỉ đáng tin khi triển khai và hoàn nguyên đều tự động: một lệnh để lên, một lệnh để lùi, có cờ tính năng (feature flag) để bật cho 5% người dùng trước khi bật toàn bộ, có log và số đo để biết hỏng ở đâu trong vài phút.
Đường ống 9 bước của một đầu việc
| Bước | Đầu vào | Ai làm chính | Sản phẩm | Cổng kiểm soát |
|---|---|---|---|---|
| 1. Ghi nhận | Vấn đề từ khách, lỗi, ý tưởng | Người | Ticket có bối cảnh | Người xác nhận vấn đề thật |
| 2. Đặc tả | Ticket | Người viết, AI phản biện | Tệp đặc tả + tiêu chí nghiệm thu | Người duyệt đặc tả |
| 3. Thiết kế | Đặc tả | AI đề xuất 2–3 phương án | Bản thiết kế ngắn | Người chọn phương án |
| 4. Chia lô | Thiết kế | Planner agent | Danh sách lô việc theo chiều dọc | Người kiểm phạm vi |
| 5. Thực thi | Từng lô | Implementer agent | Nhánh mã + mô tả thay đổi | Build & test cục bộ |
| 6. Kiểm thử | Nhánh mã | Tester agent + người | Bộ kiểm thử mới | Test phải đỏ khi cố tình làm sai |
| 7. Duyệt | Diff | Reviewer agent + người | Bình luận, yêu cầu sửa | Người bấm duyệt |
| 8. Triển khai | Nhánh đã duyệt | Pipeline | Bản chạy có cờ tính năng | Theo dõi 24–48 giờ |
| 9. Học lại | Dữ liệu vận hành | Người + AI | Cập nhật quy ước, mẫu, eval | Định kỳ hằng tuần |
Ba điểm không được tự động hoá ở giai đoạn đầu: duyệt đặc tả, duyệt mã, quyết định triển khai. Các điểm này có thể nới dần khi đã có dữ liệu chứng minh độ chính xác.
Một chi tiết dễ bị xem nhẹ: lô việc phải cắt theo chiều dọc — nghĩa là mỗi lô đi hết từ giao diện, nghiệp vụ, dữ liệu đến kiểm thử, thay vì chia theo tầng ("anh làm giao diện, tôi làm API"). Cắt ngang tầng làm agent phải chờ nhau và tạo ra các nhánh dở dang không kiểm chứng được.
Bộ công cụ: chọn theo vai, không chọn theo quảng cáo
| Vai trò trong nhà máy | Loại công cụ cần | Ghi chú chọn |
|---|---|---|
| Ghi nhận & đặc tả | Trình quản lý công việc + mẫu đặc tả | Mẫu quan trọng hơn công cụ |
| Kho mã | Git + quy ước nhánh | Nhánh ngắn, sống dưới 2 ngày |
| Agent viết mã | Trợ lý CLI/IDE có khả năng chạy lệnh trong repo | Cần chạy được build và test, không chỉ sinh chữ |
| Kiểm thử | Bộ chạy test của ngôn ngữ + kiểm thử giao diện tự động | Đầu tư sớm nhất |
| Tích hợp | CI chạy trên mỗi nhánh | Bắt buộc, không thương lượng |
| Bảo mật | Quét phụ thuộc, quét bí mật, quét mã tĩnh | Chạy tự động trong CI |
| Vận hành | Cờ tính năng, log tập trung, đo lỗi | Cần trước khi tăng tốc |
| Chi phí | Bảng theo dõi lượng dùng theo đầu việc | Không có thì không quản được |
Sai lầm phổ biến là mua công cụ đắt nhất trước rồi mới nghĩ đến quy trình. Thứ tự đúng ngược lại: quy ước → kiểm thử → CI → agent → công cụ cao cấp.
Kinh tế của nhà máy
Chi phí một nhà máy gồm bốn phần, và phần lớn doanh nghiệp chỉ tính phần đầu tiên.
| Khoản mục | Đặc điểm | Ước tính cho đội 5 kỹ sư |
|---|---|---|
| Lượng xử lý AI | Tăng theo số đầu việc, giảm dần khi quy ước tốt lên | 3–15 triệu đồng/tháng |
| Hạ tầng CI, môi trường xem trước | Tăng theo số nhánh song song | 1–5 triệu đồng/tháng |
| Công sức review | Khoản lớn nhất và hay bị bỏ sót | 20–35% quỹ thời gian kỹ sư |
| Xây dựng ban đầu | Viết chuẩn, mẫu, bộ kiểm thử, pipeline | 4–8 tuần của 1–2 người |
Điểm hoà vốn điển hình: nếu mỗi tháng đội làm từ 6 đầu việc vừa trở lên và hệ thống đã có kiểm thử tự động, nhà máy có lãi rõ rệt. Với đội chỉ làm 1–2 việc nhỏ mỗi tháng, chi phí dựng nền lớn hơn lợi ích — nên dùng mức 1 hoặc 2 trong bảng bốn cấp độ.
Một phép so sánh thường được dùng khi tư vấn (số liệu là ví dụ điển hình, không phải cam kết):
| 3 kỹ sư truyền thống | 2 kỹ sư + nhà máy | |
|---|---|---|
| đầu việc vừa/tháng | 9–12 | 9–12 |
| thời gian ra bản đầu | 4–6 tuần | 3–4 tuần |
| chi phí nhân sự | 100% | 67% |
| chi phí hạ tầng & AI | ~0 | +5–8% |
| rủi ro chính | Phụ thuộc con người | Phụ thuộc kỷ luật quy trình |
Lợi ích thật không nằm ở chỗ giảm người, mà ở chỗ cùng số người làm được nhiều việc hơn mà chất lượng không tệ đi — và khi một người nghỉ, tri thức vẫn nằm trong kho mã, đặc tả và bộ kiểm thử.
Tám chỉ số phải đo
Không đo thì không biết nhà máy đang chạy tốt lên hay xấu đi. Bộ chỉ số tối thiểu:
| Chỉ số | Cách đo | Ngưỡng tốt |
|---|---|---|
| Tần suất triển khai | Số lần lên production mỗi tuần | ≥ 5 |
| Thời gian từ mã đến chạy | Trung vị từ lúc mở nhánh đến production | < 1 ngày |
| Tỷ lệ thay đổi gây lỗi | % bản phải sửa hoặc lùi | < 15% |
| Thời gian khắc phục | Trung vị từ lúc phát hiện đến hồi phục | < 2 giờ |
| Tỷ lệ mã do AI sinh | % dòng thay đổi có nguồn gốc AI | 40–70% |
| Tỷ lệ hoàn nguyên | % nhánh bị đóng không merge | < 20% |
| Chi phí trên đầu việc | (AI + hạ tầng) / số đầu việc hoàn thành | Giảm dần theo tháng |
| Độ phủ kiểm thử theo rủi ro | % luồng nghiệp vụ quan trọng có kiểm thử | > 80% ở luồng tiền và quyền |
Hai chỉ số cuối ít được nói tới nhưng phát hiện vấn đề sớm nhất. Khi tỷ lệ hoàn nguyên tăng mà thời gian review cũng tăng, gần như chắc chắn đặc tả đang mơ hồ — không phải AI yếu.
Chống "AI slop" và nợ kỹ thuật
"AI slop" là mã trông hợp lý, chạy được ở đường hạnh phúc, nhưng sai ở biên, trùng lặp logic, và không ai dám sửa. Bảy quy tắc dưới đây giữ nhà máy khỏi sinh ra nó:
- Đặc tả trước, mã sau. Không có tiêu chí nghiệm thu thì không mở nhánh.
- Nhánh nhỏ. Mục tiêu dưới 400 dòng thay đổi. Trên mức đó, review của người gần như vô hiệu.
- Không refactor ngoài phạm vi. Agent chỉ được chạm tệp trong danh sách của lô việc; việc dọn dẹp là một lô riêng.
- Kiểm thử vàng (golden tests). Các luồng nghiệp vụ quan trọng có bộ kiểm thử không được phép thay đổi nếu không có phê duyệt.
- Ranh giới module rõ. Một module không được đọc thẳng bảng của module khác; mọi giao tiếp qua hợp đồng.
- Một nguồn sự thật cho quy ước. Quy ước nằm trong kho mã, không nằm trong đầu người.
- Đọc diff như đọc hợp đồng. Người duyệt phải hiểu mình đang duyệt gì; duyệt cho xong chính là cách nhanh nhất để tạo nợ.
Dấu hiệu cảnh báo sớm: cùng một logic xuất hiện ở ba nơi; số tệp trong một lần thay đổi tăng dần; thời gian review trung bình vượt 60 phút; kiểm thử được sửa để "chạy cho qua".
Bảo mật và tuân thủ
Nhà máy làm việc nhanh hơn, nên lỗi bảo mật cũng lan nhanh hơn. Bảng rủi ro — kiểm soát:
| Rủi ro | Cách kiểm soát |
|---|---|
| Tiêm lệnh vào AI (prompt injection) từ dữ liệu người dùng | Không đưa văn bản ngoài vào ngữ cảnh có quyền ghi; tách kênh "dữ liệu" và "mệnh lệnh" |
| Lộ khoá bí mật trong mã hoặc log | Quét bí mật trong CI; khoá chỉ nằm trong kho bí mật, không trong tệp |
| Thư viện không tồn tại do AI bịa tên gói | Chỉ cho phép thư viện trong danh mục đã duyệt; khoá registry nội bộ |
| Chuỗi cung ứng bị chèn mã độc | Khoá phiên bản, kiểm tra chữ ký, tạo SBOM |
| Vi phạm giấy phép | Quét giấy phép tự động, chặn giấy phép không tương thích |
| Dữ liệu cá nhân bị gửi ra ngoài | Phân loại dữ liệu; ẩn danh trước khi gửi; thoả thuận xử lý dữ liệu với nhà cung cấp |
| Không truy vết được | Ghi log: ai/agent nào đổi gì, dựa trên đặc tả nào, khi nào |
Với doanh nghiệp Việt Nam, phần dữ liệu cá nhân cần đối chiếu với Nghị định 13/2023/NĐ-CP: biết dữ liệu nào là dữ liệu cá nhân, dữ liệu nào nhạy cảm, luồng nào gửi ra nước ngoài. Nguyên tắc thực dụng: dữ liệu nhạy cảm không rời khỏi hạ tầng của doanh nghiệp — dùng mô hình chạy nội bộ cho các luồng đó.
Một điểm nữa ít được chú ý: agent có quyền chạy lệnh trong repo thì cũng có quyền chạy lệnh trên máy. Cần sandbox, giới hạn quyền truy cập mạng, và không cấp quyền ghi vào kho bí mật.
Con người và tổ chức
Nhà máy đổi cấu trúc đội. Bốn vai xuất hiện:
| Vai | Trách nhiệm | Tỷ lệ gợi ý |
|---|---|---|
| Chủ đặc tả (Product Engineer) | Viết đặc tả, quyết định phạm vi, duyệt hành vi | 1 người / 1–2 luồng nghiệp vụ |
| Kỹ sư nền tảng | Quy ước, mẫu, CI, công cụ, chi phí | 1 người / 5–8 kỹ sư |
| Người duyệt | Đọc diff, giữ chuẩn chất lượng | Luân phiên trong đội |
| Vận hành AI | Theo dõi eval, chi phí, sự cố do AI | Kiêm nhiệm giai đoạn đầu |
Ba hệ quả tổ chức thường gặp:
- Review trở thành nút cổ chai mới. Nếu vẫn giữ quy định "hai người duyệt mọi thay đổi", tốc độ sẽ nghẽn ở đây. Cách xử lý: phân tầng rủi ro — thay đổi nhỏ, ít rủi ro chỉ cần một người duyệt; thay đổi chạm tiền, quyền, dữ liệu cần hai.
- Đánh giá hiệu suất phải đổi. Đếm số dòng mã hoặc số commit trở nên vô nghĩa. Chuyển sang đếm đầu việc hoàn thành đúng hạn, tỷ lệ lỗi sau bàn giao, chất lượng đặc tả.
- Kỹ năng viết trở nên quan trọng hơn kỹ năng gõ. Người mô tả vấn đề rõ ràng tạo ra giá trị lớn hơn người gõ nhanh.
Lộ trình 12 tháng
| Giai đoạn | Thời gian | Việc chính | Điều kiện để qua giai đoạn sau |
|---|---|---|---|
| 0. Chuẩn bị | 2–4 tuần | Viết quy ước, tạo mẫu module, dựng CI, đo chỉ số hiện tại | Toàn bộ kiểm thử chạy trong CI dưới 10 phút |
| 1. Một luồng dọc | 4–6 tuần | Chọn một module nhỏ, chạy đủ 9 bước với 1 agent | Đầu việc ra production đúng hạn, không lỗi nghiêm trọng |
| 2. Mở rộng | 2–3 tháng | 2–3 agent song song, viết eval, phân tầng review | Thời gian review không tăng, tỷ lệ hoàn nguyên dưới 20% |
| 3. Nhà máy | 3–6 tháng | Tự động hoá triển khai, cờ tính năng, đo chi phí theo đầu việc | Chỉ số ổn định 2 tháng liên tiếp |
Đừng nhảy giai đoạn. Lỗi phổ biến nhất là bật nhiều agent song song khi bộ kiểm thử còn yếu — kết quả là hàng loạt nhánh dở dang và niềm tin sụp đổ sau hai tuần.
Mười câu hỏi tự đánh giá
Nếu trả lời "không" từ 3 câu trở lên, bạn chưa có nhà máy — đang ở cấp 1 hoặc 2:
- Quy ước mã nguồn có nằm trong kho mã và ai cũng đọc được không?
- Bộ kiểm thử có chạy tự động trên mỗi nhánh trong dưới 10 phút không?
- Một thay đổi có lên production trong cùng ngày không?
- Có thể lùi một bản phát hành trong 5 phút không?
- Đặc tả có tiêu chí nghiệm thu trước khi mở nhánh không?
- Có đo được tỷ lệ mã do AI sinh ra không?
- Có đo được chi phí AI trên mỗi đầu việc hoàn thành không?
- Có bộ kiểm thử vàng cho các luồng chạm tiền và quyền không?
- Review có phân tầng theo rủi ro không?
- Tri thức sau mỗi dự án có quay lại kho mã (mẫu, ADR) không?
Bảy sai lầm phổ biến
- Mua công cụ trước, xây quy trình sau. Công cụ tốt không bù được quy ước rỗng.
- Cho agent quyền sửa toàn kho mã. Kết quả là các thay đổi ngoài phạm vi, khó review, khó lùi.
- Review hình thức. Duyệt 800 dòng diff trong 5 phút là tự tạo nợ kỹ thuật có chủ đích.
- Nhầm tốc độ gõ mã với tốc độ bàn giao. Nút thắt thật thường nằm ở kiểm thử, review và triển khai.
- Không viết eval. Với các luồng có AI ra quyết định, không có eval nghĩa là mỗi thay đổi mô hình đều là một canh bạc.
- Đo số dòng mã. Chỉ số này luôn tăng, kể cả khi sản phẩm tệ đi.
- Bỏ qua chi phí review. Đây là khoản làm nhà máy mất lãi nhanh nhất.
Khi nào chưa nên xây
- Sản phẩm còn đang tìm mô hình kinh doanh. Bạn cần tốc độ thử nghiệm, không cần tính đều đặn. Dùng vibe coding có kiểm soát là đủ.
- Hệ thống không có kiểm thử và không thể viết kiểm thử. Nhà máy không thể chạy trên nền không kiểm chứng được.
- Đội dưới 3 người và khối lượng việc nhỏ. Chi phí dựng nền lớn hơn lợi ích.
- Sản phẩm chịu quy định chặt ở mọi dòng mã. Cần quy trình phê duyệt riêng, nhà máy chỉ dùng được ở phần không chạm dữ liệu nhạy cảm.
- Không có người chịu trách nhiệm về kiến trúc. AI sẽ tự chọn kiến trúc; không ai chặn thì ba tháng sau sẽ có năm kiến trúc.
Một ví dụ minh hoạ
Để dễ hình dung, đây là một dự án điển hình ở mức vừa (số liệu là ví dụ, không phải cam kết):
Bài toán: module quản lý đơn hàng cho chuỗi bán lẻ 6 cửa hàng, có phân quyền theo cửa hàng, in hoá đơn, đồng bộ tồn kho, báo cáo doanh thu theo ngày.
Cách chạy:
- Tuần 1: viết đặc tả 14 trang, 22 tiêu chí nghiệm thu; dựng CI, mẫu module, bộ kiểm thử vàng cho luồng tạo đơn và trả hàng.
- Tuần 2: 3 lô dọc chạy song song (tạo đơn, in hoá đơn, đồng bộ tồn kho); mỗi lô một agent, mỗi nhánh sống dưới 2 ngày.
- Tuần 3: lô báo cáo và phân quyền; kiểm thử giao diện; diễn tập hoàn nguyên; bật cờ tính năng cho 1 cửa hàng.
Kết quả điển hình: khoảng 60–70% mã do AI sinh, kỹ sư dành phần lớn thời gian cho đặc tả và review, số lỗi phát hiện sau khi bật thật thấp hơn cách làm cũ vì mỗi luồng tiền đều có kiểm thử vàng.
Điều đáng chú ý: phần lớn thời gian tiết kiệm không đến từ việc gõ mã nhanh, mà từ việc không phải hỏi lại yêu cầu và không phải sửa lỗi hồi quy — hai nguồn lãng phí lớn nhất của phát triển phần mềm truyền thống.
Liên quan
- AI Agent là gì — công cụ nằm ở lớp 2 của nhà máy
- Tự động hoá bằng AI — dịch vụ triển khai
- Chi phí AI Agent — cách tính chi phí vận hành
- Quy trình làm việc — quy trình giao việc và bàn giao của DNT
- Bảng giá — chi phí triển khai theo quy mô