Tự dựng software factory bằng Claude Code

1. Dựng một software factory ngay trong project của bạn

Alexander Galea (kênh ZazenCodes) mở đầu: hôm nay anh dựng một software factory bằng Claude Code. Video có một đoạn quảng cáo cho Claude Code của Anthropic. Anh nói mình rất thích dùng Claude Code, và tất nhiên Claude sẽ được đặt vào trong chính factory này. Anh sẽ dùng một hỗn hợp Opus và Sonnet, ở thời điểm quay là phiên bản 5.5. Ai cũng đồng ý rằng các model này rất ấn tượng, nên anh muốn cho xem chúng làm được gì.

Đây sẽ là một factory rất đơn giản, nhưng như mọi người sẽ thấy, nó vẫn rất hiệu quả. Ý tưởng là bạn có thể tự build một cái cho mình, ngay bên trong một project đang có. Vì vậy anh khuyến khích người xem làm theo từng bước: video rất thực hành (hands-on). Anh sẽ giải thích chính xác factory này là gì, cách tiếp cận ra sao, và giới thiệu nhanh software factory thực chất là gì.

Anh mở mind map của video. Bên phải là phần demo; anh giải thích sơ đồ đó trước cho ai đã biết software factory là gì, rồi mới quay sang phía bên trái để kể một chút lịch sử. Anh nhắc rằng ai đăng ký newsletter của anh sẽ nhận bản mind map này dưới dạng ảnh chất lượng cao để xem lại cùng anh.

2. Dây chuyền: spec writer, builder, bốn reviewer, approver

Thứ sẽ được build là một agentic software factory đơn giản: một đội agent nhận một feature và đưa nó vào code base chính (main) ở cuối dây chuyền. Đầu vào là một feature request; phần còn lại chạy tự động, trừ bước cuối là bước con người duyệt (human approval).

Anh đi qua từng bước:

1. Viết spec. Bước đầu tiên là viết spec, và anh dùng Opus cho việc này.
2. Builder. Spec được chuyển cho một building agent, agent này build ra feature hoàn chỉnh, chạy được.
3. Review. Feature được giao cho nhiều review agent: một security review, một UX review, một UI design review và một code review. Mỗi review do một agent riêng làm; có cái chạy Opus, có cái chạy Sonnet.
4. Vòng lặp. Kết quả review được đưa ngược lại cho builder agent, và chuyện này lặp lại cho tới khi code đạt yêu cầu.
5. Approval. Cuối cùng là bước duyệt, do một agent khác chạy Opus. Agent này quyết định một trong hai: tự động merge vào main, hoặc chuyển cho người review.

Tất cả được điều phối bởi chính cái factory anh sắp build. Ai muốn vào thẳng phần build có thể dùng các mốc chương trong phần mô tả video; còn không thì anh tiếp tục đi qua phần còn lại của mind map.

3. Software factory là gì: lịch sử từ 1968 tới nay

Software factory được mô tả lần đầu bởi Robert W. Bemer ở General Electric năm 1968. Về cơ bản, đó là một môi trường lập trình do máy tính điều khiển, chứa các công cụ phát triển được chuẩn hoá, cùng với thông tin lịch sử phục vụ việc quản lý và đo lường.

Tóm tắt lịch sử theo lời anh: từ đó, rất nhiều chuyện diễn ra ở Nhật Bản. Anh tin là ở châu Âu và Mỹ cũng có ở mức nào đó, nhưng Nhật Bản là thứ định hình giai đoạn đầu của software factory. Tới thập niên 2000, chưa có CI/CD đúng nghĩa, câu hỏi khi đó là làm sao có các pattern, model và framework tái sử dụng được để build phần mềm. Sang thập niên 2010 và 2020 thì có CI/CD: các pipeline continuous integration bài bản, GitHub Actions.

Và bây giờ là agentic factory.

4. Agentic software factory 101

Đây là hình dạng của một software factory trong thời đại AI. Anh thích một câu trích dẫn: cái mới là việc tự động hoá phần công việc nhận thức (cognitive work) tương đối phi cấu trúc nằm giữa các bước deterministic, và tất nhiên bao gồm cả việc viết toàn bộ code.

Đây là vòng cơ bản: có một trigger, trigger đi tới một agent, agent nộp một PR, và PR được một người merge. Bên trong vòng đó có đủ thứ thông minh: agent kéo thông tin từ nhiều nguồn vào. Đó là chỗ các sơ đồ thú vị của software factory xuất hiện.

Anh thừa nhận đã lướt qua nhiều chi tiết, và nói sẽ bàn kỹ hơn trong các buổi gọi hằng tuần ở cộng đồng Skool của mình.

5. Chuẩn bị: project thật, bypass permissions, Opus 5.5 effort high

Giờ tới phần build với Claude Code. Anh sẽ dán một prompt vào Claude để bắt đầu, và đó là toàn bộ prompt dùng trong video. Prompt này nằm trong source code của video (link ở phần mô tả), ai muốn có thể tham khảo.

Tới đây, nếu đang làm theo, bạn nên mở một project có sẵn của mình. Project của anh là source code website của anh. Anh tự nhận đó là một project "khá xấu", có rất nhiều thứ đang diễn ra bên trong. Anh sẽ dựng software factory ngay trong website đó.

Anh khởi động Claude Code và chỉ ra rằng mình đang bật bypass permissions, tức để Claude làm bất cứ điều gì nó muốn. Bạn có thể đặt mức này tuỳ theo độ thoải mái của mình. Việc đầu tiên anh làm là đổi model sang Opus 5.5, rồi đặt effort. Với task này anh chọn effort high, vì muốn kết quả chất lượng rất cao và muốn model làm theo đủ mọi chi tiết trong prompt.

Anh dán prompt vào, rồi bấm Ctrl+G để mở prompt trong editor mặc định của mình (và có thể thoát ra để xem lại trong Claude).

6. Build prompt: một skill, các subagent và file markdown

Câu mô tả một dòng của spec: build một software factory đơn giản, trực quan, ngay trong repo này, dùng Claude skill, subagent và file markdown. Các file markdown sẽ giữ trạng thái (state) của ứng dụng.

Phần quan trọng nhất là orchestrator. Orchestrator của anh là Claude Code, chạy model nào anh chọn lúc đó; anh chạy skill factory để khởi động nó. Từ đó, factory chạy theo vòng lặp đã mô tả: một feature đi qua spec writer, vào builder, rồi được nhiều review agent kiểm tra. Xong review, nếu cần sửa thì quay lại vòng lặp; sau đó tới approver, nơi feature hoặc được merge vào main, hoặc chuyển cho người review. Đây là một hệ thống dùng lặp lại mỗi khi muốn build một feature mới cho project. Theo anh, đó là sức mạnh của software factory, và là lý do mọi người đang hào hứng với chúng.

Anh hình dung trong tương lai có thể kéo dữ liệu từ thế giới bên ngoài vào, và có những thứ khác kích hoạt vòng này thay vì một feature gõ tay. Anh nhắc: tất cả vẫn đang là prompt của anh. Đi xuống tiếp, factory được dựng thành một skill, theo đúng quy ước của agent skill. Có thêm thư mục factory, nằm ngay trong app anh đang làm. Rồi có vài file mẫu để định đúng phong cách, ví dụ cú pháp subagent của Claude trông thế nào; phần lớn còn lại để agent tự build.

Cuối prompt là các lệnh anh muốn có: bắt đầu một job mới qua vòng lặp bằng /factory kèm mô tả feature, và một dashboard để thấy được hệ thống đang làm gì trong lúc chạy. Toàn bộ prompt (lấy từ source code của video, khớp với nội dung trên màn hình):

Build a simple, visual "software factory" in this repo using a Claude Code skill,
subagents, and markdown files. Keep it small: a viewer should understand the whole
thing in a few minutes. Inspect the repo first so the agents know its language,
test command, and conventions.

## The orchestrator

The factory is one skill, /factory. Whichever Claude Code session runs it becomes
the orchestrator: it runs the loop below, spawns every agent, and is the only
writer of factory/board.json.

## The loop (edit this to change the factory)

                   ┌──────────────────┐
                   │     feature      │
                   └─────────┬────────┘
                             ▼
                   ┌──────────────────┐
                   │   spec-writer    │
                   │       opus       │
                   └─────────┬────────┘
                             ▼
                   ┌──────────────────┐
                   │     builder      │◄────────────────────┐
                   │       opus       │                     │
                   └─────────┬────────┘                     │
        ┌─────────────┬──────┴──────┬─────────────┐         │
        ▼             ▼             ▼             ▼         │
  ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐   │
  │  security │ │     ux    │ │ ui design │ │    code   │   │
  │    opus   │ │   sonnet  │ │   sonnet  │ │   sonnet  │   │
  └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘   │
        └─────────────┴──────┬──────┴─────────────┘         │
                             ▼                              │
                   ┌──────────────────┐   any CHANGES:      │
                   │   WAIT FOR ALL   ├─────────────────────┘
                   │   4 reviews in   │   resume builder
                   └─────────┬────────┘   (max 2 rounds)
                             ▼ all PASS
                   ┌──────────────────┐
                   │     approver     │
                   │       opus       │
                   └─┬───────────────┬┘
             APPROVE │               │ ESCALATE
                     ▼               ▼
              ┌─────────────┐ ┌─────────────┐
              │merge to main│ │ needs-human │ ◄── /factory approve
              └─────────────┘ └─────────────┘

## Target file system

.claude/
  skills/factory/SKILL.md          # the orchestrator's instructions
  agents/                          # one file per agent in the loop
factory/
  board.json                       # durable state, drives the dashboard
  dashboard.html                   # visual board, polls board.json
  backlog.md                       # queue of features for /factory next
  jobs/003-rate-limiting/          # one folder per job
    spec.md
    build.md
    round-1/                       # one folder per review round,
      review-security.md           # one file per reviewer
      review-ux.md
      review-ui.md
      review-code.md
    decision.md

## Example files

.claude/agents/<name>.md  (Claude Code subagent syntax)
---
name: example-agent
description: One line on when the orchestrator should use this agent.
tools: Read, Grep, Glob, Bash, Write
model: sonnet
---
What this agent reads, what it does, and which file it writes.

factory/board.json
{ "jobs": [ { "id": "003-rate-limiting", "branch": "factory/003-rate-limiting",
  "stage": "review", "round": 2,
  "reviews": { "security": "CHANGES", "ux": "PASS", "ui": "pending", "code": "PASS" } } ] }

## Rules
- Agents get context from files, not the conversation, and write only their own file.
- Each review starts with VERDICT: PASS or CHANGES; decision.md starts with
  APPROVE or ESCALATE.
- The builder works and commits on a feature branch (factory/<job-id>) and tests
  against the spec's acceptance criteria.
- WAIT FOR ALL: a review round is done only when every reviewer's file exists in
  the round folder. Never resume the builder mid-round.
- Spawn the builder with a name (builder-<job-id>) and resume that same builder
  with SendMessage for each new round, pointing it at the round folder.

## Commands
/factory <feature>               run a new job through the loop
/factory next                    run the first unchecked item in backlog.md
/factory approve <job-id>        merge a needs-human job into main
/factory rework <job-id> <note>  send a job back to the builder with feedback

## Dashboard
One self-contained HTML file, served with `python3 -m http.server` from factory/.
Jobs are cards moving across the loop's stages. Each review round shows as a row
of reviewer chips that fill in as verdicts land. needs-human jobs stand out. Click
a card to read its markdown files. Clean and minimal.

Anh bấm chạy.

7. Claude build xong: các quyết định cần xem lại

Anh cho xem skill orchestrator đang được viết ra. Anh tự tin rằng với một task agentic chạy dài như thế này, model sẽ xử lý được mọi chi tiết nhỏ. Ai đã dùng Opus đều hiểu: bạn có thể ném vào bất kỳ chi tiết nhỏ nào, nó rất giỏi nắm lấy và lan chúng ra khắp code trong lúc build. Tiếp theo nó build các reviewer agent. Tất cả đều là Claude subagent, và đây là "những anh thợ" trong software factory làm toàn bộ công việc; anh mở thử reviewer UI agent.

Claude làm xong. Thứ cuối cùng nó làm là dashboard cho factory. Anh đọc phần các quyết định.

• Tối đa hai vòng (max two rounds). Anh thấy ổn.
• Checkout của bạn. Builder làm việc trên factory: đó là branch được checkout ra để build feature. Ổn.
• Rework. Nếu chưa được, có thể cho job chạy lại vòng lặp.
• Approver escalate gì. Có một đoạn bàn về những gì approver phải đẩy lên cho người: bất cứ thứ gì dính tới billing, bất cứ thứ gì dính tới quyền truy cập khoá học. Những thứ này là đặc thù repo của anh; với repo của bạn, agent cũng sẽ tự đặc thù hoá theo.

Anh nhấn mạnh thêm một điểm hay: prompt anh viết là tổng quát, áp được cho bất kỳ project nào. Nó sẽ chạy tốt với project của bạn y như với project của anh, vì nó hoàn toàn không được may đo cho project của anh. "Thật sự hay", anh nói.

8. Backlog tự sinh và xem lại những gì vừa build

Anh khởi động lại Claude Code để nó nạp các agent mới, rồi định chạy /factory next. Nhưng anh tự hỏi: chạy factory next thì sẽ làm gì? Anh nghĩ mình chưa có gì trong hàng đợi, tức chưa có feature nào đang chờ build, nên chắc lệnh đó không chạy được. Thứ anh muốn là chạy factory rồi mô tả feature cần build, và nhờ Claude dựng luôn dashboard.

Câu trả lời làm anh bất ngờ: backlog thực ra đã có sẵn ba mục khởi đầu. Opus đã tự tìm ra anh nên build gì tiếp theo. "Buồn cười thật", anh nói. Dashboard cũng đã chạy, nhưng chưa có gì: mọi cột đều trống.

Trước khi chạy thử, anh cho xem chính xác những gì vừa được build. Anh mở LazyGit trong project để xem mọi thay đổi.

• Các agent. Một loạt subagent, những thứ làm việc bên trong factory: approval agent, builder agent, các reviewer agent.
• Skill. Với anh, đây là thứ chính điều khiển factory: agent skill dùng để khởi động nó. Về thực chất, đó là orchestrator skill.
• Thư mục factory. Chỉ có rất ít code: một file backlog.md để theo dõi các job, tức những thứ chưa build mà muốn build sau, và một dashboard cho observability (đã thấy ở trên).
• Vài chỉnh sửa nhỏ trong file AGENTS.md, cộng thêm .gitignore cho một số thứ.

"Chỉ vậy thôi các bạn", anh nói. Anh mở thêm trong Vim: về cơ bản đây là factory, đây là orchestration skill, nó ghi lại các cách khác nhau để dùng.

9. Skill /factory và job đầu tiên trên website production

Trong skill có lệnh /factory kèm feature. Bên trong Claude, nếu gõ dấu gạch chéo rồi gõ "factory", skill hiện ra ngay: nó đã được Claude Code index, và anh gọi trực tiếp được. Trong danh sách skill, tìm "factory" cũng thấy. Đó là một project skill, chỉ dành cho project này, vì nó nằm trong thư mục .claude/skills.

Quay lại mind map, giờ đang ở bước chạy factory. Feature anh muốn build: các trang khoá học "Obsidian agent setup" của anh không nên bị paywall, chỉ video mới bị paywall. Anh muốn xem factory có xử lý được feature này trên website thật hay không. Đây là site production của anh.

/factory my obsidian agent setup course pages should not be paywalled (ONLY the videos are paywalled)

Job không chạy. Điều kiện tiên quyết đầu tiên của factory là working tree phải sạch, mà anh chưa commit chỗ code vừa sinh ra. Anh tự commit, "kiểu cổ điển", với message "Add Claude Code Software Factory", rồi push. Sau đó anh clear phiên và chạy lại /factory với feature trên.

10. Spec, build, bốn review chạy song song trên dashboard

Factory tạo job "Obsidian Course Unpaywall", và bắt đầu dùng subagent. Cái đầu tiên: tạo spec bằng spec writer chạy dạng background agent. Anh nhảy vào xem chính subagent đó đang làm gì: nó đang viết spec. Rồi spec xong, đã ghi ra một file spec, và builder vừa bắt đầu làm.

Quay lại orchestrator để xem chuyện gì đã xảy ra: subagent xong việc, orchestrator nhận kết quả rồi mở builder. Builder giờ là subagent đang build feature. Anh mở dashboard của software factory: builder đang sửa code. "Rất hay", vì bạn hoàn toàn có thể hình dung mình làm việc khác cùng lúc. Anh chỉ ra dashboard còn có một cột "needs human": job nào kẹt ở đó nghĩa là cần người review. Tức dashboard này dùng được thật trong công việc.

Builder vừa ghi một file build vào thư mục factory. Quay lại main: orchestrator chuyển sang review và kích hoạt toàn bộ review subagent, những agent đại diện cho khâu review của factory.

Round UX xong, round UI xong, cả hai đều pass. Security vẫn đang cân nhắc, rồi cũng xong. Rồi tới code review. "Đỉnh thật", anh nói. Trên dashboard còn thấy được cả các icon nhỏ, và anh thấy thế là "quá ngầu". Giờ agent đang quyết định có kéo feature này vào hay không. Anh nói mình thật sự choáng: đây là cách anh muốn phát triển feature từ giờ, và tự hỏi sao mình chưa làm thế này sớm hơn.

11. Approver escalate, human review và /factory approve

Opus đang quyết định gì? Escalate. Nó đang escalate, nên anh đoán job sẽ sang human review. Đúng vậy: job nằm ở pha human review, và giờ anh phải duyệt. Bấm vào card trên dashboard, anh xem được đủ loại thông tin. Lý do escalate: build sạch, mọi acceptance criteria đều đạt, và có hai câu hỏi dành cho người.

Để duyệt, anh cần biết ID của feature rồi chạy factory approve. Anh làm trong một phiên mới: clear, rồi gõ lệnh approve kèm ID.

/factory approve 001-obsidian-course-unpaywall

Xong. Nó đã merge vào code thật của anh. Kiểm tra lại: trong source code, git status báo đang đi trước bốn commit, vì anh vừa commit cái này. Có một commit merge "Merge factory/001-obsidian-course-unpaywall", là thứ agent làm. Xem các commit trước đó: agent đã tách ra một branch, làm vài commit, build feature, rồi merge ngược lại. Và lần merge đó chỉ xảy ra khi anh approve. "Rất ngầu."

Anh muốn nhấn mạnh một điều. Khi gõ factory approve, thứ thực sự xảy ra là: anh có một agent skill tên factory, chạy lệnh là kích hoạt skill đó. Mọi thứ phía sau chỉ là chữ tự do (free form). Đó không phải một schema hay một spec chặt chẽ cho chữ "approve".

12. Metadata nằm trong file markdown, và chuyện .gitignore

Anh cho xem metadata của hệ thống nằm ở đâu. Chính metadata này đổ dữ liệu vào mọi thông tin trên dashboard. Chúng chỉ là file markdown trong project: vào thư mục factory, xem mọi file bên trong, có thư mục của feature vừa build, và tất cả các file đó là metadata hiển thị trên dashboard.

Anh rất thích sự đơn giản này. Anh có thể tự mở trong Vim để review. Agent dùng được, các agent sau này dùng được, các hệ thống khác cũng dùng được. "Với tôi thế này là quá hay."

Điều duy nhất anh lưu ý: có lẽ ta không muốn commit hết những thứ này vào Git. Tất nhiên chúng chỉ là file text, commit hết cũng chẳng sai gì; nhưng chúng có thể làm rối fuzzy search khi bạn bắt đầu tìm file. Đây là thứ bạn tự quyết. Phần anh, anh không muốn commit chúng. Mở .gitignore ra thì thấy thư mục factory không được commit: Claude đã tự quyết như vậy.

Nghĩa là các file này là tạm thời (transient), sẽ mất nếu bạn clone lại repo ở chỗ khác, trừ khi sao lưu bằng một quy trình riêng. Và đó chính xác là điều anh sẽ làm: đẩy chúng lên một cloud storage nào đó và để agent quản lý việc đó. Anh nói ai muốn tìm hiểu thêm thì có thể hỏi trong cộng đồng Skool hoặc các buổi gọi hằng tuần của anh, nơi anh nói về chuyện này thường xuyên. Đây là cách các developer đang build với coding agent bây giờ.

13. Thêm git worktree để chạy nhiều feature cùng lúc

Nói tới build với coding agent, anh tiếp tục phát triển factory bằng Claude Code. Điều anh muốn là chạy được nhiều thứ qua software factory cùng một lúc. Hiện tại thì không ổn lắm, vì chưa dùng git worktree. Anh nhờ Claude: hãy xem software factory của tôi, tôi muốn chạy nhiều feature qua factory cùng lúc, và để làm được, tôi nghĩ cần tích hợp git worktree.

Tới đây anh chợt nhận ra: lẽ ra anh đã có thể dùng chính software factory để build tính năng này cho nó. "Như thế thì quá đỉnh." Dù sao thì việc đã xong. Anh mở phiên mới.

Build những feature nào? Anh mở backlog trong factory:

• Hiện thời gian đọc ước tính cạnh ngày đăng trên trang blog post. "Okay, làm cái đó."
• Thêm nút copy cho các code block. "Được, làm luôn."
• Thêm trang 404. "Tuyệt."

Đây đều là những thứ anh nên có trên site từ lâu. Anh thấy thật điên rồ khi Opus tự nghĩ ra chúng ngay trong lúc build; những chuyện như vậy lúc nào cũng làm anh choáng. Anh chạy /factory next. Mục đích ở đây là chạy nhiều job song song, và job này vừa được đánh dấu nhận.

Anh mở một phiên mới phía dưới, trong các vùng tmux riêng để theo dõi tất cả cùng lúc, khởi động Claude và gõ factory next. Ở agent phía trên, việc viết spec đã bắt đầu. Phía dưới thì sao? Đây rồi: hai feature mới đã vào factory. "Thêm cái thứ ba nữa, sao không?"

14. Orchestrator Sonnet effort low, và vì sao nên tự build factory

Anh lưu ý: orchestrator chính là agent nào mình khởi động trong phiên đó. Ở phiên trên là Claude Opus 5.5. Cho vui, phiên này anh đổi sang Sonnet 5.5 và thử đặt effort low, "sao không, thử xem". Chạy factory next: đây là feature cuối cùng còn lại, trang 404. Sonnet sẽ rất nhanh, nên anh đoán feature này có thể xong sớm.

Mặt khác, orchestrator không nhất thiết là agent quyết định tốc độ. Thứ giới hạn là các subagent. Lúc này đang ở pha spec writer, và phiên Sonnet này vẫn bị giới hạn bởi tốc độ của subagent, vốn vẫn chạy Opus. Thật ra có thể dùng một model nhỏ để làm orchestrator. Nhưng anh không nghĩ vậy: trực giác của anh là cần một model thật thông minh làm orchestrator, còn một số subagent có thể dùng model thấp hơn, nhanh hơn, kém hơn. Đó là cách anh tiếp cận software factory của mình.

Dù vậy Sonnet "đang bay": đã tới pha builder. "Như một cuộc đua vậy." Và tất cả chạy với git worktree mà anh chẳng phải lo gì, chẳng phải tự loay hoay chuyển qua lại giữa các worktree.

Anh nhấn mạnh thêm: chính chúng ta vừa build cái này. Đây là thứ của riêng bạn, bạn vừa build nó, bạn sửa được, muốn làm gì cũng được. Bạn không phụ thuộc vào cái factory skill của một ai đó đang được tung hô, bạn tình cờ thấy, và nó làm cả triệu thứ. Đây là một skill rất đơn giản cho software factory của riêng bạn, bạn biết chính xác nó chạy thế nào, và khi muốn đổi, bạn biết cách đổi. Anh nghĩ điều này cực kỳ quan trọng, và nhiều người đang hoàn toàn bỏ lỡ điểm này: chạy theo những thứ lớn, star mọi thứ trên GitHub, nghĩ rằng mình phải theo kịp và phải thử hết. Thực ra điều cần làm là hiểu các khái niệm cốt lõi, hiểu cách dùng coding agent để làm những điều mọi người đang hào hứng, rồi làm cho nó chạy cho mình để có năng suất thật.

Và anh cho rằng thứ anh vừa làm là năng suất thật: anh đang xem ba agent nghiền qua các feature trên website của mình, làm việc trong software factory của chúng. "Thế giới chúng ta đang sống thật là..."

Agent Sonnet đã sang review và kích hoạt tất cả các review. Theo anh, đây có lẽ là phần UI anh thích nhất: xem kết quả review lần lượt đổ về. Feature thời gian đọc blog cũng đang được đẩy qua. Feature này có phần UI và UX, trong khi các feature kia thì không nhiều, nên anh tò mò liệu nó có bị từ chối không. Anh nghi là không, vì đã dùng Opus để build. Điều sẽ khá điên là thử một agent "thật ngốc" làm builder, rồi để Opus liên tục sửa và chấm điểm agent ngốc đó. Theo anh như thế sẽ khá vui.

15. Needs-human vì main không sạch: sửa bước merge

Job 404 rơi vào needs human. Anh có cảm giác sẽ phải nới guardrail: như mọi thứ khác, Claude sẽ tìm ra lý do nào đó để bắt anh xem lại. Đó là chỗ có thể cải tiến factory, cho nó hiệu quả hơn. Approver agent chạy khá lâu, rồi job thời gian đọc blog cũng needs human.

Với job thời gian đọc, lý do là chính đáng: Claude không muốn làm mất hiệu lực cache render blog của anh, và việc đó sẽ tốn chút thời gian khi merge feature này. "Hợp lý." Còn job 404 thì anh hơi bối rối: có vẻ đã được approve, nhưng không có gì dành cho người, mà vẫn cần người quyết. Anh hỏi lý do vì sao nó không tự approve và merge. Câu trả lời: merge chỉ chạy khi main checkout sạch, mà trên main đang có thay đổi, nên merge thất bại.

Anh nhận xét software factory đang "hơi ngốc": thay đổi nằm ở backlog nên không commit được, mà những thay đổi đó là điều tất yếu mỗi lần dùng software factory, nên lẽ ra không được chặn merge. Anh nhờ Sonnet sửa. Anh nói thật là hơi tiếc khi đang nhờ Sonnet làm việc này: Sonnet chắc chắn đủ khả năng, nhưng anh muốn dùng agent tốt nhất của mình để làm việc trên factory, vì đó là thứ quan trọng nhất trong code base của anh.

Bản sửa ghi rõ file này được phép có thay đổi. "Hay", và anh hy vọng lần sau sẽ chạy đúng. Giờ anh có hai thứ cần duyệt. Có lệnh factory approve, nhưng anh cũng có thể chỉ nói "okay, merge vào đi". Anh thừa nhận nếu nói thật lòng, đó là cách anh sẽ làm. Nhưng ý tưởng của factory là đầu vào đến từ những thứ anh không điều khiển: không nhất thiết là anh khởi động agent trong software factory, nó có thể bắt đầu từ các trigger khác. Anh sẽ nói thêm về điều đó trong phần kết.

Anh merge xong. Metadata đã cập nhật, và thấy được job đã merge. Trong khi đó, một job khác vẫn đang chạy: thêm nút copy cho code block, có lẽ là một feature hơi khó. Rồi một chuyện buồn cười: job này không merge được vì chính những thay đổi anh vừa nhờ Sonnet làm. Anh bảo Claude cập nhật và commit, commit riêng những thay đổi đó, rồi merge job này vào. Anh vấp lời một chút và đùa: "Opus làm tôi nói không nên lời." Xong. "Thật đẹp."

16. Bước tiếp theo: GitHub issues, Sentry, metrics hạ tầng

Anh quay về mind map để kết thúc, nhìn xem có thể làm gì tiếp cho factory. Có bốn việc có thể làm ngay để software factory cơ bản này chạy tốt hơn, hiệu quả hơn.

1. Git worktree. Việc đầu tiên đã làm: thêm hỗ trợ git worktree để chạy nhiều job song song, và vừa demo xong. "Đỉnh, đúng không?"
2. GitHub issues làm đầu vào, hoặc nguồn khác. Ví dụ có thể kích hoạt từ Slack. GitHub issues là một cách rất hay, vì issue có thể do nhiều người khác nhau gửi, được theo dõi trong GitHub, và tích hợp tự nhiên với GitHub. Anh thấy nhiều người làm vậy, có nhiều video trên YouTube về chuyện đó. Có thể dễ dàng mở rộng hệ thống để dùng nó làm nguồn đầu vào.
3. Kết nối application metrics. Ví dụ kết nối Sentry, một nền tảng giám sát ứng dụng. Khi đó có thể kéo trực tiếp bug từ app đang chạy production vào software factory, để có context liên quan tới feature đang đẩy qua. Anh coi điều này là cực kỳ quan trọng với software factory. Nó gợi lại chính các ý tưởng ban đầu về software factory từ thập niên 60 đã nói ở đầu video: muốn có quyền truy cập vào giám sát và số đo.
4. Metrics hạ tầng như CPU và memory. Lý do là để theo dõi mọi thứ sau khi deploy. Software factory có thể lo luôn cả phần sau deploy và tiếp tục theo dõi: nếu build một feature làm hỏng phần mềm, có thể hoàn tác nó ngay trong software factory. Nó vẫn có thể nằm trong vòng lặp sau khi đã phát hành; việc chưa xong khi đã đẩy lên production.

"Đây là tương lai chúng ta đang đi tới. Đây là tương lai chúng ta đã ở trong rồi." Anh nói mình nổi da gà khi nói ra câu đó.

17. Chi phí token và lời kết

Anh cảm ơn Anthropic đã tài trợ video, và hy vọng người xem đã làm theo trong lúc xem và giờ đã có software factory của riêng mình cho project của mình.

Rồi anh nêu vài điều nên cân nhắc mà video chưa nói tới. Điều đầu tiên, "con voi trong phòng", là chi phí. Anh nghĩ hệ thống này có lẽ đang build ra những feature rất tốt cho anh. Observability tốt: anh vào được từng subagent, xem được log. Về dữ liệu và chất lượng, anh thấy nó rất tốt, hạng nhất. Nhưng nó sẽ tốn tiền hơn, không có cách nào tránh. Mỗi khi dùng subagent là có thể phát sinh chi phí thêm, vì agent phải truyền context qua lại.

Vậy câu hỏi là: chi phí token này có đáng với chất lượng không? Toàn bộ những gì trong video đều chạy trên gói (plan) Claude của anh; anh không dùng API token cho bất cứ thứ gì. Đó là điều cần cân nhắc, và anh nghĩ nó có lợi rất lớn.

Đó là vài điều cân nhắc. Dù vậy, đây chắc chắn là điều anh sẽ làm: anh sẽ build thêm nhiều hệ thống như thế này. Anh kết thúc video ở đây, nói rằng sẽ tiếp tục build những thứ tương tự và có thêm vài video về Claude Code sắp ra. Ai muốn xem chủ đề gì thì để lại bình luận. Anh cảm ơn mọi người đã xem và chào tạm biệt.