Thôi tự code, hãy xây software factory

1. Mở đầu: Astra, Opus 5.5 và câu hỏi con người sẽ làm gì

David Ondrej mở đầu bằng lý lịch của mình: trong bốn năm qua anh đã dành hơn 2.000 giờ để code cùng AI, và đã tự phỏng vấn một số người "thật sự có thực lực" trong giới AI. Trên màn hình là trang GitHub của anh, ghi anh là founder của Cloudroom, và trang kênh YouTube với dòng tóm tắt: hơn bốn năm, hơn 2.000 giờ code với AI, đã phỏng vấn những người hàng đầu trong ngành.

Anh liệt kê những gì video sẽ đi qua: agent đang thay thế công việc của con người ra sao; một cách hoàn toàn mới để khởi động agent; vì sao agentic loop và software factory là điều tất yếu trong tương lai; vì sao cloud agent đang thay thế local agent và vì sao cloud là tương lai; công việc của anh và của bạn sẽ trông thế nào sau 12 tháng nữa. Gần cuối video, anh sẽ cho xem trực tiếp cách dựng một "mini software factory" từ con số không, và cách chính anh đang làm việc đó.

Điểm xuất phát của anh: công việc với agent đang tiến hoá. Nó không còn là chuyện ngồi chat qua lại với Claude Code hay với Codex nữa. Theo anh, mọi thứ đã thay đổi khi Astra (GPT-6 Astra của OpenAI) và Opus 5.5 ra mắt. Nhiều người có uy tín đã nói Astra là AGI; trên màn hình là một bài đăng trên X của Jensen Huang, ngày 6/9/2026, viết rằng GPT-6 Astra được huấn luyện trên khoảng 100 nghìn hệ NVIDIA Grace Blackwell NVL72, "AGI has arrived", và sắp có thêm 400 nghìn GPU đi vào hoạt động.

Dù Astra có phải AGI hay không, theo David bằng chứng đã nằm đó. OpenAI vừa đưa lên một repo vài ngày trước (trên màn hình là repo openai/math và bài "Sharing AI progress in mathematics"), và rất nhiều nhà toán học đang "phát điên" vì họ vừa công bố khoảng 370 chứng minh cho những bài toán chưa có lời giải suốt nhiều thập kỷ, có bài suốt nhiều thế kỷ.

Anh nói thẳng: anh sẽ không nói dối bạn, tất cả chúng ta đều đang bị thay thế. Lập trình viên, người dựng video, nhà toán học, graphic designer, người làm content. AI làm được ngày càng nhiều thứ. Vậy câu hỏi đặt ra là: con người rốt cuộc sẽ làm gì? Anh hứa sẽ trả lời ở phần sau, vì đây là một câu hỏi mang tính sống còn khiến rất nhiều người mất ngủ. Theo anh, thực ra có một câu trả lời rất rõ và một con đường rất rõ phía trước, chỉ là nhiều người chưa nghĩ cho thấu.

2. Con người vẫn hơn agent ở đâu

Trước hết, con người vẫn giỏi hơn agent ở rất nhiều thứ. David thừa nhận điều này có vẻ hiển nhiên, nhưng anh muốn nói cho rõ. Về nhiều mặt, các LLM vận hành "máy móc" hơn: bạn đưa vào một input, nó làm một số việc nhất định. Nó không tự sinh ra input, không tự mang theo một mục tiêu định sẵn, không bất chợt nảy ra một ý nghĩ ngẫu nhiên giữa chừng. Bạn có thể nhìn thấy cả chuỗi reasoning của nó, và chuỗi đó đến từ training data. Trên màn hình anh minh hoạ bằng một model đang "Thought for 22 seconds" trước một câu hỏi, rồi in ra phần "Intermediate reasoning steps" và "Final Output".

Bảng vẽ "Humans > Agents" liệt kê những thứ con người giỏi hơn:

• Creativity, tư duy mới lạ, sáng tạo.
• Intuition, trực giác và bản năng. Lý do là suốt cuộc đời, chúng ta đã "nhìn thấy" vô số token: token âm thanh, token từ giác quan, token từ xúc giác, những thứ hoàn toàn không có trong training data. Chúng không tồn tại dưới dạng văn bản trên internet, và cái gì không có trong training data thì agent và model làm kém.
• Being practical, tính thực tế (bảng vẽ gạch chân hai lần). Nếu bạn có một task coding lớn mà chỉ còn một giờ để xong, agent không hiểu điều đó có nghĩa là gì. Nó không biết nói "thôi bỏ qua mấy chi tiết này" hay "đừng nhồi repo này đầy test vô tận". Nó thiếu sự thực tế và khả năng phân bổ nguồn lực hợp lý.
• Taste, gu thẩm mỹ. Ai cũng có thể dùng AI để dựng 1.000 app hay sinh hàng trăm hình ảnh, nhưng chỉ một cái sẽ viral, chỉ một vài cái kiếm ra tiền. Biết cái gì là tốt, cái gì làm nên một sản phẩm tuyệt vời, một thumbnail YouTube tuyệt vời, một bài hát tuyệt vời: đó là taste, và model không có nó. Những người có taste sẽ làm những việc đó tốt hơn.

Bảng vẽ ghi tiếp: "models just don't have these" và "stop holding on to what LLMs do better", kèm một dòng chữ nhỏ màu tím "people struggle to articulate this". Bên cạnh là hình vẽ một người đang vẩy sơn xanh lên toan và một con robot đứng cạnh dây chuyền.

Vì vậy, David khuyên hãy thôi bám vào những việc LLM làm tốt hơn. Nếu bạn vẫn đang cố viết code từng dòng một thay vì dùng Codex hay Claude Code, anh "không biết phải nói gì với bạn nữa": bạn giống hệt người cố làm nghề trực thang máy khi thang máy tự động đã được bán, hay người ngồi tính toán bảng tính bằng tay khi máy tính và máy tính bỏ túi đã ra đời. Hãy làm những việc con người giỏi hơn và để agent làm phần còn lại, nếu không bạn sẽ có một quãng thời gian rất tệ.

3. Nhìn lại quá khứ: nông nghiệp, "human computer" và tổng đài viên

Để hiểu tương lai đang đi về đâu, theo David, nhìn lại quá khứ rất có ích, và nông nghiệp là một phép so sánh tuyệt vời. Thế giới 200 đến 250 năm trước trông như thế này: ở Mỹ năm 1800, hơn 75% người lao động làm nông nghiệp, tức là đại đa số dân số. Ngày nay con số đó dưới 2%, vậy mà lương thực lại nhiều hơn bao giờ hết. Vì sao? Nhờ công nghệ.

Anh đưa lên hình vẽ hai nửa: bên trái là những người nông dân cúi gập người cuốc đất bằng tay, bên phải là một chiếc máy kéo cày cả cánh đồng. Nhìn bức hình bên trái, anh thấy chính chúng ta hôm nay: click khắp nơi, điền form, nộp hồ sơ xin giấy tờ, làm thuế, làm kế toán. Bức hình bên phải chính xác hơn, dù dĩ nhiên nó chưa thể hiện đúng cách chúng ta sẽ làm việc với agent và điều phối chúng; phần đó anh sẽ nói ngay sau.

Tóm lại, TL;DR của anh là: đừng sợ. Thôi đừng hoảng như thế. Trong quá khứ chúng ta đã đi qua nhiều cuộc cách mạng công nghiệp kiểu này. "Human computer" là một ví dụ: ai cũng tính toán bằng tay, có cả những toà nhà 15 tầng mà tầng nào cũng là người ngồi làm toán bằng tay. Màn hình chiếu ảnh đen trắng các phòng máy tính đời đầu và những người phụ nữ vận hành bảng điều khiển. Con người luôn thích nghi. Nếu có một quy luật xuyên suốt hàng chục, hàng trăm nghìn năm lịch sử của chúng ta, thì đó là chúng ta luôn thích nghi.

Rồi anh chuyển sang câu hỏi chính: tương lai của công việc trông thế nào? Anh gọi đó là "higher level work", công việc ở tầng cao hơn, vì nếu những task chúng ta làm hôm nay bị thay thế thì ta cần biết mình sẽ làm gì, và nhiều người chưa thấy rõ điều đó. Phần này nói về việc công việc tầng cao sẽ ra sao khi mọi thứ ta làm hôm nay đã được thay thế.

4. Bậc thang công việc: từ tự làm tới vận hành nhà máy

David dùng một hình vẽ bậc thang để minh hoạ. Hôm nay, bạn chỉ đơn giản là làm task: ngồi trước máy tính và làm một việc cụ thể. Nếu bạn xem kênh của anh, hy vọng là bạn đã chạy agent: Codex, Claude Code, Cursor, Pi, Hermes, bất kỳ cái gì. Như thế đã tốt hơn tự làm task, vì bạn tương tác với agent rồi để nó làm. Phần lớn mọi người đang ở đây, theo đúng nghĩa đen là kẹt ở bậc một hoặc bậc hai.

Nhưng ta cần đi lên các bậc tiếp theo. "Đã đến lúc rồi, thật sự đã đến lúc." Bậc kế tiếp là thiết kế agentic loop, và sau đó là vận hành agent factory. Càng đi về góc trên bên phải của hình, công việc càng ít thủ công, ít lặp lại, và càng độc đáo, sáng tạo, trừu tượng hơn.

Anh nói cụ thể: trong tương lai, bạn sẽ không còn khởi động agent từng cái một. Đó là chuyện của quá khứ. Năm 2024, 2025, thậm chí ba quý đầu của 2026, làm vậy vẫn ổn. Bây giờ thì không ổn nữa. Khoảng cách đang nới rộng, và anh sẽ có một phần riêng về điểm này ở cuối video: khoảng cách giữa những người thật sự ở cutting edge và những người chỉ dùng AI "tàm tạm" sẽ ngày càng lớn.

Hãy nghĩ tới người tiêu dùng trung bình. Họ đang dùng gì? Bản miễn phí của ChatGPT, tính năng AI search miễn phí của Google. Họ đang dùng những model tệ hơn rất nhiều so với Opus 5.5 ở mức extra high hay max. Còn trong tương lai, theo David, chúng ta sẽ thiết kế những thứ chạy theo lịch.

5. Con người phải rời khỏi vòng lặp

Những agent đó sẽ không do bạn hay tôi khởi động. Bất cứ thứ gì có con người tham gia đều bị nghẽn. Giống như một doanh nghiệp: CEO không thể dính vào mọi chuyện. Ông ấy không thể quyết khi nào lau sàn, khi nào khoá sổ kế toán, khi nào sa thải một nhân viên junior, khi nào dừng một chiến dịch marketing. Với một công ty 5.000 người, CEO không thể tự làm hết. Màn hình chiếu một loạt ảnh minh hoạ: một giám đốc ôm đầu giữa đống giấy tờ, chiếc xe lau sàn, cuốn sổ kế toán, một nhân viên trẻ, một văn phòng khổng lồ, một CEO bị cả đám người vây lấy.

Bạn phải nhận ra rằng chẳng bao lâu nữa, mỗi người chúng ta sẽ có một "công ty 5.000 thực thể". Chỉ một số là người, phần lớn sẽ là agent. Nên tốt nhất là hãy giỏi quản lý đi.

Một điều nữa cần hiểu: AI là một lĩnh vực đã 80 năm tuổi, và rất nhiều đột phá đến từ việc bắt chước sinh học và con người. Neural network được mô phỏng theo bộ não (màn hình chiếu bài báo năm 1943 "A Logical Calculus of the Ideas Immanent in Nervous Activity" của Warren McCulloch và Walter Pitts, cùng hình vẽ tế bào thần kinh). Và lúc này (tính đến 10/2026), giới hạn của việc chạy thêm agent là bạn đơn giản không thể gỡ kẹt cho tất cả chúng, nhất là từ khi có Opus, vì nó chạy quá nhanh.

Đó thật sự là một thách thức. Nếu bạn gỡ kẹt cho agent từng cái một, thì ngay cả việc có hơn năm agent chạy cùng lúc cũng đã khó. Hình động trên màn hình cho thấy năm robot nhỏ màu cam xếp hàng, rồi chồng chất lên nhau chờ một người đứng bên cạnh. Khi bạn ngồi xuống và nhận ra vấn đề này lớn tới mức nào, điều hiển nhiên sẽ là: con người không thể nằm trong vòng lặp. Trước đây là kiểu "human in the loop", AI làm gì đó, rồi lại human in the loop.

Chúng ta cần tự rút mình ra khỏi vòng lặp. Vậy ta cần những trigger khác thay vì "con người nhận ra vấn đề": có thể là lịch chạy, webhook, sự cố ngừng dịch vụ, tính năng sản phẩm, hành vi của khách hàng. Những trigger không đòi hỏi bạn gõ phím hay nói một voice prompt. Voice prompt dĩ nhiên tốt hơn gõ, nhưng nó vẫn đòi sự chú ý của bạn, vẫn tốn thời gian của bạn, và như thế là không đủ. Sáu hay mười hai tháng trước có lẽ là đủ. Giờ thì không.

6. Công việc tầng cao hơn trông như thế nào

David bảo người xem chú ý, vì đây chính là nội dung cốt lõi của video. Anh kể rằng khi nói về chủ đề này, chính anh cũng bất ngờ: trên podcast của mình, anh luôn hỏi câu này, và khách mời thường chưa nghĩ thấu. Ngay cả những người ở frontier cũng rất chật vật khi trả lời tương lai của công việc sẽ ra sao. Anh hiểu vì sao: nó không hiển nhiên. Một vài thứ anh liệt kê là hiển nhiên, nhưng ta không biết hết. Những thứ này chỉ là phần nhìn rõ được trong màn sương; ta không biết đằng sau màn sương có gì.

Danh sách "we will": tạo agent mới, quản lý các đội agent, phân bổ nguồn lực, chọn model và harness, xây eval, và dành nhiều thời gian hơn để suy nghĩ. Dòng chữ xanh ghi "this is exactly what we'll cover in this video".

Dựa trên những gì ta biết lúc này (tính đến 10/2026), đây là những việc chúng ta sẽ làm:

• Tạo agent mới, có thể là agent được dựng riêng cho một việc cụ thể, hoặc agent đa năng.
• Ở tầng trừu tượng cao hơn nữa, quản lý các "fleet" agent: một đội agent làm marketing, một đội làm product, một đội làm customer support, và vân vân.
• Phân bổ nguồn lực. Giả sử bạn có một doanh nghiệp làm ra 50.000 đô một tháng. Bạn tiêu số đó ra sao? Bao nhiêu cho token, bao nhiêu cho lương nhân viên, bao nhiêu cho quảng cáo Facebook, bao nhiêu để đầu tư phần cứng mới? Chúng ta sẽ là người phân bổ.
• Chọn model và harness. Khi nào dùng Pi agent, khi nào dùng Hermes, khi nào dùng Claude Code, và đặt model nào vào các harness đó. Ví dụ, đây là một task rất dễ, vậy dùng một bản Flash của DeepSeek vì nó rẻ và đủ dùng. Hoặc task này rất quan trọng, vậy dùng một decision model chuyên xuất ra structured output, không được phép sai. Hoặc task này cần thứ tốt nhất, vậy dùng Opus 5.5, hoặc trong tương lai là Fable 5.5 hay Astra 6.1, tuỳ cái gì có lúc đó.
• Xây eval. Làm sao biết agent của ta đang làm tốt? Ta có theo dõi bao nhiêu phần trăm task do agent làm, bao nhiêu do người làm, đang đốt bao nhiêu token không? Eval, benchmark: đó là công việc tầng cao.
• Dành nhiều thời gian hơn để suy nghĩ. Đơn giản vậy thôi. Nghĩ xem làm sao đưa doanh nghiệp lên tầm mới, làm sao dùng nhiều agent hơn, làm sao tạo thêm agentic loop, mình đang bỏ sót điều gì. Đó mới là công việc thật. Đó là việc CEO và các lãnh đạo làm, và giờ tất cả chúng ta sẽ làm nó, vì mọi công việc của ta sẽ do agent làm.

7. Agentic loop: bắt đầu bằng 5% công việc dễ đoán nhất

Tiếp theo là agentic loop, vì nhiều người đang bối rối không biết nó là gì. David nhắc tới trào lưu "loops", "graphs" quanh Peter Steinberger, và bảo hãy bỏ qua hoàn toàn chuyện đó; anh sẽ nói rất thực tế. Agentic loop và software factory: về cơ bản, một software factory là nhiều agentic loop. Một agentic loop vẫn có thể có con người ở đâu đó, ví dụ ở khâu phê duyệt, nhưng một software factory đúng nghĩa thì không nên có; nó phải tự chạy. Factory là tầng tiếp theo của loop, và anh sẽ quay lại phần này sau.

Vậy agentic loop là gì? Về cơ bản, đó là nỗ lực rút bản thân ra khỏi công việc. Nếu bạn theo dõi anh lâu, hai ba năm trước anh từng nói về n8n: đừng cố tự động hoá mọi thứ cùng lúc như một task lớn, hãy thử với một task nhỏ. Bạn cần phân tích xem mình đang làm những việc gì. Sự thật là bạn và anh làm cùng một kiểu việc mỗi ngày. Chỉ khi bạn mở một công ty mới, theo đuổi một dự án mới hay quyết định viết một cuốn sách, tức là làm gì đó triệt để, khác biệt, thì công việc mới thay đổi. Còn lại phần lớn thời gian là trả lời cùng kiểu email, mở Slack, giao hàng cho khách, làm thêm một brand deal. Không phải y hệt mỗi ngày, nhưng cùng một kiểu, và nghĩa là đó là cơ hội tự động hoá.

"Agentic Loops (and trying to remove yourself)": bắt đầu bằng cách rút bỏ 1 đến 2% các workflow dễ đoán nhất; sự thật là phần lớn việc ta làm mỗi ngày không độc đáo, chủ yếu là cùng một kiểu việc lặp đi lặp lại; vậy hãy nhìn các loại task của mình và nghĩ xem cái nào có thể giao cho Opus 5.5.

Kiểu tự động hoá này trước đây không thật sự làm được bằng programmatic automation, tức là code thuần. Nhưng giờ làm được bằng cách đặt một agent vào đó. Khác biệt nằm ở model và harness, với tiến bộ khổng lồ về harness trong năm qua. Một năm trước (tính từ video đăng ngày 11/10/2026), harness tốt nhất có lẽ là Claude Code. Rồi tháng Một có OpenClaw, tháng Hai có Hermes Agent, sau đó Pi agent trở nên cực kỳ phổ biến, cùng nhiều agent tự cải thiện khác. Tất cả các harness này đều tốt lên vì phần lớn là open source: một cái cải tiến, những cái khác lấy ý tưởng đó và cải tiến tiếp. Đó là lợi ích của open source. Anh ước gì các model cũng giữ được open source. Dù sao, điểm chính là tiến bộ của model và harness trong 6 đến 12 tháng qua là rất lớn, và giờ có những thứ làm được mà trước đây không thể: làm design trọn vẹn, animation, những thứ "điên rồ", nhất là từ khi có Opus 5.5. Nên thật sự không còn lý do gì để bạn tự làm mọi thứ.

Lời khuyên của anh: bắt đầu bằng việc lấy khoảng 5% công việc của bạn, phần rất dễ đoán và an toàn, và tự động hoá nó. Rồi làm thêm 5% nữa. Hãy nhìn các loại task bạn làm. Ví dụ, anh ghi lại lịch làm việc của mình theo từng khung 15 phút, mỗi ngày, đã nhiều năm nay. Nên anh có rất nhiều dữ liệu, và có thể dùng Composio CLI để hỏi agent ngay lúc này. Anh nói trực tiếp vào Cloudroom:

Look at, use Composio CLI and tell me what I spent the last 14 days working on. Just leave out any private stuff. I'm recording YouTube video. It's going to be seen by tens of thousands of people. So just give me like very broad buckets of what we're doing.

Agent dùng skill Composio CLI của anh, chạy bên trong Cloudroom, và sau khoảng 30 giây là xong. Đó là cách phân tích: bạn cần biết thời gian của mình đi đâu, giống như phải theo dõi chi phí kế toán để biết cần tối ưu chỗ nào.

Thời gian cũng vậy. Bạn cần theo dõi thời gian theo một cách nào đó, không nhất thiết từng 15 phút, để biết tối ưu ra sao và bạn thật sự đang phân bổ nó thế nào. Phần lớn mọi người mù tịt: họ nghĩ mình dành 20% thời gian cho việc này, hoá ra là 60%. Hoặc họ nghĩ "ừ, mình là người tập thể dục thường xuyên", hoá ra một tháng đi gym có ba lần.

Trong bất kỳ doanh nghiệp nào, tài nguyên quý nhất là thời gian của CEO. Dù là SpaceX với Elon Musk hay một team ba người. Team của anh khá nhỏ, vậy mà anh vẫn là nút thắt của gần như mọi thứ, dù các thành viên có tập trung tới đâu. Nếu bạn là founder kiêm CEO, thời gian của bạn là tài nguyên quý nhất và bạn cần biết nó đi đâu. Hãy tìm cách theo dõi nó, vì bước tiếp theo là thay 5% đó bằng một agentic loop hoặc một mini software factory.

8. Sai lầm lớn: nghĩ rằng ta sẽ làm việc với agent như hôm nay

Một sai lầm lớn nhiều người mắc phải là cho rằng cách ta làm việc với agent sẽ giữ nguyên. Họ nhìn cách ta đã tương tác với ChatGPT, Claude, Perplexity, Cursor và nghĩ tương lai sẽ y như vậy. Sẽ không như vậy, vì với Astra và giờ là Opus 5.5, chúng ta đã thật sự trở thành nút thắt, và điều đó rất tệ. Ai xem video này cũng biết mình nên chạy nhiều agent hơn, nhưng ta không làm.

Nút thắt không còn là model hay token. Token rẻ. Theo video đăng ngày 11/10/2026, lượng inference bạn nhận được từ một subscription Claude 200 đô một tháng là "điên rồ". Nếu không có nhiều tiền, gói OpenCode Go là một lựa chọn cực kỳ đáng giá. Token rẻ, và token rất thông minh cũng rẻ. Nhất là nếu bạn đầu tư phần cứng và tự host, thì token gần như miễn phí sau khi mua máy. Vậy nút thắt không còn là model, không còn là chi phí token, không còn là harness. Thứ còn thiếu là "mọi thứ khác". Đó là vấn đề, một vấn đề rất trừu tượng, và là thứ anh dành phần lớn thời gian để ám ảnh và giải quyết.

Anh chỉ vào hình vẽ "today": chính là chúng ta đây, các agent đang chờ ta. Nếu bạn chạy nhiều agent, 30, 40, 50 agent cùng lúc, chúng đều đang chờ bạn. Anh mở sidebar của mình ra cho xem: rất nhiều thread. Đúng lúc đó, vài thread mới tự xuất hiện, và anh hỏi người xem có thấy không: đó là các agentic loop của anh vừa tự khởi động cho những việc khác nhau, như xử lý feedback từ người dùng Cloudroom, các agent tự động làm cybersecurity, và agent tìm cách đơn giản hoá codebase. Anh nói mình không nói suông; anh làm đúng điều mình giảng. Các thread đó tự khởi động, không phải anh bấm, và anh sẽ cho xem toàn bộ automation của mình ở phần sau.

Nhưng điều anh muốn cho thấy là anh có hàng trăm thread đang mở và tất cả đang chờ anh, trừ các automation và mini software factory vốn tự động hơn. Rất nhiều việc vẫn đang đợi anh, nghĩa là chính anh đang chặn tất cả agent, chặn tiến độ. Thách thức trở thành: làm sao kiến trúc một factory, một agentic loop, thứ gì đó chạy được mà không cần bạn? Làm sao rút mình khỏi vòng lặp? Đó là thách thức thật.

Nên hãy thôi cho rằng bạn sẽ là người gửi prompt, hay sẽ voice prompt. Ai nói với bạn như vậy là đang sống trong quá khứ. Có thể điều đó đúng vài tháng hay sáu tháng trước, nhưng giờ không còn đúng nữa. Lĩnh vực AI thay đổi nhanh và bạn cần chấp nhận điều đó. Nếu bạn không thích thay đổi thì chúc may mắn: mọi thứ đang thay đổi nhanh hơn bao giờ hết. Bạn phải gạt cảm xúc ra, nhìn "cuộc chơi" đúng như bản chất của nó, và sẵn sàng chơi.

Hai mảnh ghép đầu tiên là trigger và execution. Trigger là gì: một số chạy theo lịch, mỗi ngày một lần, mỗi ba giờ, mỗi giờ. Rất nhiều sẽ là webhook. Hoặc khi database chạm 90% số kết nối đồng thời được phép. Hoặc khi thanh toán bị lỗi và hệ thống bắn một webhook: đó là trigger. Vậy cần tìm ra cách kích hoạt một đơn vị công việc, và biết thế nào là một đơn vị công việc tốt. Rồi tới execution, để agent làm được việc. Dĩ nhiên bạn đặt vào một model mạnh, nhưng giao cho nó skill gì, context gì, MCP và API nào: đó là nghệ thuật, đó là thách thức.

Trigger và execution. Bản chất công việc sẽ thay đổi. Hãy thôi cho rằng cách bạn tương tác với agent hôm nay sẽ là cách bạn tương tác với chúng 12 tháng nữa, vì nó sẽ rất, rất khác. Số lượng agent cũng đang tăng. Hôm nay, mỗi ngày anh tương tác với hàng trăm agent khác nhau, điều mà 12 tháng trước không có. Cả bạn lẫn anh hôm nay đều chạy nhiều agent hơn 12 tháng trước, và 12 tháng nữa ta sẽ chạy nhiều hơn hôm nay rất nhiều. Thách thức là tìm cách tới đó nhanh hơn, để có lợi thế "không công bằng" so với mọi người.

9. Vấn đề laptop, và 110 agent chỉ từ một prompt

Khi anh cố tìm hiểu vì sao chúng ta không chạy nhiều agent hơn, câu hỏi mà anh cho là đáng giá "nghìn tỷ đô, nhiều nghìn tỷ đô", điểm khởi đầu là vấn đề laptop. Hãy tưởng tượng bạn vào một công ty và người ta bảo: có 20 người khác dùng chung laptop với bạn. Về cơ bản, chạy nhiều agent trên cùng một laptop là như vậy. Bạn có thể vá một chút bằng worktree, nhưng tới một lúc các agent vẫn sẽ xung đột. Nếu muốn dùng computer use, agent sẽ bật pop-up, mở tab trình duyệt lung tung trong khi bạn đang cố làm việc.

Còn nữa: gập laptop là agent chết. Mất wifi hay mất mạng, agent chết. Laptop hết pin, agent ngừng chạy. Theo anh, đó là "tội ác", rất tệ, nhất là khi agent dính vào doanh nghiệp và cuộc sống của bạn càng nhiều. Có thể hôm nay nó chưa làm bạn tê liệt, nhưng hãy nghĩ tới tương lai, khi agent làm 20, 40, 60% task của doanh nghiệp: giao hàng cho khách, nghiên cứu đối thủ, tìm thêm lead, làm creative mới và chạy quảng cáo, giúp làm thêm content, cải thiện sản phẩm, sửa bug. Nếu tất cả automation, agentic loop, software factory đó ngừng chạy vì laptop của bạn ở môi trường tệ hay đơn giản là sập, thì doanh nghiệp của bạn cũng sập. Chỉ cần một agent quyết định mở Docker Desktop và chạy một bộ test lớn là bạn đã nghe quạt máy rú lên.

"The laptop problem": gập laptop thì agent chết; vài bộ test là máy đã chạy hết công suất; trigger cần một server luôn bật; cloud thì mở rộng gần như vô hạn. Bên dưới là đường link tới bài đăng trên X của Cloudroom về demo 110 subagent.

Thêm nữa, nếu bạn muốn xây một tương lai mà agent được sinh ra bởi trigger chứ không bởi bạn gửi prompt, bạn cần một server luôn bật: một cloud VM luôn sẵn sàng ít nhất 99,99% thời gian, mạng hoàn hảo kiểu 10 gigabit, và có thể mở rộng. Nhiều người mua một máy thật mạnh, một con Linux box hay một Mac Studio mạnh, và nghĩ đã giải quyết xong. Thật ra bạn chỉ giải quyết được cho X agent. Nếu bạn cần X cộng 20 thì sao? Bạn không thể nâng cấp cái máy đang có để thêm 20 được, bạn phải mua thêm máy. Và nếu bạn chỉ cần thêm 20% trong vài ngày, một tuần? Bạn cần thứ này động, mở rộng được cả lên lẫn xuống.

Giả sử bạn muốn khởi chạy hàng trăm agent. Phần lớn mọi người không làm được trên máy của mình, vì phần cứng không đủ mạnh. Nhưng nếu có một cơ hội đòi hỏi điều đó thì sao: một khách hàng lớn cần làm khối lượng việc đó, hay một cơ hội trên thị trường chứng khoán, bất cứ thứ gì cần hàng trăm agent cùng lúc, mà máy bạn thì có giới hạn?

Anh cho xem cách họ đã làm: một kỹ sư của Cloudroom đã giải quyết đúng bài toán đó. Vì mọi người vẫn sống trong mô hình cũ là khởi động agent từng cái một, trong Cloudroom bạn chỉ cần bảo một agent khởi động 110 agent. Đây là một cấu trúc ba tầng: tầng quản lý mạnh nhất (như CEO) là Opus, các coordinator ở giữa là Sonnet, và worker là Haiku. Bài đăng trên X của Cloudroom ghi: "Spawning 110 cloud subagents inside cloudroom.dev with one prompt", 110 thread được sinh ra trong 57 giây, 10 agent Sonnet mỗi cái chạy 10 agent Haiku, và câu kết "Your laptop is no longer the limit".

Anh nhấn mạnh: chỉ một prompt đơn giản. Đây là cách bạn cần nghĩ: nếu bạn thiết kế một agent có thể khởi động 10 agent khác thì sao? Bạn thấy đòn bẩy ở đó chưa? Thay vì tự khởi động từng worker, hãy nghĩ tới một task mà 20, 50, 100 agent thật sự làm được việc có ý nghĩa, và nghĩ xem bạn cần làm gì để chắc chắn chúng làm tốt chứ không chỉ sinh ra một đống "slop". Thách thức của tương lai là tìm ra skill, rule, điều kiện, giao diện người dùng, quy trình review, tất cả những thứ đó.

10. Immortal Agents, và local agent so với cloud agent

Bước đầu tiên khi anh bắt tay vào câu hỏi "vì sao ta không chạy nhiều agent hơn" là nhận ra đó là vấn đề laptop. Anh đã thử xây quanh nó và open source nhiều repo. Một trong số đó tên là Immortal Agents: về cơ bản, mỗi khi một agent "đi ngủ", nó sẽ được khởi động lại. Anh tìm thấy repo ngay trên màn hình, nằm dưới org Vectal Labs. Agent nào chết vì mất mạng hay vì bạn gập laptop, khi mở lại máy nó sẽ tự chạy tiếp. Nhờ vậy agent của bạn tiếp tục chạy.

README của immortal-agents ("keeps your agents running"): hồi sinh agent sau khi mất mạng từ 2 phút trở lên; khi API của nhà cung cấp phục hồi, nó gửi "keep going" cho các agent bị treo, còn session đã xong hoặc đang chờ input thì để yên. Chỉ chạy trên macOS, cần Python 3 và git; đã thử với bb (Claude Code, Cursor CLI), cmux (Claude Code, Pi), Terminal.app và Ghostty 1.3 trở lên (Claude Code).

Dĩ nhiên đó chỉ là một công cụ, nhưng nó đẩy anh theo đúng hướng: vì sao agent không chạy nhiều hơn? Và một vấn đề lớn là agent đang chạy local. Đây là lúc nói về local agent so với cloud agent. Nhiều người không biết khác biệt. Thực tế, Cursor đã làm một nghiên cứu nội bộ: đầu năm 2026, chỉ khoảng 10% số PR được đưa lên production đến từ cloud agent; tới tháng 8/2026, con số đó là hơn 60% (theo video đăng ngày 11/10/2026). Từ 10% lên 60% chỉ trong khoảng tám tháng. Nếu bạn có khả năng hình dung tốt, hãy tưởng tượng một thang đo: 10% ở tháng Một, 60% ở tháng Tám. Không cần thiên tài cũng thấy được sự tăng trưởng hàm mũ, và chẳng bao lâu nữa nó sẽ là 90%. Có lẽ sẽ không tới 100%, vì đôi khi vẫn có giá trị khi chạy agent local, ví dụ vì quyền riêng tư hay để dọn dẹp thư mục. Nhưng theo anh, phần lớn task, chắc chắn hơn 95%, có lẽ hơn 98%, làm trên cloud sẽ tốt hơn.

Vậy khác nhau ở đâu? Local agent chạy trên laptop hay PC của bạn. Cloud agent chạy trên một server, một VM, một sandbox cô lập. Laptop hay máy tính của bạn, dù là workstation đỉnh nhất hay Mac Studio đỉnh nhất, vẫn có một lượng CPU, RAM và ổ đĩa giới hạn mà bạn đã mua và phải chịu. Với cloud, nhất là khi mỗi agent có sandbox cô lập riêng, bạn chỉ trả tiền khi agent chạy, và nó mở rộng vô hạn: 10 agent thì 10 sandbox, 500 agent thì 500 sandbox, không bao giờ chạm trần.

Đây là một trong những điều đầu tiên: môi trường phải đúng. Còn nhiều yếu tố khác để bảo đảm agent luôn chạy và không bị bạn giới hạn hay chặn lại, nhưng điều đầu tiên là môi trường. Chạy trên laptop thì sẽ bị giới hạn theo nhiều cách.

Rồi tới computer use, một điều rất phiền. Computer use đã tiến bộ rất lớn trong ba bốn tháng qua. Nếu bạn chưa thử Codex computer use hay Cua Driver thì bạn đang bỏ lỡ: agent rất tuyệt, chúng có thể chiếm màn hình, click khắp nơi, điền form, setup AWS hay Google Cloud Console và những giao diện rối rắm nhất mà loài người từng biết. Bạn không bao giờ phải dùng chúng nữa, chỉ cần đưa computer use cho một model mạnh là xong. Vấn đề là chúng chiếm màn hình, bật pop-up, hỏi quyền, mở tab trình duyệt mới. Nếu bạn không định làm gì trên máy đó thì ổn, nhưng nếu bạn đang làm việc trên đó thì rất bất tiện khi có hơn 20 agent chạy cùng máy.

Một điều nữa là cybersecurity, mỗi ngày một quan trọng hơn. Gần đây anh phỏng vấn Guillermo, CEO của Vercel, và ông nói cloud tốt hơn vô hạn lần về bảo mật. Điều đó hợp lý. Anh vẽ nhanh lên bảng: đây là laptop của bạn, và đây là các sandbox nơi agent chạy trên cloud. Nếu một sandbox bị xâm nhập, tệ nhất là agent đó bị xâm nhập. Còn nếu máy chính của bạn bị xâm nhập, vì bạn chạy một model kém và ai đó prompt-inject nó, bảo nó tải về một package độc hại, thì bạn mất mọi thứ trên laptop: thông tin đăng nhập, dữ liệu, mọi thứ. Nhưng nếu một sandbox bị hack thì chỉ là sandbox đó.

11. Bảo mật, và các automation đang chạy trong Cloudroom

Khi cybersecurity ngày càng quan trọng với cả cá nhân lẫn công ty, giá trị của việc chạy agent trên cloud, cụ thể là trong các cloud sandbox cô lập, càng lớn. Anh đã cho thấy automation tự khởi động ở phần trước, giờ anh mở trang Automations trong Cloudroom để giải thích vài cái.

• Billing review kiểm tra toàn bộ code billing mỗi 4 giờ, xem có vấn đề gì, có bug mới nào, có gì anh bỏ sót lần trước.
• Database health check: database có thể thay đổi bất cứ lúc nào. Có thể nhiều power user thức dậy và dùng cùng lúc, số kết nối đồng thời không theo kịp, CPU không theo kịp, hay sắp hết bộ nhớ. Có nhiều lý do, nhiều thứ có thể hỏng, nên có một agent điều tra là rất tốt.

Đây là một dự án phần mềm, nên tất cả những thứ này sẽ là các phòng ban trong một công ty phần mềm lớn. Một công ty phần mềm 5.000 người sẽ có một team database, một team chỉ lo billing và thanh toán, một team cybersecurity và authentication. Dù bạn làm gì, hãy nghĩ xem nó sẽ chia ra thế nào. Nếu công ty bạn lớn gấp 10 lần, nó sẽ chia thành những team nào? Rồi nghĩ tới các agentic loop bạn có thể tạo ngay hôm nay cho từng mảng đó của doanh nghiệp.

Có một automation anh đặc biệt thích. Bất cứ ai gặp bug trong Cloudroom đều có thể bảo "report this to David". Automation này chạy mỗi 10 phút, kiểm tra một bảng trong Supabase, và nếu có bản ghi mới thì nó sinh ra một agent Opus 5.5 để điều tra. Cái hay là nó không tốn thời gian của anh, nó hoàn toàn tự động khi đó là việc nhỏ, như một edge case hiếm gặp hay một ý tưởng không thật sự phù hợp. Nếu đó là vấn đề nghiêm trọng, hay một ý tưởng tính năng tuyệt vời, thứ gì đáng sửa, nó điều tra, giải thích cho anh bằng vài câu tiếng Anh đơn giản rồi để đó. Còn nếu không, nó tự archive.

Vậy những thread anh thấy trong sidebar là những thứ nó quyết định giữ lại. Mọi thứ khác mà các automation tự động khởi động nhưng nhỏ, hay không có vấn đề gì, thì đã tự đóng. Ví dụ database được kiểm tra mỗi năm giờ, và phần lớn thời gian không có vấn đề, nên Opus 5.5, model thông minh nhất thế giới, chạy ở mức extra high hay max, điều tra rồi tự đóng nếu không có gì. Theo anh, giá trị đó là khổng lồ. Nếu có vấn đề, nó phát hiện, giải thích bằng tiếng Anh đơn giản và nói cách sửa đúng.

Trong tương lai, việc này sẽ còn tự động hơn, sẽ có nhiều automation hơn do chính agent khởi chạy, nhưng bạn bắt đầu thấy nó mạnh thế nào. Là người điều hành một team rất tinh gọn, họ đang làm nhiều việc hơn hẳn những công ty có 50, 100, 200 developer. Vì sao? Vì họ biết cách dùng agent và có các agentic automation này; và người xem đã thấy ở đầu video nhiều automation khởi động cùng lúc.

Còn những thứ như security sweep là tuyệt đối thiết yếu: mỗi 90 phút, chạy pen test và kiểm thử cybersecurity rộng khắp codebase của anh (trên màn hình, automation này có nhãn "every 90 min" và lịch chạy "Every 30 min"). Nếu bạn không làm việc đó, người khác sẽ làm với bạn. Trong tương lai, đơn giản là ai tiêu nhiều token hơn vào phần mềm sẽ thắng: kẻ tấn công thử xuyên qua, truy cập dữ liệu nhạy cảm, chiếm quyền admin hay DDoS bạn. Nên việc này không phải tuỳ chọn. Tất cả các bạn sẽ triển khai nó. Câu hỏi là bạn bắt đầu từ hôm nay, hay đợi 6 tháng, 12 tháng tới khi ai cũng thấy hiển nhiên, lúc đó không còn lợi thế nào nữa.

12. Vì sao cloud agent khó, tầm nhìn Cloudroom và demo 15 subagent

Cloud agent khó, và có lý do vì sao phần lớn mọi người vẫn chưa dùng. Theo video đăng ngày 11/10/2026, những sản phẩm tốt nhất đều là closed source của các công ty lớn: Codex, Cursor, Claude, Devin của Cognition AI. Theo David, chưa từng có một giải pháp tốt cho phép bạn hoàn toàn làm chủ dữ liệu của mình, xuất được ra, cho cảm giác thật sự mượt, và cho phép dùng bất kỳ model nào, harness nào, subscription nào. Lý do là cloud agent khó.

"why cloud agents are hard": phải cảm thấy nhanh như chạy local; repo và context phải đi theo bạn; dùng được các subscription bạn đang trả tiền; agent đôi khi vẫn cần tới laptop của bạn.

• Khởi tạo một thread phải cho cảm giác như local. Nếu nó không nhanh bằng local, người ta sẽ không dùng cloud agent.
• Repo của bạn phải có ở đó, context và skill của bạn cũng vậy.
• Bạn muốn dùng các subscription mình đã trả tiền. Nếu phải chuyển sang những sản phẩm như Amp hay Devin, vấn đề là họ bắt bạn dùng subscription và harness của họ. Trong khi ai cũng đang trả cho token AI nhiều hơn bao giờ hết, và muốn dùng subscription mình đã có, dù là Codex, Claude Code, Cursor hay thứ gì khác.
• Agent đôi khi vẫn cần tới laptop của bạn.

Cloud agent đòi hỏi rất nhiều công sức, sự chăm chút và hiểu biết sâu để chạy đúng, và chỉ một trong những điểm ma sát này thôi cũng đủ khiến người ta không dùng.

Đó chính là tầm nhìn của anh với Cloudroom, sản phẩm anh đang xây: một nền tảng để chạy hàng nghìn agent một cách hiệu quả. Đó là tầm nhìn tối thượng, và anh xây nó open source, cho phép dùng bất kỳ model, harness, subscription nào. Nó được thiết kế không chỉ cho công việc hiện tại như anh đã cho xem, chat với bất kỳ model nào, dù là Claude Code, Cursor, Codex, Devin, Pi, OpenCode, Hermes, mà còn cho các bước của tương lai: tạo agentic loop, agentic automation, tiến tới tương lai của công việc với software factory, có đủ công cụ để chạy hàng nghìn agent hiệu quả từ một giao diện duy nhất. Nó cũng cho bạn chọn khởi tạo thread ở local hay trên cloud, vì đôi khi bạn thật sự muốn dọn thư mục Downloads hay Desktop và muốn chạy local, hoặc local trong một worktree, hoặc trên cloud, nơi mỗi cloud thread có sandbox cô lập riêng.

"My vision for Cloudroom": nền tảng để chạy hơn 1.000 agent hiệu quả; dùng bất kỳ model, harness, subscription nào; agentic loop và mini software factory chạy 24/7. Người dùng mục tiêu: entrepreneur và super-power user, đã có nhiều subscription 200 đô (giá tính đến 10/2026), đã có nhu cầu chạy agent trên cloud.

Người dùng mục tiêu không phải người bình thường mà là entrepreneur, những power user thật sự như developer nâng cao và người làm rất nhiều việc với agent. Nếu bạn chưa trả cho nhiều gói subscription 200 đô một tháng (giá tính đến 10/2026), đây chưa phải sản phẩm dành cho bạn. Người lý tưởng đã có gói 200 đô của Claude Code, gói 200 đô của Codex, và đã có nhu cầu chạy agent trên cloud. Anh nói việc của anh không phải là thuyết phục bạn nên chạy cloud agent: nếu xem tới đây mà vẫn chưa thấy hiển nhiên thì có lẽ anh không thuyết phục được. Cloudroom đang tiến tới bản phát hành chung, và trước đó anh mở một gói cao cấp (Ultra) cho một nhóm nhỏ người dùng cần chạy rất nhiều agent trên cloud.

Rồi anh demo. Trong Cloudroom, bạn chọn được môi trường. Anh chọn Cloud và gõ:

Launch 15 sub-agents to analyze different parts of this codebase for small bugs
Put each subagent as Sonnet 5.5 extra high model

Agent chính khởi động gần như tức thì, chưa tới một giây. Theo anh, phần lớn nền tảng cloud agent mất 20 đến 30 giây để khởi động sandbox; anh và team đã làm rất nhiều để nó nhanh nhất có thể, nhanh như local, vì đó là mức chuẩn: phải cảm giác nhanh như chạy agent ở local.

Opus sẽ khởi động 15 subagent để phân tích codebase, mỗi cái tìm một loại bug nhỏ khác nhau. Đây chỉ là task minh hoạ; nó có thể là nghiên cứu, kiểm thử cybersecurity hay làm một tính năng. Ở sidebar bên trái, các thread con đang được khởi động rất dễ dàng. Theo anh, đây đã là thứ mà Claude desktop không làm được: tương tác với các thread khác một cách programmatic như vậy. Cái hay của cloud thread là mỗi agent chạy trong sandbox cô lập riêng, nên chúng không giành tài nguyên của nhau, không tranh cùng CPU, RAM và ổ đĩa.

Anh bảo agent dừng tất cả lại. Ở đây bạn cũng xem được mọi hạn mức từ các gói khác nhau. Agent dừng cả 15. Rồi anh gõ tiếp:

Now archive all of them and reload them as codex instead with GPT-6.1 SOL as the model

And do 25 sub-agents instead of 15.

Trước đó các subagent rõ ràng là Sonnet, như đã yêu cầu. Giờ nó archive tất cả trong chớp mắt, và sẽ khởi động 25 subagent Codex với một model khác. Bạn có thể trộn các harness: Opus làm orchestrator và Sol làm worker, hay Astra làm manager và Opus hoặc Sonnet làm agent thực thi, tuỳ bạn. Tất cả đều làm được trong Cloudroom, và đó là thứ anh đang xây: nền tảng để chạy hàng nghìn agent hiệu quả.

13. Bạn là nút thắt: đừng để token của subscription bị bỏ phí

Nguyên tắc tiếp theo là bạn là nút thắt. Đây là điều cốt lõi để hiểu tương lai của công việc: nếu bạn không rút mình ra khỏi ngày càng nhiều thứ, bạn không thể mở rộng. Giống như doanh nghiệp: muốn lên 10, 20, 30 người, bạn phải bắt đầu rút khỏi một số việc, vì CEO không thể làm mọi thứ. Bạn cũng là CEO của "đội quân agent" của mình, và bạn không thể làm mọi thứ.

"you are the bottleneck": Opus 5.5 đã ở mức AGI; subscription của bạn có nhiều token hơn bạn dùng được; đừng để số token đó bị bỏ phí; còn gì khác có thể giao cho Opus? Các nhánh vẽ ra hướng tới marketing, product và cybersecurity.

Theo anh, Opus 5.5 đã ở mức AGI, "nếu bạn không đồng ý thì bạn sai". Nó là model tốt nhất lúc này (theo video đăng ngày 11/10/2026), bỏ xa các model khác, vì nó cực kỳ hiệu quả về chi phí. Anh sẽ nói về cách anh setup token và subscription ở phần sau, nhưng Opus 5.5 cực kỳ nhanh, cực kỳ tiết kiệm token, và cực kỳ thông minh. Anh thừa nhận: toàn bộ design và hình ảnh trên trang Cloudroom, tất cả animation và đồ hoạ đó, là anh làm cùng Opus 5.5. Đúng là anh yêu cầu nhiều phương án và tự chỉnh vài chỗ cho animation mượt, nhưng không model nào khác tới gần được. Dĩ nhiên con người vẫn cần có taste để biết cái gì tốt, cái gì không, "nhưng Opus là AGI". Vậy bạn cần tìm cách "let it cook", khai thác tối đa subscription và rút mình ra.

Một điều khác: rất nhiều người để hạn mức hàng tuần trôi qua với hơn một nửa chưa dùng. Có hai cách phản ứng, và cách tệ là: "ok, mình hạ gói". Chắc chắn bạn tiết kiệm được 100 đô một tháng, nhưng như vậy bạn đang thừa nhận mình không biết biến token thành doanh thu, và đó là một vấn đề rất tệ, vì đó chính là kỹ năng chính của tương lai: bạn có dùng được số token này để làm ra nhiều tiền hơn số tiền bạn trả cho subscription không? Theo anh, tính đến 10/2026, subscription của Anthropic đã được trợ giá khoảng 90%, nghĩa là bạn nhận token Opus 5.5 rẻ hơn khoảng 50 đến 90% so với mua qua API; anh sẽ cho xem số liệu từ nghiên cứu của SemiAnalysis ở phần sau.

Vậy làm gì? Hãy thử làm một điều gì đó: cải thiện marketing, cải thiện sản phẩm, cybersecurity. Anh nói thẳng: "cứ lấy luôn các automation của tôi đi". Billing review, database health check, feedback thread từ khách hàng, GitHub issue và PR, tổng quan các repo public, thread cảnh báo sandbox về các vấn đề với sandbox và chạm hạn mức, security sweep cho cybersecurity, simplify codebase để tìm độ phức tạp không cần thiết hay code không dùng tới.

Anh đi sâu vào một cái nâng cao hơn: Test gap. Nó tìm các test còn thiếu, nhưng tinh tế hơn, vì agent rất thích test: chúng sẽ nhồi cả codebase đầy unit test, component test, integration test. Cách này tốt hơn nhiều: nó kiểm tra các phần khác nhau của codebase xem có khoảng trống cho một test thật sự tốt không. Khi Opus nghĩ ra một test, nó khởi động GPT-6.1 Sol ở mức extra high để làm adversarial review, về cơ bản là giả định "test này có vô nghĩa không, cứ giả định là nó không cần". Chỉ khi cả hai model, Opus là bên tìm ra test và GPT là bên review, cùng đồng ý đây là test tốt nên thêm vào, thì nó mới đi qua, và chuyển tới anh để duyệt.

Phần đầu của script trên màn hình:

#!/bin/bash
# Runs every 30 minutes: starts one test gap hunt when the last one began 5h25m+ ago, so hunts start every 5.5 hours.
# Picks the least recently hunted area (never-hunted first, in random order) and skips areas with an open hunt thread.
# Prints nothing when it starts nothing, so quiet ticks stay silent.
set -euo pipefail
export PATH="/opt/homebrew/bin:$PATH"
skill="$HOME/code/cloudroom/.agents/skills/test-gaps/SKILL.md"
log="$HOME/.config/cloudroom/test-gaps.log"
# Create the log only when missing: its modified time is the last start.
mkdir -p "${log%/*}" && { [ -e "$log" ] || : > "$log"; }

Bạn thấy các agentic automation này có thể ngày càng nâng cao theo thời gian. Và bạn cần bắt đầu xây chúng cho chính mình. Dù bạn làm phần mềm, làm agency marketing hay làm môi giới bất động sản, hãy hình dung nếu doanh nghiệp bạn lớn gấp 100 lần thì sao. Bạn có thể nghiên cứu điều đó, vì có lẽ đã có những công ty lớn gấp 100 lần bạn: các phòng ban của họ thế nào, các team của họ ra sao? Đó là cách bắt đầu tạo automation: một số chạy theo trigger, một số chạy mỗi 10 phút, một số mỗi 4 giờ, tuỳ bạn, và đó là nghệ thuật tinh chỉnh dần theo thời gian.

Nên câu hỏi là: còn gì khác có thể giao cho Opus, hay Astra, hay GPT-6, những model siêu mạnh này? Automation nào, loop nào, mini software factory nào bạn có thể khởi chạy mà đi đúng hướng? Bạn phải thử. Có thể bạn sẽ xoá vài cái không hữu ích, nhưng nếu không thử thì bạn sẽ không tìm ra những cái tuyệt vời.

14. Inference: subscription nào đáng tiền, và review chéo hai hãng

Tiếp theo là inference, một trong những biến số chính khi vận hành software factory hay agentic loop: bạn tiêu bao nhiêu cho inference và chạy loại token nào. Anh dẫn một nghiên cứu "tuyệt vời" của SemiAnalysis. Trước đó anh đã đăng một phiên bản kém khoa học hơn trên Twitter và nó viral; nhiều người nghĩ anh nói đùa, nói quá, hay đang làm quá lên. Nhưng điều đó là thật.

Trước khi Opus 5.5 ra mắt, anh trả cho sáu gói Codex 200 đô một tháng. Vì sao? Vì Astra là model tốt nhất thế giới. Trong suốt ba tuần, Astra là "GOAT", bỏ xa mọi model khác, tốt hơn hẳn Fable 5.1. Rồi Opus 5.5 ra mắt, và một subscription Claude Code 200 đô xử lý được cùng lượng token đó, thậm chí nhiều hơn, vì Opus nhanh kinh khủng, nhanh hơn Astra rất nhiều. Đó là lý do anh tự tin vào ước tính rằng hiện tại (theo video đăng ngày 11/10/2026) subscription Claude Code 200 đô cho bạn lượng dùng gấp 16 đến 20 lần so với Codex 200. Rồi OpenAI, trước khi DevDay diễn ra, đã giảm một nửa hạn mức của gói Codex 200 và ra mắt gói 500 đô. "Thôi thì nó là vậy."

Theo anh, SemiAnalysis dù không cực đoan bằng nhưng cũng đã xác nhận đại ý là giá trị gấp khoảng 10 lần, anh đọc con số 10,6 trên biểu đồ. Nói gọn, theo anh, tính đến 10/2026, bạn nhận giá trị gấp khoảng 10 lần từ subscription Claude Code so với OpenAI Codex. Nếu chỉ đủ tiền cho một gói 200 đô thì "không có gì để so", anh không thể thành thật khuyên bạn gói Codex 200 đô lúc này khi gói của Anthropic đáng giá như vậy. Opus 5.5 là model tốt nhất, "nếu bạn nghĩ khác thì bạn sai". Anh cũng nói thêm rằng có lẽ sẽ có một model lớn khác ra mắt trong hai ba tuần tới, ai biết được, nên chuyện này có thể đổi rất nhanh; nhưng Anthropic đang trong chuỗi phong độ cao, và nếu họ ra Fable 5.5 thì nhiều khả năng nó cũng sẽ là tốt nhất.

Theo video đăng ngày 11/10/2026, phần lớn token của anh đến từ một subscription Claude Code 200 đô. Thật ra anh đã mua thêm cái thứ hai để chạy thêm agentic loop, nên nói cho minh bạch là anh đang trả cho hai gói. Và đúng, anh tự trả tiền cho tất cả, các công ty không trả tiền cho anh. Hồi trước việc đó đáng: Astra có token tốt nhất, nên anh vui vẻ trả 1.200 đô một tháng cho sáu gói Codex; giờ Opus là tốt nhất.

Vậy dùng model GPT thế nào? Anh dùng chúng để review. Anh mở Cloudroom cho xem một automation đang chạy: đây là lần chạy thứ 16 của automation simplify codebase. Nó đi kèm prompt, khởi chạy, chạy trong 4 phút 12 giây, với model là Sol ở mức Max, và tìm ra một chỗ có thể dọn: các bản sao Computer Use SDK không còn dùng, tổng cộng 23.944 dòng (khoảng 1 MB), và cách sửa an toàn là xoá cả hai file.

Kết quả của Simplify sweep (section 16, Other plugins): làm theo SKILL.md của simplify-sweep, chỉ điều tra, không sửa code; nếu không có gì đáng làm thì tự archive thread, ngược lại thì báo David bằng tiếng Anh đơn giản rồi chờ. Agent đã chạy 4 phút 12 giây và tìm ra "One clear cleanup: unused Computer Use SDK copies". David đang gõ lệnh review vào ô chat.

Lần này kết quả do Sol tìm ra, nên anh gõ "run /opus-review to see if this is legit, and safe to delete"; thường thì anh làm ngược lại. Dĩ nhiên nó sẽ chạy việc này như một subagent. Theo anh, bạn luôn muốn review bằng model của công ty khác. Lúc này (theo video đăng ngày 11/10/2026) có hai công ty frontier: OpenAI và Anthropic. Các công ty khác đang cố trở thành frontier nhưng "còn xa lắm". Vậy khi bạn build bằng GPT-6.1 Sol hay GPT-6 Astra, hãy review bằng Opus 5.5; nếu build bằng Opus 5.5, hãy review bằng GPT-6.1 Sol. Luôn review bằng model của hãng thứ hai để phát hiện khác biệt và nhìn vấn đề theo một cách khác.

Khoảng 98% thread của anh chạy Opus làm model chính, rồi anh khởi động GPT-6.1 Sol hay Astra, hoặc đôi khi cả hai nếu là thay đổi nghiêm trọng, để review. Rồi anh hỏi Opus: cái này có thật sự đúng không, hay chỉ là nghĩ quá lên? Lời khuyên tiếp theo: tránh trả giá API bằng mọi giá. Subscription là lựa chọn tốt hơn. Nếu vì lý do gì đó bạn buộc phải trả giá API, thì chắc chắn nên dùng các model Trung Quốc vì chúng rẻ hơn nhiều. Anh nói thêm Haiku cũng là một lựa chọn khá đáng tiền từ Anthropic, và bạn có thể xem số liệu cụ thể hơn trên Artificial Analysis. Theo anh, tính đến 10/2026, Anthropic đang cho bạn một mức giá tốt hơn hẳn, "không có gì để so".

15. Cái gì khởi động một agent: trigger và Director

Giờ tới các loại trigger, vì đó là điều quan trọng khi xây software factory hay agentic loop: cái gì khởi động một agent? Trước đây, và có lẽ cả bây giờ (tính đến 10/2026), phần lớn chúng ta vẫn khởi động agent bằng tay. Điều đó ổn trong giai đoạn chuyển tiếp, làm ở chỗ thật sự cần, nhưng bạn nên tìm cách rút mình khỏi càng nhiều chỗ càng tốt và tìm các loại trigger khác.

Các trigger anh liệt kê: chạy theo lịch, mỗi 15 phút, mỗi 5 giờ, mỗi ngày một lần. Webhook, theo anh sẽ là một trong những loại linh hoạt nhất. Một sự cố riêng biệt như database sập hay lỗi tăng vọt. Feedback của khách hàng: càng nhiều khách thì càng nhiều feedback. Săn bug chủ động, cái này cũng có thể chạy theo lịch. Hoặc một agent khác.

Loại cuối này, theo anh, sẽ thật sự là frontier. Ví dụ, một trong các repo open source của anh là Director. Anh tìm nó trên màn hình: đó là một agent chính quản lý các agent khác, học dần cách bạn viết prompt và cách bạn ra quyết định theo thời gian. Đây là repo open source nên bạn có thể lấy về dùng. README trên màn hình mô tả Director giúp các coding agent tiếp tục chạy trong bb hoặc cmux, review những agent đã dừng và xin bạn duyệt trước khi hành động; nó cần macOS, Python 3.9 trở lên, và cài bằng một lệnh curl.

curl -fsSL https://raw.githubusercontent.com/vectal-labs/director/main/install.sh | sh

Đây sẽ là frontier khó nhất, và cũng là nơi mọi thứ trở nên "điên rồ" nhất. Như anh đã cho thấy, bạn có thể có một manager với 15, 20, 25 subagent. Nếu bạn có skill tốt, kiến thức tốt, rule tốt về cách mình vận hành, và dạy được những thứ đó cho một model mạnh như Opus 5.5 trong vai trò director, bạn có thể đi rất xa, và nó có thể gỡ kẹt cho các agent khác hiệu quả hơn bạn tưởng. Đây là điều quan trọng cần hiểu: trigger là một nửa câu chuyện.

16. Prompt, skill, và dự đoán về "sequence"

Nửa còn lại là execution. Ở đây anh nói về prompt và skill, vì mọi người không thấy rõ bản chất của chúng: họ nghĩ skill chỉ là một file markdown. Thật ra đó là bước đầu tiên hướng tới tự động hoá và tối ưu. Skill là thứ bạn làm rất nhiều lần. Prompt là dạng đơn giản nhất; một prompt template chỉ là thứ bạn dùng liên tục.

Anh cho xem một loạt prompt anh dùng mỗi ngày. Ví dụ:

rebase off of 'main' branch, and check the underlying code again to see if this has been fixed, or not yet

answer in short, in plain english

Hoặc chỉ "answer in short and plain English". Hoặc "don't be verbose, make your answer simpler and shorter, focus on what really matters". Hoặc một snippet yêu cầu chạy 4 lượt search, 3 lượt deep research và 3 lượt deep scrape về chủ đề đang bàn. Hoặc "anything else to do here or not really", hay "remind me of the original purpose of this thread". Tất cả đều là Raycast snippet mà anh gọi ra ngay lập tức, "nhanh hơn cả việc bạn kịp hiểu chuyện gì đang xảy ra". Theo anh, đó là cách anh làm việc nhanh hơn bất kỳ ai.

"prompts & skills": bước 1 là nhận ra mình lặp lại việc gì; biến nó thành prompt template hoặc text snippet; rồi thành một skill mà agent chạy bằng một lệnh; đó là bước đầu để làm việc nhanh hơn với agent. Sơ đồ: "same task ×100" tới prompt tới /skill, "type once, run forever". Bên phải là thẻ repo skills public của David, khoảng 4.100 sao.

Nhưng đó vẫn chỉ là prompt template. Tầng tiếp theo là skill. Anh có rất nhiều skill, và repo skill của anh là open source, bạn cứ lấy, copy những cái hữu ích. Đó là repo phổ biến nhất của anh, hơn 4.000 sao. Skill về cơ bản là những quy trình nâng cao hơn, giống SOP (standard operating procedure) trong công ty: những việc bạn thấy mình lặp đi lặp lại. Khi anh gõ /gpt trong ô chat, danh sách hiện ra skill gpt-review ("Launch an independent GPT code review and return it verbatim"), cùng image-prompt, signal-from-expert và một skill best practice Postgres của Supabase. Anh kể thêm các review skill khác, một skill review tổng thể, các skill release khác nhau như GUI release hay core release, các skill computer use, và rất nhiều thứ khác. Các loại quy trình, các loại công việc, bạn có thể biến thành skill rồi gọi chúng ra.

Nhưng nếu để ý kỹ video này, bạn sẽ thấy mình vẫn phải có mặt trong vòng lặp đó, và như vậy chưa lý tưởng. Prompt và skill là một bước đi đúng hướng, chắc chắn là đúng hướng, nhưng bạn vẫn muốn rút mình ra; và nếu bạn buộc phải tham gia, thì mỗi lần tham gia nên kéo theo nhiều việc hơn được làm.

Dự đoán của anh là sau skill, chúng ta sẽ thấy sự ra đời của sequence. Một sequence về cơ bản là nhiều skill nối với nhau thành chuỗi, nhưng dựa trên xác suất rút ra từ việc quan sát hành vi của chính bạn. Ai cũng có agent trace, các agentic session nằm trên máy. Nếu bạn đã dùng agent vài tháng, có lẽ bạn có hàng nghìn session chồng chất. Vậy ai đó có thể nhìn vào và thấy: "trong kiểu tình huống này, David chạy ba skill này liên tiếp với xác suất 98%". Đó sẽ là một sequence, một chuỗi skill, và anh nghĩ đó là bước tiếp theo đúng hướng.

Bạn vẫn sẽ phải tham gia ở một mức nào đó. Nên chúng ta sẽ tối ưu cả công việc bất đồng bộ lẫn công việc đồng bộ của con người; cả hai đều cần được tối ưu tới cực hạn. Nhưng sau skill, anh dự đoán sequence sẽ là paradigm lớn tiếp theo trong khoảng sáu tháng tới.

17. Từ agentic loop tới software factory: tạo một automation bằng giọng nói

Giờ tới khác biệt giữa agentic loop và software factory. Loop là: một trigger, agent làm việc, có một bước kiểm tra, rồi lặp lại. Một vòng lặp đơn giản. Còn factory là nhiều loop khác nhau làm những việc khác nhau. Anh gọi thứ mình đã cho xem là "mini software factory" vì anh không nghĩ chúng ta đã thật sự tới đó; anh nghĩ đây vẫn là giai đoạn đầu. Anh không muốn tuyên bố quá: nhiều người cứ nói AGI suốt ba năm qua, "AGI is here" này nọ. Về software factory, anh muốn chỉ tuyên bố khi nó thật sự tới. Anh nghĩ chúng ta đã đạt tới AGI, nhưng anh sẽ không nói thứ mình đang có là software factory tốt nhất có thể. Đó là lý do anh gọi nó là mini software factory.

"agentic loop → software factory": loop là trigger, agent làm, kiểm tra, lặp lại; factory là nhiều loop nối với nhau; signals tới code, tests, review, deploy, monitor; agentic engineering bằng product engineering cộng factory engineering. Bên phải là vòng lặp và chuỗi các bước có mũi tên quay ngược về "signals".

Nó không chỉ là một agentic loop: bạn thấy nó trải trên nhiều mảng và loại công việc phần mềm khác nhau, vì anh đang xây một công ty phần mềm. Nếu bạn xây một kiểu công ty khác, nó sẽ trông khác. Tóm lại, software factory là nhiều agentic loop làm việc song song cùng nhau để đạt một kết quả cụ thể, trong cuộc sống hay trong doanh nghiệp của bạn. Đó là khác biệt.

Rồi anh cho xem việc tạo một automation bằng tiếng Anh thông thường trong Cloudroom dễ thế nào. Anh đã có nhiều automation rồi, giờ tạo một thread mới. Ban đầu anh định dùng cloud thread để khoe cloud thread nhanh thế nào, chọn Opus 5.5 ở mức high là đủ, và sẽ voice prompt. Rồi anh đổi ý: anh đã cho xem cloud thread rồi, giờ muốn cho thấy local thread cũng làm được. Nếu bạn dùng Codex hay Claude Code, bạn cũng có thể làm việc local trong Cloudroom. Anh nói vào micro, và đoạn văn hiện trên màn hình:

Create a new Cloudroom automation where every two hours a new thread spawns with opus 5.5 extra high as the model and it looks for product gaps against all of the ADRs we have in slash docs slash ADR and looks for like one obvious improvement for our product. It could be a feature, it could be more clear UI, anything. It just needs to be aligned with our ADRs and decisions we've made in slash docs folder. And then when it finishes and it has a good idea, launch a reviewer, a subagent below it with GPT 6.1 fast extra high as the model and doing adversarial review to try to make the arguments of like why this shouldn't be a feature and why this shouldn't be added. Once the subagent finishes, it should go back to the main agent and he should review the feedback of the subagent, thinking about it from first principles. And if he agrees with the subagent, he should simply archive both threads. But if he disagrees, he should keep this thread open waiting for me, David, to review it. Create this Cloudroom automation now. Keep it simple. Don't overthink it.

Chỉ như vậy, chưa tới một phút nói, anh đã có một prompt sẽ trở thành một automation có thể cải thiện sản phẩm của anh mãi mãi. Dĩ nhiên khi khởi chạy một automation mới, nó có thể cần vài lần tinh chỉnh trong mấy lần chạy đầu để chạy đúng, để thật sự hữu ích, tạo ra kết quả tốt chứ không phí token hay thêm slop.

Đây là điều chính: rất nhiều người chỉ thích khoe. Gần đây anh nghe một người khoe có hơn nửa triệu file markdown. "Chẳng ai quan tâm." Bạn chỉ cần chạy một model rẻ là sinh ra nửa triệu file markdown. Vậy đừng khoe số dòng code, đừng khoe có bao nhiêu file markdown; điều đó chỉ cho thấy bạn là người mới. Bạn cần tìm cách làm việc này cho đúng. Anh nghĩ các quyết định sản phẩm lớn nên do con người đưa ra, và UI/UX vẫn cần taste mà agent chưa có. Nhưng bug backend, tối ưu database, tăng tốc codebase, rất nhiều thứ như vậy thì Opus giỏi hơn anh nhiều, và anh không có chút cái tôi nào về chuyện đó. Anh không cần bám lấy những việc Opus, Astra hay các model khác làm tốt hơn mình. Bạn cần buông ở những chỗ agent giỏi hơn, đón nhận nó, và xây các agentic loop và automation.

Agent tạo xong và chạy thử luôn: nó đang phân tích codebase để tìm ý tưởng, và anh chờ xem subagent Sol có được khởi động không. Thread "Product gap automation" xuất hiện. Cái hay là bạn có thể click qua các thread, và agent được gắn tag, nên bạn có thể tag bất kỳ agent nào. Ví dụ anh tag thread "find bugs across 15 codebase areas" từ demo trước và bảo: "just archive this thread and all of his subagents". Các agent có thể tương tác với nhau; bạn có thể có những quan hệ phức tạp và cấu trúc phân cấp, "sức sáng tạo của bạn là giới hạn duy nhất". Tất cả đã được archive.

Mục tiêu của anh với Cloudroom là xây cloud agent open source tốt nhất. Theo anh, lúc này (theo video đăng ngày 11/10/2026) họ là công cụ AI coding đầu tiên trên thế giới cho bạn một cloud agent trong mỗi thread với môi trường tách biệt. Anh minh hoạ bằng một câu hỏi: "what computer are we on" hay "what machine are we on". Ở local thread, agent trả lời: đang ở trên MacBook Pro của anh, chip Apple M3 Max, 128 GB RAM, macOS 26.6.2, thread local chạy trong checkout của project. Anh chạy cùng câu hỏi đó trong một cloud thread mới, và nó trả lời nhanh y như local: đang ở trong một cloud sandbox của Cloudroom.

Subagent reviewer (GPT-6.1 Sol, Extra High) trong thread "Product gap review" đang phản biện ý tưởng agent chính đưa ra: thông báo hết giờ cloud mà người dùng thấy đang bị hardcode và sai với người dùng có gói trả phí, và thiếu nút Upgrade.

Và đây rồi: automation đã khởi động subagent để làm adversarial review, xem chuyện gì đang diễn ra và đây có phải tính năng tốt không. Đó là việc khởi chạy một automation mới dễ tới mức nào. Bạn thấy ngay trong danh sách: giờ có 32 automation thay vì 31, và cái mới là Product gap, mỗi 2 giờ. Bật hay tắt đều rất dễ quản lý.

18. Khoảng cách ngày càng lớn, và cách nhìn ra tương lai

Trước khi kết thúc, David muốn nói về một điều anh gọi là "lời nói dối hoàn toàn" mà bạn có thể đã nghe từ những người như Sam Altman: rằng AI sẽ mang lợi ích cho tất cả mọi người và nâng tất cả lên. Theo anh, khoảng cách đang lớn dần. Lúc quay video anh đang ở San Francisco, đã gặp rất nhiều người cực kỳ tập trung vào AI, và ai cũng đồng ý: nếu bạn biết cách chạy 50, 100, 200 agent một cách hiệu quả và hữu ích, thì so với người bình thường ngoài đường, cuộc đua sẽ không còn công bằng nữa.

"the gap keeps growing": tốc độ phụ thuộc vào mức độ bạn tập trung; phần lớn mọi người dùng Google AI search và ChatGPT miễn phí; ở cutting edge là hàng chục agent, loop, mini factory; "intelligence for everybody" là một lời nói dối; khoảng cách rộng thêm mỗi tháng. Biểu đồ: đường "locked in" cong vút lên, đường "everyone else" gần như đi ngang theo thời gian.

Phần lớn mọi người vẫn chưa dùng AI gì cả: bạn bè, gia đình bạn, họ chẳng quan tâm chút nào. Ngay cả những người có dùng thì đang dùng gói miễn phí của ChatGPT, gói miễn phí của Gemini. Họ không xây software factory. Những người tập trung cao độ, ở cutting edge của AI, đang ngày càng bỏ xa và năng suất hơn mọi người một cách khủng khiếp. Cái giá của việc không ở cutting edge chưa bao giờ cao như vậy. Theo anh, lý do các CEO đại chúng của những công ty lớn không nói điều này là vì họ đang trả lời phỏng vấn trên TV, nói vậy sẽ là PR rất tệ. "Nhưng tôi không quan tâm, tôi sẽ nói sự thật: khoảng cách đang lớn dần."

Vậy làm sao nhìn ra tương lai, làm sao suy luận về nó? Theo David, rất nhiều thứ khá hiển nhiên nếu bạn chịu ngồi xuống và nghĩ. Team của anh làm thế này: một buổi một giờ, có thể chỉ cần ghi âm bằng điện thoại hay máy tính, và cùng suy luận về một chủ đề cụ thể. Ví dụ: vì sao công ty này đang tăng trưởng? Hay ta thấy xu hướng này trong hành vi của người dùng AI, điều đó ngụ ý gì? Hay khi một decision model rẻ được ra mắt, điều đó ngụ ý gì? Bạn ngồi xuống và không làm gì khác: không điện thoại, không máy tính, chỉ suy luận và nói về một hướng cụ thể trong 60 đến 90 phút.

Nếu làm vậy mỗi ngày trong một hai tháng, bạn sẽ hiểu tương lai rõ hơn cả phần lớn những người trong ngành AI, kể cả những người ở cutting edge, vì suy nghĩ là việc khó. Bạn cần suy luận từ first principles về hành vi con người, động lực thị trường, các đột phá công nghệ mới: cái gì sẽ thay đổi, nếu một điều xảy ra thì hệ quả bậc hai, bậc ba là gì, và suy luận cho tới cùng. Đừng rời bàn cho tới khi ý tưởng bắt đầu tuôn ra. Thường năm hay mười phút đầu không hiệu quả, bị bí, chẳng có gì độc đáo, nhưng sau đó ý tưởng sẽ tới.

Đó cũng là cách anh suy luận để đi tới Cloudroom, và tới kết luận rằng cloud agent là tất yếu: chỉ bằng cách suy luận, nhận ra cái gì sẽ là nút thắt, nhận ra các model đã đủ mạnh để chạy hàng trăm, hàng nghìn agent mà phần lớn chúng ta không chạy, không có hàng nghìn agent làm việc hiệu quả. Vậy hãy tìm ra các nút thắt và giải chúng từng cái một.

Và bạn thật sự phải dành thời gian cho việc đó, vì như Joshua Reynolds từng nói: "There is no expedient to which a man will not resort to avoid the real labor of thinking", không có mẹo nào mà con người không dùng tới để né tránh lao động thật sự của việc suy nghĩ. Nói cách khác, người ta sẽ làm bất cứ thứ gì khác. Họ sẵn lòng làm ở McDonald's 10 tiếng một ngày suốt 40 năm chỉ để khỏi phải ngồi xuống nghĩ xem làm sao có công việc tốt hơn, làm sao phát triển sự nghiệp, hay nên làm trong ngành nào. Suy nghĩ mới là phần khó. Click khắp nơi và làm việc vặt không còn là phần khó, agent nào cũng làm được. Đưa cho agent quyền computer use cùng vài MCP và tool, chúng làm được rất nhiều thứ tốt hơn con người. Lao động thật, công việc thật sự khó từ giờ trở đi là suy nghĩ và suy luận về tương lai từ first principles. Nên hãy chắc chắn bạn làm điều đó, và đừng né tránh việc suy nghĩ đầy khó nhọc.

David cảm ơn người xem và chúc mọi người có một tuần làm việc thật năng suất.