# Mission control cho AI software factory của Cole Medin

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

> Cole Medin dẫn đi một vòng mission control dashboard của AI software factory: owner decisions, scorecard, testing, rewind, Archon và live query trên Postgres.

Topics: Software Factory, Coding Agents

Canonical: https://homus.dev/talks/my-ai-software-factory-ships-hundreds-of-prs-a-week-heres-how-i-manage-it

## 1. Một năm dồn sức cho AI software factory

Cole Medin kể (video đăng ngày 02/11/2026) rằng suốt năm nay anh đã bỏ ra một lượng thời gian khủng khiếp cho AI software factory của mình. Đó là hệ thống mà anh có thể gửi vào bất kỳ issue ticket nào, thậm chí cả một release, rồi nó tự lên plan cho tất cả và build trong một vòng lặp tự động, kèm mọi bước verification anh cần, và có con người ở trong hoặc ở gần vòng lặp (human in the loop, near the loop) ở những chỗ anh muốn.

Như ta có thể hình dung, theo Cole (video đăng ngày 02/11/2026), cần rất nhiều công sức để một hệ thống tự động kiểu này trở nên đáng tin cậy. Đó là lý do anh dành nhiều thời gian đến vậy, đặc biệt với hy vọng đưa cho người xem một điểm khởi đầu, để ta dùng được loại hệ thống này mà không phải trải qua mọi "cơn đau trưởng thành" như anh đã trải qua. Anh nói anh vẫn đang liên tục phát triển nó.

![Sơ đồ How My AI Software Factory Runs với Plan the release, Split, The loop, Staging và Production](https://homus.dev/photos/YHKuUjicB3M-0003.jpg)

"I plan the release. The factory builds it. I test it, and anything off goes back in." Phần 1 là Plan the release (anh cùng một agent, cho một proof of concept hoặc một epic nhỏ) và Split thành các issue chạy song song được. Phần 2 là The loop: Pick, Ship, App validation, Code review, Merge, "one issue per lap, many laps at once", có Manager agent "steps back every few hours, asks me when it needs a call". Phần 3 là Staging (anh test cả release) rồi Production; chỗ nào chưa ổn thì thành issue mới.

Điều anh muốn làm trong video (đăng ngày 02/11/2026) là dẫn người xem đi một vòng qua mọi thứ anh đang làm để quản lý và phát triển software factory, vì anh đã dồn nhiều thời gian xây một mission control dashboard mà anh nghĩ người xem sẽ thấy rất hay và hy vọng cũng truyền được cảm hứng. Anh báo trước rằng video lần này sẽ ít cấu trúc hơn thường lệ, có thể coi như một devlog.

Anh còn nhiều điều muốn cho xem, vì nói chung thứ anh đang làm cũng là hướng anh thấy cả ngành dịch chuyển gần đây (theo Cole, video đăng ngày 02/11/2026). Mọi công ty anh thấy đang xây software factory ở quy mô lớn đều kết thúc bằng việc tạo ra một kiểu dashboard như thế này để quản lý hệ thống. Lý do theo anh: một factory là một cỗ máy sống và thở. Kể cả khi ta làm được thứ rất đáng tin cậy ngay từ đầu, ta vẫn phải liên tục phát triển nó khi thay đổi quy trình và thay đổi thứ mình đang build.

## 2. Mission control nhìn lướt qua

Hôm nay Cole sẽ đi nhanh qua nhiều thành phần khác nhau của dashboard. Màn đầu tiên là góc nhìn toàn cảnh (at-a-glance) về workflow của software factory, chi tiết xuống tới từng skill anh chạy qua các agent của mình (demo trong video đăng ngày 02/11/2026).

![Tab Owner của mission control với ba mục đang chờ chủ sở hữu](https://homus.dev/photos/YHKuUjicB3M-0143.jpg)

Tab Owner của dashboard trong demo (video đăng ngày 02/11/2026): "Waiting on the owner 3". Mục đầu là một QUESTION (#27, Q10) hỏi màn hình testing có nên chia kết quả holdout theo tên scenario bằng chữ thay vì mã H-nn hay không, kèm hai phương án A và B, một khuyến nghị (A) và dòng "No default: this waits for the owner." Hai mục NEEDS OWNER (#252 và #288) đều đã chờ 2h 25m.

Từ đó ta xem được các key decision anh đã đưa ra theo thời gian trong quá trình cải tiến factory, và xem được từng lap riêng của mỗi factory đang chạy. Anh nối hai factory vào dashboard này (demo trong video đăng ngày 02/11/2026). Ngoài ra có các quyết định riêng lẻ mà ta phải đưa ra khi factory mang việc tới cho ta, tức những quyết định ở mức cao cần ta chú ý.

## 3. Ít quyết định nhất cho con người, nhiều quyền kiểm soát nhất

Cole nói (video đăng ngày 02/11/2026) phần lớn lý do anh xây nhiều thứ trong dashboard này là vì, qua toàn bộ quá trình thử nghiệm, làm việc với các công ty và triển khai những hệ thống kiểu này, anh nhận ra cách duy nhất để hệ thống thật sự đáng tin cậy là có một số thứ được đẩy ngược lên (bubble back up) để con người quyết định.

Vì vậy, theo anh (video đăng ngày 02/11/2026), tất cả xoay quanh câu hỏi: làm sao có được tập quyết định tối thiểu cho con người mà vẫn cho nhiều quyền kiểm soát nhất có thể. Ta muốn mọi thứ chạy tự động hết mức có thể, nhưng nó không thể hoàn toàn là một dark factory.

Ý chính Cole nêu (video đăng ngày 02/11/2026): factory chạy tự động hết mức, đẩy lên con người một tập quyết định tối thiểu nhưng cho nhiều quyền kiểm soát nhất.

## 4. Từ Dark Factory sang Software Factory

Cole kể (video đăng ngày 02/11/2026) rằng hồi đầu năm nay, khi anh xây Dark Factory, đó là loại hệ thống hoàn toàn không có con người trong vòng lặp. Anh xây nó công khai. Mục tiêu ban đầu của Dark Factory, cái mà anh đã đổi tên thành Software Factory vì đã thêm human in the loop, là ta chỉ cần đưa vào một PRD, tức một mô tả ở mức cao về thứ mình muốn build. Ta gần như không phải lên plan gì với agent, rồi nó sẽ tự đi qua mọi thứ một cách tự động.

![Sơ đồ The AI Software Factory dạng nhà xưởng với các trạm Plan, Build, Judge, Merge](https://homus.dev/photos/YHKuUjicB3M-0223.jpg)

"A PRD goes in one end. Shipped code comes out the other. Nobody is on the floor." PRD được cắt thành issue, đi qua băng chuyền Plan, Build, Judge, Merge rồi vào main. Dòng đỏ "Nobody is in the chair" ghi "A separate agent judged it. A script merged it.", và chú thích cuối: "Every gate in here is a script. Not one of them is a person."

Theo lời Cole (video đăng ngày 02/11/2026), hệ thống đó cắt toàn bộ PRD thành các issue, đi qua từng issue với các bước verification và code review riêng, rồi merge thẳng mọi thứ lên production. Anh gọi đây là một kiểu giấc mơ với generative AI: đủ đáng tin cậy để đi từ ý tưởng tới code được ship và validate đầy đủ, không có con người ở bất kỳ đâu trong vòng lặp, kể cả ở bước merge.

Dù cách này có thể chạy được cho một số thứ, như proof of concept, theo Cole (video đăng ngày 02/11/2026) nó thật sự là chưa đủ. Anh đã phải giảm bớt mức tự chủ và thêm human in the loop, và đó là chỗ anh đang đứng với software factory. Hệ thống mà anh đang quản lý bằng dashboard này là thứ anh thấy thật sự chạy được.

## 5. Vì sao anh vẫn dựng một control plane

Cole nói thật lòng (video đăng ngày 02/11/2026) rằng lúc đầu anh rất không thích ý tưởng có một control plane đặt trên software factory, vì anh nghĩ nó sẽ làm mọi thứ kém tự động đi và anh sẽ phải gánh thêm trách nhiệm quản lý. Nhưng anh đã xây nó theo cách rất dễ nhìn mọi thứ ở mức cao, và nó thật sự giúp anh thúc đẩy các cải tiến cho factory cũng như quản lý mọi thứ trong lúc chúng đang chạy.

Theo anh (video đăng ngày 02/11/2026), đó thật sự là cách duy nhất để quản lý độ phức tạp của factory. Anh đã cố gắng nhiều để giữ mọi thứ đơn giản, và giờ anh quản lý khá dễ dàng. Nhưng bên dưới có rất nhiều thứ diễn ra. Anh bảo ta thử nghĩ mà xem: phải quản lý dependency mapping, chạy song song để thật sự scale, tìm cách dựng app validation cho từng phần mềm ta tạo ra, quản lý môi trường staging, và tất cả những chỗ có human in the loop.

Những việc Cole liệt kê phải quản lý bên dưới factory (video đăng ngày 02/11/2026): dependency mapping, chạy song song để scale, app validation cho từng phần mềm, môi trường staging và mọi chỗ có human in the loop.

Vì thế, theo Cole (video đăng ngày 02/11/2026), có một hệ thống như vậy để theo dõi mọi thứ khi chúng đang chạy, đẩy các quyết định lên trong một giao diện dễ nhìn, thay vì lúc nào cũng nằm trong GitHub issues như trước đây anh từng làm, đang tạo ra khác biệt lớn với anh.

## 6. Factory tự build dashboard của chính nó

Như người xem có lẽ đã đoán, Cole cũng dùng software factory để build chính dashboard này (video đăng ngày 02/11/2026). Mission control, lựa chọn này trong dashboard (ô FACTORY ở góc trên ghi "mission-control"), chính là ứng dụng mà ta đang nhìn thấy.

Anh thấy điều này rất hay (video đăng ngày 02/11/2026), vì khi anh làm factory ngày càng tốt hơn, nó sẽ làm dashboard ngày càng tốt hơn, và đến lượt mình dashboard lại giúp anh quản lý software factory dễ hơn. Đó là một flywheel đẹp, nơi theo thời gian hệ thống gần như sẽ trở thành tự tiến hoá, điều anh rất mong chờ. Anh nói anh chỉ mới bắt đầu build nó.

Flywheel Cole mô tả (video đăng ngày 02/11/2026): factory tốt hơn làm dashboard tốt hơn, dashboard tốt hơn lại giúp quản lý factory dễ hơn.

Trước khi có dashboard, Cole quản lý mọi thứ trực tiếp trong GitHub (video đăng ngày 02/11/2026). Cách đó cũng tạm chạy được, vì anh có các comment trên PR cho owner decisions, và có thể nhìn thẳng vào các lần merge để xem các lap đang chạy ra sao, đại loại vậy. Nhưng theo anh, cách hiện tại chắc chắn tốt hơn nhiều.

## 7. Trang chủ: bản đồ toàn bộ factory

Rồi Cole bắt đầu dẫn đi một vòng. Thứ số một anh muốn cho trang chủ của hệ thống là một hình dung ở mức cao về toàn bộ factory: mọi điểm ra quyết định, mọi skill riêng lẻ (video đăng ngày 02/11/2026). Trước khi có nó, anh khó hình dung trong đầu hình dạng của factory, và vì thế cũng khó hiểu nên phát triển mọi thứ ra sao khi muốn làm factory tốt hơn. Anh gọi phần này là một game-changer với anh.

![Factory map trong mission control với các nút pick, claim, ship, build, forge, triage, intel](https://homus.dev/photos/YHKuUjicB3M-0643.jpg)

Factory map trên trang chủ (demo trong video đăng ngày 02/11/2026). Hàng đầu là các input: Product document, archon-backlog (5 steps), archon-holdouts (2 steps), Owner decisions; dưới là manager archon-manager (2 steps). Phần LOOP bắt đầu bằng pick rồi claim, sau đó rẽ hai nhánh: "complex" đi tới ship rồi forge, triage (3 steps), intel; "continue / simple" đi tới build. Mỗi nút có con số bên cạnh, ở khung này nút build hiện 1.

Cole cũng muốn nói về hạ tầng bên dưới factory, cách mọi thứ được lưu trong một database Postgres và việc anh dùng Archon để điều khiển tất cả (video đăng ngày 02/11/2026). Anh sẽ quay lại phần đó sau một chút, còn trước hết anh muốn lướt thật nhanh qua tất cả các mục khác nhau của dashboard.

## 8. Tab Decisions và Diff: ghi lại cách factory tiến hoá

Sau phần hình dung chính, thứ đầu tiên Cole muốn là một tab liệt kê các key decision anh đã đưa ra cho software factory trong quá trình phát triển nó (video đăng ngày 02/11/2026). Lý do: anh nói chuyện với coding agent của mình mỗi khi có vấn đề phát sinh trong factory, và anh suy nghĩ xem làm sao cho factory tốt hơn. Anh muốn ghi lại tất cả để không quay lại thử những thứ đã thử rồi.

Anh cũng muốn thấy những cải tiến nào đang được test (video đăng ngày 02/11/2026). Anh có đủ loại ý tưởng cho các thay đổi muốn làm với skill của mình, hoặc những bước muốn thêm vào, và anh quản lý việc test tất cả những thứ đó ở đây, đồng thời xem lại mọi thứ đã thay đổi. Key decision đầu tiên anh đưa ra là dùng Archon cho mọi thứ; anh sẽ nói về Archon sau một chút.

![Tab Decisions với cột Key decisions và cột Improvements being tested](https://homus.dev/photos/YHKuUjicB3M-0723.jpg)

Tab Decisions (demo trong video đăng ngày 02/11/2026). Cột trái "Key decisions" theo ngày: 2026-10-07 "Archon runs everything" (không coding agent nào chạy ngoài một Archon workflow, factory là một lớp vỏ mỏng), 2026-10-12 "Agents over deterministic scripts" (lý do ghi một lap từng có 140 node, 86 node là deterministic, và ít nhất 15 lần dừng sai đến từ script kiểm agent), 2026-10-13 "The hybrid loop". Cột phải "Improvements being tested" liệt kê từng thay đổi kèm số lap đã chạy, số lap đang chờ và cách đo.

Với mọi quyết định anh đưa ra, hiển nhiên chúng tạo ra các phiên bản khác nhau của factory trong source control (video đăng ngày 02/11/2026). Vì vậy anh có tất cả các commit và có thể xem diff giữa hai phiên bản bất kỳ mà anh chọn. Giữa hai phiên bản đó, anh thấy được cái gì khác ở workflow, ở các bước, ở các prompt bên dưới và ở các skill anh dùng cho từng bước. Anh nói phần này cũng rất hữu ích.

Trong khung tab Diff mở ra lúc đó (demo trong video đăng ngày 02/11/2026), dòng "Architecture diff" so sánh hai phiên bản mới nhất có kiến trúc được ghi lại; mục Workflows, Steps và Subagents đều ghi "No change.", còn mục Prompts ghi một thay đổi ở file `loop/commands/loop-review.md`.

## 9. Tab Health và Issues

Cole cũng có tab Health cho sức khoẻ tổng thể (demo trong video đăng ngày 02/11/2026): mỗi lần có lỗi, cái gì gây ra nó. Theo số của anh trong video đăng ngày 02/11/2026, có hai lần lỗi là vì anh chạm rate limit của Claude Code. Và trong hàng trăm, hàng trăm lap anh đã chạy trong vài tuần qua, 21 lần lỗi là do vấn đề nằm trong chính các workflow mà anh phải chỉnh lại.

Anh còn có vài tab để quản lý các lượt chạy đang diễn ra của từng software factory riêng (demo trong video đăng ngày 02/11/2026). Hai tab này tuỳ biến theo factory mà anh chọn. Ở đây anh đã đưa cho nó một PRD, nó cắt PRD thành các ticket, và đó là thứ ta đang xem. Anh đang làm thêm phần gom nhóm; hiện chưa gom nhóm nhiều, nhưng ta thấy được vài chỗ.

![Tab Issues với các phase đã merge và issue graph gồm các thẻ Queued, Claimed, PR open, Needs owner](https://homus.dev/photos/YHKuUjicB3M-0845.jpg)

Phần dưới tab Issues (demo trong video đăng ngày 02/11/2026). Phía trên là các phase như "decisions timeline and improvements ledger", "architecture diff", "Owner queue", "testing panel", "rewind" (0/1 merged), "Health". Phía dưới là "Issue graph: 15 open issues and what they depend on, 22 phases done: 26 merged, 2 closed", với chú giải Queued, Claimed, PR open, Needs owner, Merged, Closed, và nhóm "No phase: 15 open, 68 merged, 63 closed". Hai thẻ #252 và #288 có nhãn NEEDS OWNER màu vàng.

Với release này, Cole đã xử lý phần lớn các issue (demo trong video đăng ngày 02/11/2026). Có vài cái cần anh chú ý, và chúng dẫn tới tab Owner mà anh sẽ nói sau. Còn ba thẻ màu xanh dương là các lap đang chạy: một cái đang ở giữa bước review pull request, hai cái đang ở bước implementation.

## 10. Tab Laps và Scorecard

Cole có thể mở tab Laps để xem chi tiết hơn về bước mà mỗi lap đang ở và các quyết định quan trọng đã được đưa ra, ví dụ độ phức tạp của task (demo trong video đăng ngày 02/11/2026). Factory của anh là dynamic: nó làm các bước khác nhau tuỳ theo issue phức tạp đến đâu. Theo anh, ta không muốn tốn quá nhiều thời gian cho những thứ thật sự đơn giản, và cũng không muốn factory chỉ là một vòng build rồi validate cơ bản cho những thứ thật sự phức tạp.

![Tab Laps với ba lane đang chạy, mỗi lane có route, depth, step, thời gian và chi phí](https://homus.dev/photos/YHKuUjicB3M-0903.jpg)

Tab Laps (demo trong video đăng ngày 02/11/2026): ba lane RUNNING. #244 và #269 có route "complex", depth "deep", đang ở bước ship; #247 có route "simple", depth "normal", đang ở bước check-app. Mỗi lane ghi thời gian ở bước hiện tại và "cost so far" ($0.382, $5.88, $1.60), cùng chuỗi bước pick, claim, build/ship, subject, briefs, check-app, evidence, handoff, review, land, deploy, release.

Tab Owner, với các quyết định quan trọng được đẩy lên cho anh, sẽ được nói sau. Còn scorecard thì theo Cole rất hay (demo trong video đăng ngày 02/11/2026): với phiên bản hiện tại của software factory, nó cho thấy đã chạy bao nhiêu lap, đã có bao nhiêu lần merge trong codebase cụ thể này, và quá trình đã kéo dài bao lâu. Đây là các chỉ số chính anh nhìn vào để biết có cần cải tiến phiên bản factory này không và nên cải tiến gì.

![Tab Scorecard với các ô Laps 102, Merges 41, Active hours 48](https://homus.dev/photos/YHKuUjicB3M-0923.jpg)

Tab Scorecard cho phiên bản mới nhất có lap, f51dccdb, chạy lần đầu ngày 2026-10-26 (demo trong video đăng ngày 02/11/2026): Laps 102, Merges 41, Empty laps 0, Failed laps 1, Send-backs 13, Gate refusals 20, Active hours 48, Merges per active hour 0.8542, Lap-hours per merge 3.0426.

## 11. Tab Testing, Versions và Rewind

Ở phần testing, Cole cho xem tất cả các scenario mà factory tự nghĩ ra để regression test và để test từng feature khi nó build codebase (demo trong video đăng ngày 02/11/2026). Anh cũng xem được nó quyết định chạy những scenario nào, vì hiển nhiên với mỗi PR ta sẽ không chạy từng cái một trong số này, và xem cả kết quả thành công lẫn thất bại của tất cả.

![Tab Testing với lưới holdout H-01 đến H-55 và các số pass, fail, incomplete](https://homus.dev/photos/YHKuUjicB3M-0943.jpg)

Tab Testing (demo trong video đăng ngày 02/11/2026): "Holdouts at pull-request time, 54 scenarios, 877 lines across every lap", mỗi ô từ H-01 tới H-55 có số PASS, FAIL và INCOMPLETE. Dòng chú thích ghi INCOMPLETE nghĩa là checker không chạy xong scenario (app không khởi động, check branch thiếu thứ scenario cần, hoặc máy quá bận để tin vào thời gian đo); merge gate coi đó là lỗi, nhưng nó không phải bằng chứng của một bug. Phía dưới là phần holdouts trên default branch.

Tiếp theo, Cole có bản ghi của tất cả các phiên bản và những gì đã thay đổi ở mỗi phiên bản, hay ít nhất là các thay đổi cốt lõi (demo trong video đăng ngày 02/11/2026).

Rồi có tab Rewind, một thứ mới hơn mà anh cũng đang làm (demo trong video đăng ngày 02/11/2026). Theo Cole, Rewind dựa trên branching của database Postgres (Neon) mà factory dùng làm backend, và cho phép anh thật sự quay lại các phiên bản khác nhau của software factory nếu muốn roll back, hoặc chỉ để test thêm trên phiên bản đó và so với cái đang có. Trên màn hình tab Rewind lúc đó có một dòng "rewind-2026-10-27t21-45-00z, as of 2026-10-27 21:45:00 UTC, from main". Xong anh quay về branch live.

Đến đây là phần tổng quan dashboard. Cole biết một số thứ có thể chỉ hợp với riêng anh, nhưng anh hy vọng người xem lấy được cảm hứng từ nhiều ý tưởng trong cách anh đưa observability vào và tạo một cách dễ hơn để quản lý toàn bộ hệ thống (video đăng ngày 02/11/2026).

## 12. Archon: xương sống của factory

Sau đó Cole nói thêm về hạ tầng bên dưới cho dashboard và cho chính factory. Anh lưu ý ta sẽ thấy rất nhiều chỗ nhắc tới Archon. Theo Cole (video đăng ngày 02/11/2026), Archon là harness builder mã nguồn mở của anh: nó cho phép lấy bất kỳ quy trình AI coding nào và biến nó thành một workflow tái sử dụng được. Nó xử lý bên dưới nhiều phần khó hơn của agentic engineering, như worktree, nên ta quản lý mọi thứ chạy song song rất dễ.

![README của repo Archon trên GitHub với logo và dòng mô tả](https://homus.dev/photos/YHKuUjicB3M-1103.jpg)

README của repo Archon trên GitHub mà Cole mở (video đăng ngày 02/11/2026): "The simplest way to build the software that builds your software. YAML workflows that can do anything.", kèm huy hiệu "GitHub Trending #1 Repository Of The Day", license MIT, docs archon.diy. Đoạn mô tả ghi Archon là một factory builder: ta mô tả công việc nên được làm ra sao bằng YAML workflow, và Archon chạy chúng với AI agent, script và các quyết định của ta ở những chỗ cần.

Đây là xương sống của toàn bộ software factory (theo Cole, video đăng ngày 02/11/2026). Nhiều người hỏi anh Archon nằm ở đâu trong chuyện này. Về cơ bản, trong factory của anh không có một coding agent nào được chạy mà không đi qua một Archon workflow. Toàn bộ hệ thống chỉ là một tập các Archon workflow cùng nhau điều khiển cả factory: mọi phần planning, mọi phần implementation, mọi phần validation.

Khi vào UI của Archon, một giao diện riêng, ta thấy được tất cả các lượt chạy riêng lẻ, chi tiết xuống tới log của từng lượt (demo trong video đăng ngày 02/11/2026). Nên ở đây có observability đầy đủ. Dashboard của anh cũng link sang đây mỗi khi muốn bấm vào bất kỳ bước riêng nào trong mỗi lap của factory. Cole nói thường thì ở mức chi tiết này ta sẽ để agent tự đào vào; anh chỉ đang cho thấy mọi thứ thật sự chạy Archon bên dưới.

## 13. SDLC pack và audit trail trong Postgres

Cole kể (video đăng ngày 02/11/2026) rằng người đồng tác giả Archon với anh, Rasmus, đã bỏ ra một lượng công sức khủng khiếp để build tất cả các workflow chạy factory của anh. Chúng nằm trong SDLC pack đi kèm mặc định với Archon. Ta có thể bấm vào bất kỳ workflow nào, và anh tin người xem sẽ ấn tượng với từng cái. Theo anh, rất nhiều tâm huyết đã được đặt vào từng workflow, và mọi thứ chạy trong factory đều dùng một trong số đó cho mỗi bước.

Điểm hay của Archon, theo Cole (video đăng ngày 02/11/2026), là mọi thứ ta quan sát được, xuống tới mức từng tool call, từng lượt và từng quyết định của agent, đều được lưu trong một database Postgres. Mọi thứ xảy ra trong software factory được lưu ở đó. Anh có audit trail đầy đủ, và có thể xử lý dữ liệu đó sau này để tìm ra chỗ nào sai rồi cải tiến software factory theo cách đó.

Luồng dữ liệu Cole mô tả (video đăng ngày 02/11/2026): mọi tool call, lượt và quyết định của agent trong các Archon workflow được lưu vào Postgres, thành audit trail để xem lại và cải tiến factory; dashboard đọc từ cùng nơi đó.

Theo Cole (video đăng ngày 02/11/2026), nếu không lưu từng lượt, từng quyết định và từng tool call của agent, anh thật sự không có cách nào biết mọi thứ đã sai ra sao, hay vì sao chúng sai, khi muốn quay lại về sau để tìm cách phát triển factory. Vì vậy mọi thứ diễn ra trong Archon, mọi thứ anh thấy trên dashboard, đều được lưu trong database đó.

## 14. Owner decisions trước khi có dashboard

Một ví dụ Cole đưa ra (video đăng ngày 02/11/2026): một trong những thứ trước đây khó quản lý với anh là tất cả các owner decision, tức câu hỏi cho anh và những blocker cần anh chú ý. Theo anh, có phần này là quan trọng vì đây không phải dark factory; ta cần một ít human in the loop khi agent thấy cần.

Nhưng trước đây việc quản lý khá khó (video đăng ngày 02/11/2026). Cole mở một ví dụ trông như thế nào trước khi có dashboard: anh cho agent mention anh trong một issue hoặc một pull request. Đó là tín hiệu rằng đến lượt anh vào giải quyết vấn đề, trả lời câu hỏi, bằng cách nói chuyện với manager agent hoặc đăng một comment ngay trong issue hay PR đó. Trên màn hình là một issue tên "Owner decisions needed #27" trong repo factory-mission-control, chứa câu hỏi Q10 về màn hình testing, các phương án, khuyến nghị và danh sách những câu đã trả lời.

So sánh Cole đưa ra (video đăng ngày 02/11/2026): trước đây owner decision đến qua mention trên GitHub và anh phải canh repo, email hay Slack; giờ anh muốn quản lý mọi thứ ở một chỗ.

Cách đó có chạy (video đăng ngày 02/11/2026), nhưng anh phải canh repository rất sát, hoặc để ý email thông báo khi được mention, hoặc các Slack alert anh đã cài. Anh thấy tạm được, nhưng anh muốn quản lý mọi thứ ở một chỗ, không chỉ owner decision mà mọi thứ diễn ra trong repository, cả những việc cần anh hành động lẫn những việc chỉ để anh quan sát.

## 15. Một điểm vào duy nhất và dữ liệu live cho dashboard

Cách Cole làm (video đăng ngày 02/11/2026): anh có một GitHub webhook kích hoạt một function mỗi khi có GitHub issue hoặc pull request mới. Vì anh quản lý toàn bộ factory bằng issue và PR, giờ anh có một điểm vào duy nhất để xử lý mọi thứ đang diễn ra trong factory và lưu nó vào database Postgres. Và vì các lượt chạy Archon cũng được lưu trong database đó, anh có một chỗ trung tâm cho mọi thứ: cho toàn bộ observability, và cho những lúc anh muốn cùng agent đào vào để cải tiến hệ thống.

Theo Cole (video đăng ngày 02/11/2026), dashboard nhận thông tin nhanh trong lúc mọi thứ liên tục thay đổi vì anh nối nhiều SQL query dạng live vào dashboard, nên nó kéo thông tin về ngay khi mọi chuyện đang xảy ra với các Archon workflow bên dưới. Anh nói anh không muốn đi sâu vào code, chỉ chạy thử một trong các query mà dashboard dùng.

![Cửa sổ terminal chạy một live SQL query, hiện snapshot ba dòng và các transaction insert, delete](https://homus.dev/photos/YHKuUjicB3M-1523.jpg)

Live query trong demo (video đăng ngày 02/11/2026): query lấy các bước đang chạy của những lap archon-loop. Sau "Initial snapshot, 3 rows" (factory mission-control, các bước check-app, check-app, build) là các Transaction với dòng "- delete" và "+ insert" khi một lượt chạy đi từ check-app sang evidence rồi handoff.

Cole nói "there we go" khi vài record mới vừa tới (demo trong video đăng ngày 02/11/2026). Khi có pull request mới, issue mới, comment mới, hay bất kỳ thứ gì, dashboard nhận được ngay và hiển thị cho anh. Anh không chỉ có bản ghi của mọi thứ mà còn xem được mọi thứ khi chúng đang diễn ra, điều theo anh đặc biệt hữu ích khi anh đang cải tiến chính software factory.

## 16. Mã nguồn mở toàn bộ

Đó là dashboard và factory ở mức cao, để đưa người xem vài ý tưởng và cảm hứng (video đăng ngày 02/11/2026). Cole muốn cập nhật cho người xem những gì anh đang làm, vì software factory là thứ lớn mà anh đang dồn rất nhiều thời gian vào lúc này. Anh nói anh đưa hết cho người xem: anh mở mã nguồn toàn bộ factory, và tiếp tục làm việc phía sau để nó ngày càng đáng tin cậy, với dashboard giúp anh làm việc đó.

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

- Tên gốc: My AI Software Factory Ships Hundreds of PRs a Week (Here's How I Manage It)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=YHKuUjicB3M](https://www.youtube.com/watch?v=YHKuUjicB3M)

- 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 (mô tả repo, đọc ngày 07/11/2026: ta plan release, factory build, ta test trên staging; GitHub issue vào, pull request được review độc lập và merge ra, tất cả trên Archon workflow): [github.com/coleam00/ai-software-factory](https://github.com/coleam00/ai-software-factory)

- Factory Mission Control, repo của dashboard (mô tả repo, đọc ngày 07/11/2026: kiến trúc factory, quá trình tiến hoá, PRD, issue và lap của từng factory, cập nhật live, do chính factory build): [github.com/coleam00/factory-mission-control](https://github.com/coleam00/factory-mission-control)

- Archon, harness builder mã nguồn mở cho AI coding (mô tả repo, đọc ngày 07/11/2026): [github.com/coleam00/Archon](https://github.com/coleam00/Archon)

Nguồn: https://homus.dev/talks/my-ai-software-factory-ships-hundreds-of-prs-a-week-heres-how-i-manage-it · cập nhật 2026-11-07