Hai bài viết của Dex Horthy (HumanLayer), đọc cùng nhau, tạo ra một lập luận mạnh hơn nhiều so với đọc riêng lẻ. “Advanced Context Engineering for Coding Agents” (ACE-FCA) là hướng dẫn thực chiến: quy trình cụ thể giúp một team nhỏ ship 35 nghìn dòng Rust production trong một ngày. “Why Software Factories Fail” (WSFF) là phần lý thuyết bên dưới: lời giải thích thẳng thắn cho việc tại sao các model hiện nay không thể được tin tưởng chạy không giám sát, dù harness có tốt tới đâu. Đọc theo thứ tự này, chúng tạo thành một lập luận xuyên suốt: câu chuyện “cứ viết thêm loop, để agent chạy lights-off” đang tối ưu sai mục tiêu, và cách khắc phục thực sự là một kỷ luật cụ thể, có thể học được — không phải một prompt tốt hơn, không phải context window lớn hơn, không phải model đời sau.

Phần lý thuyết: Vì sao “lights-off” không hoạt động

Luận điểm cốt lõi của WSFF khá khó chịu với bất kỳ ai muốn coi AI coding là bài toán đã giải xong: đây không phải vấn đề kỹ năng, đây là vấn đề huấn luyện model.

Các coding model được huấn luyện bằng RL trên các benchmark như SWE-bench: agent nhận một bug report, viết một patch, và patch được chấm 1 hoặc 0 dựa trên việc test có pass mà không phá vỡ test khác hay không. Tín hiệu reward đó có một lỗ hổng đủ lớn để lái xe tải qua: không có hình phạt nào cho việc làm xói mòn khả năng bảo trì codebase. Một model bọc mọi thứ trong try/catch, ép kiểu vượt qua hệ thống type, hay lặp logic ở mười một chỗ khác nhau, vẫn được chấm điểm y hệt một model viết phiên bản sạch — miễn là test xanh. Sau hàng triệu vòng lặp RL, bạn đã tối ưu rất mạnh cho “làm test pass” và gần như không tối ưu cho “không làm codebase khó làm việc hơn sau sáu tháng.”

Khoảng trống đó giải thích một pattern mà nhiều team đã trải qua trực tiếp: model đã cải thiện rõ rệt trong việc giải quyết vấn đề đơn lẻ và xây dựng greenfield trong năm qua, nhưng “không cải thiện nhiều” trong việc duy trì chất lượng codebase theo thời gian — vì không có cách nào nhanh và đáng tin cậy để chấm điểm điều đó trong lúc huấn luyện. Việc pass test là tín hiệu trong ngày; kiến trúc tồi là chi phí xuất hiện sau vài tuần hoặc vài tháng, và không có cách nào để backprop sự cố đó về quyết định thiết kế đã gây ra nó.

Team của Horthy đã thử mô hình factory lights-off hoàn toàn, thật sự, vào giữa 2025 — background agent xử lý mọi thứ, không ai đọc code. Nó hoạt động cho tới khi không hoạt động nữa: cuối cùng một bug xuất hiện mà không lượng prompting nào có thể gỡ ra được, vì chẳng ai đọc đoạn code đã dẫn tới nó. Đến lần tái diễn thứ ba, viết lại hệ thống từ đầu rẻ hơn là tiếp tục debug thứ mà agent đã dựng lên.

Cách khắc phục: Bật đèn trở lại

Cách khắc phục không phải “review nhiều code hơn” theo nghĩa cũ — cách đó cũng không scale nổi với tốc độ output của agent. Đó là front-load cấu trúc trước khi code được viết, cùng bản năng khiến các team phần mềm con người làm planning và architecture review từ hàng chục năm trước khi có AI, áp dụng tại bốn điểm kiểm tra nơi một bước đi sai là rẻ nhất để bắt lỗi:

1. Product Review — một tài liệu ngắn chốt vấn đề thực sự của người dùng và thành công trông như thế nào, kèm mockup HTML thô thay vì mô tả bằng văn xuôi khi UI còn chưa rõ. Không phải mọi thứ cần bước này — một chỉnh sửa nội dung hay fix bug rõ ràng đi thẳng tới agent.
2. System Architecture — cách các service, endpoint, schema, và store nói chuyện với nhau, thể hiện bằng sequence diagram và hình dạng contract, chưa đi sâu vào chi tiết implementation.
3. Program Design — bước hầu hết team bỏ qua, và Horthy gọi là “bị xem nhẹ một cách đáng trách”: cây call-stack, diff cây thư mục file, và chữ ký hàm cho hình dạng của code, quyết định trước khi ai đó viết implementation. Mỗi quyết định này là thứ bạn vốn sẽ phải quyết định ngầm trong lúc code review — tại thời điểm đắt đỏ nhất để đổi ý.
4. Vertical Slices — thay vì build theo chiều ngang theo tầng (migration → service → API → frontend, thứ không tạo ra gì test được cho tới tận cuối), build một đường mỏng xuyên suốt toàn bộ stack tại một thời điểm, test được bằng trình duyệt hoặc curl ở mỗi bước.

Không phải task nào cũng cần cả bốn bước. Phân bổ tương đối của Horthy: ~40% task được làm one-shot với feedback nhẹ, task tầm trung gộp product/system design vào một tài liệu, và chỉ task lớn hoặc thực sự rủi ro mới nhận đủ bốn giai đoạn.

Thực hành đi kèm: Context là đòn bẩy duy nhất bạn có

ACE-FCA cung cấp cơ chế khiến quy trình bốn giai đoạn thực sự hoạt động ở từng lượt: frequent intentional compaction (nén có chủ đích, thường xuyên). Tiền đề rất thẳng thắn — một lệnh gọi LLM là một hàm stateless, và context window là thứ duy nhất quyết định chất lượng output. Tối ưu nó cho độ đúng trước, độ đầy đủ thứ hai, kích thước thứ ba. Những điều tệ nhất có thể xảy ra với context window, theo thứ tự, là: thông tin sai, thông tin thiếu, và nhiễu.

Quy trình cụ thể gồm ba bước, cố tình giữ tách biệt để không context window nào phải ôm mọi thứ cùng lúc:

• Research — hiểu codebase và cách thông tin luân chuyển, chưa cố gắng sửa gì.
• Plan — các bước chính xác, file, và cách sửa, cụ thể về testing/verification cho từng phase.
• Implement — đi qua kế hoạch từng phase, nén lại trạng thái vào tài liệu plan sau mỗi phase.

Lập luận về đòn bẩy bên dưới điều này đáng nhớ nhất dù bạn có quên hết phần còn lại: một dòng code tồi là một dòng code tồi. Một dòng plan tồi có thể tạo ra hàng trăm dòng code tồi. Một dòng research tồi — một giả định sai về cách codebase hoạt động — có thể tạo ra hàng nghìn dòng. Vì vậy công sức review của con người nên đặt ở giai đoạn research và plan, không dàn đều khắp pipeline. Review một plan 200 dòng là một hành động rẻ hơn và khác về bản chất so với review một diff 2.000 dòng sau khi đã viết xong, và nó bắt được cùng loại lỗi sớm hơn.

Ý nghĩa với một Tech Lead

Gộp lại, hai bài viết hội tụ về một nguyên tắc vận hành: điểm đòn bẩy trong agentic coding đã chuyển từ “viết code” sang “viết spec, và quyết định ai review nó, khi nào.” Công việc không biến mất, nó dịch chuyển sớm hơn và tập trung hơn — đây chính là lý do phán đoán của một tech lead quan trọng hơn ở đây, không phải kém quan trọng hơn.

Hướng dẫn triển khai

Ở công ty

1. Dừng ngay bất kỳ pilot “lights-off” nào đang âm thầm chạy. Nếu bất kỳ phần nào trong pipeline của bạn đưa output của agent thẳng tới production mà không ai đọc, đó chính xác là failure mode cả hai bài viết mô tả. Nó sẽ hoạt động tốt trong nhiều tháng, rồi thất bại đắt đỏ ở đúng con bug mà chẳng ai theo dõi.
2. Khớp độ sâu review với quy mô task, đừng “vì là AI nên review giống hệt nhau.” Áp dụng phân bổ tương đối của Horthy: task tầm thường (chỉnh sửa nội dung, fix bug rõ ràng) đi thẳng tới agent; task tầm trung gộp product/architecture vào một tài liệu; chỉ thay đổi lớn hoặc rủi ro cao mới nhận đủ bốn giai đoạn. Ép mọi task qua quy trình nặng sẽ đốt hết thiện chí bạn cần cho những trường hợp thực sự xứng đáng.
3. Thêm “Program Design” như một bước rõ ràng nếu team bạn hiện đang nhảy thẳng từ architecture sang code. Đây là khoảng trống của hầu hết team — không phải vì nó khó, mà vì nó cảm giác như nghi thức thừa thãi cho tới khi chính bạn là người debug bản sao thứ mười một của logic bị lặp. Một diff call-stack và vài chữ ký type tốn vài phút; đó là chỗ rẻ nhất còn lại để bắt một bước đi sai.
4. Xây lại thói quen review PR quanh tài liệu research và plan, không chỉ quanh diff. Nếu team bạn đã review tài liệu bất đồng bộ (Notion, GitHub discussions, gì cũng được), mở rộng thêm một bước sớm hơn — review plan giống cách bạn review PR, vì một lỗi ở tầng plan là lỗi đắt đỏ hơn nếu bắt muộn.
5. Đo lường theo failure mode, không chỉ theo tốc độ. Theo dõi tỷ lệ rework trên PR đã merge và số incident trên mỗi PR do agent tạo — cùng tín hiệu báo cáo của Faros AI đã chỉ ra ở quy mô ngành (nhiều comment review hơn, nhiều incident hơn, nhiều PR merge mà không review). Nếu các con số đó đang tăng trong khi team bạn ăn mừng “AI ship X% code,” bạn đang ở trong failure mode mà WSFF mô tả, không phải trường hợp thành công.
6. Tính thời gian review là thời gian kỹ thuật, không phải overhead. Cả hai bài viết đều nói rõ kỷ luật này tốn thời gian thật ngay từ đầu — 30 phút lên kế hoạch để tiết kiệm hàng giờ review là một sự đánh đổi, không phải bữa trưa miễn phí. Nếu leadership kỳ vọng agentic coding không tốn chi phí đó, kỳ vọng đó cần được điều chỉnh trước khi pipeline được xây, không phải sau sự cố đầu tiên.

Cho dự án cá nhân

1. Áp dụng research → plan → implement kể cả khi làm một mình. Lập luận về đòn bẩy vẫn đúng ở quy mô một người: một giả định sai trong đầu bạn, không bắt được trước khi bắt đầu implement, vẫn gây ra hiệu ứng nhân lên y hệt như với một team.
2. Viết plan thành một file bạn đọc lại, không phải một đoạn chat bạn cuộn lại xem. Nén tiến độ của chính bạn vào một file plan.md sau mỗi phase là phiên bản quy mô cá nhân của “frequent intentional compaction” — nó cho phép bạn quay lại dự án sau một khoảng nghỉ mà không phải suy luận lại từ đầu xem mình đã dừng ở đâu.
3. Coi vertical slice là mặc định, không phải build theo tầng ngang. Build database → service → API → frontend theo thứ tự stack nghĩa là không có gì test được cho tới tận cuối. Build một đường mỏng xuyên suốt trước — kể cả với một tầng giả lập — nghĩa là bạn bắt được hướng đi sai sau hai mươi phút, không phải sau hai nghìn dòng.

Ranh giới cần giữ

Không bài viết nào lập luận quay lại viết mọi thứ bằng tay — cả hai tác giả đều đang ship một lượng code khổng lồ do agent viết, nhanh hơn trước. Ranh giới hẹp hơn và cụ thể hơn: những phần của phát triển phần mềm đòi hỏi phán đoán về đánh đổi — xây gì, các mảnh ghép ra sao, code nên trông như thế nào trước khi được viết — vẫn cần một con người trong vòng lặp, vì chưa có tín hiệu huấn luyện nào hiện nay thưởng cho model làm đúng những phần đó. Bỏ qua phán đoán đó và bạn không đi nhanh hơn 10 lần; bạn đang vay tốc độ từ một codebase mà cuối cùng bạn sẽ phải trả lại, cộng lãi, dưới dạng một sự cố hoặc một lần viết lại.

Tuần này: chọn một feature hoặc fix hiện đang đi thẳng từ prompt tới merge mà không có tài liệu plan, và chèn một bước research + plan trước khi implement — kể cả một bản thô. So sánh cảm giác review với PR agent gần nhất bạn không review kỹ.

Nguồn: Why Software Factories Fail và Advanced Context Engineering for Coding Agents, cả hai của Dex Horthy / HumanLayer.