# Dựng một software factory chạy được thật

[Greg Isenberg](https://homus.dev/speakers/greg-isenberg) · [Greg Isenberg](https://homus.dev/orgs/greg-isenberg), [Michael Shimeles](https://homus.dev/speakers/michael-shimeles) · [Greg Isenberg](https://homus.dev/orgs/greg-isenberg)

> Bốn bước isolate, build, prove, ship gói trong vài file markdown để chạy nhiều agent song song và tin được code chúng trả về.

Topics: Software Factory, Coding Agents, Workflow, Skills

Canonical: https://homus.dev/talks/building-a-software-factory-that-actually-works-full-course

## 1. Software factory là gì, và vì sao nó đang viral

Greg Isenberg mở đầu bằng câu hỏi: software factory là gì, và tại sao khái niệm này đang viral? Theo anh, về cơ bản đây là một cách dùng AI agent để thật sự ship được phần mềm không hề cẩu thả (sloppy), vận hành giống một nhà máy hơn. Hãy hình dung một dây chuyền lắp ráp (assembly line), chỉ khác là thay vì làm ra sản phẩm vật lý, bạn làm ra phần mềm.

Với Greg, đó là giấc mơ: nếu bạn dựng được một nhà máy chuyên làm ra phần mềm, và là phần mềm có giá trị, bạn có thể tạo ra nhiều app vừa sinh doanh thu vừa thêm giá trị cho cuộc sống của người dùng. Nghe vậy là đủ hấp dẫn với anh rồi.

Khách mời của tập này là Michael Shimeles, người làm nội dung với tên Ras Mic (Greg hay gọi thân là "Mickey"). Greg hứa rằng Mic sẽ giải thích rõ toàn bộ quy trình, và tới cuối tập, người xem sẽ hiểu cách tự dựng software factory của riêng mình. Anh nói có lý do để khái niệm này viral, và hẹn gặp lại ở cuối tập.

Greg chào Mic quay lại podcast và hỏi: tới cuối tập, mọi người sẽ học được gì? Mic trả lời: mọi người sẽ hiểu cụm từ kỳ quặc "software factory" thật ra nghĩa là gì, và anh sẽ cho xem chính cách anh đang vận hành factory của mình. Nó dễ hơn nhiều so với mọi người nghĩ, và chắc chắn là model agnostic, harness agnostic: bạn không cần mua một sản phẩm khác nào để có một software factory. Anh hứa phần này sẽ vui và đơn giản.

![Greg Isenberg và Ras Mic trong hai khung gọi video cạnh nhau](https://homus.dev/photos/_LCeJZFIsd4-0136.jpg)

Greg Isenberg (trái) và Michael Shimeles, tức Ras Mic (phải), ở phần mở đầu cuộc trò chuyện.

## 2. Không phải một sản phẩm: harness agnostic, model agnostic

Greg tóm lại: vậy là Mic sẽ giải thích nó là gì, tại sao nó quan trọng, nó hoạt động thế nào và nên nghĩ về nó ra sao. Xem xong, ai muốn thì có thể tự khởi động software factory của mình; còn ai nghĩ "anh chàng Ras Mic này, tôi không thích software factory, tôi không thích điều anh ta nói" thì cứ bỏ qua. Mic đồng ý hoàn toàn: "100%."

Mic nói thẳng: quanh cụm từ software factory đã có khá nhiều startup ra đời, và anh không có ý chê bai công sức của ai cả. Nhưng một software factory hoàn toàn không phụ thuộc harness hay model. Nghĩa là bạn dùng model nào cũng được, dùng harness nào cũng được, nó vẫn phải chạy.

Lý do là software factory chủ yếu nói về workflow, skill và kiến thức chuyên môn (domain knowledge) của một người. Tất cả được đóng gói thành những skill cụ thể mà người đó dùng trong quá trình phát triển phần mềm.

Anh đề nghị mọi người nghĩ lại app gần nhất mình đã build. Nhiều khả năng bạn mở Codex, Claude Code, Cursor hay công cụ nào đó, rồi cứ thế gõ: "tôi muốn build cái này". Nó build ra cho bạn. Bạn xem, bạn không thích. Bạn sửa vài chỗ, xem lại các thay đổi, có thể lần này thì thích. Bạn deploy lên Vercel hay production là xong. Hoặc bạn tiếp tục lặp (iterate).

Đó chính là quy trình. Mục đích của software factory là ở mỗi bước trong quy trình phát triển ấy, làm sao tận dụng tối đa năng lực của model để có output tốt nhất, và đồng thời làm sao đi nhanh. Vì khi đã dùng chữ "factory" (nhà máy), phải có một cấu trúc nào đó, một tốc độ và tính chất băng chuyền (conveyor belt) cho phép ship nhanh nhất có thể mà không đánh mất chất lượng. Mic tự gọi đó là "định nghĩa dài dòng kiểu Michael Shimeles" về software factory.

Theo Mic, software factory là ba thứ của chính người làm: workflow, skill và domain knowledge, đóng gói thành file markdown và đặt lên trên bất kỳ model hay harness nào.

## 3. Vì sao chuyện này quan trọng lúc này

Mic hỏi lại Greg xem mình có làm ai lạc chưa; Greg bảo phần định nghĩa vừa rồi rất hoàn hảo. Vậy thì tại sao nó quan trọng?

Mic giải thích: vì trí thông minh của model vẫn tiếp tục tăng. Tại thời điểm video được đăng (14/09/2026), anh nhắc tới những model rất mạnh như GPT-6 Astra. Một software factory tốt cho phép bạn hệ thống hoá việc dùng các model này một cách hiệu quả, thay vì chỉ gõ vào rồi qua lại mãi với nó.

Anh nghĩ tốt nhất là cho xem factory của mình chạy thế nào để mọi người hình dung. Các skill của anh được chia sẻ miễn phí, không tính phí gì cả. Nhưng anh không muốn mọi người sao chép mù quáng. Anh muốn mọi người suy nghĩ, hiểu quy trình, rồi tự áp dụng theo cách của mình. Nói vậy rồi, toàn bộ software factory của anh chỉ gồm khoảng năm, sáu file.

![Bảng vẽ My Software Factory với tweet định nghĩa, hai gạch đầu dòng agnostic và danh sách skill trong agents.md](https://homus.dev/photos/_LCeJZFIsd4-0943.jpg)

Bảng vẽ "My Software Factory" của Mic: tweet của anh (20/08/2026) định nghĩa software factory là "workflows + skills + domain knowledge" nhiều hơn là một harness; hai ý harness agnostic, model agnostic; bên phải là agents.md trỏ tới các skill /new-feature, /code-structure, /greploop & /greploop-apps, /before-and-after, /evidence-driven-testing.

## 4. File agents.md: viết workflow, đừng viết lại code base

File đầu tiên là `agents.md`. Với ai chưa biết, đây là một tài liệu duy nhất, một file markdown, được đưa vào system prompt. Mic tự sửa lại ngay: không phải system prompt, mà được chèn vào cuộc chat với agent mỗi lần bạn giao tiếp với nó. Mỗi lần anh gõ "hi", nếu có file agents.md, thì trước khi chữ "hi" được gửi đi, nội dung agents.md đã được gửi trước. Điểm hay của file này là anh có thể quy định agent nên hành xử ra sao.

Mic nhắc lại một video anh làm với Greg cách đây không lâu, trong đó anh nói file agents.md của đa số mọi người là vô dụng. Lý do: họ dùng nó để kể cho agent code trông như thế nào, toàn là thông tin đã có sẵn trong code base mà agent tự đọc được. Còn file của anh chứa một workflow đơn giản, và workflow đó là thứ agent không có sẵn (not native). Vì vậy file giải thích rõ từng bước phải làm, và anh sẽ đi qua từng bước một.

Trên màn hình là file Agent workflow của Mic. Phần mở đầu và bốn nhịp của workflow, như hiện trong video:

```
Agent workflow

Every task moves through the same four beats, each backed by a skill from this collection (or installed alongside it - see Skill sources). Drop this file into a repo as AGENTS.md and fill in the repo-specific callouts; it also governs work in this repo itself.

Workflow

1. Isolate - /new-feature. Every new feature starts in a fresh Git worktree branched from origin/main so agents can work in parallel without conflicts. Never build on main.
2. Build - /code-structure. Write code to the service-layer architecture: actions/boundaries orchestrate the "why/when", a service layer owns the reusable "how", with explicit inputs and structured returns.
3. Prove - /evidence-driven-testing. Verify with the repo's checks plus runtime evidence. Capture the before state while reproducing the issue - prior to fixing it, when it is cheapest - and the after once the change works.
4. Ship - /before-and-after, then /greploop. Open the PR with before/after proof embedded in the description (screenshot or video whenever the change has a visible surface; measured numbers or output pairs when it doesn't). Run /greploop - or /greploop-apps when the PR exceeds Greptile's file-count limit - until Greptile reports 5/5 with zero unresolved comments. Finish by presenting the PR URL.
```

![File Agent workflow mở trên GitHub với bốn bước Isolate, Build, Prove, Ship](https://homus.dev/photos/_LCeJZFIsd4-1143.jpg)

File AGENTS.md của Mic trên GitHub: bốn nhịp Isolate, Build, Prove, Ship, mỗi nhịp gắn một skill; bên dưới là ghi chú cho bước ship (CLI before-and-after, cờ cho container không có sandbox Chrome, host upload mặc định là public).

Bản AGENTS.md trong repo skill công khai của Mic đã được viết lại chi tiết hơn so với bản trong video (tính đến 10/2026), nhưng vẫn giữ bốn bước Isolate, Build, Prove, Ship.

## 5. Bước 1, Isolate: mỗi feature một git worktree

Bước đầu tiên là cô lập (isolate). Có một skill tên `new-feature`, và nó làm đúng như dòng đầu trong workflow: mọi feature mới đều bắt đầu trong một git worktree mới, tách nhánh từ `origin/main`, để các agent làm song song được mà không xung đột. Không bao giờ build trên `main`.

Mic đùa: ai từng xem Michael lên kênh của Greg đều biết lần nào cũng có diagram. Thế là anh bắt đầu vẽ.

Khi anh đang làm một project và bảo agent làm một feature, việc đầu tiên agent làm là isolate. Để hình dung, hãy lấy app của Greg và Mike. Hành trình của app là một đường thẳng: bắt đầu ở đây, bắt đầu prompt ở đây, rồi tới lúc launch lên production, có hàng nghìn khách hàng. Cách đa số mọi người làm việc với agent là ở từng điểm trên hành trình đó, họ build một feature, rồi một feature, rồi một feature nữa.

Đó là một quy trình rất tuyến tính: mỗi lần một feature, mỗi lần một feature. Và nếu bạn từng thử làm nhiều feature cùng lúc, đôi khi sẽ có xung đột, có lỗi. Người ta than: "ôi, agent của tôi xoá mất file này", "nó ghi đè file kia".

Bước isolate xử lý chuyện đó như sau, và Mic minh hoạ bằng diagram. Giả sử Greg bảo: "tôi thật sự không thích landing page của mình". Còn Mic nói với Greg: "các API call của mình có thể nhanh hơn". Khi Greg làm feature của anh, agent (nhờ agents.md của Mic) sẽ tạo một branch mới.

Có thể nghĩ về branch như một bản copy-paste của app tại đúng thời điểm đó. Greg làm việc trên một branch mới, một worktree mới của app. Worktree về cơ bản là một bản sao của app. Giống như ai đó copy một đoạn văn bản, dán sang một tài liệu mới, làm việc trên tài liệu đó, và tới lúc nào đó sẽ merge ngược lại vào tài liệu gốc.

Đó là điều Greg đang làm: anh có một tài liệu mới để làm feature của mình. Và Mike cũng có một feature khác phải làm. Anh có thể làm cùng lúc với Greg hoặc vào lúc khác, nhưng giờ anh có branch riêng của mình.

![Diagram 1. Isolate: đường thẳng Start tới Finish, nhánh của Mike phía trên và nhánh của Greg phía dưới](https://homus.dev/photos/_LCeJZFIsd4-1003.jpg)

Diagram "1. Isolate" trên app của Greg và Mike: từ đường chính (Start tới Finish), Mike tách một nhánh phía trên, Greg tách một nhánh phía dưới; mỗi nhánh làm riêng rồi nhập lại đường chính.

## 6. Vì sao agent "tự dưng xoá mất file"

Điểm hay là: Mic, Greg và thêm một người nữa, hay chính bạn với 50 agent khác nhau, có thể làm nhiều feature cùng lúc mà không có chuyện agent này giẫm lên việc của agent kia. Chuyện đó xảy ra rất nhiều. Mic bảo Greg: nếu từng thấy những tweet kiểu "trời ơi, tôi đang làm cái này thì agent xoá mất một đống thứ", thì gần như lúc nào nguyên nhân cũng là người ta cho các agent làm nhiều feature khác nhau trên cùng một branch. Mà agent thì sẽ làm đúng những gì bạn bảo.

Ví dụ: bạn bảo nó cập nhật landing page, nhưng bạn cũng bảo nó làm các API call nhanh hơn. Giờ nó để ý thấy: "à, các trang này gọi API tệ quá, để mình xoá đi viết lại". Nhưng trong khi đó nó lại đang làm design trên chính trang ấy. Thế là vấn đề bắt đầu nảy sinh. Isolate cho phép Mic làm nhiều feature cùng lúc, song song, mà không để agent này giẫm lên agent kia.

Đây là bước đầu tiên trong workflow của anh. Nó không có sẵn trong agent, nên đặt nó trong agents.md là hợp lý. Để khép vòng (anh sẽ giải thích workflow chi tiết sau): khi Mike làm xong, anh chỉ cần merge các thay đổi trở lại. Khi Greg xong, anh ấy có thể merge trước hoặc sau Mike, nhưng cả hai đều merge vào tài liệu chính.

Và sẽ không có xung đột, vì lúc đầu mỗi người làm trên một bản sao. Nhờ vậy anh ship nhanh được với nhiều agent cùng lúc.

Ví dụ của Mic: hai yêu cầu (landing page và API nhanh hơn) trên cùng một branch thì agent sửa đè lên nhau; mỗi yêu cầu một worktree thì cả hai làm song song rồi merge vào main mà không xung đột.

## 7. Bốn feature song song trên cùng một app, và câu hỏi về "team"

Mic mở terminal của mình ra: có bốn tab cùng làm trên Bezalel, app anh đang build, ba tab đã xong. Anh đang chạy bốn feature khác nhau trên cùng một app. Một cái làm email client. Một cái làm môi trường máy tính, một môi trường Linux. Một cái cập nhật landing page. Anh làm được những việc này một cách tự tin trong khi vẫn giữ được sự cô lập. Thứ đó không có sẵn trong agent; chính agents.md cộng với skill new-feature cho phép anh làm vậy. Anh dừng lại hỏi Greg có câu hỏi gì không.

Greg thấy mọi thứ rõ như pha lê. Cách anh nghĩ về nó: nếu bạn thật sự có một team kỹ sư đang build một app, hiển nhiên bạn sẽ không để mọi người build hết trên main, ai cũng push thẳng lên main. Như vậy chẳng hợp lý chút nào. Greg tự nhận mình không rành kỹ thuật, và giờ bỗng có rất nhiều người không rành kỹ thuật bắt đầu build app, và họ đụng đúng vấn đề này.

Greg nhắc lại chuyện Mic vừa kể kiểu "đôi khi agent ghi đè thứ này thứ kia". Theo anh, sự thật là 95% thời gian agent sẽ làm hỏng và ghi đè gì đó. Nên với anh điều này rất hợp lý, và nó là một ý lớn hơn: làm sao cấu trúc cách mình làm việc với agent để nó giống một team.

Mic đồng ý: "team" là cái tên hay hơn "isolate". Greg đáp: thì vì thế anh là marketer còn Mic là kỹ sư. Mic tự trêu rằng "isolate" nghe như tên một loại whey protein, và hứa nếu mọi người mở link thì sắp tới sẽ có tên mới. Nhưng về cơ bản bước này cho phép anh có nhiều agent làm các task khác nhau cùng lúc mà không giẫm chân nhau.

Ngoài ra còn có một quy trình dọn dẹp (cleanup) mà anh không đi sâu: khi việc đã được merge, worktree sẽ bị xoá, và những thứ tương tự. Đó là bước số một.

Terminal của Mic lúc quay: bốn tab agent cùng làm trên app Bezalel, ba tab đã xong; mỗi tab chạy trong worktree riêng nên không đụng nhau.

## 8. Bước 2, Build: skill code-structure

Bước số hai là build thật sự. Skill dùng ở đây là `code-structure`. Mic kể đây là skill anh đã chia sẻ từ lâu, giờ nó thành một phần trong workflow và anh chia sẻ cho mọi người.

Anh hẹn sẽ nói về model ngay sau đây, nhưng có một điều về model: chúng làm việc rất giỏi, chỉ là có thể không làm theo cách tốt nhất, nhất là khi viết code. Ví dụ, theo Mic, Fable là một trong những model đầu tiên thật sự viết code khiến anh phải thốt lên "hừm, cái này còn tốt hơn một số kỹ sư giỏi nhất mình từng gặp". Fable viết code rất tốt. Nhưng ngay cả Astra, model mạnh nhất và là model yêu thích của anh, cũng có những quyết định về chất lượng code khiến anh lắc đầu. Không phải model thiếu năng lực.

Model chỉ đơn giản là làm cho xong việc. Nếu có thể làm xong theo cách cẩu thả, nó sẽ làm xong theo cách cẩu thả. Skill code-structure buộc nó viết theo một kiến trúc gọi là service layer architecture. Mic không muốn làm mọi người buồn ngủ, nhưng tóm lại code được viết theo cách mà nếu bạn cần con người can thiệp, chẳng hạn bạn thuê một developer, thì developer đó nắm bắt rất dễ.

Hoặc chính bạn là developer, bạn cũng nắm bắt rất dễ. Và ngay cả agent của bạn, khi quay lại đọc code, cũng sẽ thấy "à, hợp lý".

![Diagram thêm bước 2. building (code-structure) sau 1. Isolate](https://homus.dev/photos/_LCeJZFIsd4-1358.jpg)

Diagram có thêm bước "2. building (code-structure)" ngay sau "1. Isolate": sau khi tách worktree, agent build feature theo hướng dẫn của skill code-structure.

## 9. Code chạy được chưa chắc là code viết tốt

Mic kể anh từng cho GPT 5.6 Sol viết code: nó chạy, làm đúng điều nó phải làm. Nhưng rồi anh cho Fable review lại, và Fable phán: "cái này kinh khủng". Code bị trùng lặp, function nằm rải rác khắp nơi, có cả dead code.

Vì thế, chạy được không có nghĩa là viết tốt. Skill này cho agent một bộ hướng dẫn về cách viết code. Quay lại diagram: anh đang làm một feature mới. Việc đầu tiên xảy ra là isolate. Việc thứ hai (anh mong mọi người bắt đầu thấy tính chất nhà máy của nó) là build. Ở bước build, agent dùng skill code-structure. Khi anh bảo agent "build cho tôi landing page này", "build cho tôi feature này", nó sẽ tham chiếu skill đó.

Ví dụ cụ thể: Mic đang làm một app, và feature anh muốn có là một kiểu kho chứa skill (skills repository), nơi các agent của anh kết nối vào app và lưu skill ở đó.

![Landing page Bezalel với dòng chữ Super powers for your agent](https://homus.dev/photos/_LCeJZFIsd4-1346.jpg)

Landing page của Bezalel, app Mic đang build: "Super powers for your agent", gồm memory, email, money, texting, một máy tính, sandbox và hàng trăm connector, qua một MCP URL và một token, chạy với Claude Code, Codex CLI, Cursor và các agent khác.

Anh chỉ bảo agent "build cho tôi cái đó". Trong lúc viết code, nó liên tục tham chiếu skill code-structure. Kết quả là nó viết code theo cách mà anh, với tư cách developer, review được. Và lỡ như anh cần thuê ai đó review code, đó sẽ không phải một "khẩu pháo bắn slop" (slop cannon) khiến họ bối rối, không biết làm gì, hay tính phí bạn quá tay. Code được viết để một developer hiểu được.

Anh còn thấy rằng nếu dùng một agent khác không có chút context nào về code base, nó cũng hiểu code rất tốt. Vậy là đầu tiên, isolate (anh xin lỗi vì cái tên dở). Thứ hai, build. Và tất cả đều được làm theo một cách có chủ kiến (opinionated), giúp agent đi nhanh và làm việc tốt nhất có thể. Greg xác nhận là hiểu và bảo Mic đi tiếp.

## 10. Bước 3, Prove: agent không thể "hứa móc ngoéo"

Bước số ba là prove (chứng minh). Mic nói: agent đâu thể hứa móc ngoéo (pinky promise) được. Nếu bạn ép agent đủ mạnh... Anh nói GPT-6 Astra là một bước nhảy lớn về năng lực chính vì, theo anh lúc quay video, đó là model ít hallucinate nhất, điều rất tuyệt. Nhưng ngoài model đó ra, phần lớn model đều có thể bị ép tới mức nói dối, hay tin vào một điều gì đó, hoặc đôi khi thẳng thừng nhận: "à, tôi mới nhận ra là tôi chưa làm phần việc này cho bạn". Vì vậy anh bắt agent chứng minh việc nó đã làm.

Đây có lẽ là skill anh thích nhất. Có hai skill liên quan. Skill đầu là evidence-driven testing. Nếu máy của bạn có khả năng, nó sẽ quay lại trạng thái trước (before state): trước khi có feature, hoặc khi bạn đang sửa bug thì nó quay lại cảnh bug đang xảy ra. Sau khi sửa xong, nó quay lại một phiên bản đã chạy đúng (after). Skill này chứng minh rằng bản sửa thật sự đã được thực hiện. Bạn sẽ ngạc nhiên vì đôi khi agent viết code xong, tưởng là chạy rồi, nhưng nó không test, không chứng minh là chạy được, mà cứ thế bảo bạn là chạy được.

Nên anh cần chắc chắn agent thật sự chứng minh công việc của nó. Còn nếu máy của bạn không làm được việc quay màn hình đó, thì có một skill khác tên before-and-after. Anh mở một PR ra để cho Greg xem, vì cho xem thì tốt hơn là kể.

Đây là một PR do agent của anh tạo, không phải anh. Anh muốn nó tạo một trang admin email và kết nối với một dịch vụ email anh đã làm. Nhìn xem nó làm gì: nó cho anh thấy trạng thái trước, khi trang đó chưa tồn tại. Rồi cho thấy trạng thái sau.

![PR đã merge Add Cloudflare email provider and admin test console với bảng ảnh Admin email before và after](https://homus.dev/photos/_LCeJZFIsd4-1630.jpg)

PR "Add Cloudflare email provider and admin test console" do agent mở: bảng "Admin email before" là trang 404 "No such page on Bezalel", "Admin email after" là trang Cloudflare Email mới trong dashboard; phía dưới là mô tả các browser check đã qua.

Vậy là với mỗi feature anh build, mỗi PR anh làm, anh đều nhận được trạng thái trước và trạng thái sau. Và lý do nó giúp được anh: Mic thành thật thừa nhận dạo này anh không đọc hết code của mình nữa. Có thì cũng chỉ lướt qua. Một tình huống "đọc lướt", và nói thật là số lần lướt cũng ngày càng ít đi.

Phần lớn việc anh làm bây giờ là ở phía front end: anh đảm bảo agent tuân theo skill code-structure và anh nhận được ảnh chụp before và after. Anh mở thêm một ví dụ rõ hơn: anh đang làm một feature về máy tính, muốn cho agent của mình một chiếc máy tính, nhưng nó không chạy.

## 11. Agent tự quay lại build, và bằng chứng bằng con số

Lần chạy đầu tiên không được. Lúc đó anh thậm chí chưa dựng software factory, anh đang làm trên một máy khác, agent push code lên và nó không chạy. Như trên màn hình, chẳng có gì xảy ra cả. Anh bảo agent: nó không chạy, dùng các skill đi, dùng factory đi. Và đây là ảnh after, với agent thực sự đang dùng app.

![Ảnh After an agent opened Firefox on its native VM trong trang Computer của Bezalel](https://homus.dev/photos/_LCeJZFIsd4-1754.jpg)

Ảnh "after" trong PR feature máy tính: trang Computer của Bezalel hiển thị desktop trực tiếp của một agent ("Research agent") đã mở Firefox trên VM riêng của nó.

Hai skill proof và before-and-after buộc agent đưa cho anh bằng chứng thực tế về trước và sau, dù là video hay ảnh chụp. Có những lúc agent làm phần before, rồi tới phần after thì tự nhận ra: "à, mình vừa xem ảnh after hay video after và thấy mình chưa thật sự làm xong feature".

Vậy nó quay về đâu? Nó quay về bước build. Đó là tính chất nhà máy. Anh không phải bảo nó "này, bạn trượt bài before và after rồi, đi làm cho xong đi". Các skill được viết sao cho agent tự biết: tiêu chí before và after chưa đạt, mình phải tiếp tục build. Nhờ vậy anh có một hình ảnh trực quan về công việc đã làm, và việc review trở nên dễ hơn.

Nhất là nếu bạn không rành kỹ thuật, review dễ hơn nhiều vì bạn chỉ cần xem vài ảnh chụp hay một video. Trong quá trình build, tới một lúc anh sẽ có một PR cho xem before và after. Dù anh có thể không hiểu hết đống "lằng nhằng" kia, nó vẫn cho anh bằng chứng trực quan rằng việc đã được làm.

Anh đoán trước câu hỏi: nếu bằng chứng không trực quan thì sao? Anh mở một PR về performance để trả lời. Với một trong các app anh đang build, các cú click chưa đủ nhanh nhạy (snappy). Giờ thì như trên màn hình, mọi thứ đều nhanh, tải nhanh. Trước đây không phải vậy. Anh bảo agent: sửa đi.

Và nó sửa. Lần này nó vẫn đưa được ảnh chụp, nhưng giả sử đây là thứ không thể chụp ảnh, nó sẽ viết test rồi đưa kết quả. Trong ví dụ này, nó đo tốc độ tải trang trước khi sửa. Mic đọc con số của một trang là khoảng 850 mili giây.

Theo anh, đó là một tội lỗi trong web development, chuyện đó không được phép xảy ra. Và lưu ý, code đó do GPT 5.6 Sol viết, một model tốt. Nhưng agent đã kéo nó xuống còn khoảng 60. Trên bảng trong PR, các con số đo là: Connectors 815 ms xuống 60 ms, Email 817 ms xuống 61 ms, Skills 893 ms xuống 74 ms, Agents inventory 817 ms xuống 71 ms.

![Bình luận trong PR với bảng Warm navigation Before After cho Connectors, Email, Skills, Agents inventory](https://homus.dev/photos/_LCeJZFIsd4-2003.jpg)

Bằng chứng không cần ảnh: bảng "Warm navigation" trong PR performance, thời gian tải trước và sau cho bốn trang (815 xuống 60 ms, 817 xuống 61, 893 xuống 74, 817 xuống 71), kèm ghi chú đây là trung vị của ba lần chạy trên production build.

Vậy là một lần nữa anh có bằng chứng thực sự từ agent rằng nó đã làm điều nó nói, ngay trong quá trình review. Mic dừng lại hỏi Greg có gì anh bỏ sót không.

## 12. Người quản lý agent và kiểu review như xem stories

Greg diễn giải lại: nếu bạn đang cố dựng một software factory, niềm tin hiển nhiên là phần rất lớn. Ý Mic là: nếu để tất cả các agent này build feature, build app, thì ta cần tin được thứ chúng tạo ra. Vậy đây là vài skill cho phép bạn đóng vai người quản lý agent (agent manager). Như Mickey lúc này chính là agent manager.

Bạn không còn chìm sâu trong code nữa, bạn chỉ quan sát những gì đang diễn ra. Và điều Greg thấy hay ở phần before và after trực quan là nó hợp với millennials và Gen Z, những người quen Instagram stories hay Snap stories. Giống như bạn bấm qua từ story này sang story khác: có, có, không.

Mic đồng ý: nó vừa miếng (bite size), đúng là vậy. Nó cho phép anh xây dựng niềm tin với agent. Và điều buồn cười là câu Greg nói khiến anh chợt nhận ra: đây chính là điều các tổ chức bình thường vẫn làm với kỹ sư của họ. Bạn build một feature, rồi có một người, chẳng hạn một senior engineer, có nhiệm vụ review việc của bạn. Bạn có một PR với phần mô tả cho thấy "đây là việc tôi đã làm, đây là test tôi đã viết". Về cơ bản vẫn y như vậy, chỉ là giờ ta làm với máy.

Anh cho xem thêm một ví dụ dạng video: lần này anh dùng Cursor Cloud Agents, và trong PR có mục "Proof of improvement" với video agent đang làm việc, đang dùng app. Đúng như Greg nói, giống Instagram hay TikTok: anh xem video và thấy "được rồi, agent thật sự build cái này và nó chạy". Nhờ vậy anh không phải đọc code, cứ thế merge.

Rồi sống cuộc đời tốt nhất của mình, ra ngoài chạm cỏ (touch grass), anh đùa.

## 13. Bước 4, Ship: skill greploop và Greptile

Bước cuối cùng là ship. Mic đã nhắc before-and-after ở trên, nhưng còn một skill tên greploop, dùng một dịch vụ bên thứ ba tên Greptile, là một code review agent. Bạn không bắt buộc phải dùng code review agent, nhưng nếu thật sự nghiêm túc với việc build phần mềm và phần mềm đó sẽ có người dùng, anh rất khuyên dùng một code review agent nào đó. Greptile là cái anh thích nhất; CodeRabbit, Macroscope và còn rất nhiều cái tốt khác.

Greptile có skill tên greploop. Anh mở một PR để cho xem: Greptile để lại các bản tóm tắt rồi đưa feedback. Ví dụ đây là feedback ban đầu nó đưa cho PR: có một vấn đề với pagination ở đây, một chỗ không giữ được khoảng trống của menu. Nghĩa là agent viết code đã bỏ sót những thứ đó.

![Bình luận của bot greptile-apps: Invalidate pending pagination, đã được đánh dấu resolved](https://homus.dev/photos/_LCeJZFIsd4-2303.jpg)

Feedback của Greptile trong PR "Prepare dashboard data before navigation": lỗi "Invalidate pending pagination" (request trang hai có thể ghi đè dữ liệu mới), kèm các nút Fix in Cursor, Fix in Claude, Fix in Codex; cuộc thảo luận đã được đánh dấu resolved.

Mà thế cũng không sao, chuyện đó vẫn xảy ra, con người cũng bỏ sót những thứ như vậy. Nhưng Greptile không chỉ đưa feedback, nó còn đưa một điểm tự tin (confidence score). Ở đây là 5/5, vì sau khi có feedback, như dòng có tên anh ở đây cho thấy, feedback đã được xử lý: agent của anh đã sửa theo feedback. Trước khi được sửa, điểm này là 3/5. Con số đó báo cho agent biết còn những chỗ nó đã bỏ sót và cần xem lại.

![Greptile Summary với Confidence Score 5/5, Safe to merge](https://homus.dev/photos/_LCeJZFIsd4-2323.jpg)

Bản tóm tắt của Greptile cho cùng PR sau khi agent sửa: "Confidence Score: 5/5, Safe to merge", và ghi rằng lỗi pagination của mailbox cùng lỗi layout của account menu đều đã được sửa hẳn.

Greploop chạy tự động: không ai phải gõ "greploop", agent tự làm. Nó làm theo đúng mô tả trong workflow: mở PR với bằng chứng before và after nhúng trong phần mô tả. Khi thay đổi có bề mặt nhìn thấy được thì là ảnh chụp hay video; khi không có thì là con số đo được hoặc cặp output. Rồi xem agent làm gì tiếp.

Nó chạy greploop hoặc greploop-apps. Khác biệt: theo lời Mic, nếu thay đổi của bạn kiểu hơn 10.000 dòng thì skill greploop-apps được kích hoạt (trong file workflow ghi là khi PR vượt giới hạn số file của Greptile). Bạn không phải lo, agent tự làm việc đó.

## 14. Vòng lặp tốt: build, prove, ship cho tới 5/5

Dòng tiếp theo trong workflow: chạy cho tới khi Greptile báo 5/5 và không còn bình luận nào chưa giải quyết, rồi kết thúc bằng việc đưa ra URL của PR. Nghĩa là agent sẽ lấy feedback nhận được và quay lại bước build. Mic vẽ lên diagram: giả sử ta đang ở build, rồi ship, và đang chạy greploop. Khi nhận điểm confidence là 3/5, điều gì xảy ra? Nhớ lúc nãy nói về các vòng lặp không, đây là một vòng lặp tốt.

Nó quay lại building. Agent về lại bước hai, bắt đầu build. Build xong thì sao? Nó prove, rồi nó ship. Và đây là điều xảy ra:

Agent tự động chờ điểm mới. Greptile cho 4/5: đã bắt được vài thứ, nhưng vẫn còn một thứ cuối cùng bị bỏ sót. Quay lại building. Nó build, nó prove, và đoán xem nó làm gì tiếp, Greg? Nó ship.

![Diagram bốn bước với mũi tên vòng từ 4. ship về 2. building, ghi 3/5, 4/5, 5/5](https://homus.dev/photos/_LCeJZFIsd4-2543.jpg)

1. Isolate, 2. building (code-structure), 3. prove, 4. ship (/greploop). Mũi tên vòng từ ship về building mỗi khi điểm Greptile là 3/5 rồi 4/5, cho tới khi đạt 5/5.

Và giờ anh có 5/5. Khi có 5/5, việc còn lại là anh merge. Anh mở một PR đang mở để cho xem: việc còn lại của anh chỉ là bấm merge. Khi bấm merge, thay đổi cuối cùng cũng vào bản chính của app. Anh làm điều này trong lúc chạy 15 feature cùng lúc, 15 feature khác nhau với các agent khác nhau, sub-agent, đủ kiểu.

Điều này cho phép, và đây là tính chất nhà máy, mỗi agent có một instance cô lập để làm việc một mình. Nó có hướng dẫn về cách build. Nó có phương pháp để chứng minh việc nó làm. Rồi có một dịch vụ bên ngoài kiểm tra việc của nó. Nếu việc chưa đạt chuẩn, nó phải tiếp tục làm trong vòng lặp cho tới khi đạt. Khi có 5/5, đó là lúc anh bước vào.

Đó là software factory. Để ý là nãy giờ không nói gì về model, không nói gì về harness. Tất cả là workflow, skill và một chút domain knowledge. Không phải ai cũng làm việc giống nhau, đây là cách anh làm. Nhưng anh thấy kết quả rất tốt. Anh dừng lại hỏi Greg cần giải thích hay bổ sung gì thêm.

## 15. Phép so sánh với một nhà máy thật

Greg nói điều đang "click" trong đầu anh là phép so sánh software factory với một nhà máy vật lý. Anh tóm tắt lại theo cách anh hiểu và hỏi ý Mic.

Bước một, isolate, giống như nhà máy nhận một đơn hàng đặt riêng và cho nó một trạm làm việc riêng, để nó không làm xáo trộn phần còn lại của dây chuyền. Trong phần mềm, Mic gọi đó là worktree: một branch, một worktree, một môi trường cô lập. Nhưng khái niệm cơ bản là vậy.

Bước hai, build, là dây chuyền lắp ráp: agent thật sự cắt, hàn, lắp ráp, đi dây cho sản phẩm. Dĩ nhiên trong phần mềm không có chuyện đó. Bạn viết code, thay đổi file, thêm cấu trúc cho mọi thứ. Bạn thật sự tạo ra một thứ có thật theo nghĩa phần mềm.

Bước ba, prove, về cơ bản là cách gọi sang của kiểm soát chất lượng (quality control). Trước khi bất cứ thứ gì rời nhà máy, phải có người kiểm tra. Bạn không thể làm ra sản phẩm mà không cho ai test: nó có bật lên không, có vừa không, có gãy khi chịu lực không. Greg hình dung một nhà máy ô tô hay đại loại thế. Trong phần mềm, bạn chạy test, xem preview, xem log, và những ảnh chụp Mic vừa cho xem.

Cuối cùng là shipping: khi đã qua kiểm soát chất lượng, sản phẩm ra khỏi cửa. Nhưng sẽ có những việc như phải merge, phải deploy PR, phải viết release notes, phải gửi feedback lại cho team sản phẩm, vì có thể nó không qua kiểm soát chất lượng và bạn phải chạy lại vòng lặp.

Phép so sánh của Greg: hàng trên là bốn bước trong factory của Mic, hàng dưới là khâu tương ứng trong một nhà máy thật.

Mic đồng ý hoàn toàn. Anh nói có khi anh sẽ đổi tên mọi thứ mình viết theo cách Greg vừa nói, vì giờ anh nhận ra tên của mình dở quá. Cách Greg mô tả rất hợp lý, đúng là nó hoạt động như vậy. Về cơ bản, điều họ đang làm là lấy một nhà máy và biến nó thành nhà máy phần mềm.

## 16. Một software factory chỉ là vài file markdown

Mic quay lại ý ban đầu: đây là lý do anh từng thấy (không có ý chê ai, startup hay sản phẩm nào) một software factory không phải là một sản phẩm. Nó không phải một harness đặc biệt, không phải kiểu "công ty này đã build một phần mềm". Không, một software factory theo đúng nghĩa đen chỉ là một bộ file markdown.

Anh nói thêm một điều ngoài lề, có lẽ để dành cho video khác: giờ có những startup mà bản chất chỉ là một agent cộng vài file markdown. Ta thật sự đã bước vào thời đại đó. Anh mong phần trình bày dễ hiểu và khiến mọi người hào hứng; bản thân anh rất phấn khích với thời điểm hiện tại vì rất nhiều thứ giờ đã có thể làm được.

Greg đồng ý 100%: thật điên rồ khi người ta làm được điều này, và thật hay khi những người như Mic chia sẻ nó, vì nó đáng giá. Greg muốn thêm một ghi chú nhanh về greploop hay bất kỳ phần mềm code review nào. Anh nói rõ mình không có liên kết gì với các công cụ đó. Nhưng nếu nghiêm túc với việc tạo ra phần mềm, anh không hiểu sao người ta lại không dùng greploop, CodeRabbit hay một công cụ nào đó trong số này.

Lý do của anh: trong kinh doanh, và anh biết nhiều người đang xem cũng vậy, ta coi trọng dịch vụ mình cung cấp. Thế mà với việc build phần mềm, dường như ta lại chẳng quan tâm. Nếu có người sẽ dùng app của bạn, Greg nói anh có một sự đồng cảm với người dùng ở phía bên kia. Và vì nhiều startup làm công cụ này đã gọi được rất nhiều vốn, họ có nhiều gói miễn phí (free tier); theo Greg lúc quay video, bạn có thể xoay vòng qua các free tier và dùng khá nhiều thứ mà không mất tiền. Nên nếu bạn đang build thứ gì bạn nghiêm túc và đam mê, anh rất khuyến khích dùng một code review agent, loại nào cũng được.

Greg cảm ơn Mic đã tới và chia sẻ "bí kíp", hứa để link theo dõi Mic trên mạng, trên YouTube và phần mềm Mic đang làm. Mic cảm ơn Greg và mọi người đã ủng hộ, và hẹn gặp lại ở tập sau.

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

- Tên gốc: Building a Software Factory that actually works (Full Course)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=_LCeJZFIsd4](https://www.youtube.com/watch?v=_LCeJZFIsd4)

- Kênh YouTube Greg Isenberg (Greg Isenberg): [youtube.com/channel/UCPjNBjflYl0-HQtUvOx0Ibw](https://www.youtube.com/channel/UCPjNBjflYl0-HQtUvOx0Ibw)

- Bộ skill của Michael Shimeles (AGENTS.md, new-feature, code-structure, evidence-driven-testing, before-and-after, greploop, greploop-apps), được nhắc trong mô tả video: [github.com/michaelshimeles/skills](https://github.com/michaelshimeles/skills)

- Định dạng AGENTS.md: [agents.md](https://agents.md/)

- Greptile, code review agent dùng ở bước ship: [greptile.com](https://www.greptile.com); skill greploop gốc của Greptile: [github.com/greptileai/skills](https://github.com/greptileai/skills)

- CLI before-and-after mà skill before-and-after dùng: [github.com/vercel-labs/before-and-after](https://github.com/vercel-labs/before-and-after)

- Các code review agent khác được nhắc: [CodeRabbit](https://www.coderabbit.ai), [Macroscope](https://www.macroscope.com)

- Cursor Cloud Agents (dùng trong ví dụ video "Proof of improvement"): [cursor.com/docs/cloud-agent](https://cursor.com/docs/cloud-agent)

Nguồn: https://homus.dev/talks/building-a-software-factory-that-actually-works-full-course · cập nhật 2026-10-18