What Is a Software Factory and How to Build One in 20 Minutes

1. Từ 1968 tới định nghĩa software factory hôm nay

Victor mở phần định nghĩa bằng một mốc lịch sử: năm 1968, khi cụm từ "software factory" lần đầu được dùng. Anh nhấn mạnh 1968 là một thời điểm rất, rất xa: đó là năm The Beatles ra White Album. Và điều người ta nói tới khi dùng chữ software factory hồi đó khác hoàn toàn với thứ chúng ta gọi là software factory bây giờ, hai thứ gần như chẳng liên quan gì tới nhau. Nên ai bảo "chúng tôi đã nghĩ về chuyện này nửa thế kỷ rồi" thì, theo lời anh, không hẳn là nói dối, nhưng cũng là đang "bịa ra" cho câu chuyện nghe có bề dày.

Định nghĩa software factory mà mọi người đang dùng hôm nay, cái bạn thấy trên Twitter, mới chỉ tồn tại khoảng một năm. Nó xuất hiện vào cuối năm 2025, khi cộng đồng cuối cùng cũng bắt đầu nói về "cái thứ đó". Định nghĩa rất gọn: software factory là một quy trình (process) tự sản xuất phần mềm cho bạn, phần lớn là tự động, dùng AI, dùng agent.

Định nghĩa software factory kiểu "cuối 2025": một process nhận việc và tự sản xuất phần mềm, phần lớn tự động, bằng agent. Định nghĩa thì đơn giản; phần khó là con người đứng ở đâu trong process đó.

Có định nghĩa rồi, bạn sẽ nghĩ: vậy là rõ ràng, cụ thể, giờ mọi người biết mình đang nói về cái gì. Nhưng không phải vậy. Victor giải thích: là programmer, chúng ta thích có nhiều biến thể của cùng một định nghĩa, một bản "strong" và một bản "weak". Chúng ta làm vậy với mọi thứ. Ví dụ functional programming có dạng strong, còn dạng weak là "tôi cũng làm được kiểu đó bằng JavaScript". Software factory cũng thế.

2. Strong form và weak form

Strong form của software factory là con người gần như không tham gia vào implementation. Bạn bật factory lên, nó sản xuất phần mềm chất lượng cao cho bạn, còn bạn chỉ định hướng từ xa, giống một stakeholder. Bạn không review design, không làm architecture; factory lo hết.

Weak form thì con người có tham gia. Con người đưa ra design, nhìn vào mọi thứ, xác định điều gì cần xảy ra. Đại khái như vậy rồi gửi sang phần implementation, tức là vào factory. Factory làm phần việc của nó, sau đó con người review để chắc chắn design còn nguyên vẹn và implementation khớp với design.

Slide Strong and weak forms — Slide "Strong and weak forms". Strong: con người không tham gia implementation, chuỗi chỉ là Human request, Factory, Software. Weak: con người tham gia implementation, chuỗi là Human design, Agent implementation, Human review. Khác biệt nằm ở hai đầu: con người có mặt trước (design) và sau (review) bước agent làm.

Victor nói thẳng: con người sẽ phải review code, dù mình có thích hay không. Phần lớn chúng ta sẽ không đọc hết phần lớn code được sinh ra, nhưng ít nhất phải review được mental model và thấy: nó có gần với điều mình kỳ vọng không, hay sai hoàn toàn? Bước đó bắt buộc phải có.

3. Dark factory và lit factory, và vì sao cần bước design

Hai dạng này khớp rất sát với cách mọi người hay gọi là dark factory và lit factory. Cách gọi "dark factory" đến từ ngành sản xuất: nếu trong nhà kho chỉ có robot chạy qua chạy lại thì bạn không cần nhiều ánh sáng, vì chẳng có ai cần nhìn (xem Dark factory).

Dark software factory về cơ bản là strong form. Lấy việc từ queue. Agent implement nó, tự kiểm tra. Nó tự review, hoặc nhờ một agent khác review, kiểu gì cũng được. Rồi deploy lên production, nhìn vào production xem cái gì hỏng, tự tìm ra nguyên nhân, và đổ feedback từ production ngược lại vào queue.

Slide Dark vs. lit factories, phần Dark — Slide "Dark vs. lit factories", phần Dark: con người không tham gia implementation. Chuỗi Queue, Implement, Auto-checks (tests, scans), Agentic review ("machine grades machine", máy chấm máy), Prod.

Lit factory là weak form. Vẫn có queue, vẫn kéo item từ queue ra. Nhưng sau đó con người quyết định implement thế nào, đặt các guardrail quan trọng, vạch ra cấu trúc tổng thể của thay đổi. Rồi implementation chạy "trong vùng" của nó, agent tự kiểm tra việc của mình, mọi thứ ổn. Cuối cùng con người quay lại review để chắc chắn mọi thứ không bị sai.

Slide Dark vs. lit factories, đủ hai dòng — Cùng slide, thêm dòng Lit: con người tham gia implementation. Chuỗi Queue, Design + architecture (HUMAN), Implement, Auto-checks (tests, scans), Review (agentic + human, HUMAN), Prod. Hai ô tô cam là hai chỗ con người đứng: trước khi implement và trước khi lên prod.

Vì sao phải có stage design?

Victor tự đặt câu hỏi mà khán giả nên hỏi: tại sao cần stage design? Phần review thì dễ hiểu: nếu muốn nắm được chuyện gì đang xảy ra thì phải nhìn vào nó, hỏi agent, xem diagram, có thể đọc code. Nhưng design để làm gì?

Lý do: không có design thì review trở nên cực kỳ đau đớn và khó chịu. Bạn nhìn vào kết quả và thấy nó sai hoàn toàn, bạn bực, và việc review thành ra phí thời gian. Nếu bỏ ra 10 phút cho design, review sẽ dễ chịu hơn nhiều, vì kết quả agent implement ra có khả năng cao hơn là đúng hướng bạn muốn. Nói cách khác, stage design và architecture tồn tại để tiết kiệm thời gian cho bạn ở bước review.

Dark factory là "holy grail", nhưng chưa ai anh biết làm được

Dark factory là chén thánh. Ai cũng muốn nó chạy được. Nó mà chạy thì tuyệt: bạn bật lên rồi ngồi đó, bàn chuyện... Victor đùa rằng riêng giới kỹ sư thì có lẽ sẽ "toang", nhưng xét cả xã hội thì nó sẽ mở ra rất nhiều năng suất. Ý tưởng rất hay.

Nhưng anh nói thật: anh không biết một người nào, quen biết trực tiếp, làm được nó cho việc thật, không phải một project phụ kiểu PKM (personal knowledge management) để chơi, mà cho thứ thật sự ship lên production. Không một người anh quen trực tiếp. Không một người anh follow. Anh tin là ở đâu đó có người làm được, nhưng với đại đa số người trên đại đa số project, nó không chạy. Còn lit factory thì chạy được: nó chạy cho chính anh, chạy cho những người anh biết. Nên talk này sẽ ủng hộ lit factory.

4. Vì sao chọn lit factory: comprehension debt và mental model

Vì sao dark factory, hay strong form, không chạy? Vấn đề chính là comprehension debt, một thuật ngữ mà Victor nghĩ là do Addy Osmani đưa ra. Về bản chất: nếu bạn không bao giờ nhìn vào những gì đang diễn ra trong factory, và các thay đổi cứ tự trôi vào, bạn mất khả năng hiểu nó đang làm gì. Bạn đơn giản là không biết. Tới một lúc bạn có một project một triệu dòng mà bạn không hiểu bên trong chạy thế nào. Khi nó hỏng, bạn không làm gì được, vì bạn không có mental model nào về thứ đang chạy bên trong phần mềm đó.

Slide Why build a lit factory — Slide "Why build a lit factory": Comprehension debt. "We can check code. Can we check mental models?" Hình bên phải là một mạng node đã được tick cam (đã check), nhưng chỉ một cụm nhỏ được nối bằng nét liền: code thì kiểm được từng mảnh, còn cách các mảnh ghép với nhau thành một mental model thì không kiểm tĩnh được.

Anh so sánh với trải nghiệm của programmer khoảng 10 năm trước: bạn nhận một file binary đã compile nhưng source code thì thất lạc. Chuyện này đã xảy ra với anh ở vài tổ chức. Bạn chỉ có cái binary, không biết nó làm gì, cứ chọc thử vào nó, tìm workaround để bắt nó làm điều bạn muốn. Nhưng thật ra bạn chỉ đang mò.

Thêm verification có đủ không?

Những người thông minh đang cố sửa vấn đề này cho dark factory bằng cách thêm verification. Họ nói: kệ agent làm gì, nó chọn mental model nào không quan trọng; tôi sẽ thêm các check để xác nhận code có chất lượng cao; tôi không cần hiểu hệ thống, tôi tin rằng bất cứ thứ gì được sinh ra đều có thể kiểm chứng là chất lượng cao bằng cách nào đó.

Victor cho rằng đó là nỗ lực tốt. Chúng ta cần đảm bảo thứ mình sản xuất ra có chất lượng cao và maintainable. Các model hiện nay không được train để làm điều đó, vì rất khó train cho maintainability: reward function cho nó rất khó định nghĩa. Nên đó là một nỗ lực có giá trị.

Vấn đề là khi dùng nó để "chữa" cả dark factory: cái dở của code do AI viết không nằm ở chỗ function quá dài. Đó không phải vấn đề chính. Cũng không phải cyclomatic complexity quá cao, "chẳng ai quan tâm". Vấn đề chính là AI thường tự chọn một mental model của riêng nó rồi kiên định đi theo nó tới cùng. Kết quả là code over-engineered, giòn, và cuối cùng sụp.

Chuyện này rất dễ sửa nếu bạn là một phần của quy trình: bạn nhìn vào và nói "mental model này sai rồi, dùng cái kia". Mất năm phút. Nhưng nó rất khó validate theo kiểu tĩnh. Chất lượng của một mental model rất khó đo, vì nếu model tạo ra được một mental model tốt thì nó đã làm vậy ngay từ đầu rồi; và bản thân LLM còn chật vật với khái niệm mental model. Nên hiện tại chúng ta chưa sửa được vấn đề này. Đó là lý do lúc này Victor chọn lit factory.

5. Product hay workflow

Còn một cách phân biệt thứ hai giữa các factory: factory là một product hay một workflow.

Product là một phần mềm bạn mua, giống như bạn mua một issue tracker hay một hệ thống CI: bạn cài vào, và nó thay thế một hệ thống nào đó bạn đang có. Có thể nó thay luôn issue tracker, hoặc là một "công thức factory" đóng gói sẵn. Workflow thì khác: đó là một lớp keo nối các hệ thống bạn đã có sẵn lại với nhau, để trải nghiệm factory chạy được.

Slide Product vs. workflow — Slide "Product vs. workflow". Product: một chiếc hộp chứa Issues, Documents, Agents, tức là "owns issues, documents, and agent execution", sở hữu luôn issue, tài liệu và việc chạy agent. Workflow: Issues, Documents, Agents đứng riêng, cùng thả việc xuống một băng chuyền, tức là "connects the systems you already use".

Victor tin rằng rồi sẽ có nhiều người tìm ra cách build product. Chuyện đó sẽ xảy ra: sẽ xuất hiện những product hữu ích cho nhiều người, mang lại trải nghiệm kiểu factory. Nhưng nó khó hơn vẻ ngoài, vì gần như không thứ gì trong các hệ thống bạn đang có là dễ thay. Bạn không dễ gì thay hệ thống VCS; đó là một bài toán rất, rất khó. Bạn không thay được hệ thống CI; CI cũng là bài toán rất, rất khó. Tất cả những thứ này đều khó.

Nên không dễ để ai đó bước vào và nói "để chúng tôi sửa một phần lõi trong stack của bạn". Mỗi phần trong stack hiện tại có mặt ở đó vì một lý do, và đều là những domain rất khó để implement. Bạn không thể tráo một thứ khó như vậy. Thứ bạn làm được là cung cấp một lớp nằm bên trên.

Và lớp đó lại rất dễ làm. Một người có thể build nó, như sẽ thấy trong talk, trong một giờ; cùng lắm, ở quy mô lớn nhất, trong một tháng. Nhưng một product mà một người build được trong một tháng thì rất khó bán, vì product phải giải một bài toán khó ở đâu đó, còn lớp này thì không nhất thiết là bài toán khó. Vì vậy hiện tại workflow thực tế hơn nhiều cho công việc hằng ngày. Bạn có thể bắt đầu bằng một workflow, có trải nghiệm kiểu factory, thấy được giá trị. Rồi tới lúc nào đó một product xuất hiện, tuyệt, bạn dùng nó.

6. Xây lit factory như một workflow: bắt đầu từ workflow Design

Vậy hôm nay chúng ta build một lit factory dưới dạng workflow. Victor tự nhận nghe thì "đã thấy chán": nó không làm gì kỳ diệu, bạn vẫn phải tham gia, nó chỉ là một script. "How cool is that? Không cool lắm." Nhưng nó sẽ mang lại cho bạn rất nhiều.

Slide We are building a lit factory as a workflow — Slide chốt phần định nghĩa: "We are building a lit factory as a workflow. Building a system that helps you build systems." Hai lựa chọn của talk: lit (có người trong vòng) thay vì dark, và workflow (nối hệ thống có sẵn) thay vì product.

Và thật ra nó chẳng khác gì điều programmer vẫn luôn làm. Chúng ta thích build hệ thống giúp mình build hệ thống. Thích tới mức nhiều khi chẳng build hệ thống thật nào: dành hàng tuần tối ưu bộ toolkit của mình. Rồi tới một lúc bộ toolkit đó được thả ra thế giới thật và tạo ra giá trị kinh doanh. Chúng ta rất thích làm việc đó. Software factory cũng vậy, chỉ tham vọng hơn một chút. Thế thôi.

Cách làm: viết ra từng bước của workflow

Làm thế nào? Victor nói anh đã trễ giờ, "điên thật". Cách làm: nhìn vào các workflow mình muốn tự động hoá, viết ra từng bước một của workflow đó, rồi xem tự động hoá từng bước thế nào. Không khó.

Anh cho xem cách anh làm việc. Bạn có thể làm khác, nhưng anh đoán cũng tương tự. Công việc của anh gồm ba workflow: Design, Implement, Review.

Design. Anh đi tìm việc cần design: vào Linear, xem issue nào cần design, rồi design nó. Anh "get debriefed", tức là đọc issue trong Linear, tìm trong Slack, Notion, nói chuyện với các programmer, và phần lớn là nói chuyện với một agent, để hình thành hiểu biết về việc cần làm. Về cơ bản anh tạo ra phần prior work cộng với các design concern. Ai từng viết design doc ở Google hay công ty tương tự đều biết: luôn phải có phần prior work. Rồi anh set up environment và design. Anh design bằng cách nói chuyện với agent, vẽ hình, đưa hình cho agent xem, và hai bên cùng đi tới một cách hiểu để giải bài toán.

Workflow Design theo mô tả của Victor (không có ảnh slide riêng): tìm việc trên Linear, debrief từ Linear, Slack, Notion và các programmer, dựng môi trường, rồi design bằng cách trò chuyện và vẽ hình cùng agent.

7. Workflow Implement và Review, và vì sao đó vẫn chưa phải factory

Implement. Phần đầu giống hệt. Anh lấy design, đưa cho agent implement, tự mình review, và khi review xong, hài lòng với kết quả, anh sai agent: "open PR, làm cho CI xanh". Sau đó anh ghi thông tin vào một hệ thống lưu trữ (system of record) nào đó và cập nhật issue tracker.

Slide Implement workflow — Slide "Implement" (Design, Implement, Review, đang ở Implement). Tám bước: 01 Find work (Human), 02 Get design (Human / agent), 03 Set up repos (Human), 04 Implement (Human / agent), 05 Review (Human), 06 Open PRs (Human / agent), 07 Record (Human / agent), 08 Complete (Human). Gần như bước nào cũng có agent, nhưng bước nào cũng do người khởi động.

Review. Review thì khác một chút, và Victor nói quy trình review của anh có lẽ khác của bạn. Đầu tiên vẫn vậy: tìm việc, xem cần review cái gì. Anh lấy về PR và session đã tạo ra PR đó. Anh set up repo ở máy mình, đưa các agent đã tạo PR chạy lại trên máy, để có memory của chúng, có trace của chúng, và anh có thể "phỏng vấn" agent.

Khi review anh không muốn nhìn vào code, vì anh quan tâm tới mental model hơn. Anh vẫn nhìn code, nhưng thứ anh quan tâm là mental model. Nên anh cần nói chuyện với agent đã viết ra nó: hỏi câu hỏi, vẽ vài diagram, và khi hài lòng với review thì gửi feedback. Thế là xong.

Slide Review workflow — Slide "Review": 01 Find work (Human), 02 Get PRs and sessions (Human / agent), 03 Set up repos (Human), 04 Set up agents (Human / agent), 05 Adversarial review (Agent), 06 Human review (Human), 07 Submit feedback (Human), 08 Complete (Human). Điểm lạ so với review thông thường: lấy cả session, dựng lại agent, và cho một agent review kiểu adversarial trước khi người vào.

Vì sao đây chưa phải factory

Victor chỉ ra: gần như mọi bước ở đây đều có agent. Anh không làm tay, anh nhờ agent giúp. Nhưng đây vẫn chưa phải factory, vì anh vẫn là người điều phối. Anh là người đi tới và nói "được, agent sẽ giúp tôi gần như mọi mục ở đây, nhưng tôi là người bảo agent làm". Nếu bạn đang làm như vậy, dùng các tool điều phối nhiều agent hay gì đó (Victor nói bản thân anh không dùng), bạn mở một tab mới, nói "làm cái này đi", rồi tự dẫn dắt cả quy trình. Bạn là orchestrator. Bạn không có factory.

Thứ bạn cần là inversion of control, đảo ngược quyền điều khiển. Tức là thay vì quy trình được chạy bởi bạn, bạn "reify" (vật hoá) quy trình đó thành một chương trình.

8. Inversion of control: factory chạy quy trình, người như bác sĩ phẫu thuật

Quy trình được vật hoá thành một chương trình, thường được gọi là foreman (người đốc công), hoặc bạn thích gọi gì cũng được. Từ lúc đó quy trình tự chạy, và nó sẽ gọi bạn vào để xin feedback khi cần, ở stage design và các stage khác. Quy trình chạy một mình; bạn không còn phải tự chạy nó nữa.

Slide Inverting the workflow, Human runs the process — Slide "Inverting the workflow", trạng thái trước: "Human runs the process". Một ô Human ở trên, toả mũi tên xuống cả sáu bước Find work, Set up, Design, Implement, Review, Complete: người phải tự khởi động từng bước.

Slide Inverting the workflow, Factory runs the process — Cùng slide, trạng thái sau: "Human runs the process → Factory runs the process". Sáu bước nằm trong một khung tên Foreman, nối tiếp nhau; chỉ Design và Review có mũi tên lên ô Human. Dòng chú thích: "Calls on humans for decisions", factory chỉ gọi người khi cần quyết định.

Ví dụ ca phẫu thuật

Victor ví với bệnh viện. Nếu bạn từng phẫu thuật, bạn sẽ thấy người chuẩn bị bệnh nhân và người dọn dẹp sau ca mổ thường không phải bác sĩ phẫu thuật. Bác sĩ phẫu thuật bước vào vì thời gian của họ quý, làm phần phẫu thuật, rồi đi. Đó chính là điều bạn muốn: trở thành bác sĩ phẫu thuật. Bạn bước vào, mọi thứ đã sẵn sàng, "đây là vấn đề", bạn xử lý, rồi sang issue tiếp theo. Inversion of control mang lại đúng điều đó: bạn trao quyền điều khiển cho hệ thống, để bạn chỉ tham gia ra quyết định vào đúng thời điểm.

Giống strategy pattern và template method pattern

Với những người "lớn tuổi hơn" trong phòng, anh nói điều này giống strategy pattern hay template method pattern trong sách của Gang of Four: framework định nghĩa các bước, và ở một điểm cụ thể trong luồng thì nó gọi code của bạn để tuỳ biến hành vi. Ở đây cũng vậy: foreman giữ khung quy trình, và ở những điểm cần quyết định thì nó gọi con người. Victor còn chơi chữ, gọi foreman là một "generative factory method", vừa ăn theo tên pattern factory method của Gang of Four, vừa gắn với chữ "generative" của AI, đúng chủ đề software factory của cả talk.

Từ 30, 40 phút xuống còn khoảng 15 phút

Làm như vậy, anh tự động hoá cả quy trình và chỉ phải tham gia ít thời gian hơn nhiều. Ví dụ khi review PR của người khác: anh phải lấy mọi thứ về, set up, chạy vài thứ, dựng workspace, làm adversarial review, nhờ agent sinh vài hình ảnh để hiểu mọi thứ bằng mắt, rồi mới tới phần review của con người. Cả quy trình mất khoảng 30 tới 40 phút cho một PR cỡ như của team anh. Anh không phải dán mắt vào màn hình suốt thời gian đó, nhưng phải tham gia xuyên suốt, phải gửi hướng dẫn.

Nếu đảo ngược quyền điều khiển thì anh chỉ tham gia ở phần human review. Anh bước vào, mọi thứ đã set up xong, hình ảnh đã có, adversarial review đã chạy, anh đưa feedback, rồi đi. Thời gian giảm từ 30, 40 phút xuống khoảng 15 phút. Đó là ý tưởng: khi bạn đảo quyền điều khiển và để agent chạy quy trình, phần tham gia của bạn gọn và hiệu quả hơn nhiều.

9. Tám capability cần có

Vậy làm thế nào? Victor nói thứ này bạn nên làm trên đường về nhà, trên máy bay. Anh "rất khuyên" làm trên máy bay, vì khi đó bạn có một ly rượu vang, tuyệt vời. Và đây là những thứ bạn cần:

VCS hoạt động được theo kiểu agentic: cần một cách để clone repo, tạo worktree, gửi PR, v.v.
CI, cũng phải chạy được theo kiểu agentic, vì toàn bộ ý nghĩa của factory là nó sẽ tự làm CI xanh; bạn phải hỏi được trạng thái của mọi thứ.
Work queue: một dạng hàng đợi cho biết cần làm gì. Issue tracker là cách dễ nhất, nhưng nếu làm cho riêng mình ở máy local thì có thể chỉ là một document.
Institutional memory: đây là thứ then chốt. Không có nó, bạn "toang". Institutional memory là cách để trích xuất thông tin về tổ chức và project của bạn: nối Slack, Notion, hoặc thứ gì khác. Nó cho agent hiểu các giới hạn mà nó được làm việc trong đó, để bạn không phải giải thích đi giải thích lại.
Ephemeral workspaces: cách dựng một môi trường tạm để việc chạy trong đó (worktree, sandbox).
Cross-repo orchestration: điều phối nhiều repo, cần cho tổ chức lớn, vì rất nhiều thay đổi đòi hỏi nhiều hơn một repository.
Durable sessions: cách để bạn bắt đầu làm trên một máy, gửi cho người khác trên máy khác, và họ tiếp tục công việc bằng chính session của bạn. Về cơ bản là một session được vật hoá, chuyển nhượng được.
Factory metadata: về cơ bản là một thư mục các file markdown mà bạn check in, v.v.

Slide We will need — Slide "We will need" (phần 03, Implementing workflows as a lit factory): VCS · CI · Work queue (Issue tracker) · Institutional memory (Slack, Notion) · Ephemeral workspaces (Worktrees, sandboxes) · Cross-repo orchestration · Durable sessions · Factory metadata.

10. Thứ đi giữa các stage là session, không phải document hay PR

Có đủ những thứ trên, bạn sẽ thấy mỗi bước trong flow đều dùng tới các capability này: design, implement, review. Victor nói anh sẽ không đi qua từng bước, bạn sẽ tự tìm ra capability nào dùng ở đâu, dù việc đó cũng không hoàn toàn dễ.

Slide Review workflow gắn icon capability — Slide "Review" ở phần 03: cùng workflow review chín bước (Find work, Get PRs and sessions, Set up repos, Set up agents, Adversarial review, Human review, Submit feedback, Record, Complete), mỗi bước gắn icon capability nó dùng: VCS, Durable sessions, Work queue, Factory metadata, Institutional memory, Ephemeral workspaces. Phía trên là ba thanh Design, Implement, Review nối với nhau bằng chữ "Session".

Điều quan trọng cần để ý là thứ đi từ stage này sang stage kia. Từ design sang implementation không phải là một document. Từ implementation sang review không phải là một PR. Mà là một session. Nếu bạn bắt đầu truyền session đi khắp nơi, trải nghiệm trong flow sẽ có chất lượng cao hơn nhiều.

Vì nếu chỉ truyền một PR sang bước review, bạn không thể review nó chất lượng cao theo kiểu agentic: bạn đang nhìn code, và phải tự đoán ra mental model mà người viết đã dùng. Rất khó. Thứ bạn thật sự muốn là session của agent đã tạo ra code, để bạn nói chuyện với nó và tìm hiểu: mục đích là gì, nó đã cân nhắc những gì. Không thì bạn "toang". Vậy bạn cần một cách để đóng gói session và gửi đi. Anh sẽ cho xem một cách, nhưng có rất nhiều cách.

Slide Design, implement, review nối bằng session — Slide "Design, implement, review": ba khối Design, Implement, Review nối bằng mũi tên "Session". Dòng dưới: "Sessions carry the context between workflows", session mang context đi giữa các workflow.

11. Stack của Victor: Linear, Notion, Polygraph và factory metadata

Stack của anh: Linear là work queue; Linear, Notion và Polygraph là institutional memory; và một repo nơi anh lưu factory metadata.

Slide Work queue, memory, and metadata — Slide "Work queue, memory, and metadata". WORK QUEUE: Linear. INSTITUTIONAL MEMORY: Linear, Notion, Polygraph. FACTORY METADATA: "A simple repository, added to every session", một repo đơn giản được gắn vào mọi session.

Polygraph là thứ anh dùng trong ví dụ. Anh nói rõ bạn không bắt buộc phải dùng nó. Đây là một meta-harness không phụ thuộc agent nào (agent-agnostic) do team anh build, kiểu một bộ toolkit cho software factory. Mọi phần của stack này bạn đều có thể build mà không cần nó; anh không nói những điều này để bảo bạn dùng Polygraph, bạn dùng gì cũng được. Nhưng bạn sẽ cần những thứ sau, và đây là những gì Polygraph cho anh:

Ephemeral workspaces: một cách tạo môi trường để việc chạy trong đó, cho một hoặc nhiều repo.
Institutional memory: nó đi vào mọi session anh tạo ra, và anh rút insight từ đó để định hướng các session sau này.
Durable sessions: mỗi session anh bắt đầu, anh có thể chuyển cho người khác, họ resume trên máy của họ bằng một agent khác, rồi chuyển lại cho anh. Điều này bắt buộc cho design, implementation và review, vì nhiều khả năng sẽ có nhiều người tham gia. Bạn phải chuyền được session qua lại và làm tiếp.

12. Script 1000 dòng chạy mỗi giờ

Và đây là cấu trúc của script. Toàn bộ script của riêng anh dài khoảng 1000 dòng JS, "một mớ hỗn độn khổng lồ" theo lời anh. Phần lớn script là anh cố trích dữ liệu từ Linear, Notion và Polygraph; đó không phải luồng chính.

Luồng chính rất thẳng. Foreman là một script chạy mỗi giờ một lần trên máy anh. Nó query Linear, lấy các issue được gắn tag khác nhau. Với mỗi issue có tag phù hợp, nó gọi một thủ tục, một thủ tục agentic, nơi agent tự quyết định cách tiến hành. Thủ tục đó tạo bản debrief, gom tất cả hệ thống lại vào một document duy nhất, chuyển cho Polygraph; Polygraph tạo các repo liên quan, chuẩn bị môi trường cho anh; rồi thủ tục cập nhật lại Linear.

Linear trở thành system of record trong trường hợp của anh: nó nhớ trạng thái của mọi issue đang đi qua factory. Anh còn lưu một ít thông tin ở local trong một file JSON. Anh thậm chí không dùng database thật, vì không cần.

Luồng chính của foreman theo mô tả của Victor: script chạy mỗi giờ, lấy issue có tag từ Linear, gọi một thủ tục agentic để debrief và chuẩn bị môi trường qua Polygraph, rồi ghi trạng thái lại vào Linear (system of record) và một file JSON local.

Stage implementation cũng giống vậy: anh lấy session sẵn có, resume session đó với thêm một prompt, nó chạy tiếp, anh cập nhật Linear và lưu thông tin local. Không phần nào phức tạp. Cả script 1000 dòng đó bạn có thể tự viết tay, hoặc để agent viết; mất nửa giờ, rất dễ.

Kết quả là nó chạy nền, mỗi giờ một lần như một cron job trên máy bạn: tìm việc, tạo các thứ cần thiết, dựng môi trường, về cơ bản là "chuẩn bị bệnh nhân". Để rồi bạn cầm con dao mổ, tức là bộ não của bạn, bước vào xử lý, rồi bước ra, vui vẻ vì năng suất và đủ thứ.

13. TUI: nơi con người bước vào đúng lúc

Victor còn build một TUI app, cũng bằng agent. Nó chẳng tốn thời gian gì: bạn có thể "single-shot" nó, vì bạn đã có sẵn một document JSON với schema, bạn biết nó hoạt động thế nào. Điểm hay là bạn tự làm được cho mình đúng thứ mình muốn. Anh thích làm việc trong terminal, và dùng Zellij cho công việc trong terminal, nên TUI làm đúng điều anh cần.

Anh không còn vào Linear nữa. Anh mở TUI và thấy, ví dụ, có ba việc cần design. Các issue ví dụ là về một ứng dụng ngân hàng, vì "ngân hàng thì cool", anh đùa.

TUI của factory với danh sách issue theo stage — TUI của factory (chạy trong Zellij). Nhóm DESIGN 3 "Session prepared, settle the design": BNK-1471 Freeze and unfreeze a card from the mobile app, BNK-1466 Instant payment fallback, BNK-1459 Statement PDF running balance column. IMPLEMENT 2 "Check the PRs and the agent's decisions". REVIEW 3 "Adversarial review done, your call", kèm tóm tắt kết luận adversarial review ở cột phải (Request changes, Approve, Trivial change). IN FACTORY 5 "nothing for you yet". Nửa dưới là bản Debrief của BNK-1471: What is being asked, Prior work (issue liên quan đã ship, trang Notion về vòng đời thẻ).

Khi cần design hay review, rất dễ: anh đi qua danh sách, chọn issue cần làm, bấm phím. Nó mở một session mới cho anh, repo đã sẵn sàng, và anh nói chuyện với agent ngay. Xong việc, anh chỉ việc rời đi. Không có gì anh phải làm để đẩy quy trình tiếp; quy trình tự tiến lên sau đó, vì anh không phải người điều khiển quy trình. Anh chỉ chịu trách nhiệm đưa feedback cho một session vào đúng lúc cần.

TUI mở session của issue BNK-1418 — TUI mở một session cụ thể, BNK-1418 "change a standing order's amount without cancelling it". Bên trái: Goal và "The flow, today and proposed": hôm nay khách phải huỷ lệnh cũ rồi tạo lệnh mới (mất lịch sử và ngày chạy kế tiếp); đề xuất là sửa số tiền tại chỗ (120 → 150), giữ ngày chạy, ghi audit row. Bên phải: kết luận review cho hai PR ở core-banking và mobile-app, "Request changes": sửa tại chỗ là đúng hướng nhưng ghi số tiền mới không có version check, nên có thể race với job chạy đêm; cần optimistic lock trên dòng standing order. Ô dưới cùng: "Continue the session".

Phần cuối cần nói là retrospective, hay self-improvement. Theo Victor, mọi thứ liên quan tới AI đều phải có thành phần self-improvement, "vì nó là như vậy". Và anh nghĩ đó là phần then chốt của câu chuyện factory: bạn có thể tích hợp vài thứ để nó tự tốt lên, rất dễ.

14. Self-improvement: tự động qua institutional memory, và retrospective có độ trễ

Ngầm định: luôn tự tốt lên

Theo một nghĩa, factory luôn tự tốt lên mà bạn không cần làm gì. Vì mỗi session bạn chạy đều cập nhật institutional knowledge: Linear được cập nhật, Notion được cập nhật, và trong trường hợp của anh Polygraph nhớ mọi trace, tạo thành một "ngân hàng tri thức". Việc này tự xảy ra, và sẽ có insight được rút ra từ đó. Session tiếp theo sẽ dùng institutional knowledge đó. Nên self-improvement luôn đang diễn ra, vì institutional knowledge giống một khối tri thức sống, dùng chung cho mọi agent, dù có factory hay không.

Tường minh: sửa chính factory

Nhưng bạn cũng có thể cập nhật nó một cách tường minh. Các factory script, tức "kịch bản" foreman phải chạy thế nào, là một phần độc lập mà bạn có thể cập nhật bằng một quy trình riêng, tách khỏi institutional knowledge.

Cách anh làm: nhìn vào các issue mà factory đã làm xong, nhưng không nhìn ngay lúc đó. Có người làm ngay tại chỗ: issue còn đang chạy mà factory đã rút insight. Anh không tin vào cách đó. Anh nhìn lại từ vài tuần trước: "xem các issue từ hai tuần trước". Hai tuần trước chúng đã hoàn thành và deploy lên production (bạn có thể chọn mốc thời gian hợp với tổ chức của mình). Rồi anh xem chuyện gì đã xảy ra với chúng. Anh xem comment trong PR và trong Linear: có ai nói nó ngớ ngẩn không, có ai nói nó không chạy không? Nhờ session graph mà Polygraph cho anh (bạn không bắt buộc phải có, có thể tìm cách khác), anh xem các issue follow-up: có bug không, có phải làm lại không, những thứ kiểu vậy.

Slide Explicitly: retrospective hai tuần sau — Slide "Explicitly" (How the factory gets better). Một background process: Executed issues, Two weeks later (lịch số 14), Team response gồm Corrections, Follow-up bugs, Product changes, rồi đổ vào Factory metadata (Classify, stop, scope), rồi Next run, và vòng lại Executed issues. Dòng dưới: độ trễ là cách để học từ những gì team đã phải sửa.

Khoảng cách thời gian so với lúc issue hoàn thành cho anh insight hợp lý. Insight bạn thấy sẽ không phải là một evaluation function nói "tôi nghĩ là thế này". Rất nhiều insight sẽ là: nó được deploy lên production và chẳng chạy, hoặc team nói họ không thích. Insight thế giới thật đưa lại có giá trị cao hơn nhiều. Và để thấy insight thế giới thật, bạn phải nhìn lại với một khoảng cách thời gian. Độ trễ là chìa khoá.

Anh so sánh với một shop làm Agile: bạn luôn có retrospective, vào cuối sprint. Chứ không phải đang giữa chừng, bạn vừa đóng ticket thì một scrum master nhảy xổ vào hỏi "có gì sai?". Bạn chờ vài tuần để xem mọi thứ ra sao, rồi khái quát insight thành thứ gì đó hữu ích. Anh rất khuyên làm như vậy.

15. Tự build trên chuyến bay về nhà, và lời kết

Vậy nên làm thế nào? Bạn có thể tự làm, trong 20 phút hay bao lâu cũng được, nhưng trên chuyến bay về nhà thì "100%" được, nó không khó. Các bước:

Start small: bắt đầu nhỏ, chọn một workflow có thể tự động hoá, ví dụ workflow review hoặc workflow design.
Write down the steps: viết ra các bước.
Build a local script: nói chuyện với agent để build một script.
Keep the human checkpoints: giữ nguyên các checkpoint của con người.
Ignore self-improvement at first: lúc đầu bỏ qua self-improvement. Mọi người thích tập trung vào self-improvement vì nó cool, nhưng nó khó làm đúng hơn phần còn lại rất nhiều: self-improvement chiếm khoảng 95% công sức. Phần còn lại thì dễ, như đã thấy.

Slide Build it yourself — Slide "Build it yourself" (phần Retrospective): 01 Start small · 02 Write down the steps · 03 Build a local script · 04 Keep the human checkpoints · 05 Ignore self-improvement at first.

Victor kết thúc: "Đây là tôi. Tên tôi là Victor." Bạn có thể follow anh trên Twitter, tìm hiểu thêm về Polygraph, một meta-harness mà bạn có thể dùng để làm tất cả những điều vừa nói. Anh cũng được biết tới nhiều nhất vì tình yêu với monorepo. Nếu bạn muốn biết về monorepo, vì monorepo rất hợp với agent, hãy nói chuyện với anh, hoặc xem nx.dev, sản phẩm đang có những cải tiến lớn trong vài tuần tới. Cảm ơn mọi người.

Slide cảm ơn của Victor Savkin — Slide cuối: Victor Savkin · X: x.com/victorsavkin · Learn: metaharness.tools · trypolygraph.com (metaharness) · nx.dev (monorepos).