# Software factory: con người ở đầu vào và ở pull request

[Cody Seibert](https://homus.dev/speakers/cody-seibert) · [Web Dev Cody](https://homus.dev/orgs/web-dev-cody)

> Cody Seibert vẽ sơ đồ software factory: prompt vào sandbox, pull request ra, skill, knowledge base, trigger, auto-merge có luật gác cổng và rủi ro bảo mật.

Topics: Software Factory, Coding Agents, Workflow

Canonical: https://homus.dev/talks/stop-writing-code-build-a-software-factory-instead

## 1. Model chạy được rất lâu, và cách làm phần mềm trước đây

Cody Seibert muốn nói một chút về chuyện software engineering đã thay đổi ra sao trong vài năm qua. Theo anh (video đăng ngày 05/11/2026), với những model mới như Opus 5.5 và Astra, ta đang thấy các model này có thể chạy trong những khoảng thời gian rất, rất dài mà không bị ngắt quãng, làm được rất nhiều việc mà bạn không cần prompt lại, thậm chí không cần ngồi trông chừng nó.

![Bảng vẽ Eraser còn trống với nút Generate AI Diagram ở giữa, góc phải là Cody](https://homus.dev/photos/nwMNQJ_Wtw8-0003.jpg)

Lúc mở đầu, Cody đứng trước một bảng vẽ Eraser còn trống ("Untitled File", ở giữa là nút "Generate AI Diagram"), nơi anh sẽ vẽ dần sơ đồ software factory trong video đăng ngày 05/11/2026. Góc phải là Cody.

Việc đầu tiên anh muốn nói là trước đây ta làm software engineering như thế nào, rồi sau đó anh sẽ chuyển sang những gì anh đang thấy trong ngành lúc quay video (đăng ngày 05/11/2026).

Trước đây, bạn có các engineer, có các UX designer, có một product owner. Theo cách phần mềm phát triển lên (theo Cody, video đăng ngày 05/11/2026), product owner về cơ bản là người ngồi trước người dùng và cả team để thu thập requirement, cố hiểu xem tiếp theo nên xây gì. Người dùng cần gì tiếp theo? Thứ đó có thật sự hợp lý không?

Product owner cũng là người sắp thứ tự ưu tiên cho một backlog các task. Bạn sẽ có một backlog khổng lồ, vô số thứ mà mọi người nghĩ là họ muốn thêm vào hệ thống. Việc của product owner về cơ bản là đi qua danh sách đó, sắp xếp nó, làm cho nó có lý. Rồi khi đã quyết định chính xác thứ gì sẽ mang lại giá trị cao nhất cho người dùng, product owner sẽ bảo team, gồm người làm user experience, designer, engineer, người làm QA: được rồi, giờ thì xây nó đi (theo Cody, video đăng ngày 05/11/2026).

## 2. Pipeline cũ: Figma, deploy, sửa lại và overhead

Có thể có vài sắc thái khác nhau ở đây (theo Cody, video đăng ngày 05/11/2026). Có team cho task đi tới UX designer trước, người này dựng một bản thiết kế Figma rồi giao lại cho engineer để code. Có team thì bạn làm việc trực tiếp với người làm UX và cùng nhau lặp đi lặp lại trên thiết kế, có thể trong một cuộc gọi Zoom hay trong các buổi họp.

Nhưng nhìn chung, theo anh (video đăng ngày 05/11/2026), đã có một kiểu pipeline: bạn có feature request từ người dùng. Bạn có product owner, người thật sự hiểu core business domain và là người thêm được những tính năng đó. Rồi bạn có các engineer, system engineer, UI engineer, backend engineer, những người tìm cách làm xong tất cả.

Việc này tốn rất nhiều thời gian, Cody nói (video đăng ngày 05/11/2026). Một task phải đi qua toàn bộ pipeline này. Cuối cùng bạn deploy nó lên đâu đó. Và khi đã deploy ra ngoài, bạn nhận ra mình phải sửa một thứ bạn chưa nghĩ tới. Có những edge case và lỗ hổng bạn đã bỏ sót. Đôi khi người UX designer thấy thứ bạn thêm vào không đúng hẳn cái họ muốn, vì bản mock-up đã đổi kể từ lúc họ làm nó, hoặc ngược lại. Theo anh, có rất nhiều khâu ở giữa và overhead trong vòng đời software engineering truyền thống.

Pipeline truyền thống theo lời Cody (video đăng ngày 05/11/2026): mỗi task đi lần lượt qua từng người, deploy xong mới lộ ra những chỗ phải sửa.

## 3. Software factory: prompt vào, sandbox làm việc

Giờ hãy tua nhanh tới hôm nay, với những công ty đã dùng AI, và xem mọi thứ thật sự trông thế nào. Một lần nữa, Cody nói anh chỉ có thể kể trải nghiệm của mình: những gì anh thấy ở những thứ anh và đồng nghiệp đang làm, và những gì anh thấy ở các side project của anh (video đăng ngày 05/11/2026).

Giờ đã có AI, theo anh (video đăng ngày 05/11/2026), rất nhiều lúc thay vì lúc nào cũng tương tác trực tiếp với nhau, tất cả mọi người về cơ bản đang tương tác với cái mà bạn có thể gọi là một software factory. Anh nói anh sẽ gọi nó là software factory.

Dĩ nhiên, Cody nói, giữa mọi người vẫn nên có giao tiếp. Bạn nên có một trải nghiệm cộng tác khi làm việc với người khác, nếu không bạn sẽ không xây được một sản phẩm tốt. Vậy nên phần giao tiếp đó vẫn nên tiếp diễn. Nhưng thay vì một pipeline kiểu "được rồi, giờ product owner cần X", điều anh đang thấy trong ngành (theo video đăng ngày 05/11/2026) là bạn thật sự có thể để product owner prompt software factory của bạn, và software factory có thể dựng lên một sandbox nào đó.

Sandbox đó có thể chạy trong một môi trường cô lập, nên nó an toàn. Nó nhận prompt từ product owner. Nó làm việc. Theo Cody (video đăng ngày 05/11/2026), Opus có thể chạy liên tục hàng giờ cho tới khi làm xong hẳn. Và cuối cùng sandbox sẽ tạo một pull request.

Luồng Cody mô tả (video đăng ngày 05/11/2026): product owner prompt software factory, factory dựng một sandbox cô lập, Opus làm việc trong đó, và cuối cùng sandbox tạo một pull request.

## 4. Một pull request mẫu: quả bí ngô trong game

Pull request đó có thể trông như thế này. Cody mở một pull request mẫu anh làm trên side project, game của anh. Nhưng theo anh (video đăng ngày 05/11/2026), đúng kiểu mô tả này là thứ anh và đồng nghiệp cũng làm ở chỗ làm, chỉ có điều ở đó chi tiết hơn một chút.

![Trang pull request trên GitHub: The Jack-o'-lantern rebuilt in Blender as a carved, candle-lit pumpkin on Dale #702, phần Overview và Screenshots](https://homus.dev/photos/nwMNQJ_Wtw8-0321.jpg)

Pull request mẫu trong game của Cody (demo trong video đăng ngày 05/11/2026): tiêu đề "The Jack-o'-lantern rebuilt in Blender as a carved, candle-lit pumpkin on Dale #702", 9 commit, 38 file đổi. Phần Overview kể chiếc mũ bí ngô được làm lại trong Blender thành quả bí khắc thật, thắp sáng từ bên trong như ngọn nến; bên dưới là phần Screenshots với ảnh "Before".

Khi bạn làm trên một sản phẩm thật, có khách hàng thật và có rủi ro thật, theo Cody (video đăng ngày 05/11/2026), có nhiều thứ hơn nhiều mà bạn muốn đưa vào phần mô tả: kiến trúc hệ thống đã thay đổi thế nào? Có những rủi ro gì? Bạn đã làm một kiểu phân tích bảo mật nào đó chưa? Performance metric của thay đổi này là gì? Nó có làm thứ gì chậm đi, hay ảnh hưởng tới các dịch vụ bên thứ ba bên ngoài đang kết nối với bạn không?

Còn trong tình huống này thì nó chỉ là một pull request, và nó chỉ có ảnh chụp màn hình của model quả bí ngô anh thêm vào game. Về mặt kỹ thuật, anh có thể thêm thông tin về metric vì anh đang thêm một model 3D mới. Có triangle trong đó, điều đó có thể khiến game chạy chậm đi một chút nếu anh chạy nó trên một chiếc MacBook hay trên một GPU. Theo Cody (video đăng ngày 05/11/2026), thêm model mới vào game có những tác động thật.

![Phần Risk của pull request: Level Low, các mục What could go wrong, Deploy, How we'd notice, Undo, rồi Size, Tested và Generated with Claude Code](https://homus.dev/photos/nwMNQJ_Wtw8-0403.jpg)

Phần "Risk" của cùng pull request (demo trong video đăng ngày 05/11/2026): "Level: Low", các mục "What could go wrong for players", "Deploy", "How we'd notice", "Undo: revert the merge"; dòng "Size" ghi 2,582 triangles, dưới mức trần 3,000; tiếp theo là "Tested" và dòng "Generated with Claude Code".

Và anh có thể cải thiện cái skill viết mô tả PR mà anh dùng trong project này để nó phân tích nhiều hơn, để anh, người ở vị trí human in the loop, chỉ cần ở tận cuối của software factory nhìn vào và nói: cái này có vẻ ổn. Dĩ nhiên, theo Cody (video đăng ngày 05/11/2026), bạn cũng có thể làm thêm vài thứ để software factory tự động merge các pull request này dựa trên tiêu chí bạn đặt ra. Anh nói sẽ quay lại chuyện đó ngay sau đây.

## 5. Ở công ty: product owner và designer tự tạo pull request

Ở công ty của anh, Cody kể (video đăng ngày 05/11/2026), anh và đồng nghiệp đã thấy có những product owner giờ có thể đưa được tính năng vào codebase mà không cần đụng tới hay nói chuyện với một designer hay một engineer. Có những designer làm việc cùng anh, ngay lúc quay video, đang thật sự tạo pull request: thay đổi cách UI hoạt động, thay đổi thiết kế của UI và thay đổi trải nghiệm của các trang khác nhau.

![Sơ đồ trên Eraser: khung Software Factory chứa ô sandbox, bên dưới là bốn vòng tròn engineers, ux / designers, product owner, user nối mũi tên lên factory](https://homus.dev/photos/nwMNQJ_Wtw8-0443.jpg)

Một khung "Software Factory" chứa ô "sandbox", bên dưới là bốn vòng tròn "engineers", "ux / designers", "product owner" và "user", nối với nhau và đều có mũi tên đi lên factory.

Những người này chỉ việc prompt software factory, và nó tự chạy đi: nó dựng một sandbox, nó làm thay đổi, nó tạo một pull request để các engineer có thể vào review. Cody nói hãy cứ coi pull request là phía bên ngoài của software factory (video đăng ngày 05/11/2026).

Theo Cody (video đăng ngày 05/11/2026), con người giờ thật ra đang sống ở bên ngoài. Nếu nghĩ về humans on the loop, humans in the loop, HIL, H-I-L là human in the loop, thì chúng ta sống ở phần đầu vào của software factory. Chúng ta phải là người prompt nó. Chúng ta phải là người thu thập requirement và hiểu người dùng cần gì.

Và chúng ta cũng sống ở phía đầu ra: review code, review ảnh chụp màn hình, review metric. Thay đổi này thật sự tác động thế nào tới hệ thống của mình? Chúng ta review nó rồi đưa nó merge vào. Dĩ nhiên, theo anh, người làm UX và designer cũng có thể xem ảnh chụp màn hình trong pull request, product owner cũng có thể xem. Anh và đồng nghiệp thấy GitHub và pull request là một trong những cách chính để làm việc này (video đăng ngày 05/11/2026).

![Sơ đồ có thêm ô Pull Request bên trái với nhãn humans in the loop HIL, và nhãn thứ hai humans in the loop HIL phía trên các vòng tròn](https://homus.dev/photos/nwMNQJ_Wtw8-0543.jpg)

Mũi tên từ "Software Factory" sang "Pull Request" mang nhãn "humans in the loop HIL", và một nhãn "humans in the loop HIL" thứ hai đặt giữa các vòng tròn người và factory; các vòng tròn cũng có đường nối sang ô "Pull Request".

## 6. Hôm nay chạy trên máy từng người, mai là factory trên cloud

Phần tiếp theo, theo Cody, là phần còn đang để ngỏ cho tranh luận, tuỳ team, tuỳ công ty, tuỳ tổ chức của bạn. Trên thực tế (theo anh, video đăng ngày 05/11/2026), phần lớn những người này chỉ đang chạy Claude Code trên máy của mình. Tất cả đều chạy nó trên máy riêng, và software factory về cơ bản chỉ là một tập hợp các skill, workflow và MCP mà mọi người chạy kiểu ad hoc.

Nhưng trong tương lai, Cody nói anh có thể thấy phần lớn công ty và tổ chức thậm chí không còn cần cài gì trên máy tính nữa (dự đoán trong video đăng ngày 05/11/2026). Họ chỉ việc tiếp tục prompt môi trường software factory trên cloud này. Nó biết cách dựng sandbox. Nó lưu toàn bộ context. Nó có knowledge base. Nó có sẵn mọi skill trong repo.

Hai trạng thái Cody so sánh trong video đăng ngày 05/11/2026: cách phần lớn mọi người đang chạy lúc đó, và môi trường software factory trên cloud anh hình dung cho tương lai.

## 7. Fine-tune cỗ máy: skill, knowledge base và vòng feedback

Theo Cody (video đăng ngày 05/11/2026), việc của chúng ta giờ không còn chỉ là làm xong việc. Nó còn là cố fine-tune cỗ máy này, cái hộp đen này. Chúng ta đang cố fine-tune các skill. Chúng ta đang fine-tune knowledge base. Anh và đồng nghiệp có một vòng feedback dựng sẵn bên trong software factory, để mỗi lần nó thêm tính năng, nó có thể cố cải thiện các skill đang có.

Chẳng hạn, nếu bạn xem Matt Pocock, anh ấy có một retro skill, có nhiệm vụ cải thiện các skill hiện có để chúng chính xác hơn (theo Cody, video đăng ngày 05/11/2026). Và nếu bạn theo dõi đầu ra của các LLM chạy trong những sandbox này, dù đó là Claude Code hay Astra hay thứ gì khác, bạn có thể có một skill tự động review history log hay transaction log của session Claude Code đó, rồi tạo thêm một pull request nữa để sửa các skill cho tốt hơn một chút. Việc này sẽ cải thiện các skill. Và tới một lúc nào đó bạn có một pull request cập nhật các skill để chúng chính xác hơn.

![Sơ đồ có thêm ba ô context, knowledge base, skills trong Software Factory và một mũi tên vòng từ sandbox quay lại factory](https://homus.dev/photos/nwMNQJ_Wtw8-0703.jpg)

Bên trong khung "Software Factory" giờ có ba ô "context", "knowledge base" và "skills" (video đăng ngày 05/11/2026), cạnh ô "sandbox"; một mũi tên đi vòng từ sandbox ra ngoài rồi quay lại factory, đúng lúc Cody nói về vòng feedback cải thiện skill.

Vậy, Cody nói, về cơ bản chúng ta sống ở đây, phía bên trái và phía dưới của sơ đồ. Và chúng ta còn một trách nhiệm khác. Thay vì viết code và tự tay dựng mock-up trong Figma, chúng ta để AI làm hết những việc đó. Rồi chúng ta quay lại và lặp trên kết quả. Có thể phải qua rất, rất nhiều vòng lặp. Có thể cần rất nhiều vòng cho tới khi bạn thật sự fine-tune được toàn bộ quy trình này (theo Cody, video đăng ngày 05/11/2026).

## 8. Mỗi công ty một factory, và context từ các dịch vụ bên ngoài

Nhất là với công ty và project của chính bạn: theo Cody (video đăng ngày 05/11/2026), software factory của bạn sẽ trông rất khác so với của một công ty khác. Bạn không thể cứ dùng lại y nguyên những skill đó và áp cho mọi công ty trên thế giới. Rốt cuộc bạn cần có một team người biết cách quản lý, bảo trì và tinh chỉnh các skill này, để mỗi lần ai đó thay đổi gì, nó cập nhật đúng API doc, cập nhật đúng file readme, hay bất kỳ tài liệu engineering nào bạn có.

Rồi bạn cũng cần đảm bảo mình có sẵn những thứ liên tục nhìn vào knowledge base, nơi chứa business context và những thứ khác được bàn trong các buổi họp team hay trong chat Slack. Theo anh (video đăng ngày 05/11/2026), đó là những thứ về cơ bản bạn có thể đưa thẳng vào knowledge base, hoặc bạn có thể cho sandbox quyền truy cập MCP.

Chẳng hạn ta có thể kể Slack, có thể kể Microsoft Teams: tất cả những dịch vụ bên ngoài nơi có thảo luận diễn ra, nơi mọi người thật sự trao đổi với nhau, đều có thể được kéo vào làm context bằng MCP, để sandbox của bạn dựng và thiết kế chính xác hơn những gì cần làm tiếp theo (theo Cody, video đăng ngày 05/11/2026). Và một lần nữa, bạn có thể nối nó vào kho tài liệu của mình. Bạn có thể nối nó vào bất cứ thứ gì. Về cơ bản, bạn giờ có cả đống context nằm bên ngoài software factory thật sự của mình, và bạn cần tìm cách nối nó vào, để mỗi lần AI lặp lại, nó chính xác hơn và cải thiện được những thứ nó có.

![Sơ đồ có thêm hai mũi tên từ slack và microsoft teams đi vào ô sandbox, và mũi tên từ skills sang sandbox](https://homus.dev/photos/nwMNQJ_Wtw8-0923.jpg)

Sơ đồ có thêm "slack" và "microsoft teams" ở bên phải, mỗi cái một mũi tên đi vào ô "sandbox"; ô "skills" cũng có mũi tên nối sang sandbox (video đăng ngày 05/11/2026). Đây là phần context bên ngoài factory mà Cody nói có thể kéo vào qua MCP.

## 9. Không phải chuyện viển vông: một box tập trung cho mọi người

Theo Cody (video đăng ngày 05/11/2026), đây không phải một ý tưởng viển vông. Giờ khi Opus 5.5 đã ra mắt, anh cho rằng có lẽ đây sẽ là chuẩn mặc định mà nhiều công ty sẽ dần chuyển sang. Những công ty ngại rủi ro hơn có lẽ sẽ mất rất nhiều thời gian mới tới được môi trường hay cách thiết lập này.

Nhưng anh nhìn thấy tương lai của software engineering là mọi người về cơ bản đăng nhập vào một box tập trung (dự đoán trong video đăng ngày 05/11/2026). Ở đó họ có thể kick off prompt. Họ có thể tải lên ảnh của mình. Mọi tài liệu của họ được lưu ở đó.

Nhưng theo Cody, cách phần mềm vận hành lúc quay video (đăng ngày 05/11/2026) là ta có cả đống chỗ ad hoc để lưu file PDF và CSV. Có những hệ thống ad hoc tồn tại ở khắp nơi. Vô số database và bảng khác nhau. Nên chuyện trở nên phức tạp hơn một chút, và không phải cứ ném AI vào là xong.

## 10. Bảo mật và rủi ro khi đưa dữ liệu vào sandbox

Có những thứ thật sự cần cân nhắc khi nói tới bảo mật và rủi ro, Cody nói (video đăng ngày 05/11/2026). Ví dụ, cho một sandbox quyền truy cập vào mọi database production của bạn, mọi đoạn chat Slack, mọi đoạn chat Microsoft Teams và mọi bản ghi lời các buổi họp: có lẽ chuyện đó hơi rủi ro. Đó có thể là thông tin riêng tư, không nên cứ thế ném vào Claude Code, vì một lần nữa, các model này có truy cập tới một API của bên thứ ba.

Anh vẽ thêm logo Anthropic lên sơ đồ và nói: bạn có Anthropic ở đây, bên đang thu gom toàn bộ dữ liệu của chúng ta, và nếu bạn đẩy một cuộc thảo luận nhạy cảm nào đó vào, Anthropic có thể train trên đó, và rồi người khác có thể truy cập được nó. Đó là nhận định của Cody trong video đăng ngày 05/11/2026.

Nên dù bạn có thể lướt mạng xã hội và thấy mọi người nói về software factory, kiểu như bạn chỉ cần cho nó chạy vòng lặp, dựng các loop và graph của mình, thì theo Cody, đây là những gì anh đang thấy lúc quay video (đăng ngày 05/11/2026).

## 11. Trigger và cron job chạy mỗi ngày

Và theo Cody (video đăng ngày 05/11/2026), một việc bạn cần làm là: nếu bạn tự hỏi, với tư cách engineer hay designer, rằng giờ chúng ta đóng vai trò gì, thì một lần nữa, chúng ta phải review công việc đang được làm.

Có một điều anh chưa nhắc tới: software factory có thể có cron job, hay các agent chạy liên tục. Anh ghi "cron" lên sơ đồ, nhưng ý anh là bất kỳ trigger nào bạn muốn thêm vào. Về cơ bản có những trigger xảy ra, dù đó là một người tự tay gửi trigger vào, Slack gửi trigger vào, hay một chuyện gì đó xảy ra bên ngoài hệ thống của bạn kích software factory làm thêm việc. Rồi anh đổi nhãn thành "triggers" (theo video đăng ngày 05/11/2026).

![Sơ đồ với logo Anthropic phía trên sandbox và một ô mới tên cron đang được chọn cạnh ô context](https://homus.dev/photos/nwMNQJ_Wtw8-1043.jpg)

Sơ đồ lúc Cody vừa thêm một ô "cron" cạnh ô "context" (video đăng ngày 05/11/2026); phía trên ô "sandbox" là logo Anthropic với một mũi tên đi lên, phần anh vẽ khi nói về dữ liệu đi ra API của bên thứ ba.

Một trong các trigger có thể là: mỗi sáng bạn muốn software factory đi review codebase và cố tìm những chỗ performance có thể cải thiện. Vậy là improve performance, improve security, clean up code, update docs: theo Cody (video đăng ngày 05/11/2026), tất cả những việc này đều có thể chỉ là cron job chạy mỗi ngày. Rồi khi chúng quét xong toàn bộ codebase của bạn, dù bạn có một agent làm việc đó hay bạn đã fan out ra 10 agent khác nhau cùng làm, điều phối và nói chuyện với nhau, thì cuối cùng bạn sẽ nhận được các pull request.

## 12. Tự động merge với một luật gác cổng

Giờ hãy đi thêm một bước nữa: làm sao tự động hoá việc này hơn nữa? Theo Cody (video đăng ngày 05/11/2026), rất nhiều lúc một pull request bạn có thể cứ thế merge vào, bạn không cần review nó.

Một ví dụ khác là quả jack-o'-lantern anh đang làm, như anh đã nhắc. Nếu anh có một kiểu luật gác cổng (gatekeep rule) nói rằng: này, bạn được merge mọi pull request mới, miễn là nó được xác nhận không làm FPS của game giảm quá một hay hai FPS, hoặc render loop không được tăng thêm mili giây, từ khoảng 0.01. Nếu bạn có một agent được ghi rõ điều đó trong context hay trong một script nào đó, theo Cody (video đăng ngày 05/11/2026), bạn có thể có một trigger tự động làm hết những việc này. Nó cứ thế tiếp tục dọn dẹp code của bạn.

Bạn cũng có thể có một trigger tự động nhìn vào pull request: mỗi khi một pull request được tạo, nó có thể tự review và tự merge nó vào. Để rồi, theo anh (video đăng ngày 05/11/2026), con người chỉ còn phải tập trung vào những thứ thật sự cốt lõi, những thứ có thể thay đổi trải nghiệm người dùng.

![Sơ đồ với ô triggers trong Software Factory và một mũi tên vòng mang nhãn improve performance, improve security, clean up code, update docs](https://homus.dev/photos/nwMNQJ_Wtw8-1203.jpg)

Ô "cron" giờ đã thành "triggers" (video đăng ngày 05/11/2026), và phía trên factory là một mũi tên vòng mang bốn dòng "improve performance", "improve security", "clean up code", "update docs": những việc Cody nói có thể chạy mỗi ngày rồi trả về pull request.

## 13. Rủi ro ghi trong mô tả PR, và lúc con người thành nút thắt

Còn mọi thứ khác ở phía sau, theo Cody (video đăng ngày 05/11/2026): nếu đó là một thay đổi rủi ro cao, chẳng hạn agent của bạn đang làm gì đó và nó quyết định đổi cách API của bạn hoạt động, hay đổi phần bảo mật của API, thì đó là một thay đổi rủi ro rất cao và bạn sẽ muốn có người review.

Nên dù bạn làm gì, theo anh, có lẽ bạn cần đảm bảo trong mô tả PR có một kiểu mục rủi ro báo cho các agent biết, nếu bạn quyết định tự động hoá tới mức này, rằng đây là một PR rủi ro thấp. Nó không ảnh hưởng tới performance của game. Nó không ảnh hưởng tới thời gian load của game, vì mỗi lần bạn thêm một model, nó phải được load vào, người dùng phải tải thêm vài kilobyte mới qua được màn hình loading. Vậy nên miễn là nó rủi ro thấp và không thật sự ảnh hưởng tới game, thì cứ merge đi. Còn chờ gì nữa? Tại sao phải có người vào tận đây mà review cái này? Nếu hình ảnh trông ổn, anh nói lẽ ra anh phải review được nó (video đăng ngày 05/11/2026).

Cody nói giờ anh thậm chí không còn tự tay review pull request nữa (video đăng ngày 05/11/2026). Anh thật sự chỉ prompt một agent, kiểu: này, xem pull request này trên GitHub, sửa mọi conflict đang có trên nó, xử lý mọi comment PR mà mọi người có thể đã để lại, và merge nó vào khi xong. Và anh làm vậy cho tất cả. Thật ra, thường thì bạn có một cron job đi qua và review những thứ này.

![Pull request bí ngô, phần ảnh Walking, two moments: nhân vật đội mũ bí ngô đang đi, và hàng ảnh bí ngô khắc chụp từ 3, 10 và 30 m ban đêm](https://homus.dev/photos/nwMNQJ_Wtw8-1322.jpg)

Cody quay lại pull request quả bí ngô (demo trong video đăng ngày 05/11/2026): mục "Walking, two moments" là hai hàng ảnh nhân vật đội mũ bí ngô đang đi; mục "The copies drawn from 3, 10 and 30 m (night): the carving stays" là ảnh quả bí khắc nhìn từ ba khoảng cách. Anh mở lại trang này khi nói về việc nhờ agent xử lý pull request.

Nhưng anh nói đó chủ yếu là cho side project. Với các project công việc ngoài đời thật, anh vẫn cố đi qua pull request và review code (theo video đăng ngày 05/11/2026). Có điều, tới một lúc nào đó, con người sẽ thành nút thắt, và bạn, tổ chức của bạn, team của bạn phải quyết định: chúng ta muốn ném thêm bao nhiêu token vào pull request để thật sự đảm bảo nó an toàn và thật sự đảm bảo nó không ảnh hưởng tới người dùng? Chúng ta có tin việc cứ thế merge mà không có người thật sự review code không?

Theo Cody (video đăng ngày 05/11/2026), đó là vấn đề nền tảng mà anh nghĩ nhiều người phải bắt đầu bàn tới: ta biết mình có thể đi cực nhanh với những công cụ này, với đủ loại vụ vi phạm bảo mật đang xảy ra ở các công ty cloud khác nhau. Anh kể Railway là một vụ, và anh nghĩ OpenCode cũng đã bị hack, rồi có người tìm cách làm distillation attack (theo lời Cody, video đăng ngày 05/11/2026). Ta phải tìm được điểm cân bằng ở giữa: ta muốn đi nhanh tới đâu? Ta muốn con người review tới mức nào?

## 14. Không chỉ đưa prompt cho Opus: skill nhiều workflow

Một điều anh chưa nhắc tới ở đây, theo Cody (video đăng ngày 05/11/2026), là chuyện này không chỉ là đưa prompt của bạn cho Opus rồi nói "chúc may mắn, xây đi". Thường thì bạn có một skill chứa nhiều workflow khác nhau. Bạn có kiểu một skill lên kế hoạch (planning skill). Bạn có kiểu một skill triển khai (implementation skill). Bạn có một skill code review riêng. Bạn có thể có nhiều sub-agent khác nhau cùng review tất cả những thứ này một lúc. Và cuối cùng nó mới tạo pull request.

![Sơ đồ đầy đủ với ba ô trống mới bên trong Software Factory, dưới ô sandbox](https://homus.dev/photos/nwMNQJ_Wtw8-1443.jpg)

Bên trong "Software Factory" có thêm ba ô trống xếp hàng dưới ô "sandbox", cạnh "context", "triggers", "knowledge base" và "skills".

Vậy một lần nữa, theo Cody, việc của bạn là đảm bảo toàn bộ pipeline này, workflow này, khi tới software factory thì vững chắc, để bạn bớt lo hơn khi cứ thế merge một pull request lúc nó được tạo. Bạn có độ tin cậy cao rằng nó ổn và bạn có thể cứ thế merge nó (theo video đăng ngày 05/11/2026).

Theo Cody, đó đại khái là hướng anh đang thấy ngành đi tới. Và một lần nữa, đây không phải ý tưởng viển vông: anh nói anh thật sự đang làm việc này ở chỗ làm, và anh biết những người khác, những công ty khác đang làm việc này (video đăng ngày 05/11/2026). Chỉ là vấn đề khi nào công ty hay team của bạn thật sự bắt đầu triển khai một thứ như thế này, để tất cả những người khác nhau đó không bị nghẽn vì phải giao tiếp với nhau. Họ giao tiếp với software factory, và nó lưu context của cuộc thảo luận để tạo ra tốt hơn thứ bạn đang cố xây.

## 15. Phần khó nhất: hiểu người dùng và business requirements

Điều cuối cùng Cody muốn nhắc: theo anh (video đăng ngày 05/11/2026), một trong những phần khó nhất khi software factory đã khá ổn là hiểu business requirements. Việc chat với người dùng và hiểu họ muốn gì vẫn là mảnh quan trọng nhất. Vì bạn có thể để AI cứ mù quáng thêm tính năng và cải thiện chỗ này chỗ kia.

Nhưng tới một lúc nào đó, theo Cody (video đăng ngày 05/11/2026), nếu bạn không thật sự hiểu những người dùng đang dùng hệ thống của bạn, không hiểu các hệ thống đang có sẵn và những rủi ro liên quan tới các hệ thống khác, hoặc bạn có thể ở trong một công ty lớn hơn có nhiều team khác nhau, mỗi team quản lý những sản phẩm riêng, thì để AI tự do hoạt động và có quyền truy cập vào tất cả những thứ đó cùng lúc có lẽ không phải ý hay.

Và có thể trách nhiệm của bạn đã lớn lên một chút vì AI khiến mọi thứ hiệu quả hơn và năng suất hơn. Nhưng theo anh, vẫn có những bức tường được dựng lên để giúp cô lập rủi ro (video đăng ngày 05/11/2026).

## 16. Hiểu các hệ thống bên ngoài, và context không phải càng nhiều càng tốt

Vậy nên bạn vẫn cần hiểu các hệ thống, những hệ thống bên ngoài mà hệ thống của bạn đang tích hợp cùng. Theo Cody (video đăng ngày 05/11/2026), đó là hai thứ anh thấy đã trở thành trọng tâm chính lúc quay video: hiểu 100% nhu cầu người dùng của bạn là gì, và hiểu 100% cách các hệ thống bên ngoài bạn tích hợp cùng hoạt động.

![Sơ đồ với vòng tròn user phóng to bên phải và một vòng tròn mới externals systems bên dưới](https://homus.dev/photos/nwMNQJ_Wtw8-1643.jpg)

Cuối video (đăng ngày 05/11/2026), vòng tròn "user" được phóng to và bên dưới có thêm một vòng tròn ghi "externals systems": hai thứ Cody nói đã thành trọng tâm chính.

Và một lần nữa, bạn có thể dùng AI để giúp lấy được những thông tin đó. Nhưng Cody nói anh nhận thấy nếu cứ ném càng nhiều context càng tốt vào Opus, nó vẫn bị rối một chút và lạc hướng một chút (theo video đăng ngày 05/11/2026). Nên phần khó lúc này, và việc này vẫn luôn khó, là hiểu business requirements để bạn có thể prompt đúng cách và dựng context trong knowledge base đúng cách, để mỗi sandbox chạy Opus đều thành công hơn chừng đó.

Cody nói anh mong mọi người thích bài nói này, anh muốn làm một lượt đi qua thuật ngữ software factory mà mọi người đang nghe tới vào thời điểm video đăng (05/11/2026). Anh chúc mọi người một ngày tốt lành và happy prompting.

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

- Tên gốc: Stop Writing Code. Build a Software Factory Instead.
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=nwMNQJ_Wtw8](https://www.youtube.com/watch?v=nwMNQJ_Wtw8)

- Kênh YouTube Web Dev Cody (Cody Seibert): [youtube.com/channel/UCsrVDPJBYeXItETFHG0qzyw](https://www.youtube.com/channel/UCsrVDPJBYeXItETFHG0qzyw)

- Repo skills của Matt Pocock, skill "retro" với mô tả "Conduct a retrospective on a coding session", gợi ý cải thiện môi trường của coding agent cho những lần chạy sau (đọc ngày 07/11/2026): [github.com/mattpocock/skills/tree/main/skills/engineering/retro](https://github.com/mattpocock/skills/tree/main/skills/engineering/retro)

Nguồn: https://homus.dev/talks/stop-writing-code-build-a-software-factory-instead · cập nhật 2026-11-07