AI coding đã qua thời "chọn model": 5 tầng Model – Harness – Loop – Graph – Factory quyết định code AI có đáng tin không

Hai năm qua, câu hỏi quen thuộc của giới dev là "model nào viết code ngon hơn?". Theo bài viết của Code Web Không Khó (viết lại theo góc nhìn của tác giả, lấy cảm hứng từ bài gốc của Sumant Thakur trên Substack), câu hỏi đó đã lỗi thời: model giờ chỉ là một "công nhân" tạo ra code, còn độ tin cậy của code nằm ở hệ thống 5 tầng bao quanh nó — Model, Harness (môi trường chạy), Loop (vòng lặp thử–kiểm chứng), Graph (đồ thị điều phối nhiều agent) và Factory (tầng vận hành ở quy mô lớn). Agent được đề xuất, nhưng hệ thống và con người mới quyết định; và theo tác giả, thay vì hỏi model nào ngon nhất, hãy hỏi 6 câu về context, quyền sửa, bằng chứng, quyền quyết định và điểm dừng cho con người.

Trả lời nhanh

• Model chỉ còn là "người tạo ra": workflow chuẩn không bắt đầu bằng "build feature này đi" mà bằng một bản spec đã được duyệt — input/output ra sao, ranh giới bảo mật, tiêu chí nghiệm thu, phạm vi được sửa và bằng chứng nào chứng minh đã xong. Planner tách spec thành việc nhỏ, Builder làm trong workspace cách ly, và Builder không được tự chấm mình đúng: check tự động chấm, Evaluator kiểm tra độc lập, con người giữ quyền merge cuối cùng.
• Harness là môi trường quanh "công nhân": context, công cụ, quyền hạn và môi trường chạy quyết định bao nhiêu năng lực của model "sống sót" được trong repo thật — model quyết định trần năng lực, harness quyết định phần năng lực đó thành sản phẩm được bao nhiêu. Ví dụ được bài viết dẫn: một team nhỏ của OpenAI dùng Codex viết gần như toàn bộ một sản phẩm, sau 5 tháng đạt khoảng 1 triệu dòng code và 1.500 PR đã merge với ban đầu chỉ 3 engineer (số liệu theo bài viết).
• Loop dùng được phải có bằng chứng và điều kiện dừng từ bên ngoài: vòng lặp "thử – fail – thử lại" một cách ngây thơ chỉ tạo ra lặp lại chứ không tạo ra tin cậy; lỗi phải được phân loại trước khi quyết định thử lại, retry phải có giới hạn, và hết ngân sách hoặc gặp lỗi ngoài quyền của agent thì phải dừng hoặc chuyển lên người. Quyết định giá trị nhất của loop đôi khi là: model không nên chạy.
• Graph trả lời câu hỏi "ai hoặc cái gì hành động tiếp theo": nhiều agent (nghiên cứu, backend, hạ tầng) chạy song song rồi gặp nhau ở bước tích hợp; mỗi loại lỗi đi một đường khác nhau — lỗi code quay về Builder, plan sai quay về Planning, thiếu quyết định sản phẩm thì dừng đợi người. Trong kiến trúc này, loop trở thành một node, còn edge (cạnh nối) trở thành quyết định kỹ thuật.
• Factory là tầng vận hành tất cả ở quy mô lớn: khi engineer chạy hàng chục session song song qua nhiều công cụ, model, branch và project, việc quản lý context không còn là kỹ thuật prompt mà trở thành hạ tầng. Factory quyết định worker nào nhận task nào, context nào, quyền nào, verification nào và checkpoint người ở đâu — nhờ đó các coding agent như Codex, Claude Code hay Kiro trở thành những worker có thể thay thế lẫn nhau trong một hệ thống lớn hơn.

Vì sao câu hỏi "model nào viết code ngon hơn" đã lỗi thời?

Theo lập luận của bài viết, hai năm tranh cãi về model đã che mất một thực tế: model chỉ là một thành phần trong hệ thống tạo ra phần mềm. Model trả lời câu hỏi "tôi nên tạo ra cái gì?" — nó sinh ra code. Nhưng code đó có đáng tin hay không lại do các tầng xung quanh quyết định: nó được phép làm gì, được kiểm chứng bằng cách nào, khi sai thì quay về đâu, và ai là người quyết định cuối cùng.

Bài viết tách hệ thống đó thành 5 tầng: Model, Harness, Loop, Graph và Factory. Bốn tầng sau model chính là "ngành kỹ thuật" đang hình thành quanh AI coding — nơi công việc của engineer dịch chuyển từ tự tay viết code sang thiết kế hệ thống để agent viết code một cách đáng tin.

Tầng 1 — Model: "người tạo ra" không được tự chấm mình đúng

Điểm thay đổi lớn nhất ở tầng Model là cách một task bắt đầu. Theo bài viết, workflow chuẩn hiện nay không mở đầu bằng câu lệnh "build feature này đi", mà bằng một spec đã được duyệt, trong đó ghi rõ: input và output kỳ vọng, ranh giới bảo mật, tiêu chí nghiệm thu, phạm vi agent được phép sửa, và bằng chứng nào cần có để khẳng định task đã xong.

Từ spec đó, Planner tách công việc thành các phần nhỏ; Builder thực thi trong một workspace cách ly. Nguyên tắc xuyên suốt là phân tách quyền tạo và quyền chấm: Builder được đề xuất và được làm, nhưng không được tự tuyên bố mình đúng. Check tự động đảm nhiệm việc chấm theo tiêu chí xác định, Evaluator kiểm tra độc lập thêm một lớp, và con người giữ quyền merge cuối cùng. Nói ngắn gọn như tác giả: agent đề xuất — hệ thống và con người quyết.

Tầng 2 — Harness: môi trường quyết định năng lực "sống sót" được bao nhiêu

Harness trả lời câu hỏi "agent được phép và được trang bị để làm gì?". Nó là toàn bộ môi trường bao quanh model: context được cấp, các công cụ được dùng, quyền hạn được mở và môi trường thực thi. Đây cũng là chủ đề mà nhiều đội ngũ lớn đang đầu tư mạnh, theo các ví dụ bài viết dẫn lại:

• OpenAI: một team nhỏ dùng Codex để viết gần như toàn bộ một sản phẩm; sau 5 tháng, theo bài viết, sản phẩm đạt khoảng 1 triệu dòng code với 1.500 PR đã merge, trong khi ban đầu team chỉ có 3 engineer. Điểm đáng chú ý không nằm ở lượng code, mà ở việc công việc của engineer đã đổi: viết rõ ý định, tổ chức repo sao cho agent "đi lại" trong đó một cách tin cậy, và xây các ràng buộc kiến trúc cùng cơ chế kiểm tra.
• Anthropic: tách rõ ba vai trò Planner – Generator – Evaluator, với nguyên tắc người tạo ra code không được tự tuyên bố code đó đúng.

Kết luận của tác giả ở tầng này là một câu đáng nhớ: model quyết định trần năng lực, harness quyết định bao nhiêu năng lực đó sống sót trong repo thật. Cùng một model, đặt vào hai harness khác nhau — một bên context lộn xộn, quyền mở tràn lan và không có kiểm chứng; một bên spec rõ, repo được tổ chức cho agent và check tự động đầy đủ — sẽ cho ra hai mức độ tin cậy hoàn toàn khác nhau.

Tầng 3 — Loop: khi nào nên dừng quan trọng không kém khi nào nên thử lại

Loop trả lời câu hỏi "có nên tiếp tục không?". Bài viết phân biệt hai loại loop. Loop ngây thơ vận hành theo kiểu thử – fail – thử lại vô điều kiện: nó chỉ tạo ra sự lặp lại, không tạo ra độ tin cậy, vì agent có thể lặp lại cùng một sai lầm với chi phí tăng dần.

Một loop dùng được cần hai thứ từ bên ngoài vòng lặp: bằng chứng để quyết định, và điều kiện dừng rõ ràng. Cụ thể: lỗi phải được phân loại trước khi quyết định có thử lại hay không; số lần retry phải có giới hạn; khi hết ngân sách hoặc gặp lỗi nằm ngoài quyền xử lý của agent, loop phải dừng hoặc chuyển quyết định lên con người.

Ví dụ bài viết dẫn là hệ thống Sherlock của Atlan: khoảng 11.000 alert mỗi tháng; khi thêm một lớp "admission" (lớp tiếp nhận/lọc đầu vào) chặn hơn 85% alert trước khi gọi tới model, thời gian điều tra giảm từ hơn 10 phút xuống còn khoảng 2 phút (số liệu theo bài viết). Bài học rút ra: quyết định giá trị nhất của một loop đôi khi là quyết định model không nên chạy — lọc bớt việc không cần AI ngay từ cổng vào vừa tiết kiệm chi phí vừa tăng tốc độ xử lý phần việc thực sự cần model.

Tầng 4 — Graph: lỗi khác nhau phải đi đường khác nhau

Graph trả lời câu hỏi "ai hoặc cái gì hành động tiếp theo?". Bản thân khái niệm đồ thị/DAG/workflow không mới; cái mới, theo bài viết, là thứ nằm bên trong các node: một node giờ có thể là agent lập kế hoạch, agent viết code, một bước tích hợp, một bước kiểm tra chính sách, một bước verification, một vòng repair, hay một điểm chờ duyệt của con người.

Trong bức tranh đó, nhiều agent chuyên trách chạy song song — ví dụ một agent nghiên cứu dependency, một agent làm backend, một agent lo hạ tầng — rồi hội tụ ở bước tích hợp. Và quan trọng nhất là cách định tuyến khi có lỗi: lỗi code quay về Builder, kế hoạch sai quay về bước Planning, còn khi thiếu một quyết định thuộc về sản phẩm thì graph dừng lại và đợi người.

Tác giả chốt tầng này bằng hai ý: trong kiến trúc graph, loop trở thành một node, và edge trở thành một quyết định kỹ thuật — những cạnh nối đó chính là những phán đoán trước đây chỉ nằm trong đầu của developer giàu kinh nghiệm, nay được viết ra thành cấu trúc tường minh của hệ thống.

Tầng 5 — Factory: khi quản lý context trở thành hạ tầng

Factory trả lời câu hỏi "làm sao vận hành và cải tiến tất cả những thứ trên ở quy mô lớn?". Bài viết nhắc tới một số hướng đi đang hình thành ở tầng này: Xirp tập trung vào session, workspace cách ly và context có thể mang theo; Kiro Crew bổ sung thực thi bền vững, retry, replan và điều phối các task sống lâu; Warp Factories đi xa hơn với điều phối xuyên suốt vòng đời phát triển phần mềm.

Ví dụ được dẫn là Spotify: engineer ở đó không còn chạy một assistant trong một repo, mà chạy nhiều session song song qua nhiều công cụ, model, branch và project; nền tảng Xirp được cho là đã vận hành qua hơn 36.000 session và được thiết kế để phối hợp hơn 50 session song song (số liệu theo bài viết). Tới quy mô đó, quản lý context không còn là một tiện ích của prompting — nó là hạ tầng.

Sự phân biệt của Warp, theo bài viết, làm rõ ranh giới giữa hai tầng trên cùng: harness chạy worker, còn factory quyết định worker nào nhận task nào, kèm context nào, quyền hạn nào, cơ chế verification nào và các checkpoint của con người đặt ở đâu. Hệ quả là các coding agent cụ thể — Codex, Claude Code, Kiro — trở thành những worker có thể thay thế cho nhau bên trong một hệ thống lớn hơn; Factory mới là hệ thống chọn và quản trị các coding agent đó.

Năm tầng khác nhau ở câu hỏi nào?

Tầng	Câu hỏi nó trả lời	Nội dung cốt lõi
Model	Tôi nên tạo ra cái gì?	Sinh code từ spec đã duyệt; Planner tách việc, Builder làm trong workspace cách ly, Builder không tự chấm mình đúng
Harness	Agent được phép và được trang bị để làm gì?	Context, công cụ, quyền hạn, môi trường chạy; repo được tổ chức cho agent; ràng buộc kiến trúc và cơ chế kiểm tra
Loop	Có nên tiếp tục không?	Thử lại dựa trên bằng chứng, lỗi được phân loại, retry có giới hạn, có điều kiện dừng và đường chuyển lên người
Graph	Ai hoặc cái gì hành động tiếp theo?	Nhiều agent/bước chạy song song và hội tụ; mỗi loại lỗi được định tuyến về đúng bước; điểm duyệt của người nằm trong đồ thị
Factory	Làm sao vận hành và cải tiến tất cả ở quy mô lớn?	Điều phối session, workspace, context và worker ở quy mô tổ chức; chọn và quản trị các coding agent như những worker thay thế được

Thay vì hỏi "model nào ngon nhất", hãy hỏi 6 câu này

Phần chốt của bài viết đề xuất đổi hẳn bộ câu hỏi khi đánh giá một hệ thống AI coding. Sáu câu hỏi đó là:

1. Model nhận context gì?
2. Nó được phép sửa những gì?
3. Nó tạo ra bằng chứng gì?
4. Ai quyết định task đã xong?
5. Khi verification fail thì sao?
6. Quyết định nào vẫn thuộc về con người?

Sáu câu hỏi này lần lượt chạm tới cả 5 tầng: context và quyền sửa thuộc về harness; bằng chứng và điều kiện khi verification fail thuộc về loop và cơ chế kiểm chứng; quyền quyết "đã xong" và những quyết định giữ lại cho người là phần quản trị mà graph và factory phải thiết kế tường minh. Một hệ thống trả lời rõ được cả sáu câu sẽ đáng tin hơn nhiều so với một hệ thống chỉ tự hào về model mạnh — đó là thông điệp trung tâm của bài.

Cần lưu ý cách đọc các con số trong bài: các số liệu về OpenAI, Anthropic, Atlan hay Spotify là những ví dụ bài viết dẫn lại (bài gốc lấy cảm hứng từ bài của Sumant Thakur trên Substack) và chưa được kiểm chứng độc lập tại đây; giá trị chính của bài nằm ở khung tư duy 5 tầng và bộ câu hỏi đánh giá, hơn là ở từng con số cụ thể.

Câu hỏi thường gặp

Harness, Loop, Graph, Factory khác nhau như thế nào?

Theo khung 5 tầng của bài viết: Harness là môi trường quanh agent (context, công cụ, quyền hạn, môi trường chạy) — trả lời "được phép và được trang bị để làm gì". Loop là vòng lặp thử–kiểm chứng có bằng chứng và điều kiện dừng — trả lời "có nên tiếp tục không". Graph là đồ thị điều phối nhiều agent và bước xử lý, định tuyến theo loại lỗi — trả lời "ai/cái gì hành động tiếp theo". Factory là tầng vận hành toàn bộ ở quy mô lớn — trả lời "làm sao vận hành và cải tiến tất cả". Model nằm ở trung tâm, chỉ đảm nhiệm việc tạo ra code.

Vì sao Builder không được tự chấm code của mình?

Vì khi người tạo ra kết quả cũng là người tuyên bố kết quả đúng, hệ thống mất đi lớp kiểm chứng độc lập — theo bài viết, đây là nguyên tắc mà cả cách làm của OpenAI lẫn Anthropic (tách Planner – Generator – Evaluator) đều tuân theo. Trong workflow được mô tả, Builder đề xuất và thực thi trong workspace cách ly; check tự động chấm theo tiêu chí xác định, Evaluator kiểm tra độc lập, và con người giữ quyền merge cuối cùng.

Một "loop tốt" cần những điều kiện gì?

Theo bài viết, một loop dùng được cần: bằng chứng từ bên ngoài để quyết định thay vì cảm tính của chính agent; lỗi được phân loại trước khi quyết định thử lại; giới hạn số lần retry; và điều kiện dừng rõ ràng — hết ngân sách hoặc lỗi ngoài quyền của agent thì dừng hoặc chuyển lên người. Loop ngây thơ kiểu "thử – fail – thử lại" vô điều kiện chỉ tạo ra lặp lại, không tạo ra độ tin cậy.

Factory khác Harness ở điểm nào?

Theo cách phân biệt của Warp mà bài viết dẫn: Harness chạy worker — tức môi trường để một agent thực thi một task. Factory ở tầng cao hơn: nó quyết định worker nào nhận task nào, với context nào, quyền nào, verification nào và checkpoint con người ở đâu, trên quy mô nhiều session, nhiều repo và nhiều công cụ. Nhờ tầng Factory, các coding agent như Codex, Claude Code hay Kiro trở thành worker có thể thay thế lẫn nhau.

Khung 5 tầng này có ý nghĩa gì với một team nhỏ, chưa có "factory"?

Có, vì 5 tầng là một thang độ trưởng thành chứ không phải yêu cầu phải có đủ ngay. Một team nhỏ vẫn áp dụng được ngay các nguyên tắc ở tầng dưới: bắt đầu task bằng spec đã duyệt thay vì prompt mơ hồ (Model), tổ chức repo và quyền hạn cho agent (Harness), đặt giới hạn retry và điều kiện dừng (Loop). Graph và Factory trở nên cần thiết khi số agent, số session và số repo tăng lên — và bộ 6 câu hỏi chốt bài là checklist dùng được ở mọi quy mô.

Kết luận

Thông điệp của bài viết có thể gói trong một câu: model đang trở thành một công nhân, còn kiến trúc quanh nó đang trở thành một ngành kỹ thuật. Khi coding agent ngày càng phổ biến, lợi thế cạnh tranh của một team không còn nằm ở việc chọn đúng model "ngon nhất", mà ở khả năng thiết kế đủ 5 tầng — spec rõ ràng cho model, harness đủ tốt để năng lực của model sống sót trong repo thật, loop biết dừng đúng lúc, graph định tuyến đúng việc cho đúng tác nhân, và factory vận hành tất cả ở quy mô lớn với quyền quyết định cuối cùng vẫn thuộc về con người ở những điểm quan trọng nhất.

Nguồn: bài viết "AI coding đã vượt qua thời kỳ Agent — giờ là thời kỳ của hệ thống quanh Agent" của Code Web Không Khó trên Facebook (11/11/2026); tác giả cho biết bài được viết lại theo góc nhìn cá nhân, lấy cảm hứng từ bài gốc "AI Coding Is Moving Beyond the Agent" của Sumant Thakur trên Substack. Các số liệu về OpenAI, Anthropic, Atlan, Spotify được dẫn theo bài viết, chưa kiểm chứng độc lập; biên tập và hệ thống hóa bởi Wotech Electronics. Ảnh minh họa: ảnh đính kèm bài viết gốc.