Dựng một software factory chạy bằng agent: đi sâu

1. Software factory: phần mềm tự cải thiện

Steve Sewell (Builder.io) mở đầu bằng một câu khẳng định: thứ khiến anh hào hứng nhất trong phát triển phần mềm lúc này là software factory. Nói theo nghĩa đen, đó là phần mềm tự cải thiện (self-improving software): khi bạn thu thập feedback và telemetry, phần mềm tự động tốt lên.

Anh kể đã dùng cách làm này trong vài tháng gần đây để đẩy giới hạn xem có thể tự động hoá tới mức nào: gửi bug và các cải tiến thẳng qua các agentic loop, và nhận về phần mềm tốt hơn ở đầu bên kia. Đồng thời anh luôn bảo đảm có những điểm chạm của con người (human touchpoint) để canh gác và tiếp quản bất cứ lúc nào, nhiều tới mức cần thiết.

Anh đã open source một bộ skill mà bạn có thể dùng ngay hoặc tuỳ biến, để chạy software factory của riêng mình từ Codex, Claude Code hay bất kỳ công cụ nào bạn chọn. Mọi thứ đều tuỳ biến và cấu hình được. Phần còn lại của video là anh đi qua cách nó hoạt động.

2. Vòng lặp cơ bản: feedback, agent, PR, ship

Tóm gọn, đây là một vòng lặp khá đơn giản. Ta muốn lấy mọi feedback hay telemetry, ví dụ lỗi trên Sentry, error log, các chỉ số hiệu năng và uptime, rồi lọc ra những thứ sửa được một cách kiểm chứng được (verifiably fixable). Nghĩa là một agent có thể tự tái hiện vấn đề, viết bản sửa, kiểm chứng bản sửa đúng, và gửi một pull request.

Những việc như vậy, ta chỉ muốn tự động giao cho agent. Các agent đó có thể chạy ngay trên máy tính của bạn, bằng Codex, Claude Code hay công cụ bạn thích. Khi bản sửa đã được kiểm chứng, chúng mở pull request.

Sau đó hệ thống quyết định PR này cần con người review, hay chỉ cần một agent ngang hàng (peer agent) review là đủ. Khi CI, agent review và (nếu có) human review đều qua, phần mềm được ship và vòng lặp bắt đầu lại.

Tất nhiên có những điều khá quan trọng phải làm để bảo đảm bạn không thực sự làm hỏng mọi thứ, hay làm chất lượng code tệ đi. Đó là lý do anh sẽ đi qua workflow thật mà anh dùng, với những skill thật, mỗi ngày.

3. Agent-Native: những app không hề nhỏ do factory build

Theo Steve, phần lớn công việc trên project open source Agent-Native của anh được build bởi các software factory tự động. Chúng lấy input từ GitHub issue, feedback trong app, feedback nội bộ và các nguồn khác, rồi kiểm chứng và đẩy bản sửa vào framework. Ngoài framework còn có một loạt app agent-native được host mà nhóm anh build và duy trì: tạo design theo kiểu agentic, slides, analytics, một bản thay thế Loom, mail, calendar, đủ thứ.

Các app này đều miễn phí và open source, nên bạn có thể tự đọc code, và chúng không hề tầm thường. Chúng làm những việc như chỉnh sửa và tạo design đầy đủ kiểu Figma, chỉnh slide như Google Slides, quản lý lịch, bạn kể tên gì cũng có.

Chúng cũng rất hiện đại và hoàn toàn agentic: mọi việc UI làm được thì agent cũng làm được. Bạn có thể dùng chúng như những agent thuần hình ảnh, hoặc như những UI thuần tuý, nhưng tốt nhất là trộn một chút cả hai.

Vậy đây không phải app nhỏ. Chúng được build theo những cách khá mới, nhưng phần lớn thời gian của Steve lại dành cho việc thiết kế, tối ưu và đánh giá các hệ thống build phần mềm, chứ không phải tự viết code. Nhóm của anh cũng tập trung vào đúng việc đó. Rồi anh quay lại từ đầu để chỉ cách mọi thứ vận hành.

4. Input sources và skill factory collect

Mọi thứ rốt cuộc bắt đầu từ input sources (nguồn đầu vào). Nếu làm theo cách truyền thống, đội product và đội engineering sẽ xem feedback được gửi qua Slack, qua chính sản phẩm, hay qua phỏng vấn khách hàng. Bạn cũng nhìn vào các vấn đề trong telemetry: uptime có giảm không? Thời gian phản hồi P90 có tăng không? Có đợt tăng vọt lỗi mới trên Sentry không? Hoặc với một project open source như của anh: có GitHub issue và PR nào đang được gửi lên không? Tất cả những thứ đó trở thành input để ta bắt đầu ra quyết định.

Đó là lúc skill đầu tiên vào cuộc: factory-collect. Việc đầu tiên nó làm là thu thập và xem xét các input source này theo một vòng lặp. Vì thế Steve có rất nhiều thứ như vậy chạy dưới dạng scheduled task. Anh dùng Codex cho việc này, và cách làm y hệt cũng chạy được trong Claude Code. Anh hơi nghiêng về Codex, lý do sẽ nói sau, nhưng thật ra không quan trọng: coding agent nào bạn dùng cũng nên có cách lên lịch task chạy mỗi giờ, mỗi ngày, hay theo nhịp nào tuỳ bạn.

Skill factory-collect của anh chạy mỗi vài giờ. Nó gom từ tất cả các input đó, rồi cho chúng đi qua một policy. Trong danh sách scheduled task của Codex, anh có những task như "Review latest feedback and ship" chạy theo lịch riêng, hàng loạt task babysit PR chạy mỗi 2 phút, và những task watchdog chạy mỗi vài phút.

5. File YAML cấu hình và fix policy

Toàn bộ được cấu hình trong một file YAML: bạn liệt kê các source, tự tạo source mới, rồi đặt chúng vào các workflow. Steve hứa sẽ giải thích một số mục sau, nhưng điều quan trọng cần biết là bạn cũng có thể thêm prompt vào bất kỳ mục nào. Tức là cấu hình thật chính xác, hoặc chỉ áp prompt bằng ngôn ngữ tự nhiên, hoặc cả hai.

Nội dung file mẫu trên màn hình, gồm cả phần cuối với skill_prompts:

version: 1
timezone: UTC

sources:
  - id: support
    provider: slack
    scope: channel-id
  - id: product-events
    provider: custom
    scope: product-name
    integration: analytics-mcp
    read_tool: query_events
  - id: runtime-errors
    provider: sentry
    scope: organization/project

workflows:
  collect:
    enabled: true
    schedule: every 4 hours
    sources: [support, product-events, runtime-errors]
    implement:
      mode: criteria
      allow: [verified defects in owned code]
      stop: [unclear product intent, security-sensitive changes]
    reply:
      mode: never
  lookback:
    enabled: true
    schedule: monthly
    window: last 30 days
    compare_with: previous 30 days
    sources: [support, product-events, runtime-errors]
    implement:
      mode: manual

skill_prompts:
  factory-ship: |
    Keep release summaries concise and link the verified change.

Bên dưới, README giải thích skill_prompts là một map mở: mỗi skill Factory đọc mục trùng tên mình và xếp đoạn text đó lên trên chỉ dẫn bình thường của nó; nó không ghi đè được yêu cầu hiện tại của người dùng.

Mặc định, các factory của Steve có một fix policy đơn giản. Nếu đó là một vấn đề rõ ràng và kiểm chứng được, tức một agent có thể tự tái hiện vấn đề, sửa nó, kiểm chứng bản sửa rồi gửi PR, thì policy cho phép. Khi đó, trong Codex, nó tự tạo một worktree cô lập (isolated worktree), làm verification, viết bản sửa, rồi mở hoặc cập nhật PR.

6. Vì sao chọn Codex: Luna rẻ, còn verification thì tốn token

Lý do Steve hơi nghiêng về Codex cho việc này là model Luna rẻ đến mức điên rồ: bạn có thể chạy factory ở khối lượng rất lớn mà gần như không tốn gì. Anh tạo ra hàng chục PR được merge mỗi ngày, theo đúng nghĩa đen, tất cả chạy bằng Luna ở mức thiết lập max, và vẫn không chạm giới hạn của tài khoản ChatGPT Pro 200 đô la của anh (theo video đăng ngày 23/09/2026). Anh thấy vậy là tuyệt vời.

Cách này cũng chạy được với Claude, nhưng anh nói bạn sẽ chạm giới hạn. Và nếu factory của bạn chạy ở quy mô lớn, chi phí bắt đầu trở nên quan trọng.

Nhất là khi tính tới chuyện verification cực kỳ then chốt: nhiều thứ phải được kiểm chứng end-to-end trong trình duyệt, và việc đó ngốn token, vì mỗi lần đều phải tự động hoá, chụp màn hình, tái hiện và kiểm chứng. Nhưng như bạn có thể đoán, phần verification là bắt buộc.

Bạn không muốn agent chỉ đoán mò rồi ném lên một PR cho bất cứ thứ gì chúng nghĩ có thể sửa được. Ta phải biết vấn đề đã được tái hiện, đã được sửa, trước khi có bất kỳ PR tự động nào từ factory.

Còn nếu có gì không khớp policy, nó đi hẳn sang nhánh bên kia và tới tay con người. Input dành cho con người được gom lại riêng theo đợt, bằng một automation khác mà anh sẽ quay lại sau.

7. Nhiều lớp review và skill factory babysit PR

Khi agent đã tạo PR, một skill và automation khác vào cuộc: Steve có một automation chạy mỗi vài giờ để review các PR. Điều quan trọng cần lưu ý là có nhiều lớp review ở đây.

Nếu mở một pull request trong repo Agent-Native, bạn sẽ thấy các comment từ review bot tiêu chuẩn được đẩy vào. Nhóm anh có agent riêng cho việc này, nhưng bạn hoàn toàn có thể chạy nó trên Claude Code hoặc Codex bằng một skill và một vòng lặp.

Agent gửi PR dùng skill factory-babysit-pr để theo dõi PR đó. Nó bắt buộc phải kiểm chứng và xử lý từng comment hay từng lần CI fail. Nếu nó kiểm chứng và đồng ý với comment, tức comment phù hợp với ý định ban đầu và đúng là một vấn đề thật, nó sửa và comment lại. Trong trường hợp này, vì chạy từ Codex, nó comment dưới tên của chính Steve. Còn nếu không đồng ý, nó chỉ trả lời lý do vì sao sẽ không làm.

8. Review PRs và approval policy

Sau đó, một agent review PR riêng (skill factory-review-prs) xem qua các PR đang mở: bảo đảm mọi thứ đã được xử lý, CI đã qua, không có merge conflict, rồi gọi tới một approval policy.

Approval policy do bạn tuỳ biến bằng config và prompt, và về cơ bản nó quyết định: ta có ổn với việc PR này tự merge và deploy không? Ví dụ vì nó có test kỹ lưỡng, đã được kiểm chứng rõ ràng, và được đánh giá là tương đối an toàn: đó là một bản sửa CSS, hay một bản sửa rất dễ unit test, đại loại vậy. Hay nó cần con người review?

Nếu cần human review, nó chờ con người review rồi mới merge. Nếu được phép, nó được ship end-to-end. Đó là workflow siêu cơ bản: collect, babysit, review, ship, lặp lại. Ở bất kỳ điểm nào mà policy không khớp, việc đó được để sang một bên cho con người, bằng cách tag họ hoặc gom lại cho họ.

Trong README, danh sách skill gồm /factory (experimental, cấu hình source, prompt, lịch và delivery policy), rồi /factory-collect, /factory-babysit-pr, /factory-review-prs, /factory-ship, /factory-lookback, /factory-watchdog và /factory-recover (tiếp tục việc bị gián đoạn khi quyền và worktree vẫn còn hợp lệ).

9. Khi issue chưa đủ rõ: agent tự hỏi thêm

Steve chỉ ra thêm vài sắc thái. Chẳng hạn khi collect, nếu issue chưa đủ rõ thì sao? Đó là lúc skill collect có thể tuỳ chọn hỏi lại (follow up). Nếu cần thêm thông tin, nó tự động đăng comment xin thêm, ví dụ: bạn có thể ít nhất cho biết URL bạn đang ở, hay chuyện này xảy ra lúc mấy giờ để chúng tôi tra error log được không. Phần này bạn tuỳ biến hoàn toàn.

Trong nhiều trường hợp anh phải ghi rõ tin này được gửi từ một bot, vì nó đến từ Codex hoặc Claude Code nhưng dùng thông tin đăng nhập của anh, tức là hiện dưới profile của anh. Skill cũng biết quay lại kiểm tra xem các câu hỏi làm rõ trước đó đã được trả lời chưa, và giờ đã đủ rõ để nhận việc chưa; nếu rồi thì nó sẽ nhận.

10. Chạy trên cloud hay trên laptop: một chiếc laptop thứ hai

Trước khi sang các automation sâu hơn, bạn có thể hỏi: chạy cái này trên cloud có tốt hơn không? Một dịch vụ cloud nào đó chạy cả khi laptop đóng? Hay nên chạy trên máy local, nghĩa là nó không chạy khi máy tắt hoặc ngủ?

Steve thừa nhận đã đổi qua đổi lại chuyện này như điên. Câu trả lời dứt khoát của anh lúc này là phải chạy trên laptop, vì để thực sự kiểm chứng, nó cần đúng môi trường của anh. Nó cần chạy trên chiếc Mac của anh, với các file env, các key, các phiên đăng nhập trình duyệt của anh.

Khi nó bị kẹt, anh cần nhìn được màn hình và nhập OTP, hoặc bấm đăng nhập bằng passkey, hoặc trong một số trường hợp nhóm đang phát triển app native cho Mac. Rốt cuộc, anh liên tục vất vả để bắt các hệ thống cloud tái tạo môi trường của mình cho hiệu quả, và anh chỉ cần nó chạy trên môi trường của anh.

Nhưng đúng là rất phiền khi thứ này đang chạy, nhất là khi nó làm nhiều việc, trong lúc anh cố làm việc song song. Giải pháp mới nhất của anh là một chiếc laptop thứ hai, đặt ngay bên cạnh. Chiếc laptop đó bật 24/7, luôn online, và chạy các vòng lặp này cả ngày lẫn đêm.

Nếu nó bị chặn ở đâu, nó nhắn Telegram cho anh: cần một key, cần đăng nhập, cần thứ gì đó. Anh chỉ việc nhìn sang bên, đăng nhập, rồi để nó chạy tiếp. Anh cũng có thể liếc sang kiểm tra, xem nó có làm đúng không.

11. Codex remote, SSH của Claude Code, và Luna ở mức max

Điều Steve thích ở Codex là anh thấy được tất cả remote task và worktree ngay trong giao diện; chúng đều có biểu tượng quả địa cầu màu xanh. Thực tế, trong Codex anh dùng tính năng remote để làm toàn bộ việc code trên chiếc laptop kia. Mỗi khi có ý tưởng và muốn tạo một branch hay một worktree, anh gõ vào laptop chính, còn việc thì chạy trên laptop kia.

Vì vậy chiếc laptop đó thường xuyên bị quá tải, ngốn nhiều bộ nhớ, chạy nhiều trình duyệt song song. Trên laptop chính, anh vẫn chạy và làm mọi cuộc chat, nhưng CPU và bộ nhớ không bao giờ bị kéo chậm. Anh gọi đó là thứ thay đổi cuộc sống.

Anh dùng cách này cả với Codex lẫn Claude Code. Với Claude Code, đó là tính năng SSH: anh SSH sang chiếc laptop bên cạnh. Nhưng anh thích bản của Codex hơn, vì với SSH, ít nhất là qua mạng local của anh, anh chỉ truy cập được chiếc laptop kia qua Claude khi cả hai ở cùng một mạng. Còn với Codex, khi đi công tác hay khi laptop chính đóng, anh vẫn mở ra, xem và quản lý Codex được.

Ngoài ra, vì token của Codex quá rẻ, anh mặc định dùng Codex. Theo anh, Luna là một model tốt đến bất ngờ, nhất là cho loại việc này, nhất là khi có guardrail rõ ràng từ các skill để luôn tập trung vào verification, verification, verification. Anh cũng luôn dùng nó ở mức thiết lập max, vì ở mức max Luna mạnh và rẻ đến bất ngờ: hiệu năng ngang Opus với giá chưa tới một phần mười, theo đúng lời anh, và token ra nhanh hơn nhiều.

12. Một model khác giám sát thread: watchdog cho việc khó

Nhưng có những việc khó và cần giám sát nhiều hơn. Đó là lúc Steve dùng một skill watchdog (anh gọi là factory watchdog; trên màn hình, anh gõ /watch và menu slash command gợi ý agent-watchdog). Với việc anh biết là khó hơn hay sâu hơn, anh lấy thread đó: bấm chuột phải, Copy, Copy deep link. Rồi anh sang một chỗ khác, gọi skill watchdog, đưa cho nó cái link và để nó chạy. Trong video anh dừng lại giữa chừng vì lúc đó không thực sự muốn chạy.

Thứ này sẽ theo dõi thread kia và nhắn vào thread đó với chỉ dẫn. Nó tự kiểm chứng công việc một cách độc lập, bảo đảm thread làm đúng việc, và trao đổi với thread để chắc rằng Luna luôn làm đúng việc theo đúng cách. Steve thấy sự giám sát đó cực kỳ giá trị và hiệu quả. Anh cũng thấy rằng với một gói ChatGPT Pro và một gói Claude Max, anh làm được khối lượng việc khổng lồ mà chưa bao giờ phải trả thêm phí vượt mức.

Anh thường dùng Fable cho việc giám sát đó, nhưng Opus 5.5 mới nhất có lẽ cũng đã đủ tốt. Khi phân vân, anh có một skill riêng tên efficient-frontier, chỉ để nhắc model spawn các sub-agent chi phí thấp, như Sonnet, Luna hay gì đó, càng nhiều càng tốt để tiết kiệm.

Steve gói lại: đó là phần cơ bản của một factory. Nhưng phần quan trọng là phần tiếp theo: điều gì có thể sai, và làm sao để mọi thứ đi đúng nhiều nhất có thể. Anh đi xuống xem thêm vài automation chạy trên host scheduler, tức là các automation hay loop của Claude, hoặc automation hay loop của Codex.

13. Factory watchdog: đẩy những việc bị bỏ dở

Anh nhắc lại rằng watchdog có thể dùng theo rất nhiều cách để bảo đảm có giám sát: một model hoàn toàn khác, do một công ty khác huấn luyện, đưa ra sự giám sát và chỉ dẫn cho cái factory dựa trên GPT đang làm việc hằng ngày.

Nhưng còn một vấn đề khác khiến anh phát điên. Khi bạn spawn rất nhiều worktree Luna và bảo chúng làm theo factory, có rất nhiều trường hợp chúng đơn giản là không làm. Chúng quên, hoặc dừng, hoặc không đi tới cùng. Đó là việc của factory-watchdog.

Anh chạy factory watchdog khoảng bốn lần mỗi ngày, và toàn bộ việc của nó là xem lại những việc đã làm, còn hành động được, nhưng vì lý do nào đó không đi tới bước tiếp theo. Ngày nào cũng có vài trường hợp như vậy: một PR đã tạo mà không bao giờ được ship hẳn, chẳng hạn.

Nên nó nhìn lại các thread, phát hiện những trường hợp đó, và thúc chúng cho tới khi xong. Với anh, skill này đã cứu mạng: anh từng phí rất nhiều thời gian vì tưởng một việc đang được làm trong khi thật ra không ai làm.

14. Factory lookback: tìm pattern lặp đi lặp lại

Cái bẫy lớn còn lại là pattern tái diễn. Có những trường hợp cùng một vấn đề cứ xuất hiện đi xuất hiện lại, và agent nghĩ chúng đang sửa nó hết lần này tới lần khác, nhưng thật ra không. Vì vậy mỗi tuần một lần, Steve chạy skill factory-lookback.

Factory lookback nhìn lại tuần vừa qua và hỏi: cùng một feedback có bị báo đi báo lại, kể cả sau khi ta tưởng đã sửa? Ta có liên tục nhận cùng loại báo cáo P90 không? Hay có những vùng mong manh (brittle): ta sửa, rồi nó hỏng lại, rồi ta sửa, rồi nó lại vỡ? Ta muốn phát hiện những pattern đó và bảo đảm tìm được bản sửa tổng thể.

Khi lookback tìm ra một pattern, nó giao việc cho một model lớn hơn như Sol, Opus hay Fable. Model lớn hơn đó được giao quét rộng hơn nhiều trên các input source, spawn sub-agent để xem qua những khoảng thời gian dài, những khoảng bạn cấu hình được, như cửa sổ thời gian và so sánh 30 ngày gần nhất với 30 ngày trước đó, để tìm ra các vấn đề tái diễn và bảo đảm có giải pháp tốt.

Nó đào sâu hơn nhiều: thử so sánh lỗi, log và feedback khách hàng để khoanh vùng (triangulate) ra một giải pháp tổng thể hơn. Steve thấy cách này giúp rất nhiều. Trong framework Agent-Native từng có lúc phần chat cứ mong manh, liên tục báo lỗi, làm anh phát điên. Cũng có những trường hợp cùng một kiểu lỗi kéo thả cứ quay lại mãi trong app design.

Cái hay của việc có input source có cấu trúc và các luồng factory có cấu trúc là bạn có thể làm meta-analysis hoàn toàn tự động: cái gì đang sai một cách hệ thống ở đây? Sửa nó thế nào, rồi quay lại kiểm chứng rằng loại feedback này đã thực sự giảm, hay lỗi hoặc chỉ số P90 đã thực sự đi xuống. Đó mới là mục tiêu cuối cùng ta cần thấy, và chính những input và luồng có cấu trúc, được nối với nhau, cho phép làm điều đó hiệu quả đến bất ngờ.

15. Làm nhà khoa học quan sát một sinh vật

Các skill này còn nhiều sắc thái khác. Ví dụ, khi thu thập feedback, nó cũng đã biết nhìn lại xem feedback này từng được báo trước đây chưa, và tính điều đó vào theo nhịp hằng ngày. Nên nếu một bản sửa tưởng là đúng đã được ship mà feedback vẫn tiếp tục, nó biết phải chọn một trong ba hướng: A, đào sâu hơn và kiểm chứng kỹ hơn lần này; B, hỏi con người thêm input để xác nhận, kiểu như "ta có thực sự hiểu đúng vấn đề không?"; hoặc C, nghiêng hẳn về để con người quyết định.

Rốt cuộc, Steve nói anh dành phần lớn thời gian với cảm giác mình là một nhà khoa học đang nghiên cứu một sinh vật: luôn quan sát, soi kính hiển vi và đánh giá xem factory có đang chạy hiệu quả nhất có thể không. Nó có giao cho con người những gì cần giao không? Nó có lãng phí ít thời gian của con người nhất có thể không? Nó có ra quyết định tốt, sửa tốt, cải tiến tốt không? Và cuối cùng, nó có tiết kiệm cho anh và nhóm thật nhiều thời gian không?

Để họ có thể build những thứ như framework Agent-Native và tất cả các ứng dụng chạy trên đó, và cho chính mình cùng người khác làm những thứ hay ho, như hệ thống action mà nhóm nghĩ ra: bạn định nghĩa hành vi của ứng dụng ở một chỗ, và chúng tự động dùng được trong UI, trong agent chat, qua API, qua MCP, vân vân. Đó là thứ anh muốn làm. Anh muốn làm những bài toán khó, không muốn sa vào chi tiết vụn vặt của những bản sửa nhỏ.

Nên khi có lỗi deploy lên Vercel, anh chỉ muốn nó tự xử lý. Anh thậm chí không muốn nhìn tới, miễn là hệ thống của anh chạy. Điều này biến anh, và cả nhóm, thành những system engineer nhiều hơn: bảo đảm mình đang build một hệ thống tự động có thể liên tục sửa và cải thiện mọi thứ.

16. Mẹo: monorepo, chất lượng input, beta và production

Trước khi kết thúc, Steve đưa ra vài mẹo cụ thể. Thứ nhất, rất có ích nếu toàn bộ nằm trong một monorepo. Để factory làm việc với một monorepo duy nhất, tách biệt, giúp rất nhiều.

Thứ hai, hiệu quả của factory phụ thuộc rất lớn vào chất lượng input. Hãy dành càng nhiều thời gian càng tốt để xây telemetry mạnh, các kênh feedback khách hàng, khả năng nhìn rõ lỗi gắn với đúng source code gốc, chẳng hạn bằng source map. Và thêm các lớp bổ sung: nhóm anh có bộ test end-to-end kỹ lưỡng chạy trên beta, kiểm tra hiệu năng, các luồng người dùng cốt lõi, vân vân. Những test đó bắt được các vấn đề mà nhóm không muốn dùng để chặn PR, vì chúng chạy khá lâu và khá tốn kém. Không chỉ là test viết sẵn kịch bản chạy trong trình duyệt, mà còn có agent vào test thường xuyên. Kết quả biến thành issue được tự động tạo và được xử lý ngay. Nên nếu có gì hỏng, nó bị bắt ngay lập tức.

Mẹo thứ ba là có môi trường beta và production tách riêng. Người dùng nội bộ ở Builder đều dùng môi trường beta, được tự động chuyển hướng sang đó. Beta luôn đồng bộ với main. Khi họ thấy vấn đề trên beta, vấn đề đó được tự sửa.

Mỗi ngày một lần, một bản deploy production được chuyển sang prod, nhờ vậy nhóm biết production ổn định hơn nhiều. Và nếu phát hiện một vấn đề lọt ra production, rollback rất dễ khi chỉ đẩy mỗi ngày một lần, thay vì tự động đẩy liên tục, khoảng mỗi 10 phút một lần, khi có quá nhiều PR từ agent đổ về suốt.

17. Bắt đầu nhỏ, chạy local trước

Và cuối cùng, Steve khuyên bắt đầu nhỏ. Bạn không phải bắt đầu với tất cả những thứ này. Thật ra phần cơ bản nhất chính là điểm khởi đầu của video: ta chỉ muốn có cách dễ dàng để lấy một input source, xác định một tập hữu hạn việc để giao cho agent. Bạn có thể bắt đầu thật nhỏ: thông báo lỗi rõ ràng, bảo đảm kiểm chứng được, chỉ những việc có độ tin cậy cao, và vẫn giữ quy trình human review như bình thường.

Bạn có thể dịch chuyển cán cân dần theo thời gian, và không phải phát minh lại bánh xe. Bạn vào repo skill của anh, lấy tất cả các skill này, và cái hay là đây không phải một hệ thống remote tuỳ chỉnh cầu kỳ nào cả. Tất cả chạy local được.

Nên bước số không thường chỉ là chạy local: chạy /factory-collect, nghịch cấu hình một chút và xem output. Bạn có thể bắt đầu bằng một dry run: chỉ để nó xác định những gì nó nghĩ nên sửa, rồi cho nó feedback. Vì cấu hình chỉ là một file YAML, bạn có thể để agent tự cập nhật YAML của chính nó. Bạn qua lại với skill, cho nó feedback và bảo agent cập nhật prompt, chỉ dẫn và các tuỳ chọn cấu hình, cho tới khi chạy skill đó local mà bạn thích tập issue nó quyết định nhận.

/factory-collect

Rồi thay vì tự tay làm những việc đó, hãy bảo nó làm từng việc trong worktree riêng. Bảo nó đăng PR và babysit PR. Bảo đảm bạn hài lòng với cách nó phản hồi feedback, và kiểm tra thứ tự ưu tiên giữa feedback của người và feedback của bot. Steve nói đó chính là cách anh đã bắt đầu.

Anh làm những thứ này rất thủ công: chỉ là một bộ skill cho phép anh làm những nhóm việc ngày càng lớn mỗi lần. Rồi tới lúc anh nhận ra mình gần như đang biến thành một con robot: sáng nào anh cũng chạy skill collect feedback và ship, chiều nào cũng chạy review PRs. Và anh nhận ra mình chỉ đang bấm nút.

Đến lúc đó bạn bắt đầu lên lịch task: bảo skill làm task theo lịch. Nếu không có laptop riêng để chạy, cứ chạy trên laptop chính. Đó vốn là việc bạn sẽ làm nếu làm thủ công, nên hãy bắt đầu từ đó.

Phải sau nhiều tháng chạy factory, anh mới nhận ra: ở quy mô lớn, hệ thống đang chạy rất tốt cho mình, mình cần một máy tính chuyên cho việc này. Không nhất thiết là laptop, có thể là một chiếc Mac mini hay gì cũng được. Chỉ cần bảo đảm nó có thật nhiều bộ nhớ, vì anh thấy nhiều agent cùng test trên trình duyệt có thể ngốn rất nhiều RAM.

Và khi đã đủ thành thạo, bạn có thể đi tới các workflow tự động đầy đủ và vững chắc, gồm cả lookback tự động. Nhưng một lần nữa, hãy bắt đầu bằng việc chạy lookback thủ công; nó không cần tự động ngay từ đầu. Rồi tới các watchdog tự động khôi phục việc bị kẹt.

18. Agent-Native và lời kết

"Nhưng đây là flow của tôi", Steve nói, và anh tò mò cách nào đã hiệu quả với người xem. Anh say mê ý tưởng tất cả những cỗ máy này cùng làm việc, tự động hoá quy trình cải tiến sản phẩm từ đầu tới cuối. Ý tưởng phần mềm tự cải thiện khiến anh rất hào hứng, nhưng nó có giới hạn. Bạn nên làm những gì hiệu quả với mình, và đừng làm những gì không hiệu quả.

Bạn có thể lấy, cài, fork và tuỳ biến tất cả các skill này ở repo skill của anh. Có một CLI cài đặt có thể thiết lập giúp bạn những thứ như automation và các thứ khác. README ghi lệnh cài nhanh các skill được khuyên dùng như sau:

npx @agent-native/skills@latest add

Nếu bạn đang tìm hiểu những thứ của anh, hãy xem framework Agent-Native. Theo ý anh, đó là cách tuyệt nhất để build một agent hiện nay. Agent thì tuyệt rồi, nhưng một agent đi kèm một UI được may đo riêng, liền mạch hoàn toàn, theo anh mới là tương lai tuyệt vời phía trước.

Nếu chưa sẵn sàng build gì, bạn vào AgentNative.com, xem các app và dùng thử vài cái. Theo đúng lời anh, có một bản thay thế miễn phí cho Loom, cho Figma, cho Google Slides, cho công cụ BI bạn đang dùng, cho lịch, cho mail kiểu Superhuman, cho Notion, đủ thứ. Tất cả miễn phí và open source, không tốn gì để dùng, tuỳ biến vô hạn, và bạn muốn làm gì với nó cũng được.

Nếu bạn thử những thứ này, anh rất muốn nghe feedback và quan điểm của bạn về agent factory nói chung: bạn có thích cách tiếp cận của anh không, có cách nào tốt hơn không. Anh mời người xem để lại ý kiến trong phần bình luận và cảm ơn mọi người đã xem.