Grok Bot làm manager cho các coding agent

1. Lauren Tan, Theo và một cách quản lý agent đang lan ra

Rob mở video bằng Lauren Tan. Theo lời Rob (video đăng ngày 31/10/2026), Lauren là người tạo ra pstack, một bộ skill rất được ưa chuộng, đồng thời là principal engineer ở Grok Bot và cả ở Cursor. Cô vừa chia sẻ cách mình land hàng nghìn pull request mỗi tháng, với Grok Bot đứng ra điều phối (orchestrate) các agent của cô.

Rob nhắc người xem ngay từ đầu (video đăng ngày 31/10/2026): hãy nhớ rằng công việc của Lauren là quảng bá cho chính những công cụ này. Anh muốn mọi người giữ điều đó trong đầu suốt phần còn lại của video.

Cũng vào khoảng thời gian đó, Theo, một YouTuber lớn trong giới dev mà theo Rob chắc nhiều người đã từng xem, cũng cho thấy và kể lại cách anh dùng Grok Bot để quản lý các agent của mình. Rob nói rõ Theo không có liên hệ gì với Grok Bot; Theo là người tạo ra T3 Code (theo Rob, video đăng ngày 31/10/2026). Từ hai ví dụ đó, Rob đặt câu hỏi cho cả video: liệu những bot như Grok Bot có đang trở thành bề mặt mới (surface) để quản lý việc phát triển phần mềm ở quy mô lớn, để vận hành software factory của chúng ta hay không. Và anh bắt đầu đi vào xem thử.

2. Grok Bot trong software factory của Rob

Về phần mình, Rob kể anh đang thành công khá nhiều với Grok Bot (theo trải nghiệm của anh tính đến video đăng ngày 31/10/2026). Anh để nó quản lý nhiều mảng trong công việc kinh doanh, và nó đã thay thế nhiều workflow cho anh. Anh đã thử rất nhiều giải pháp, rất nhiều agent khác nhau, và Grok Bot là cái "trụ lại" được, chủ yếu vì nó đơn giản. Anh cũng nhắc rằng mình dùng Claude Code và Cursor rất nhiều trong các software factory của riêng anh.

Trong vài tuần trước khi quay video (đăng ngày 31/10/2026), Rob bắt đầu dùng Grok Bot làm orchestrator cho software factory của mình. Theo anh, việc này giúp ích rất lớn, nhưng tất nhiên không phải không có vấn đề, và anh sẽ nói về các vấn đề đó trong video. Vì vậy khi thấy Lauren và Theo làm việc đúng theo kiểu mà anh đã tự mò ra, anh nói mình "ích kỷ" muốn đào sâu chủ đề này hơn.

Rob lại nhắc một lần nữa: Lauren làm việc ở một tầm khác hẳn phần đông chúng ta. Theo lời Rob (video đăng ngày 31/10/2026), cô chạy khoảng hơn 2000 pull request mỗi tháng và có một ngân sách token không đáy để dùng. Dù vậy, cô có những cách tiếp cận rất thú vị mà những người bình thường như chúng ta có thể học theo, và chúng cho thấy một tín hiệu về hướng mọi thứ có thể đi tới. Rob nghĩ người xem sẽ thấy cách tiếp cận này đáng quan tâm.

Anh trình bày video như một backlog của chính mình: trên màn hình có một bảng "shipped" và "up next", để người xem thấy phần nào đã xong và phần nào sắp tới. Và thông điệp của anh (video đăng ngày 31/10/2026): bot của bạn nên là manager ở đây, không phải coder.

3. Bot là manager, không phải coder: first mile và last mile

Theo Rob (video đăng ngày 31/10/2026), Grok Bot làm rất tốt hai việc. Việc thứ nhất là cái mà team Grok gọi là first mile: tìm ra nên build cái gì. Một phần lớn của bất kỳ software factory nào là quản lý intent (ý định, yêu cầu cần làm).

Theo Rob, điểm mạnh của Grok Bot (tính đến video đăng ngày 31/10/2026) là được kết nối tới nhiều kênh khác nhau để quản lý intent: Slack, email, X, Linear. Nó có thể quản lý và nối tất cả các kênh đó, và tự để mắt tới chúng. Điều này rất hữu ích để có bức tranh lớn: cái gì nên build tiếp theo, có vấn đề gì không, và nắm được cả cuộc trao đổi xoay quanh việc phát triển một feature.

Việc thứ hai, theo Rob (video đăng ngày 31/10/2026), là last mile: kiểm tra công việc. Cụ thể là đi đôn đốc, báo cho bạn cái gì đã xong, theo dõi danh sách task.

Rob ghi chú thêm: bạn không bắt buộc phải dùng Grok Bot làm orchestrator. Bạn có thể tự dựng agent của riêng mình, hoặc dùng Claude Projects hay Cursor Projects. Theo anh (video đăng ngày 31/10/2026), bất cứ thứ gì kiểu đó đều sẽ chạy theo cách tương tự, và mọi điều anh nói trong video đều có thể chuyển sang workflow của riêng bạn.

4. Phần ở giữa: coding agent viết code, Slack làm chỗ điều phối

Phần nằm giữa first mile và last mile là làm việc thật sự: viết code. Theo Rob (video đăng ngày 31/10/2026), đó là thứ mà các coding agent như Claude Code, Codex và Cursor thật sự được build ra để làm. Vậy trong workflow này, bạn để Grok Bot lập kế hoạch rồi giao việc đi. Khi việc quay về, nó có thể kiểm tra bằng chứng (proof) và cập nhật cho bạn biết chuyện gì đang diễn ra.

Lauren có một bài đăng nói đúng về điều này. Về cơ bản, bài đó hướng dẫn tạo một "team engineer bot", thêm nó vào Slack, rồi tag nó mỗi khi bạn muốn có việc code cần làm. Theo Rob (video đăng ngày 31/10/2026), vì cloud agent, hay cả agent chạy trên máy của bạn, đều có máy tính riêng, nên bot orchestrator chính được giải phóng để làm manager nhiều hơn, thay vì tự đi viết code.

Rob thấy một điểm đáng chú ý: trong tất cả các software factory anh từng tìm hiểu, từ nhiều công ty lớn như Stripe và các công ty khác, họ đều có xu hướng dùng Slack làm cách quản lý agent (theo Rob, video đăng ngày 31/10/2026). Vì vậy trong workflow này, hoặc bạn làm việc trực tiếp với Grok Bot, hoặc bạn nối Grok Bot vào Slack và quản lý nó ngay trong thread nơi cả team của bạn đang làm việc.

5. Chuyện tiền và chuyện cô lập: mỗi worker một máy

Rob nói anh thích dùng subscription Claude Code hoặc Cursor cloud agent của mình để làm phần việc thật hơn. Một mặt là chuyện tiền. Theo Rob (video đăng ngày 31/10/2026), Grok Bot chạy trên một pool usage hằng tuần, dùng chung với Grok và Cursor, vì lúc đó họ đã có một plan hợp nhất. Nếu bạn dùng Grok để làm hết mọi việc code, bạn sẽ đốt credit hay quota khá nhanh. Anh thích đẩy việc sang subscription anh đang có với Claude Code hoặc OpenCode hơn.

Mặt khác là chuyện cô lập (isolation). Theo Rob (video đăng ngày 31/10/2026), chia việc ra còn cho bạn sự cô lập, vì mỗi worker có máy tính riêng, context riêng và kill switch (công tắc tắt) riêng. Rob có các môi trường dựng sẵn trên máy, trong các container trên máy Mac, và cả các môi trường trên một VPS; Grok Bot làm việc được với tất cả những môi trường này (setup của anh, video đăng ngày 31/10/2026).

6. Vòng lặp mỗi ngày của Lauren: năm bước

Vậy một người chạy workflow kiểu này hằng ngày thì trông thế nào? Rob đưa ra vòng lặp mỗi ngày (daily loop) của Lauren, gồm năm bước, theo bài đăng của cô mà anh cho xem trong video đăng ngày 31/10/2026:

1. Theo dõi một kênh Slack để lấy feedback về app (bước 1 theo bài đăng của Lauren, video đăng ngày 31/10/2026). Bạn có một kênh tạo cho team về một chủ đề nhất định, và có người đổ context về app đó vào đây.
2. Tạo ticket trong Linear. Grok Bot bắt được các feedback đó và tạo một ticket trong Linear (video đăng ngày 31/10/2026).
3. Gọi một Cursor cloud agent. Từ Linear, hay Jira, hay bất cứ công cụ nào, một Cursor cloud agent được kích hoạt để đi tái hiện (reproduce) lỗi trên máy tính riêng của nó (video đăng ngày 31/10/2026).
4. Fix và fuzz. Agent tái hiện được bug rồi đưa lên cái mà Lauren gọi là pull request "fix and fuzz", với một bầy (swarm) agent nhỏ (video đăng ngày 31/10/2026).
5. Báo và merge. Nếu phần fuzz sạch, nó chỉ ping cô trên Slack, rồi tự động merge sau một giờ, trừ khi cô yêu cầu sửa (video đăng ngày 31/10/2026).

Rob giải thích "fix and fuzz" gắn với một số skill của Lauren trong pstack. Đây là lúc một bầy agent mở pull request ra và tìm cách làm nó hỏng, bằng cách bấm ngẫu nhiên khắp nơi, hoặc dùng Playwright hay công cụ tương tự, để xác minh bản sửa là đúng: dùng app như một người dùng thật sẽ dùng, để chắc chắn không có gì vỡ. Theo Rob (video đăng ngày 31/10/2026), đó là lý do verification là phần cực kỳ quan trọng trong các bước này.

7. Không phải bug nào cũng vào vòng lặp, và hình ảnh nhà bếp Michelin

Rob thêm một ý. Nếu nhìn cách Anthropic tiếp cận chuyện này (theo Rob, video đăng ngày 31/10/2026), bạn sẽ không áp vòng lặp trên cho mọi loại bug hay issue. Bạn chia theo xanh, vàng, đỏ, tuỳ blast radius (phạm vi ảnh hưởng nếu có sự cố). Nếu một việc cực kỳ quan trọng, ví dụ liên quan tới thanh toán, bạn sẽ không để nó tự động merge ở bước đó; bạn muốn có một người can thiệp. Nhưng rất nhiều bug, nhiều bản sửa nhỏ, nhiều task không quan trọng có thể chạy trong kiểu workflow này.

Theo Rob (video đăng ngày 31/10/2026), trong một video của mình, Lauren cũng nói cô không thật sự thích từ "software factory". Cô dùng hình ảnh một nhà bếp Michelin. Theo lời cô, là developer, chúng ta vẫn chịu trách nhiệm cho kết quả cuối cùng. Rob nói Addy Osmani bên Anthropic cũng nhấn mạnh đúng khái niệm này. Vậy với agent, về cơ bản bạn là bếp trưởng (head chef): bạn không còn tự nấu mọi món, nhưng tên bạn vẫn nằm trên từng đĩa thức ăn được mang ra, kể cả khi có cả một đội làm việc cho bạn.

Theo Rob (video đăng ngày 31/10/2026), phần lớn của nhà bếp Michelin hay software factory của bạn là biết khi nào có thể tin những gì agent đã làm đủ để merge nó.

8. Trust stack: kim tự tháp ngược bốn tầng

Rob muốn gạt bớt phần hype. Theo anh (video đăng ngày 31/10/2026), điều có thể học được là số ít công ty đang làm theo phương pháp software factory thuần không làm được điều đó bằng cách thêm ngày càng nhiều agent. Họ bắt đầu bằng hạ tầng thô và niềm tin, vì làm sao bạn quản lý nổi 50 agent nếu bạn còn chưa tin được một agent.

Theo Rob (video đăng ngày 31/10/2026), câu trả lời của Lauren cho chuyện này là cái cô gọi là kim tự tháp ngược (inverse pyramid). Nó có bốn tầng, và bạn muốn dồn phần lớn công sức vào tầng trên cùng.

1. Codebase. Kiến trúc tốt hơn, typing chặt hơn, ranh giới rõ ràng. Câu nguyên văn của Lauren mà Rob trích: agent rất thích sao chép những gì đang có và đi đường ngắn nhất. Vậy hãy làm cho điều dễ làm cũng là điều đúng (video đăng ngày 31/10/2026).
2. Static analysis (theo Rob, video đăng ngày 31/10/2026). Các bài kiểm tra truyền thống, mang tính tất định (deterministic), mà chúng ta đã chạy từ lâu trước khi có agent: lint rule, test, continuous integration (CI). Theo Rob, nếu bạn thấy agent cứ mắc cùng một lỗi lặp đi lặp lại, hãy biến nó thành một lint rule tất định. Nếu lần nào bạn cũng phải dọn dẹp sau agent về cùng một vấn đề, là bạn đang làm sai; điều đó cần được lập trình hẳn vào để không xảy ra nữa.
3. Prose. Theo Rob (video đăng ngày 31/10/2026), đây là các file rule: AGENTS.md, CLAUDE.md, skill của bạn, Bugbot, security bot của bạn.
4. Human review. Nằm ở dưới cùng. Theo Rob (video đăng ngày 31/10/2026), đây là tầng mà phần đông chúng ta dựa vào nhiều nhất, và cũng là tầng không scale được.

9. Anthropic và Alan Wells: niềm tin phải xây từ trước

Rob nói (video đăng ngày 31/10/2026) bên Anthropic cũng đang thấy điều tương tự. Bài "How the Claude Code team does code review" (Addy Osmani, Morgan Westlee Lunt và Qing Wang, đăng 15/10/2026) ghi rằng từ tháng 6 tới tháng 9 năm 2026, số pull request được merge vào codebase Claude Code tăng hơn gấp đôi, trong khi tỉ lệ phải revert giảm hơn 40 phần trăm. Rob nhấn mạnh: đúng là họ làm gấp đôi số pull request, nhưng các pull request đó thật sự chạy, thật sự land, không làm hỏng gì. Câu của họ về việc này là: họ không bỏ review, nhưng đã chuyển phần lớn việc đọc review sang cho máy.

Theo Rob (video đăng ngày 31/10/2026), tất cả các công ty anh từng tìm hiểu đều thừa nhận rằng đi tới mức tin được như vậy cần rất nhiều công sức bỏ ra từ trước. Ví dụ, Alan Wells điều hành một team ba người để đưa factory của mình tới chỗ ship pull request mà không cần người review code. Theo bài đăng của Alan mà Rob cho xem, team của anh đã dừng mọi việc phát triển sản phẩm mới khoảng sáu tuần chỉ để xây tất cả phần validation. Alan nói lúc đó rất đau đớn, nhưng hoàn toàn đáng.

10. Demo: một chat, nhiều bot

Tới factory của chính Rob. Anh có bot cho từng mảng trong công ty, và anh đã cố hết sức để không tạo ra 50 bot khác nhau, vì chi phí quản lý chúng trở nên quá lớn. Trong một thế giới lý tưởng, anh chỉ muốn chat với một agent. Đó là việc của agent chính tên Chief: Chief giao việc và làm việc cùng các bot khác, và bạn còn có thể lập group chat để các bot nói chuyện với nhau (setup của Rob với Grok Bot, video đăng ngày 31/10/2026). Mỗi bot của anh có quyền hẹp, chỉ nối tới những gì nó cần, để khi cần anh có thể chia sẻ bot đó cho người khác.

Theo Rob (video đăng ngày 31/10/2026), Grok Bot có một vault để lưu mọi credential. Anh nói anh không chắc mình thấy thoải mái tới đâu với chuyện này. Theo anh, phần lớn những gì Grok Bot làm là che bớt độ phức tạp, nhưng anh hơi tiếc vì không còn nhìn được memory nào đang được lưu, skill nào, vault đang được quản lý ra sao. Để tiếp tục tin Grok Bot về lâu dài, anh sẽ muốn thấy nhiều hơn những thứ đó.

Nhưng ở thời điểm quay video (đăng ngày 31/10/2026), anh chấp nhận rủi ro với Grok Bot và thử nghiệm ở rìa của những gì có thể làm được, chủ yếu để chia sẻ lại với người xem.

11. Demo: marketing site, Claude Code headless, điện thoại, Mac và PC

Rob lấy một project làm ví dụ: marketing site của anh. Anh chat với Chief, và Chief dựng lên hoặc một Cursor cloud agent, hoặc một phiên Claude Code trên máy Mac của anh. Anh cũng đã nối nó với VPS của mình. Theo Rob (video đăng ngày 31/10/2026), phần setup rất đơn giản: về cơ bản bạn chỉ cần prompt Grok Bot để tạo kết nối và nói cho nó biết bạn muốn nó chạy thế nào.

Trong trường hợp này, anh đã nói với Grok Bot rằng anh muốn nó chạy việc trên Cursor cloud agent với một số tiêu chí nhất định; còn nếu chạy các phiên Claude Code thì anh luôn chỉ định model mặc định phải dùng. Theo Rob (video đăng ngày 31/10/2026), Grok Bot về cơ bản lưu điều đó vào một skill ở đâu đó. Một lần nữa, anh không xem được skill đó nằm ở đâu, nhưng với anh nó có vẻ chạy ổn. Nếu bạn không thoải mái với mức kiểm soát này, với việc không nhìn thấy skill của mình, thì tất nhiên bạn có thể tự dựng agent riêng để làm điều tương tự như Grok Bot.

Điều Rob thích ở Grok Bot là anh có nó trên điện thoại và nó chạy rất dễ. Anh có nó trên máy Mac dưới dạng app desktop, có nó trên một máy PC riêng, và tất cả có thể phối hợp với nhau (theo trải nghiệm của Rob, video đăng ngày 31/10/2026). Anh nói bạn cũng có thể làm điều tương tự với thứ như Tailscale.

Trong mỗi folder hay môi trường, dù là Cursor CLI hay Claude Code, Rob có bộ quyền và rule bảo mật riêng. Rồi Grok Bot khởi chạy Claude Code ở chế độ headless với model anh đã chọn (setup của Rob, video đăng ngày 31/10/2026). Anh dùng đúng setup này cho các video của chính anh khi để Opus 5.5 giúp làm phần hình ảnh: nó dựng nhiều agent khác nhau và quay các đoạn terminal khác nhau.

Theo Rob (video đăng ngày 31/10/2026), vì Grok Bot đóng vai orchestrator cho cloud agent hay agent trên máy, nó có thể tự đưa ra một số quyết định mà không cần anh. Nó được nối với Slack của anh, nối với nhiều nguồn tài liệu khác, nên có thể gỡ vướng cho các sub-agent khi chúng có câu hỏi.

12. Từ backlog tới pull request: Notion và chấm điểm RICE

Theo Rob, Theo cũng đang thử một workflow tương tự với T3 Code, và đã ghi lại một phần trong một tweet. Theo nói anh giờ có thể điều khiển cả đội máy của mình từ Grok Bot. Theo lời Rob (video đăng ngày 31/10/2026), tính năng này đang ở bản nightly build và còn rất sớm, nhưng bạn đã có thể thấy mọi thứ đang đi về đâu.

Trong setup của Rob (video đăng ngày 31/10/2026), mọi thứ Chief nhặt được từ Slack hay từ các cuộc trò chuyện của anh về cơ bản đều đi vào một backlog, và anh để Grok Bot lưu tất cả vào Notion. Nhưng bạn có thể dùng Linear hay Jira, hay bất cứ thứ gì tương tự.

Anh dựng thêm một routine khác với Grok Bot để triage backlog bằng điểm RICE: reach, impact, confidence và effort (độ phủ, tác động, độ tin cậy và công sức) của từng issue hay feature cần làm. Anh còn có thêm một điểm blast radius. Với setup này, một việc nhỏ mà giúp được nhiều người sẽ nổi lên trên một bản sửa vặt (theo Rob, video đăng ngày 31/10/2026). Và nó thường còn đề xuất thêm các cải tiến mới: bạn chỉ cần bảo bot chủ động về việc nên làm tiếp theo.

Nhưng Rob dặn (video đăng ngày 31/10/2026): đừng làm vậy chỉ vì muốn làm, vì nó sẽ nhanh chóng lấp đầy backlog của bạn bằng những task sinh ra chỉ để có task.

13. Routine farm context của Lauren và nhãn blast radius

Theo Rob, Lauren cũng làm một việc tương tự để cải tiến. Bài đăng của cô mà Rob cho xem trong video (đăng ngày 31/10/2026) ghi rằng cô dùng routine của Grok Bot để "farm context": gom bug report trên Slack, rồi các phàn nàn đến từ X, và đưa tất cả vào cái cô gọi là "outer loop".

Rob cảnh báo một điều: chuyện đó ổn với người như Lauren, người có rất nhiều inference và credit để dồn vào những việc kiểu này. Theo Rob (video đăng ngày 31/10/2026), nếu bạn tự làm điều tương tự theo lịch mỗi giờ, bạn sẽ đốt rất nhiều token.

Một điều nữa Rob nói anh làm là đánh dấu mọi thay đổi theo blast radius: nếu thay đổi này hỏng thì có thể làm vỡ bao nhiêu thứ. Anh tự sửa lại ngay: thật ra không phải anh đánh dấu, mà anh để agent làm việc đó. Theo Rob (video đăng ngày 31/10/2026), bạn có thể để agent tự xác định mức độ quan trọng, và từ đó là mức review: người review, hay AI ở mức một, hai hoặc ba. Mỗi mức kéo theo các mức test bằng Playwright và test bảo mật khác nhau.

14. Khoá cửa: mọi bot dùng chung một máy tính

Việc cuối cùng cần làm về mặt niềm tin, theo Rob, là khoá cửa. Theo Rob (video đăng ngày 31/10/2026), mọi Grok Bot của bạn dùng chung một máy tính trên cloud, gồm cả file, phiên trình duyệt và credential của command line. Trang tài liệu "Use the computer and apps" của Grok Bot (đọc ngày 31/10/2026) cũng ghi đúng điều này: mọi bot trong tài khoản dùng chung một máy, cookie và phiên đăng nhập của trình duyệt được chia sẻ, file hiện ra với mọi bot, và credential của command line cũng được chia sẻ. Vậy hãy cẩn thận: theo Rob, nếu bạn đăng nhập một coding CLI bằng API key trên một máy của Grok Bot, mọi bot bạn có đều dùng được key đó.

Rob nói anh sẽ là người đầu tiên thừa nhận có điều gì đó rất hấp dẫn và mạnh mẽ ở việc chỉ cần nối thật nhiều công cụ và cho agent quyền vào mọi workflow của bạn. Có một kiểu tốc độ đẹp đẽ khi đi nhanh và làm vỡ mọi thứ, nhưng theo anh (video đăng ngày 31/10/2026), chắc chắn rồi sẽ có ngày nó quay lại cắn bạn.

Rob nhắc tới việc Docker cùng một nhóm công ty bảo mật vừa công bố một kiến trúc tham chiếu (reference architecture) cho secure software factory (theo bài viết của Docker, đọc ngày 31/10/2026). Ý trung tâm của nó là: bạn càng cho agent nhiều quyền tự chủ, bạn càng ít có thể dựa vào việc nó tự giám sát chính nó. Các cơ chế kiểm soát phải nằm trong môi trường. Rob nói anh đồng ý 100% với điều này.

Theo Rob (video đăng ngày 31/10/2026), trong thực tế điều đó có nghĩa là: chạy agent trong sandbox, cấp cho chúng credential có scope giới hạn, chỉ cho quyền đọc ở chỗ nào có thể, và cho chúng mở pull request nhưng không merge, ít nhất là cho tới khi bạn tin được cái stack đang có.

Rob nói thêm (video đăng ngày 31/10/2026): Grok Bot ở vai orchestrator sẽ không giải quyết được hết những vấn đề đó. Đây là những quyết định bạn phải tự đưa ra trong từng codebase bạn đã dựng, dựa trên mức độ quan trọng của nó.

15. Rule thứ nhất cho software factory của bạn

Nếu bạn muốn bắt đầu theo hướng này, lời khuyên của Rob (video đăng ngày 31/10/2026) là đừng đi build 50 agent. Hãy bắt đầu bằng một vòng lặp, và dán rule này vào bot của bạn. Theo lời anh, rule cơ bản bạn nên đưa cho Grok Bot là:

For anything more than a short question, don't write the code yourself. Hand it to a coding agent with an acceptance test, check the proof, open a pull request and report back.

Trên màn hình (video đăng ngày 31/10/2026) là một thẻ "Your first rule" gửi tới Grok Bot, mở đầu bằng "For anything more than a short question:", và dòng "Write the code yourself" bị gạch đi.

Theo Rob (video đăng ngày 31/10/2026), sau đó, mỗi lần bạn phải sửa lưng một agent, hãy đẩy bản sửa đó lên cao trong stack: sửa code trước, rồi tới một lint rule, rồi tới một file rule, và review đứng cuối cùng.

Rob nói (video đăng ngày 31/10/2026) tất nhiên có thể có nhiều bước hơn thế, và bạn cần tự tìm ra các chi tiết ở giữa. Nhưng về cơ bản, điều đang cố làm ở đây là move human review up, đẩy human review lên.

16. Lời cảm ơn Patrick Stewart

Video khép lại bằng một lời tưởng nhớ. Theo lời Rob trong video đăng ngày 31/10/2026, tin buồn được đưa ra một ngày trước khi anh quay video: Patrick Stewart, vị thuyền trưởng Picard mà anh yêu quý, đã qua đời. Rob kể Patrick Stewart đóng một vai trò rất lớn trong tuổi thơ và cả cuộc sống trưởng thành của anh. Hồi nhỏ, anh thường chạy vội về nhà lúc năm giờ chiều để xem The Next Generation trên Sky TV.

Theo Rob (video đăng ngày 31/10/2026), ở vai trò diễn viên, Patrick Stewart đã khắc hoạ một cách bậc thầy cái khuôn mẫu cho điều anh nghĩ một người lãnh đạo tốt nên có: có văn hoá, có tài ăn nói, mạnh mẽ và công bằng, giữa một hình mẫu về tương lai tươi đẹp mà Gene Roddenberry đã tạo ra trong Star Trek, một tương lai mà Rob hy vọng chúng ta đang hướng tới. Anh chỉ muốn nói lời cảm ơn Patrick vì tất cả, và chúc ông thượng lộ bình an (Godspeed).