# Từ dark factory sang AI software factory: thứ thật sự chạy được

[Cole Medin](https://homus.dev/speakers/cole-medin) · [Cole Medin](https://homus.dev/orgs/cole-medin)

> Vì sao dark factory không chạy được và cách Cole Medin chạy software factory: plan từng release, holdout, core loop song song, manager agent, test trên staging.

Topics: Software Factory, Coding Agents, Workflow

Canonical: https://homus.dev/talks/my-ai-dark-factory-dream-is-dead-heres-what-actually-works

## 1. Giấc mơ AI Dark Factory và lý do nó tan vỡ

Cole Medin mở đầu bằng định nghĩa: AI Dark Factory là dạng tự động nhất của agentic engineering. Ta đưa cho nó một tài liệu ở mức cao cho một epic hoặc một release, và nó tự tìm cách build, validate mọi thứ rồi ship thẳng lên production. Nếu cách này đáng tin cậy được, đó sẽ là giấc mơ cho việc build bất kỳ phần mềm nào.

Nhưng, nói hơi kịch tính một chút cho có hiệu ứng, Cole bảo hy vọng và giấc mơ của anh ở đây đã bị nghiền nát. Trong quá trình thử nghiệm, tự build dark factory của riêng mình, anh đi tới kết luận rằng đây đơn giản không phải là cách nên làm. Tuy vậy, thứ đang thật sự chạy được cho anh, thứ anh đã biến dark factory thành, không cần khác đi quá nhiều. Anh không thật sự mất nhiều tính tự động. Đó là điều anh muốn trình bày trong video này.

![Sơ đồ The AI Dark Factory với các trạm Plan, Build, Judge, Merge trên băng chuyền](https://homus.dev/photos/GQatuTWSRqY-0003.jpg)

Một PRD đi vào một đầu, code đã ship đi ra đầu kia, không ai đứng trên "sàn xưởng". Bốn trạm Plan, Build, Judge, Merge nằm trên băng chuyền, dòng chữ đỏ "Nobody is in the chair" ghi rằng một agent riêng chấm và một script merge; mọi cổng kiểm đều là script hoặc agent, và code đi thẳng vào main.

Anh nói đây là một hành trình rất thú vị để đi tới chỗ anh đang đứng. Có rất nhiều bài học anh muốn chia sẻ: vì sao dark factory không chạy được, và vì sao thứ anh đang build bây giờ thì chạy được.

Với dark factory, theo Cole, kể cả khi ta có AGI và những LLM tốt nhất thế giới thì nó vẫn sẽ không chạy. Ta cần một hệ thống trông giống sơ đồ anh đưa lên tiếp theo. Anh biết sơ đồ trông phức tạp, nhưng anh hứa sẽ chia nó ra thật đơn giản.

## 2. Vì sao vẫn nên hiểu workflow này

Cole giải thích (trong video ngày 16/10/2026) vì sao hiểu loại workflow này là quan trọng: cách ta làm việc với coding agent, kể cả chỉ trong sáu tháng tới, sẽ không còn như bây giờ. Khi harness và LLM ngày càng tốt hơn, ta phải trao cho chúng nhiều quyền tự chủ hơn nếu muốn ship nhanh hơn. Anh thật sự tin rằng trong vài năm tới, mọi người và mọi công ty sẽ dịch chuyển dần về một hệ thống trông giống thế này.

![Sơ đồ đầy đủ How My AI Software Factory Runs](https://homus.dev/photos/GQatuTWSRqY-0103.jpg)

Tôi lên kế hoạch release, factory build, feedback của tôi quay lại dưới dạng issue. Ba tầng: (1) lên kế hoạch release kế tiếp cùng holdout scenarios, (2) factory build qua Split, Issues, Pick, Ship Simple hoặc Ship, App validation, Code review, Merge, Pull requests, có Manager agent trông chừng, (3) test rồi đưa feedback ngược lại. Biểu tượng khiên đỏ đánh dấu luật cứng, phần còn lại do agent tự quyết.

Kể cả khi bạn chưa muốn build hẳn một AI software factory đầy đủ ngay bây giờ (và Cole nhấn mạnh software factory khác với dark factory), vẫn đáng để xem toàn bộ quy trình trông ra sao. Có rất nhiều bài học anh đã đưa vào đây mà bạn có thể áp dụng ngay cho workflow agentic coding hiện tại của mình.

Nhìn tổng thể, đây là hướng anh thấy cả ngành đang hội tụ về. Khi làm việc với các công ty và build những hệ thống kiểu này, khi nói chuyện với những người đang tự làm factory của họ, anh thấy ai cũng đang build một hệ thống ngày càng giống nhau theo thời gian. Vì vậy theo anh đây thật sự là tương lai, là bước tiếp theo của agentic engineering.

## 3. Mục tiêu tự động hoá và dark factory của chính Cole

Trước khi đi vào bất cứ điều gì khác, Cole cần giải thích vì sao dark factory không chạy được như anh mong. Mục tiêu số một ở đây rất đơn giản: ta chỉ muốn làm cho coding agent tự chủ nhiều nhất có thể.

Anh nói rõ đây không phải vibe coding, vì ta bỏ rất nhiều công sức từ đầu để engineer harness. Đúng là ta tin agent lúc runtime khi nó đang build phần mềm, nhưng đó chỉ vì ta đã dồn phần lớn công sức kỹ thuật vào việc chuẩn bị để nó thành công. Ta định nghĩa chính xác quy trình nó phải đi qua khi build mọi thứ.

Dark factory của riêng Cole bắt đầu như một thí nghiệm công khai, khoảng đầu năm 2026. Anh kể ngồi xem factory chạy thì rất chán, vì ta chỉ ngồi chờ agent xử lý dần công việc. Nhưng như anh đã nói, phần lớn công sức kỹ thuật nằm ở harness từ trước, nên đó là thứ anh đã trình bày. Qua các video YouTube và livestream lúc đó, anh thấy rất vui, và anh đã build được một dark factory khá thành công.

![Bài blog của Dan Shapiro: The Five Levels: From Spicy Autocomplete to the Dark Factory](https://homus.dev/photos/GQatuTWSRqY-0247.jpg)

Bài blog "The Five Levels: From Spicy Autocomplete to the Dark Factory" của Dan Shapiro, đăng ngày 23/01/2026, nguồn cảm hứng chính cho dark factory của Cole. Đoạn mở đầu nói chi phí viết code đang giảm nhanh đến mức các đội phải thay đổi cách "trả nợ" tech debt.

Cole đã nói nhiều về chuyện này hồi đó, nhưng nguồn cảm hứng chính để anh build dark factory là bài blog của Dan Shapiro. Dan mô tả năm cấp độ tự động trong AI coding. Theo Cole, phần lớn chúng ta sống hằng ngày ở khoảng cấp ba, có thể cấp bốn, còn cấp năm, Dark Software Factory, là dạng tự động tối thượng.

Dan dùng phép so sánh với việc lái xe: ở dark factory thậm chí không còn vô lăng. Bạn chỉ đưa ra điểm đến cuối cùng, tức thứ bạn muốn build, nhưng không đưa chỉ dẫn nào về cách đi tới đó. Nghe như giấc mơ. Cole đùa rằng nó nghe đại loại thế này: "Hey Claude, hey Codex, đây là một app khổng lồ tôi muốn build. Đi tạo nó đi. Đừng dừng cho tới khi xong. Đừng mắc lỗi nào." Anh bảo đó gần như là cảm giác mà dark factory gợi ra.

## 4. Vấn đề cốt lõi: LLM không đọc được suy nghĩ của ta

Trên lý thuyết, có vẻ đến lúc nào đó dark factory sẽ trở nên thực tế, vì khi LLM ngày càng tốt hơn, tốt hơn nữa, ta sẽ chạm tới mức tự chủ này và nó sẽ dùng được thật. Nhưng có một vấn đề lớn, và vấn đề này liên quan đúng tới điều Cole đã trình bày trong video trước của anh.

![Sơ đồ Is Anything Still Worth Learning with AI, bottleneck là getting what you actually want](https://homus.dev/photos/GQatuTWSRqY-0343.jpg)

Viết code đã nhanh khủng khiếp, nhưng việc nhận được đúng thứ bạn muốn thì không nhanh lên bao nhiêu. Bottleneck nằm ở hai đầu: bạn nói điều mình muốn (lên kế hoạch, agent hỏi dồn bạn, bạn kiểm plan và edge case) và bạn kiểm xem mình nhận được đúng chưa (agent kiểm app chạy, chỉ bạn kiểm được đó có phải thứ bạn muốn).

Khi LLM ngày càng tốt, chúng giỏi hơn ở việc build phần mềm, nhưng không giỏi hơn bao nhiêu ở việc hiểu chúng ta và ý định của chúng ta. Bottleneck trở thành việc nhận được đúng thứ bạn thật sự muốn, vì con người sẽ không bao giờ truyền đạt hoàn hảo những feature ta muốn build, cách ta muốn bảo trì codebase, và những thứ tương tự. Cole biết nghe hơi sến, nhưng anh cho rằng dark factory sai về bản chất, vì dù LLM mạnh tới đâu, chúng sẽ không bao giờ đọc được suy nghĩ của ta.

Anh cũng đã nghe một lập luận ngược lại và thấy nó rất thú vị: có người nói LLM sẽ giỏi tới mức ý tưởng và ý định của chúng còn tốt hơn của chính ta, nên ta sẽ giao hẳn việc phát triển phần mềm cho chúng. Cole không tin điều đó. Anh nghĩ ta sẽ luôn phải ngồi ở ghế lái, vì dù LLM giỏi đến đâu, ta vẫn luôn là người hiểu người khác muốn gì. Những vấn đề ta đang giải cho khách hàng, ta sẽ luôn là người hiểu rõ nhất.

## 5. Ai bảo trì codebase: lập luận của Dex Horthy

Để thật sự giữ mình ở ghế lái, Cole nói ta cũng phải bảo đảm mình là một phần của việc bảo trì codebase. Ta không thể rút mình ra khỏi code hoàn toàn, vì coding agent có một cách bảo trì codebase khá kỳ lạ: chúng làm code phình ra, lan rộng (sprawl) rất nhiều.

![Talk Why Software Factories Fail của Dex Horthy tại AI Engineer World's Fair](https://homus.dev/photos/GQatuTWSRqY-0433.jpg)

Talk "Harness Engineering is not Enough: Why Software Factories Fail" của Dex Horthy, co-founder và CEO của HumanLayer, trên kênh AI Engineer, quay tại AI Engineer World's Fair.

Đây chính là lập luận chính của Dex Horthy. Theo Cole, vài tháng trước video này (đăng ngày 16/10/2026), Dex có một talk rất được chú ý tên là "Why Software Factories Fail", và lập luận chính của anh là khả năng bảo trì code: agent đơn giản là không theo kịp việc giữ code dễ bảo trì theo cách con người làm, nên ta vẫn phải là một phần của quy trình đó. Thật ra Dex cũng đã làm giống Cole: bắt đầu với dark factory rồi phải lùi lại một chút, thêm nhiều human in the loop hơn để nó thực tế được.

Cole cho rằng khi Dex nói "software factories fail", ý đó khớp hơn với định nghĩa dark factory của Cole: chính hệ thống kiểu đó là thứ không chạy được. Anh đã gom tất cả bài học vừa giải thích vào đây, và coi chúng là phần dẫn nhập quan trọng. Điều đó dẫn tới hệ thống anh đang có, thứ đang chạy cực kỳ tốt cho anh.

Anh tự đặt các câu hỏi: làm sao giữ được human in the loop mà quy trình vẫn tự động nhiều nhất có thể? Làm sao để ta tiếp tục cùng bảo trì codebase? Làm sao giữ agent đi đúng hướng khi chúng đang xử lý dồn dập rất nhiều ticket khác nhau? Theo Cole, tất cả những điều đó đều đã được đưa sẵn vào hệ thống.

## 6. Software factory khác dark factory ở phạm vi công việc

Có một khác biệt lớn giữa software factory và dark factory. Cole không muốn sa đà vào chuyện định nghĩa, nhưng anh nghĩ đây là một phân biệt thật sự quan trọng. Anh trình bày nó bằng một bản đơn giản hoá của software factory, rồi mới đi vào từng bước, để người xem thấy độ tin cậy và human in the loop được đưa vào như thế nào.

![Sơ đồ rút gọn How My AI Software Factory Runs với ba phần](https://homus.dev/photos/GQatuTWSRqY-0643.jpg)

Bản rút gọn: Plan the release (tôi cùng một agent, một proof of concept hoặc một epic nhỏ), Split thành các issue chạy song song được, rồi tới The loop gồm Pick, Ship, App validation, Code review, Merge (mỗi lap một issue, nhiều lap cùng lúc, Manager agent lùi ra xem mỗi vài giờ và hỏi tôi khi cần quyết), sau đó Staging (tôi test cả release) và Production khi đã đúng. Có gì chưa ổn thì thành issue mới. Bên dưới chia thành Part 1 Plan and split, Part 2 The loop, Part 3 Test it.

Ngoài khác biệt hiển nhiên là human in the loop (sẽ nói ở cuối), khác biệt lớn giữa AI software factory và dark factory là phạm vi công việc ta đưa vào hệ thống, và mức độ ta lên kế hoạch phạm vi đó cùng agent.

Với dark factory, ta buông tay hết mức có thể. Ta chỉ tạo một tài liệu ở mức cao cho cả ứng dụng khổng lồ mình muốn tạo, rồi kỳ vọng factory tự cắt nó thành issue và xử lý từng cái một hoặc vài cái song song. Điểm mấu chốt là mọi thứ hoàn toàn "tắt đèn" ngay khi ta đưa mô tả rộng về thứ mình muốn. Ta thậm chí để agent tự lấp chỗ trống cho một phần ý định của mình. Đó chính là vấn đề lớn Cole đã nói: ta không muốn agent tự đoán ý định của ta, dù đó là một model rất có năng lực.

Với software factory, ta đưa vào hệ thống từng release riêng lẻ. Factory vẫn tự mình xử lý dồn dập rất nhiều issue. Nhưng thay vì "build cả cái này đi, chạy", ta cùng tìm xem phạm vi công việc kế tiếp là gì, xác định các ticket và cách ta muốn chia việc. Sau đó mới để factory tự động xử lý.

## 7. Core loop giữ nguyên: issue vào, pull request ra

Core loop của factory vẫn y như cũ. Cách Cole xử lý mỗi GitHub issue, JIRA ticket hay bất cứ dạng nào, anh có một cách build và validate rất giống nhau. Luôn luôn là issue là input, pull request là output. Phần đó không đổi. Thứ làm factory có nhiều human in the loop hơn và đáng tin cậy hơn nằm ở những gì anh làm trước và sau vòng lặp.

Theo Cole, vòng lặp ở giữa giống nhau; khác biệt nằm ở việc lên kế hoạch từng release trước vòng lặp và tự kiểm trên staging sau vòng lặp.

Từ đây Cole đi qua ba phần cốt lõi của factory. Anh nói trước là sẽ giữ ở mức khá cao, vì anh đã bỏ hàng trăm giờ để build và test hệ thống này. Dĩ nhiên anh có thể đi rất sâu vào chi tiết, nhưng anh chỉ muốn đem lại cảm hứng chung về quy trình, nói về những gì thật sự đang chạy tốt trong cả ngành, và mời người xem để lại bình luận nếu muốn anh làm một video riêng về một phần cụ thể nào đó.

## 8. Phần 1: lên kế hoạch cho release kế tiếp

Trước khi vào core loop của factory có hai bước. Ta cần lên kế hoạch cho khối công việc lớn hơn muốn hoàn thành trong release kế tiếp, rồi cắt nó thành ticket, để có những mẩu việc nhỏ vừa miệng mà mỗi mẩu đi trọn được một vòng loop sẽ nói ở phần sau.

Bước đầu tiên, lên kế hoạch, Cole cố ý để nằm ngoài factory. Không có gì trong harness dẫn bạn qua bước này, vì anh giả định bạn đã có cách riêng để lên kế hoạch cùng agent. Anh có cách của anh, và có lẽ bạn cũng có. Với mọi công ty anh làm việc cùng, anh không muốn ép bước đó vào factory, và anh muốn mình ở trọn trong vòng lặp lúc lên kế hoạch. Vậy là bạn tạo PRD, tài liệu architecture, hay bất cứ thứ gì bạn vẫn thường làm theo cách bình thường của mình, và thứ đó trở thành input cho factory.

![Part 1 Plan the release: I plan it with an agent, The next release, Holdout scenarios](https://homus.dev/photos/GQatuTWSRqY-0943.jpg)

Part 1, "Plan the release, then split it". Khung 1 "I plan it, with an agent": tôi cùng một planning agent viết hai thứ trước khi có dòng code nào. The next release: greenfield là một proof of concept, brownfield là một epic nhỏ, ghi nó làm gì và nó không bao giờ được trở thành gì. Holdout scenarios: cách ta biết nó chạy, giữ ngoài context của agent chính để builder không bao giờ thấy, và App validation chạy chúng ở Part 2. Khung 2 bên phải là bước factory cắt release.

Như vậy ta đang lên kế hoạch cho release kế tiếp. Điểm làm software factory rất khác dark factory là ta không cố build cả ứng dụng một lần. Với greenfield, đó đơn giản là một proof of concept mà bạn muốn factory build cho release đầu tiên. Với brownfield (và đúng vậy, theo Cole factory chạy rất tốt khi áp lên codebase có sẵn), đó đơn giản là một epic nhỏ do bạn định nghĩa.

Cole biết "nhỏ" là chữ rất tuỳ cách hiểu với một epic. Mỗi tổ chức có cách riêng để định phạm vi cho một epic hay release, và việc đó hoàn toàn tuỳ bạn. Quy tắc ngón tay cái của anh là tạo một tài liệu epic sẽ được cắt thành khoảng 10 đến 20 ticket. Anh biết đó là một khoảng rộng, và mỗi ticket sẽ có kích thước rất khác nhau, nhưng đó là ước lượng tốt nhất anh đưa ra được. Khi bạn tự build factory và dùng hệ thống này, bạn sẽ dần luyện được cảm giác về cỡ epic hợp với mình.

Điểm quan trọng trong epic là bạn mô tả cả thứ ta đang build lẫn thứ ta cụ thể không build. Có danh sách những thứ nằm ngoài phạm vi (out of scope) cũng rất hữu ích để tiếp tục lái factory đúng hướng khi nó đang xử lý dần các ticket.

## 9. Holdout scenarios: bài test mà builder không được thấy

Thứ còn lại ta định nghĩa từ đầu, đặc thù hơn cho factory nhưng cũng rất hữu ích cho mọi workflow agentic coding, là holdout scenarios. Về cơ bản, một holdout scenario là một bài test ta sẽ chạy ở cuối phần implementation, nhưng agent implement, tức builder, không hề biết các holdout scenario là gì. Ta giấu thông tin đó đi.

Holdout scenarios được viết lúc lên kế hoạch, giữ ngoài context của builder, và chỉ bước App validation dùng tới, để agent không thể "học tủ" theo bài test.

Như vậy không có thiên lệch: agent không thể overfit phần implementation chỉ để các kịch bản test của ta pass. Cole nói đây là một thứ lớn đã tăng độ tin cậy cho software factory của anh, vì agent có tính xu nịnh (sycophantic). Nếu chúng biết các kịch bản test bạn sẽ dùng, chúng sẽ cố engineer phần implementation chỉ để những bài test đó pass. Nhiều khi phần mềm vì thế không thật sự được build tốt, nó chỉ được build tốt cho đúng những bài test đó. Vì vậy ta không muốn builder biết chúng là gì.

Ta định nghĩa tất cả những thứ đó trong một tài liệu. Bạn tạo PRD, tài liệu architecture hay gì đó như thường lệ, rồi factory nhận lấy và giúp bạn cắt nó thành ticket.

## 10. Factory cắt release thành issue và map dependency

Trong quá trình cắt ticket, factory cũng giúp bạn làm dependency mapping: tìm ra những việc có thể xử lý song song, và những dependency buộc các lap phải làm theo một thứ tự nhất định. Điểm mấu chốt là factory sẽ gắn GitHub label để dựng toàn bộ các dependency này, chuẩn bị cho core loop thành công, để nó làm và test mọi thứ theo đúng thứ tự.

![The factory splits it: các issue chạy song song và issue phụ thuộc](https://homus.dev/photos/GQatuTWSRqY-1223.jpg)

Khung 2 "The factory splits it" trong ví dụ một app ghi chú: bốn issue bắt đầu ngay, song song (#29 Download notes as JSON, #31 Search notes by text, #32 Word count on every note, #34 System dark mode), còn #30 Import notes phải chờ tới khi #29 được merge. Khung 3 bên phải là một issue trên GitHub (#31) với phần mô tả vấn đề, acceptance criteria dạng checklist và mục dependency.

Trong ví dụ trên màn hình, issue #31 "Search notes by text" ghi vấn đề là tìm một ghi chú cũ phải cuộn rất lâu, rồi liệt kê acceptance criteria: ô tìm kiếm liệt kê các ghi chú có chứa đoạn chữ, chữ hoa chữ thường không quan trọng, ghi chú mới nhất lên trước, tìm không thấy gì thì hiện gợi ý, và có test cho trường hợp khớp, không khớp và tìm rỗng. Issue này không phụ thuộc gì nên được bắt đầu ngay.

## 11. Human in the loop như những công tắc bật tắt

Ở bước này ta không bắt buộc phải có human in the loop. Cole nói phần lớn thứ anh đưa vào software factory giống như những công tắc (toggle) cho human in the loop. Có thể ta không review PR trước khi merge vào staging, hoặc có. Có thể ta review bản cắt ticket trước khi bắt đầu build, hoặc không.

Hai ví dụ Cole đưa ra: cùng một factory, mức human in the loop được bật hay tắt tuỳ độ phức tạp và rủi ro của từng release; ở cả hai, hệ thống vẫn tự xử lý các issue sau khi chúng được tạo.

Mỗi tổ chức, mỗi người có nhu cầu khác nhau. Nó cũng phụ thuộc vào độ phức tạp của thứ ta đang build trong release cụ thể đó. Có những release ta phải làm việc với compliance và quy định pháp lý, phải chắc chắn mọi thứ thật vững. Khi đó ta muốn review bản cắt ticket, muốn review các PR ở cuối, nhưng vẫn muốn hệ thống tự xử lý các issue sau khi ta tạo chúng.

Lại có những release mà có thể ta chỉ đang xử lý một backlog bug lớn. Trong trường hợp đó, có lẽ ta muốn tin hệ thống hoàn toàn để nó tự cắt ticket và merge thẳng vào môi trường staging. Theo Cole, nhu cầu ở đây là động: không phải lúc nào human in the loop cũng phải nằm ở chỗ này, chỗ này và chỗ này. Vì vậy anh làm factory rất dễ điều chỉnh.

Cole nói anh rất muốn cho xem factory chạy thực tế: các lần chạy, các plan của anh, các bản cắt ticket và danh sách issue trông thế nào. Anh đã thử quay một phiên bản video có tất cả những thứ đó, nhưng nó dài quá mức. Nên lần này anh phải giữ ở mức cao, và chắc chắn sẽ đi sâu hơn trong các video sau.

Điểm chính ở đây là sau bước lên kế hoạch và bước cắt ticket, ta có một danh sách GitHub issue, và ta sẽ xử lý dồn dập chúng bằng core loop của factory, gồm toàn bộ phần lên kế hoạch và validation.

## 12. Phần 2: core loop, bước Pick và hai nhánh build

Phóng to vào core loop, ta bắt đầu với GitHub issue. Ta có thể chạy nhiều lap song song. Vì đã làm dependency mapping, ta biết những việc nào làm được cùng lúc. Mỗi lần chạy một lap, nó chọn đúng một GitHub issue để làm, và gắn một kiểu label "claim" để các lap song song khác không nhặt trùng issue đó.

![Part 2 The loop: Issues, Pick, Ship Simple, Ship, App validation, Code review, Merge, Pull requests](https://homus.dev/photos/GQatuTWSRqY-1243.jpg)

Part 2, "The loop": mỗi lap một issue, có thể chạy nhiều lap cùng lúc. Issues (GitHub là input) đi vào Pick (chọn một issue và claim nó), rẽ sang Ship Simple cho thay đổi nhỏ hoặc Ship cho việc lớn với full pipeline, rồi App validation, Code review, Merge và Pull requests (GitHub là output). Phía trên là Me (trả lời câu hỏi của nó), Holdout scenarios (lấy từ plan, giấu khỏi builder) và Manager agent (mỗi vài giờ lùi ra và sửa thứ một lap không nhìn thấy).

Sau đó ta đưa ra một quyết định ngay từ đầu. Cole nhận ra điều này từ phiên bản đầu tiên của chính dark factory: khi anh dùng workflow đầy đủ cho mọi implementation, có những ticket cơ bản mất khoảng 20 hay 30 phút để implement trong khi chúng thật sự không cần tới mức đó.

![Phóng to Pick rẽ nhánh simple sang Ship Simple và complex sang Ship](https://homus.dev/photos/GQatuTWSRqY-1403.jpg)

Phóng to bước Pick: nhánh "simple" đi tới Ship Simple (thay đổi nhỏ, sửa các PR đang mở), nhánh "complex" đi tới Ship (việc lớn hơn, full pipeline). Luật cứng dưới Pick: thử 3 lần rồi hỏi tôi. Mũi tên đỏ phía dưới là đường gửi trả về kèm bằng chứng, để sửa ở một lap sau.

Vì vậy anh quyết định ngay từ đầu, bằng Jev: đây là việc đơn giản, chỉ cần một workflow build nhanh hơn, hay là việc phức tạp hơn, cần có các giai đoạn để lặp lại và những thứ tương tự. Agent đưa ra quyết định đó, nhưng dù đi nhánh nào, khi build xong nó vẫn đi qua validation và code review. Hai bước này cũng hiểu được, dựa trên độ phức tạp của implementation, cần bỏ bao nhiêu thời gian ở đây.

## 13. Validation khác code review

Cole có cả review lẫn validation vì đó là hai việc khác nhau. Validation nghĩa là, như một phần của harness, anh cho agent công cụ để thật sự test ứng dụng như một người dùng. Nó thay thế phần lớn việc test thủ công của anh, vì ta muốn hệ thống tự chủ hơn; đó là toàn bộ ý nghĩa của software factory. Cụ thể là bấm nút, gõ chữ vào ô chat, bất cứ thao tác nào ứng dụng đó có.

Sau đó là code review, phần thiên về phân tích hơn: vì đã biết app chạy được, giờ ta kiểm xem code có đơn giản không, có dễ bảo trì không, có được implement đúng không. Đó là những quyết định kỹ thuật phần mềm, kiểu code review cổ điển hơn.

![Phóng to App validation, Code review và Merge được khoanh đỏ](https://homus.dev/photos/GQatuTWSRqY-1523.jpg)

Phóng to nửa sau của loop: App validation (dùng app như một người dùng, chạy holdout), Code review (đọc code, quyết định nó đã sẵn sàng merge chưa, luật cứng: tối đa 2 lần gửi trả, các file được bảo vệ không được đụng), rồi Merge được Cole khoanh đỏ: reviewer là người merge, chỉ khi CI xanh và chỉ merge đúng phần code đã được review.

Với bất cứ thứ gì agent cho là sai ở một trong hai giai đoạn này, nó gửi trả về workflow implementation để sửa. Kể cả với một implementation phức tạp, phần xử lý feedback chỉ đi qua workflow đơn giản. Và dĩ nhiên có giới hạn số lần thử lại (max retries) để factory không bị kẹt trong một vòng lặp vô tận.

Khi đã xong phần review và các vòng sửa nếu có, ta mới cho phép merge pull request vào nhánh nào đi vào môi trường staging, và chỉ khi CI xanh và phần code đã review là tốt.

## 14. Manager agent trông toàn bộ các lap

Bao trùm toàn bộ quy trình này, Cole có một manager agent chạy định kỳ, chẳng hạn mỗi hai hay ba giờ, để khảo sát mức thành công của tất cả các lap gộp lại. Tính tới video ngày 16/10/2026, đây là thứ mới nhất anh thêm vào factory.

Trước khi có nó, các agent không thật sự giao tiếp với nhau. Mỗi lap riêng lẻ không thật sự hiểu được dependency có đang thay đổi không, hay có một pull request nào đang kẹt nặng không. Nếu ta chạm tới max retries và một agent thật sự kẹt ở một vấn đề, ta cần một thứ nhìn bao quát cả quy trình, có thể sắp xếp lại các issue, hoặc kiểu như "cướp lái" một workflow và tự hoàn tất nó nếu cần.

Manager agent theo cách Cole mô tả: các lap không nói chuyện với nhau, nên một agent định kỳ nhìn toàn cảnh, sửa thứ một lap không thấy được, và chỉ gọi con người khi thật sự cần.

Thứ này cũng tăng độ tin cậy rất nhiều, vì Cole đã cài để nó thật sự báo cho anh khi anh thật sự cần vào hệ thống. Dù ta muốn mọi thứ tự động đến đâu, đây không còn là dark factory nữa. Ta chấp nhận thỉnh thoảng phải vào review bản cắt ticket, hoặc kiểu như giải cứu một workflow. Chuyện đó lâu lâu mới xảy ra. Thường thì Cole để agent Claude Code chính của mình, thứ anh gọi là "second brain", giúp anh khi manager báo những vấn đề này.

Và dĩ nhiên holdout scenarios được đưa vào ở bước này, vì ta chạy chúng trong phần app validation.

## 15. Những file factory không bao giờ được sửa

Như một phần của factory, Cole có context cốt lõi của mình. Anh gọi nó là `mission.md`, hoặc `engineering.md`. Trong đó là những thứ nằm ngoài phạm vi mà anh không bao giờ muốn build, và các định hướng ở mức cao về cách anh muốn agent vận hành trong codebase của mình. Có thể hiểu nó là phần đó cộng với global rules gộp lại.

Anh bảo đảm factory không bao giờ sửa những file này. Đó là một phần trong bước review của anh: kiểm chắc rằng không ai đụng tới chúng, vì anh không muốn factory có khả năng tự thay đổi quyền hạn và hành vi của chính nó. Trên sơ đồ, đây là luật cứng "protected files off limits" nằm ngay dưới bước Code review.

Lý do Cole đưa ra: factory không được tự sửa các file định nghĩa quyền hạn và hành vi của chính nó.

README của repo AI Software Factory mà Cole công bố cũng mô tả cơ chế tương tự: một danh sách đường dẫn được bảo vệ, PR nào thay đổi file khớp danh sách thì bị giữ lại kèm bình luận ghi rằng thay đổi đó phải do con người làm; bản cài mới mặc định bảo vệ `MISSION.md`, `FACTORY.md` và các thư mục harness của factory.

## 16. Trộn model để tiết kiệm token

Thứ cuối cùng trong core loop: với mỗi node trong sơ đồ, Cole dùng model khác nhau, thậm chí provider khác nhau, vì anh đã làm factory này rất tiết kiệm token. Ta không phải lúc nào cũng cần mức reasoning cao nhất.

Theo video đăng ngày 16/10/2026, với phần lớn việc lên kế hoạch, anh dùng Opus 5.5 hoặc GPT-6 Astra. Nhưng với nhiều node riêng lẻ, như bước chọn task (Pick), anh dùng Jev, còn nhánh Ship Simple có khi chỉ dùng Sonnet 5.5. Kể cả bước ship và các node khác trong đó, anh cũng không phải dùng model tốt nhất.

Cách Cole phân model theo node (video ngày 16/10/2026): Opus 5.5 hoặc GPT-6 Astra cho planning, Jev cho bước Pick, có khi Sonnet 5.5 cho nhánh Ship Simple; các node khác cũng không cần model tốt nhất.

Anh đã thử nghiệm rất nhiều để tối ưu theo token. Theo lời anh trong video ngày 16/10/2026, anh đang chạy hàng trăm, hàng trăm lap mỗi tuần mà không chạm rate limit.

## 17. Phần 3: tự test trên staging rồi mới lên production

Phần cuối của quy trình là chỗ ta quay lại để review. Ta build xong tất cả issue của epic trong core loop, merge mọi thứ vào môi trường staging. Đây là nơi ta tự validate, vì ta cần bước này để kiểm ý định của chính mình.

![Part 3: Staging, I test and review it, New issues, Production](https://homus.dev/photos/GQatuTWSRqY-1743.jpg)

Part 3: factory đưa các pull request đã merge vào Staging, nơi cả release chạy ở một môi trường thật. Tôi test và review như một khách hàng; có gì chưa ổn thì mỗi điểm thành một issue mới quay lại factory, đúng rồi thì lên Production. Ví dụ một vòng: tìm kiếm bỏ sót chữ hoa thành #44 Search ignores case, nút Import khó tìm thành #45 Make Import easy to find, chữ ở dark mode quá mờ thành #46 Raise dark mode contrast. Ô "Why staging first": mỗi PR đã qua hai reviewer riêng, nhưng không plan nào nắm hết ý định của tôi; dùng cả release mới thấy các lỗ hổng, và tôi lặp trong factory trước khi bất cứ thứ gì tới production.

Ta tự test mọi thứ, và bất cứ thứ gì chưa đúng, chẳng hạn một thứ không được build theo cách ta thật sự muốn, việc duy nhất phải làm là tạo một issue mới trong repo. Factory sẽ tự động nhặt nó, y như cách nó đã nhặt các issue từ lần cắt ticket đầu tiên từ tài liệu epic.

Nhờ vậy ta rất dễ test cả lô feature trong epic rồi đưa feedback theo lô. Ta có thể tạo bốn, năm issue, bao nhiêu cũng được, factory sẽ xử lý hết, rồi ta test lại staging. Khi mọi thứ đúng thì mới lên production.

Dark factory gần như đi thẳng lên production. Còn với software factory, Cole thấy bước staging này rất quan trọng. Ta có human in the loop thật sự, nhưng đồng thời được review nhiều thứ cùng một lúc. Nhờ đó ta giải được, ít nhất một phần, bottleneck của việc con người review ở cuối. Khi đã hài lòng với những gì trên production, ta chỉ việc chuyển sang release kế tiếp và lặp lại quy trình: lên kế hoạch, core loop, rồi staging và production.

## 18. Kết luận

Đó là toàn bộ AI software factory ở mức cao. Cole nhắc lại rằng người xem có thể bình luận nếu muốn anh trình bày chi tiết hơn bất kỳ phần nào. Anh hy vọng video đem lại cảm hứng: những bài học rút ra cho workflow AI coding của riêng bạn, hoặc nếu bạn muốn tự build một software factory. Theo anh, đây thật sự là tương lai của agentic engineering.

Anh kết bằng lời mời like, subscribe nếu người xem trông chờ thêm nội dung về AI software factory và AI coding nói chung.

## Nguồn và liên kết

- Tên gốc: My AI Dark Factory Dream Is Dead (Here's What Actually Works)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=GQatuTWSRqY](https://www.youtube.com/watch?v=GQatuTWSRqY)

- Kênh YouTube Cole Medin (Cole Medin): [youtube.com/channel/UCMwVTLZIRRUyyVrkjDpn4pA](https://www.youtube.com/channel/UCMwVTLZIRRUyyVrkjDpn4pA)

- AI Software Factory, repo mã nguồn mở của Cole (README mô tả quy trình plan release, loop, staging, MISSION.md, holdout và các đường dẫn được bảo vệ): [github.com/coleam00/ai-software-factory](https://github.com/coleam00/ai-software-factory)

- Archon, harness builder mã nguồn mở mà repo AI Software Factory dùng để chạy các workflow: [github.com/coleam00/Archon](https://github.com/coleam00/Archon)

- Dan Shapiro, "The Five Levels: from Spicy Autocomplete to the Dark Factory" (23/01/2026): [danshapiro.com](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/)

- Dex Horthy (HumanLayer), talk "Why Software Factories Fail" tại AI Engineer World's Fair, trên kênh YouTube AI Engineer.

Nguồn: https://homus.dev/talks/my-ai-dark-factory-dream-is-dead-heres-what-actually-works · cập nhật 2026-10-20