# Software factory thật ra là gì

[Zach Lloyd](https://homus.dev/speakers/zach-lloyd) · [Warp](https://homus.dev/orgs/warp)

> Zach Lloyd giải thích cloud software factory: hạ tầng mở định nghĩa bằng code, factory engineering, scoring, self-improvement và benchmark trên việc thật.

Topics: Software Factory, Coding Agents, Evals, Model Routing

Canonical: https://homus.dev/talks/what-a-software-factory-actually-is

## 1. Zach Lloyd, Warp và nội dung của bài nói

Zach Lloyd mở đầu bằng lời tự giới thiệu: anh là founder của Warp, và video này là một phiên bản ghi lại của bài talk anh vẫn đi trình bày, nói về cách anh nghĩ về software factory và cách Warp nghĩ về chúng. Anh muốn trả lời mấy câu hỏi: theo ý anh, software factory là gì; những đặc điểm quan trọng nhất của nó là gì (Warp coi nó như một loại infrastructure); và một software factory chạy được thật trông ra sao. Anh minh họa nhiều ý bằng sản phẩm thật, cụ thể là Warp Factories, nhưng anh cho rằng các khái niệm này vẫn áp dụng nếu bạn tự xây software factory từ đầu, điều mà theo anh (video đăng ngày 19/10/2026) rất nhiều người đang thử làm.

Về bản thân, Zach kể anh từng là principal engineer ở Google và từng phụ trách engineering cho bộ Google Docs. Anh đã làm software developer từ rất lâu. Slide giới thiệu của anh ghi ba dòng: principal engineer ở Google, lead mảng GDocs; 20 năm làm engineering; founder của Warp.

Hiện tại anh là founder kiêm CEO của Warp (tính đến video đăng ngày 19/10/2026). Với ai chưa biết, Warp là một công ty trong mảng agentic development. Theo Zach, sứ mệnh của Warp từ trước tới giờ vẫn là giúp developer ship phần mềm tốt hơn và nhanh hơn, và toàn bộ sự tập trung của công ty lúc quay video là software factory. Warp có một nền tảng tên Warp Factories, được anh mô tả là open infrastructure cho các công ty muốn xây software factory nội bộ của riêng mình.

Warp cũng khá nổi tiếng với Warp Terminal, một agentic terminal. Theo số Zach đưa ra trong video đăng ngày 19/10/2026, repo có khoảng 65.000 sao trên GitHub và gần một triệu developer đang dùng nó thường xuyên. Anh gọi đó là một sản phẩm rất hay, nhưng hôm nay anh sẽ nói về software factory.

![Slide tiêu đề The Software Factory Stack, Zach Lloyd, Warp](https://homus.dev/photos/x-PK3yx_MJg-0023.jpg)

Slide mở đầu "The Software Factory Stack" với tên Zach Lloyd và logo Warp; Zach nói trong khung hình nhỏ ở góc phải.

## 2. Hành trình của agentic development

Cách Zach thường dẫn vào chủ đề là vẽ lại hành trình của agentic development. Nhìn lại vài năm trước, mọi người dùng những thứ như autocomplete của Cursor, theo anh lúc đó đã rất ấn tượng. Khoảng một năm trước (tính từ video đăng ngày 19/10/2026), cả ngành chuyển sang một chế độ mới: developer nào cũng cài Claude Code hoặc Codex lên laptop và prompt để build tính năng. Nhưng về cơ bản họ vẫn làm việc cục bộ: agent chạy trên máy, tạo một PR rồi đẩy PR đó lên hệ thống.

Điểm đến mà Zach nghĩ cả ngành sẽ đi tới (theo video đăng ngày 19/10/2026), dựa trên việc nói chuyện với rất nhiều công ty và cả cách chính Warp ngày càng làm việc nội bộ, là một thế giới phát triển phần mềm tự động hơn nhiều. Lý do, nhìn từ góc độ kinh doanh, là thế này: có một công nghệ mới gần như phép màu, thật sự đáng kinh ngạc, ai cũng muốn khai thác nó tối đa, và tất cả đang cùng nhau học xem điều đó nghĩa là gì.

![Slide The evolution of agentic development: Chat, Autocomplete, Interactive Prompting, Automated development](https://homus.dev/photos/x-PK3yx_MJg-0143.jpg)

Slide "The evolution of agentic development": một đường cong đi từ Chat, qua Autocomplete, tới Interactive Prompting (nhãn TODAY), rồi Automated development (nhãn NEXT).

Các câu hỏi chung là: triển khai agent thế nào để đạt giá trị kinh doanh cao nhất, để ship những thứ thật sự hữu ích cho khách hàng, và để chắc rằng sản phẩm không cẩu thả, chất lượng không tệ. Zach nói ai cũng muốn làm được điều này, và hẳn phải có một cách làm tốt hơn cách mà mọi người đang làm lúc quay video.

## 3. Ba vấn đề của interactive agent

Đào sâu thêm một tầng, Zach liệt kê (theo video đăng ngày 19/10/2026) các vấn đề mà thế giới đang gặp với interactive agent. Thứ nhất, bạn hoàn toàn bị nghẽn ở con người. Đây là loại phần mềm mà bạn muốn thả ra để nó làm nhiều hơn, nên muốn năng suất cao hơn thì cần tự động hóa nhiều hơn. Thứ hai, interactive agent có đủ loại vấn đề về quản lý chi phí, và rất khó tối ưu chúng một cách tập thể vì mỗi người làm một kiểu. Thứ ba, không có một lớp trung tâm nào để quản trị chúng, nên có đủ loại vấn đề bảo mật.

Trên slide "More AI usage != more business value", ba ý này được viết thành: dùng theo kiểu ad hoc, tương tác, không tự động hóa; không có cách có hệ thống để tối ưu chi phí và chất lượng; không có lớp trung tâm cho governance và control. Bên cạnh là ba tiêu đề báo về cơn sốt tiêu token, về việc doanh nghiệp không kiểm soát AI tốt như họ nghĩ, và về ngân sách AI bị đốt nhanh.

Zach dừng lại một chút ở khía cạnh bảo mật (video đăng ngày 19/10/2026), với slide "Local agents are insecure agents". Khi ai cũng dùng local agent, mỗi người tự cài MCP của riêng mình. Nếu có gì đó bị xâm nhập, nó bị xâm nhập với quyền của chính người dùng đang đăng nhập. Những agent này rất khó quản trị. Theo anh, lời giải nhìn chung sẽ là đưa chúng vào sandbox.

Ba vấn đề Zach nêu với interactive agent chạy trên laptop từng người, và hướng giải anh gợi ý cho vấn đề bảo mật là sandbox.

## 4. Cloud software factory là gì

Điều Zach muốn bàn là cloud software factory là gì. Anh nói nếu bạn theo dõi Twitter thì sẽ thấy rất nhiều phiên bản khác nhau về ý nghĩa của cụm từ này, còn với anh (theo video đăng ngày 19/10/2026) nó có nghĩa rất cụ thể. Đó là một agentic loop, trong đó con người và agent cùng cộng tác. Nó chạy trên cloud: theo anh, không thể có software factory cục bộ, vì bạn không thể để các automation chạy trên laptop của mình. Và điều then chốt nhất: đó là một hệ thống đo được và cải thiện được, để bạn có thể làm cái anh gọi là factory engineering trên nó, nhờ đó thật sự làm hệ thống tốt lên theo thời gian. Anh hứa sẽ nói kỹ hơn về factory engineering ngay sau đó.

Cách một software factory vận hành cơ bản như sau. Ý tưởng đi vào từ nhiều nguồn, có thể là trực tiếp từ một người. Sau đó agent làm một phần việc, có thể là triage hoặc viết spec. Agent có thể kéo con người vào để cùng làm spec. Agent implement. Agent làm code review, và có thể kéo con người vào để review code. Agent làm verification và QA bằng computer use. Agent đi qua CI/CD để ship, rồi làm một phần việc monitoring.

![Sơ đồ vòng lặp A cloud software factory](https://homus.dev/photos/x-PK3yx_MJg-0343.jpg)

Vòng lặp "A cloud software factory": việc bắt đầu từ "New product idea or bug reported", đi qua Triage, Spec, Implement, Verify, Ship, Monitor; con người chen vào ở ba điểm: review spec, review code, review sản phẩm.

Zach nhấn mạnh (video đăng ngày 19/10/2026) vòng lặp này sẽ khác nhau về chi tiết ở mỗi công ty, mỗi team. Nó không phải một khuôn dùng cho tất cả, nhưng một software factory phải hỗ trợ việc dựng các biến thể khác nhau của vòng lặp này. Vòng lặp có thể dành cho vòng đời phần mềm, cũng có thể dành cho vòng đời sản phẩm rộng hơn. Theo anh, đây là thứ bạn muốn có, và là cách bạn nên hình dung về nó.

## 5. Factory là hạ tầng mở, định nghĩa bằng code

Trong video đăng ngày 19/10/2026, Zach nói anh cảm thấy rất chắc chắn rằng cách đúng để nhìn software factory là coi nó như một infrastructure, và infrastructure đó phải linh hoạt ngang GCP hay AWS. Cụ thể, infrastructure đó phải mở: bạn phải đưa được bất kỳ model nào, bất kỳ harness nào vào và dùng trong factory của mình. Nó phải composable, pluggable, rất dễ thích nghi. Theo anh, cách tiếp cận software factory chỉ có thể chạy được ở các công ty có quy mô đáng kể nếu bạn dựng được nó để làm việc với công cụ và hệ thống bạn đang có.

Điều lớn nhất, thứ làm cả ý tưởng này trở nên thật với anh, là software factory phải được định nghĩa bằng code. Bạn khai báo factory của mình thật ra là gì: đây là toàn bộ agent của tôi, MCP của tôi, đây là các repo mà chúng làm việc trên đó, đây là các skill chúng dùng. Và tất cả phải được version.

Một khi làm vậy, bạn mở ra nhiều cơ hội: làm sao test các phiên bản khác nhau của một factory, làm sao để agent tự cải thiện một factory. Zach gọi đây là điểm mấu chốt: nó phải là một hệ thống declarative thực thụ. Slide của anh tóm lại: software factory nên được xây trên một infrastructure stack mở, dễ thích nghi và định nghĩa bằng code.

Ý chính của phần này: khai báo agent, MCP, repo và skill trong code có version, rồi từ đó test, rollback và cho agent cải thiện chính factory.

## 6. AI sovereignty: dữ liệu, compute và inference của bạn

Zach cũng cho rằng AI sovereignty rất quan trọng. Ý anh là: nếu bạn đang xây một factory như vậy, bạn nên thật sự cố giữ toàn bộ dữ liệu đi qua nó trên hệ thống của chính mình. Lý do là dữ liệu đó chính là thứ bạn sẽ dùng để cải thiện agent của mình, và bạn không muốn người khác nắm nó. Nếu bạn coi việc làm ra phần mềm là phần cốt lõi của doanh nghiệp từ nay về sau, thì việc dữ liệu đó nằm trong hệ thống của bạn là điều quan trọng.

Factory phải đủ linh hoạt để chạy trên compute của bạn. Bạn có thể muốn chạy model của riêng mình. Nó phải chạy được với inference gateway của bạn, và phải dùng được bất kỳ model nào trong bất kỳ harness nào. Vì vậy Zach nghĩ (video đăng ngày 19/10/2026) cách tiếp cận mở sẽ thắng ở đây, chứ không phải một giải pháp walled garden của một vendor duy nhất. Slide đi kèm liệt kê bốn dòng: your data, your compute, your inference gateway, any model, any harness.

Bốn dòng trên slide "AI Sovereignty matters": dữ liệu, compute, inference gateway của bạn, và tự do chọn model cùng harness.

## 7. Đo lường thắng cảm tính

Theo video đăng ngày 19/10/2026, Zach nói đây là điều rất quan trọng khi anh nghĩ về software factory. Nếu nhìn Twitter, nơi anh tự nhận là xem quá nhiều, thì vào bất kỳ ngày nào bạn cũng có thể có cảm giác vừa có một harness tốt nhất mới, một model tốt nhất mới. Rất khó biết ai có xung đột lợi ích khi họ nói về những thứ đó. Lời giải theo anh là dựng một hệ thống để bạn tự đo được, trên chính workflow của mình, coding agent đang làm tốt đến đâu.

Cụ thể, theo Zach (video đăng ngày 19/10/2026), là: có eval kiểu LLM as a judge trên mọi session coding agent; dùng các eval đó để chạy một vòng lặp self-improvement; và benchmark được các cấu hình khác nhau. Như vậy, thay vì dựa vào SWE-bench hay Terminal-Bench, bạn có thể tự chứng minh với mình rằng bạn đang dùng đúng setup. Slide "Measurement > Vibes" đặt ba khái niệm cạnh nhau: Scoring, Self-improvement, Benchmarking, và phần demo sau đó lần lượt đi qua cả ba.

Ba công cụ đo lường Zach đặt ra trên slide "Measurement > Vibes", cũng là ba phần demo ở nửa sau bài nói.

## 8. Product engineering và factory engineering

Từ góc nhìn "tất cả chuyện này có ý nghĩa gì với kỹ sư", Zach nghĩ (video đăng ngày 19/10/2026) điều này rất quan trọng. Anh hình dung từ nay sẽ có hai loại engineering. Loại thứ nhất là product engineering, vẫn sẽ quan trọng: bạn đang xây một thứ có giá trị cho một khách hàng hay một người dùng nào đó. Nhưng product engineering sẽ diễn ra thông qua một factory, nghĩa là công việc đi vào một hệ thống vòng kín và con người có các điểm chạm với hệ thống đó.

Loại thứ hai (vẫn theo Zach) là factory engineering, và Zach nói anh rất hào hứng với nó. Đây là công việc lấy software factory của bạn và làm nó hiệu quả hơn. Phần lớn là performance tuning: tìm ra skill và MCP nào, tổ hợp model nào, workflow nào là đúng để cả team đang làm product engineering làm tốt hơn. Slide minh họa ghi "Two types of engineers will use your factory", tách thành Product Engineer và Factory Engineer.

Hai loại kỹ sư cùng dùng một factory: một người đưa việc sản phẩm vào, một người làm cho chính factory chạy tốt hơn.

Thay vì chỉ trình bày slide, Zach chuyển sang minh họa bằng Warp Factories. Anh khuyến khích mọi người thử nó, "dĩ nhiên rồi", nhưng nói những điều sắp trình bày vẫn áp dụng khi bạn nghĩ về factory nói chung. Anh nhắc lại: có việc của product engineering và việc của factory engineering. Màn hình đầu tiên là thứ factory engineer sẽ dùng, một cái nhìn về toàn bộ hệ thống. Trong Warp Factories, theo mô tả trong video đăng ngày 19/10/2026, mỗi bề mặt sản phẩm có một factory riêng.

## 9. Demo: factory là một tập agent định nghĩa bằng code

Zach giải thích (video đăng ngày 19/10/2026) một factory nên được hiểu là một tập hợp agent, và định nghĩa của các agent đó được viết bằng code. Trong demo (theo video đăng ngày 19/10/2026), trang Agents của factory tên "wilson" có một dải thông báo "Managed in GitHub": cấu hình chỉ đọc ở đây, muốn sửa thì sửa trong repo factory-dev của Warp trên nhánh main, thư mục v1, kèm nút "Open in GitHub".

![Trang Agents của factory wilson với foreman và các agent code-review, implementation, spec, triage](https://homus.dev/photos/x-PK3yx_MJg-1023.jpg)

Trang Agents trong Warp Factories (demo trong video đăng ngày 19/10/2026): "wilson Foreman" điều phối workflow và dispatch từng bước có cổng; bên dưới là các agent code-review, implementation, spec và triage, mỗi agent một dòng mô tả. Dải trên cùng ghi cấu hình được quản lý trong GitHub.

Với Warp, theo video đăng ngày 19/10/2026, họ cung cấp một bản cài đặt mặc định: mọi việc đi vào factory đều qua một agent gọi là foreman. Mở agent foreman ra, bạn thấy toàn bộ cấu hình tập trung: nó cần MCP nào, secret nào, dùng model nào, chạy ở đâu. Bạn thấy nó có thể được kích hoạt bởi những automation nào, và prompt của agent này là gì. Trên màn hình, tab Prompt của foreman hiện "Agent prompt", ghi chú "This is the base prompt the agent will use", và phần đầu của prompt như sau:

```
# Foreman

You are the orchestrator ("foreman") of the software factory. The factory is a team of agents that automates the software development lifecycle from start to end. You accept work into the factory and keep the work in motion. For the most part, you do not do all the work yourself; you delegate to subagents to handle different parts of the lifecycle, like triage and code review.

Your objective is to reach the user's goal at the lowest cost that gets there. The stages below get more expensive as the work moves forward: a message is cheap, an issue is cheap, a spec costs a round of review, and implementation is by far the most expensive stage in time, compute, and tokens. A question asked before implementation is cheap. A pull request that nobody asked for, or one that solves the problem in a shape the user would not have chosen, is the most expensive mistake the factory makes. When you are not sure whether to move to a more expensive stage, ask; do not proceed on a guess.

## Procedure
```

Khi việc đi vào, theo demo trong video đăng ngày 19/10/2026, foreman giao lại cho các agent khác theo một orchestration pattern. Zach nói chi tiết cụ thể không quá quan trọng, đây là factory "stock" của Warp, nhưng bạn có thể hình dung nó đi qua đúng vòng lặp đã vẽ ở trên: triage, spec, implement, code review.

## 10. Đưa việc vào factory từ công cụ bạn đang dùng

Cách bạn tương tác với foreman, và Zach nói điều này rất quan trọng, là từ bất kỳ bề mặt nào. Nếu bạn dựng một factory, Warp (theo video đăng ngày 19/10/2026) có hỗ trợ khái niệm nói chuyện trực tiếp với factory trong giao diện của họ (màn hình hiện ô chat "Good afternoon, Zach" với gợi ý chat với foreman). Nhưng theo anh, đó không phải cách Warp kỳ vọng mọi người tương tác với factory. Cách nên nghĩ là tích hợp factory vào bộ công cụ bạn đang có.

Ví dụ, công cụ Warp chủ yếu dùng lúc quay video (19/10/2026) là Slack. Nhưng theo Zach, họ có khách hàng dùng Teams, có khách hàng dùng Linear, Jira, GitHub. Bạn tương tác ở đâu không quan trọng, vì toàn bộ context của factory phải nằm trên cloud, ở một chỗ tập trung.

Zach mở một thread Slack trong team Warp. Anh nói thật lòng thì nó trông rất giống việc bắt đầu bằng một prompt cho local agent: một người trong team nhờ thay đổi vài thứ. Việc đi qua một flow, tới foreman. Điểm khác so với dùng một coding agent bình thường là trên đường đi, nó sẽ đi qua bước triage và mọi bước được định nghĩa trong workflow thật. Theo Zach, lúc quay video (19/10/2026) mọi người trong team Warp đều làm việc theo cách này.

Bạn nhận được vài lợi ích hay (theo demo trong video đăng ngày 19/10/2026): ở đây factory đã tạo issue trên Linear, và Zach có thể tương tác với nó trên Linear theo đúng cách đó nếu muốn. Nó đã tạo PR cho phần server. Nó đã chạy computer use, nên đã chứng minh được là nó làm đúng việc. Trên màn hình là một PR GitHub tên "[APP-6366] Truncate oversized Factory chat tool-call tooltips", có phần What, Why và mục Agent Mode ghi nhận các bản ghi computer use.

Ý chính, theo Zach (video đăng ngày 19/10/2026): là một product engineer, bạn làm việc qua những công cụ bạn vốn đang dùng. Warp dùng Slack; bạn có thể dùng Linear, có thể dùng GitHub, thậm chí có thể dùng một local coding agent và gửi việc vào factory qua nó. Anh nói đây, ở nhiều mặt, là phần kém thú vị nhất của cách tiếp cận factory.

## 11. Nhìn cả team theo real-time và các số đo của factory

Phần thú vị hơn, theo Zach (video đăng ngày 19/10/2026), là khi bắt đầu làm việc theo cách này, bạn không chỉ định nghĩa workflow của factory bằng code, mà còn thấy được theo real-time mọi người trong team đang làm gì trên tất cả các factory. Anh ví nó gần giống Google Docs, nhưng cho coding agent của cả team. Trên trang Runs, anh thấy một đồng nghiệp đang làm việc về diagnostics cho các lần chạy cloud agent; anh có thể bấm vào xem, và có thể quay lại thread Slack gốc nơi yêu cầu đó bắt đầu.

Cái hay, theo Zach (video đăng ngày 19/10/2026), là tất cả được tập trung một chỗ. Khi đã tập trung, bạn không chỉ có cái nhìn real-time mà còn tự động có phần lưu trữ và theo dõi mọi thứ người trong team đang làm với coding agent. Có được điều đó rồi thì bạn mới bắt đầu làm factory engineering được.

Với Zach, một khía cạnh của factory engineering là hiểu dòng chảy công việc qua factory. Những thứ anh cho là bạn nên nhìn ngay nếu đang làm factory engineering: mỗi PR có bao nhiêu lần con người phải tương tác, tức mức độ tự động hóa; mất bao lâu để ship; mỗi PR tốn bao nhiêu tiền. Rồi cắt các số đó theo nguồn, theo người dùng, theo agent, theo model; tính và nắm được cost per PR, và có kế hoạch để kéo nó xuống.

![Dashboard Productivity của factory wilson](https://homus.dev/photos/x-PK3yx_MJg-0903.jpg)

Tab Productivity của dashboard trong demo (số liệu 7 ngày, 9 đến 15/10, theo video đăng ngày 19/10/2026): 21,5 lần con người tương tác mỗi PR; median cycle time kickoff tới merge 15 giờ, kickoff tới PR 44 phút; 325 PR mở, 189 đã merge; 1.789 lần chạy chia theo loại agent.

![Tab Spending với cost per PR và spend by source](https://homus.dev/photos/x-PK3yx_MJg-1403.jpg)

Tab Spending trong demo (theo video đăng ngày 19/10/2026): cost per PR 16,42 USD, tách thành compute, platform và inference; bên dưới là chi phí theo nguồn như Slack, Warp Web, Scorer, Factory MCP, Linear, GitHub và self-improvement.

Đi sâu thêm một tầng, như anh đã nhắc trước đó, là khả năng chạy online eval, mà Warp Factories gọi là scoring (theo video đăng ngày 19/10/2026), trên tất cả các lần chạy coding agent bạn đang có.

## 12. Scoring: LLM as a judge trên mọi lần chạy agent

Scoring nghĩa là gì? Zach nhắc lại: một khi bạn ở trong thế giới mà mọi lần chạy coding agent đều được lưu lại, bạn có thể bắt đầu chạy LLM as a judge trên chúng để đánh giá theo nhiều chiều khác nhau.

Một chiều mà Warp theo dõi (theo video đăng ngày 19/10/2026) là "redundant tests" (anh nói đây chỉ là ví dụ, bạn có thể tự định nghĩa phiên bản của riêng mình). Theo Zach, có một kiểu lỗi thường gặp ở coding agent: chúng viết những test không cần thiết, làm tốn tiền, tốn thời gian và tốn context. Vì vậy Warp cho agent đi xem lại các lần chạy agent trước đây, dùng LLM as a judge để tìm xem kiểu lỗi này đang xảy ra ở đâu.

![Trang scorer Redundant Tests với chi phí và xu hướng pass rate](https://homus.dev/photos/x-PK3yx_MJg-1443.jpg)

Scorer "Redundant Tests" trong demo: đánh giá diff test cuối cùng của implementation agent có test thừa, ít giá trị hay tầm thường không. Màn hình (video đăng ngày 19/10/2026) ghi tổng chi phí scorer 529,20 USD, đường pass rate 30 ngày, và danh sách từng lần chạy với kết quả, điểm, phân loại, thời gian và chi phí.

Theo Zach (video đăng ngày 19/10/2026), Warp không chấm trên mọi lần chạy vì việc đó khá tốn kém; về cơ bản có một chiến lược lấy mẫu và một tiêu chí pass/fail. Tất cả cơ chế scoring này cũng được định nghĩa bằng code, và bạn xem được xu hướng theo thời gian. Ở tab cấu hình, scorer có phần Judge instructions viết dạng rubric (chỉ chấm các lần chạy của implementation agent, chấm diff test cuối cùng đã nằm trên PR chứ không chấm test trung gian, ghi samplingRate là 10 và passingScore là 0.5), một Judge model, và Runner để chọn nơi chạy judge.

## 13. Self-improvement: agent sửa chính định nghĩa factory

Khi đã có hệ thống như vậy, bước tiếp theo là dựng thêm một vòng lặp nữa, mà Warp gọi là self-improvement: có những agent nhìn vào các lần chạy bị fail và cố đề xuất thay đổi để cải thiện factory bên dưới. Zach nói khái niệm này theo anh rất quan trọng, và Warp (tính đến video đăng ngày 19/10/2026) đang ngày càng tinh vi hơn trong việc làm thế nào cho đúng, làm sao chứng minh nó thật sự hiệu quả.

Ý tưởng chung là: có agent xem tất cả các điểm số, tìm các vấn đề lặp lại. Ở đây, trong demo của video đăng ngày 19/10/2026, có một vấn đề được nhận diện với triage agent, xuất hiện 54 lần. Agent đề xuất cải thiện cho chính định nghĩa của factory để sửa vấn đề đó, ví dụ như một thay đổi vào code định nghĩa factory.

![Inbox Self-improvement với mục Let triage start research subagents đang mở](https://homus.dev/photos/x-PK3yx_MJg-1603.jpg)

Inbox Self-improvement trong demo (video đăng ngày 19/10/2026): mỗi dòng là một đề xuất. Mục "Let triage start research subagents" mở ra phần Problem (triage được dặn giao việc điều tra cho research skill nhưng thiếu quyền spawn, nên tự làm luôn trong khoảng 25 lần chạy được chấm) và Solution (khai báo spawnableBy cho triage agent), kèm nhãn 54 failed runs.

Theo Zach (video đăng ngày 19/10/2026), đây là lý do việc định nghĩa mọi thứ bằng code quan trọng đến vậy: bạn có coding agent quan sát các vấn đề trong cách công ty bạn làm ra phần mềm. Chúng quan sát lặp đi lặp lại. Chúng thông minh. Chúng kết luận: vấn đề gốc thật ra nằm ở cách chính factory được đặc tả, và có thể đề xuất một bản sửa. Rồi chúng tạo một PR để team merge vào định nghĩa factory, và vấn đề đó không lặp lại nữa. Đó là cái Warp gọi là self-improvement.

![PR Let triage start research subagents với diff agent.md](https://homus.dev/photos/x-PK3yx_MJg-1623.jpg)

PR (trong demo của video đăng ngày 19/10/2026) do bot của factory mở trong repo factory-dev: file v1/agents/triage/agent.md được thêm ba dòng spawnableBy cho foreman và triage; các dòng khác của file khai báo description, agentType, model và idleTimeoutMinutes.

Phần diff trên màn hình, đúng như hiển thị:

```
---
description: Triages requests and establishes task state.
agentType: TRIAGE
spawnableBy:
- foreman
- triage
model: grok-4-6-medium
idleTimeoutMinutes: 10
---
```

Zach nói (video đăng ngày 19/10/2026) dù bạn tiếp cận chuyện này theo cách nào, đây vẫn là một primitive rất hữu ích để đi tới một vòng lặp mà factory thật sự tốt lên theo thời gian.

## 14. Automation trigger: việc vào factory không cần người gõ

Zach muốn cho xem thêm vài thứ (video đăng ngày 19/10/2026). Anh đã nói cách một người đưa việc vào factory; mục tiêu là có một flow tương tự cho việc đi vào qua automation trigger. Nếu bạn đang xây factory, đây thậm chí có thể là điểm bạn bắt đầu. Bạn cần có cách nói rằng: ngoài prompt trực tiếp từ con người, chúng ta muốn có một prompt tự động hay một trigger tự động đưa việc qua đúng workflow factory đó, hoặc qua một workflow factory hơi khác. Vì thế factory của bạn nên hỗ trợ một tập automation.

Trang Automations trong demo (theo video đăng ngày 19/10/2026) cũng có dải "Managed in GitHub" và liệt kê từng automation với trigger, lần chạy cuối và công tắc bật/tắt. Ví dụ: daily-factory-self-triage-report chạy hằng ngày lúc 10 giờ sáng; github-pr-closed-or-merged chạy khi PR được đóng hoặc merge; linear-warp-mention khi issue Linear được giao, được tạo hoặc có agent session; slack-dms khi có tin nhắn trực tiếp trên Slack; feedback-factory-digest hằng ngày lúc 8 giờ sáng; github-factory-auto-implement khi một issue GitHub được gắn label.

## 15. Benchmark suite trên việc thật của bạn

Thêm một điều quay lại ý đo đạc và cải thiện mọi thứ: bạn muốn thật sự đo được các coding task chạy ra sao với model khác nhau, cấu hình factory khác nhau, trên workflow thật của mình. Cách Warp nghĩ về việc này, và thứ họ đã xây vào sản phẩm (theo video đăng ngày 19/10/2026), là khái niệm benchmark suite.

Về cơ bản, với bất cứ việc gì đang chạy trong một Warp factory, bạn có thể nói: đây là một task thú vị, có thể là task khó, hoặc thuộc một lớp task cụ thể như task front-end, và thêm nó vào một benchmark. Dần dần bạn xây được các benchmark suite. Vì bạn đang theo dõi mọi session coding agent, bạn có thể chạy lại và replay chúng. Zach lưu ý phải cẩn thận khi làm việc này, vì có side effect và những thứ tương tự, nhưng theo anh (video đăng ngày 19/10/2026) Warp đã xây khá nhiều infrastructure để làm được.

Trên màn hình (video đăng ngày 19/10/2026), benchmark "WarpBench 0.1" được mô tả là các task tự chứa cho implementation agent, chắt lọc từ những lần chạy thật của factory Wilson: 10 task dễ, 9 trung bình, 5 khó và 5 rất khó, trải qua config, client UI, server logic và các bề mặt Factory xuyên suốt. Bên dưới là lịch sử các lần chạy với số task, số cấu hình, thời gian và chi phí.

Bạn có thể nói: tôi muốn xem mọi thứ chạy ra sao với các cấu hình model khác nhau, với các cấu hình harness khác nhau. Zach nói anh có thể xem nó chạy ra sao trong Pi, có thể chọn model (theo demo trong video đăng ngày 19/10/2026). Khi chạy, về cơ bản hệ thống chạy một ma trận test trên chính các coding agent task thật của bạn, rồi cho ra một thứ trông giống kết quả của một benchmark công khai.

![Hộp thoại New benchmark run](https://homus.dev/photos/x-PK3yx_MJg-1917.jpg)

Hộp thoại "New benchmark run" trong demo (video đăng ngày 19/10/2026): chọn task (29 trên 29), thêm cấu hình gồm harness, model và runner, chọn scorer (Correctness luôn có), số lần lặp; dòng cuối tính ra 29 task nhân 1 cấu hình nhân 1 lần lặp nhân 1 scorer.

Zach cho rằng (video đăng ngày 19/10/2026) khái niệm này cực kỳ mạnh, và là thứ mọi người nên nghĩ cách đạt tới: nó sinh ra một đường đánh đổi giữa correctness và chi phí. Bạn có thể dùng các chiều chấm điểm khác, nhưng với benchmark này cách đọc là: càng lên trên và sang trái càng tốt, vì bên trái rẻ hơn còn bên trên chất lượng cao hơn.

![Biểu đồ correctness so với average cost của WarpBench 0.1](https://homus.dev/photos/x-PK3yx_MJg-2103.jpg)

Kết quả một lần chạy WarpBench 0.1 ngày 2/9 trong demo (video đăng ngày 19/10/2026): trục dọc correctness, trục ngang chi phí trung bình; các điểm gồm glm 5.3 flash, gemini 3.7 flash, gpt-5.6-sol (high), grok 4.6 (high) và claude opus 5 (high); ô trên ghi lựa chọn rẻ nhất là glm 5.3 flash, 1,99 USD mỗi lần thử.

Theo kết quả Zach đọc trên biểu đồ (lần chạy cách đây một thời gian, trong video đăng ngày 19/10/2026), hai ứng viên thắng benchmark này, tức nằm trên đường Pareto, là GPT-5.6 Sol và GLM 5.3 Flash. GPT-5.6 Sol tốn trung bình 6,23 USD và đúng 95%. GLM 5.3 Flash tốn khoảng một phần ba chi phí và kém đúng hơn một chút. Anh nói điều này không có nghĩa GPT-5.6 Sol tốt hơn GLM 5.3 Flash, hay ngược lại, trong mọi tình huống. Nó nói rằng với loại task này, bạn có thể đánh đổi có hiểu biết: bạn có chấp nhận chất lượng cao hơn một chút với giá gấp ba hay không. Anh nói có lẽ Warp sẽ chọn GLM 5.3 Flash cho trường hợp này. Sau đó bạn có thể đưa kết quả vào một chiến lược model routing áp dụng cho các task tương tự.

Một lần nữa, ý tưởng là thay vì dựa vào Terminal-Bench hay SWE-bench, những thứ hay và hữu ích để đo trí thông minh chung của một model, bạn tự hỏi: với công việc của chính chúng ta, cái gì tốt nhất? Zach coi đây là một primitive rất, rất mạnh (ý kiến của anh trong video đăng ngày 19/10/2026), nhất là khi kết hợp với khả năng làm model routing dựa trên thông tin đó.

## 16. Factory stack: bảy tầng ghép lại

Theo video đăng ngày 19/10/2026, cách Warp gói tất cả lại, và cách Zach thấy hữu ích để gói lại, là coi software factory như một stack. Đáy của stack là định nghĩa factory bằng code (factories-as-code). Anh nhắc lại: tầng này mở ra cách version, test và rollback toàn bộ cấu hình về cách factory của bạn vận hành, tức thật ra là cách phát triển phần mềm, agentic development, vận hành ở công ty bạn.

![Sơ đồ factory stack bảy tầng từ 00 Factories-as-code tới 06 Access](https://homus.dev/photos/x-PK3yx_MJg-2203.jpg)

Slide factory stack (video đăng ngày 19/10/2026): 00 Factories-as-code (Factory.yaml, định nghĩa agent, automation, runner, repo), 01 Data & context, 02 Compute, 03 Inference, 04 Improvement, 05 Orchestration, 06 Access; bên trái ghi các tầng có thể do Warp host hoặc do khách hàng tự host.

Tầng thứ hai phía trên, theo Zach (video đăng ngày 19/10/2026), là data và context. Bạn nên nghĩ về toàn bộ dữ liệu đi vào factory, đến từ MCP, có thể từ API; và toàn bộ dữ liệu đi ra khỏi factory. Thứ đi ra có thể là nhật ký các lần chạy agent, mà Zach nói là thứ quan trọng nhất, nhưng agent cũng tạo ra screenshot, video, và có một khái niệm memory. Có đủ loại dữ liệu đi ra.

Tầng thứ ba (theo video đăng ngày 19/10/2026) là compute: agent của bạn chạy ở đâu. Như đã nói, bạn muốn chúng chạy trong sandbox vì lý do bảo mật và governance. Tùy yêu cầu, bạn có thể muốn hỗ trợ sandbox trên nhiều nền tảng.

Inference phải pluggable, và Zach nói anh rất tin điều này. Theo anh, phần lớn công ty Warp nói chuyện cùng (tính đến video đăng ngày 19/10/2026) muốn mang inference của riêng họ. Họ muốn thử các model khác nhau, model open-weight, model frontier; họ có thể muốn thử một model fine-tune do chính họ xây. Vì vậy tầng này pluggable là rất quan trọng.

Tiếp theo, theo Zach (video đăng ngày 19/10/2026), là các primitive cải thiện, cho phép khép vòng lặp và thật sự cải thiện factory. Zach nói chúng rất quan trọng. Rồi tới orchestration: anh mới chỉ cho xem một chút primitive orchestration của Warp, nhưng cách nghĩ là bạn muốn quy trình đi qua những bước hay giai đoạn nào, chặn chúng bằng cổng con người và tính tất định ở đâu, đồng thời tận dụng việc agent thông minh và có thể tự định tuyến thông minh. Tầng này cũng phải hỗ trợ nhiều harness khác nhau và nhiều primitive automation khác nhau.

Cuối cùng, theo Zach (video đăng ngày 19/10/2026), một primitive rất quan trọng để xây factory là hỗ trợ đủ loại điểm truy cập vào factory. Mô hình tư duy là: việc đi vào factory, agent trong factory làm việc đó. Việc có thể vào qua MCP, qua Slack hay Teams, qua Jira, Linear, GitHub, GitLab; bạn phải tự xây được UI của mình trên đó, và tất cả phải chạy bằng API.

## 17. Kết: Warp đã đo được gì

Với Zach, đó là cả hệ thống. Nếu bạn nghĩ kỹ về việc phát triển tự động trông như thế nào, anh cho rằng bạn sẽ đi tới một thứ trông khá giống stack này. Anh tự nhận mình không khách quan ở đây: theo video đăng ngày 19/10/2026, Warp đã xây khá nhiều primitive trong stack, và cách họ nghĩ về việc này là giúp các platform team đang nhìn vào mảng này đi tới thế giới đó nhanh hơn. Ai quan tâm có thể xem Warp Factories, nhưng anh mong bài nói hữu ích cho bất kỳ ai đang tự hỏi software factory là gì, thật sự nghĩa là gì, và xây một cái thật thì làm thế nào.

Warp đang dành rất nhiều thời gian nghĩ về chuyện này, và theo Zach họ đã có khá nhiều thành công. Anh nói anh thường có một slide về kết quả: theo số đo của Warp mà Zach nêu trong video đăng ngày 19/10/2026, trong sáu tuần gần nhất họ đã kéo cost per PR từ khoảng 55 USD xuống khoảng 15 USD, đồng thời tăng PR throughput khoảng 40%, và revert rate cũng thấp hơn. Ý anh là đây không chỉ là đẩy ra những thứ cẩu thả.

Ba con số Zach đưa ra cho chính Warp, theo video đăng ngày 19/10/2026: cost per PR giảm, throughput tăng và revert rate thấp hơn trong sáu tuần.

Vì vậy Zach nói (video đăng ngày 19/10/2026) anh rất tin cách tiếp cận này hiệu quả, và tin đây là hình dạng tương lai của việc phát triển phần mềm. Slide kết của anh nhắc lại thông điệp: thế giới đang chuyển sang factory; factory nên mở, dễ thích nghi và định nghĩa bằng code; kèm ba điều: đưa agent vào sandbox, sở hữu dữ liệu của bạn, và đo lường thắng cảm tính. Anh cảm ơn mọi người đã xem.

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

- Tên gốc: What a software factory actually is
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=x-PK3yx_MJg](https://www.youtube.com/watch?v=x-PK3yx_MJg)

- Kênh YouTube Warp (Zach Lloyd): [youtube.com/channel/UCKONdcQCTP3aozARj1ntKhw](https://www.youtube.com/channel/UCKONdcQCTP3aozARj1ntKhw)

- Trang Warp Factories, mô tả nền tảng là open infrastructure cho cloud software factory (đọc ngày 22/10/2026): [warp.dev/factories](https://www.warp.dev/factories)

- Bài blog "The Factory Stack" của Warp, về các tầng của stack trình bày ở mục 16 (đọc ngày 22/10/2026): [warp.dev/blog/the-factory-stack](https://www.warp.dev/blog/the-factory-stack)

- Bài blog "Launch Factory Benchmarks" của Warp, về benchmark suite ở mục 15 (đọc ngày 22/10/2026): [warp.dev/blog/warp-factory-benchmarks](https://www.warp.dev/blog/warp-factory-benchmarks)

- Repo Warp trên GitHub, "an agentic development environment, born out of the terminal" (đọc ngày 22/10/2026): [github.com/warpdotdev/warp](https://github.com/warpdotdev/warp)

Nguồn: https://homus.dev/talks/what-a-software-factory-actually-is · cập nhật 2026-10-22