Devin, Cursor và Codex Cloud vận hành bên dưới ra sao

1. Cloud agent là gì, và vì sao nó là "Lovable bản nâng cao"

Tác giả kênh SouryaTalks mở đầu: trong video này (đăng ngày 11/10/2026), anh sẽ đi sâu vào system design của cloud agent. Anh nói rõ chủ đề không chỉ gói trong chuyện code; cloud agent có thể làm đủ loại task. Theo anh, phần lớn người xem đã từng nghe tới loại agent này. Có thể bạn đã nghe về Cursor Cloud; anh kể hồi trước mình gặp rất nhiều quảng cáo Cursor Cloud trên YouTube, và có thể bạn cũng vậy. Có thể bạn đã nghe về Devin, cái tên mà anh nói đã bước vào mảng này với hình ảnh "kỹ sư phần mềm của bạn, chạy trên cloud".

Rồi còn các nền tảng kiểu Codex Cloud. Theo cách anh mô tả trong video đăng ngày 11/10/2026, tất cả các nền tảng này vừa cung cấp cloud agent vừa cung cấp cả một môi trường agentic hoàn chỉnh. Bạn có thể chạy agent trong CLI ngay trên máy mình, và cũng có thể chạy chính các agent đó trên một VM ở cloud. Ví dụ, nếu bạn chạy Claude Code trên một VM, đó chính là cloud agent. Những nền tảng nói trên quản lý giúp bạn các cloud agent này: bạn không phải lo chuyện VM, họ đưa cho bạn cả môi trường, chạy agent ở đó và cho bạn một giao diện đẹp mà bạn không cần tự quản lý (theo anh, video đăng ngày 11/10/2026).

Ý tưởng thì đơn giản. Câu hỏi của video (đăng ngày 11/10/2026) là: làm sao build được một nền tảng như vậy, làm sao build một Devin chạy trên cloud, hay một Cursor agent chạy trên cloud?

Để dễ hình dung, anh lấy Lovable làm mốc. Với Lovable (theo lời anh trong video đăng ngày 11/10/2026), bạn không phải quản lý agent của Lovable trên máy mình, cũng không phải quản lý nó trên backend của bạn; họ lo hết trên backend của họ, còn bạn chỉ tương tác với giao diện Lovable. Vậy Devin, Cursor Cloud và những cái tên tương tự là gì? Theo anh, chúng là dạng nâng cao của Lovable: lấy Lovable, gắn vào một loại agent nào đó (có thể là pi, có thể là một agent khác), cộng thêm rất nhiều thứ nữa, là thành một cloud agent đầy đủ.

2. Hành trình sẽ thiết kế: từ lúc đăng ký tới lúc PR về repo

Anh vạch ra những gì video sẽ đi qua. Đầu tiên, user phải sign up. Sau đó user phải cấp quyền truy cập GitHub repo mà agent sẽ làm việc trên đó. Anh giải thích lý do: giả sử bạn giao một task cho Claude Code đang chạy trên một VM ở cloud. Nó cần clone repo, đúng không? Rồi nó cần tạo PR vào GitHub repo. Để tạo PR, để mở issue, để clone repo, cho tất cả những việc đó, bạn phải cấp cho agent quyền truy cập GitHub (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

Tiếp theo, video sẽ xem cách gửi task và kích hoạt agent, kiến trúc tổng thể, cách agent chạy các tool, giao diện trông như thế nào, và cuối cùng là PR được đưa vào GitHub repo của mình (lộ trình anh nêu trong video đăng ngày 11/10/2026).

3. GitHub access: personal access token hay GitHub App

Phần đầu tiên là GitHub access. Theo anh, có hai lựa chọn: PAT, tức personal access token, và GitHub App. Với cả hai cách, khi bạn đưa personal access token hoặc GitHub App, agent đều có được quyền truy cập GitHub. Bạn định nghĩa được nó có quyền đọc hay quyền ghi, quyền tạo PR hay quyền commit (theo cách anh trình bày trong video đăng ngày 11/10/2026).

Vậy tại sao nên chọn GitHub App? Anh nói anh không chắc mọi người đã biết personal access token hay GitHub App là gì, nên giải thích lại. Personal access token được tạo từ phần settings trong profile của bạn. Đó là token cá nhân của bạn, nên mọi repo bạn có quyền truy cập thì token này cũng có quyền truy cập. Dù bạn có thể chọn cấp quyền cho repo nào, nhưng với token cá nhân, bạn cấp được bất kỳ quyền nào. Có điều nó có một nhược điểm, và đó là chỗ GitHub App xuất hiện: token gắn với một người. Nếu người đó rời tổ chức, token chết, và mọi người mất quyền truy cập (theo anh, video đăng ngày 11/10/2026).

Anh lấy ví dụ. Giả sử bạn tạo một project trên Devin hoặc Codex Cloud bằng chính personal access token của mình. Cả tổ chức có 10 thành viên, và cả 10 người đều dùng Devin hay Codex Cloud. Rồi người đã tạo PAT và kết nối GitHub rời tổ chức. Token sẽ chết, vì profile đã tạo personal access token đó không còn quyền gì trong tổ chức nữa, họ đã đi rồi. Thế là cả tổ chức mất kết nối tới GitHub, và phải kết nối lại bằng một token khác (ví dụ của anh trong video đăng ngày 11/10/2026).

Cho tình huống đó, người ta dùng GitHub App. Anh nói nếu bạn đã từng tạo project bằng GitHub App thì có lẽ bạn đã quen. Với GitHub App, cả tổ chức cài app của bạn và chọn các repo. Nó không gắn với một cá nhân nào (theo anh, video đăng ngày 11/10/2026).

4. Tạo GitHub App và luồng cài đặt

Anh mô tả cách tạo GitHub App ngay trên GitHub (theo các bước anh kể trong video đăng ngày 11/10/2026). Từ tổ chức, bạn vào organization settings, chọn repo muốn cấp quyền, chọn các permission: đọc, ghi, tạo PR, commit, bạn chọn trong danh sách. Rồi bạn tạo GitHub App. Khi GitHub App đã sẵn sàng, bạn nhận một callback URL từ nền tảng. Nếu đang dùng Codex Cloud, Codex Cloud sẽ hiện một callback URL, và URL đó cần được dán vào GitHub App. Từ đó, mỗi khi GitHub App được tạo, mọi thứ sẽ được gửi về callback URL ấy.

Tóm lại, theo anh (video đăng ngày 11/10/2026), ta có thể dùng GitHub App để kết nối repo với Codex Cloud hay Devin. Đó là ý chính, và anh hy vọng phần này đã rõ.

Giờ tới install flow. User bấm "Connect GitHub"; sẽ có một nút để kết nối GitHub. User chọn repo, rồi approve. Callback URL chính là thứ đã đặt vào GitHub App. Backend mà ta đang build sẽ nhận các trigger: mỗi khi GitHub App được tạo, toàn bộ thông tin đi về callback URL này, và ta lưu chi tiết vào database. Vậy là có quyền truy cập repo, bước đầu tiên đã xong (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

5. Token nào được đưa vào sandbox

Câu hỏi quan trọng tiếp theo: token nào đi vào sandbox? Trước hết, anh nhắc rằng có một sandbox được tạo ra. Sau khi bạn kết nối GitHub, một sandbox được gán cho repo đó và nó sẽ clone repository. Vậy sandbox dùng token nào? Khi ta tạo GitHub App, nó cũng đưa cho ta token; tất cả token đó được gửi tới callback URL, về backend của nền tảng, và ta lưu vào database (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

Anh hỏi người xem: bạn có nghĩ token này được dùng để clone repo hay thực hiện các thao tác từ trong sandbox không? Câu trả lời là không. Ta không đưa secret key hay secret token thật vào sandbox, nếu không thì ai cũng thấy được token đó, và ta không muốn để lộ nó. Giả sử một thành viên mở terminal của sandbox, copy GitHub token, rồi rời tổ chức: họ vẫn còn quyền truy cập, đúng không? Ai cũng có thể ls vào sandbox và lấy token, và theo anh đó hoàn toàn không phải một practice tốt (video đăng ngày 11/10/2026).

Vì thế, theo anh, ta dùng một thứ gọi là installation token, cũng lấy từ chính GitHub API. Cách làm: khi tạo GitHub App, ta có một private key được sinh ra. Dùng private key đó, ta tạo một JWT đã ký, và đổi lấy một installation token chỉ có hiệu lực trong một giờ và chỉ cho các repo đã chọn. Anh gọi đây là practice tốt hơn nhiều. Sandbox dùng installation token này để clone repo và làm mọi thao tác khác trong phạm vi quyền của token, nhưng token chỉ sống một giờ; hết giờ thì xin token mới, và nó được làm mới liên tục như vậy. Sandbox không hề giữ private key thật, nó chỉ dùng installation token (theo anh, video đăng ngày 11/10/2026). Tài liệu GitHub cũng ghi installation access token hết hạn sau 1 giờ (đọc ngày 25/10/2026).

Anh nói thêm: đây là best practice, chứ không phải là bạn không thể dùng private key để fetch và push lên GitHub. Anh hy vọng phần này đã rõ (video đăng ngày 11/10/2026).

6. Bấm gửi: mỗi session một sandbox mới

Chuyện gì xảy ra khi bạn giao task cho agent? Giả sử bạn đã kết nối GitHub, tạo GitHub App và làm xong mọi thứ. Bạn muốn làm việc trên một repository, bạn thêm repository đó và giao task. Việc đầu tiên là nó khởi động một sandbox. Theo anh, trong phần lớn trường hợp, các nền tảng cấp một Docker container; có nền tảng còn cấp hẳn một VM. Dù thế nào, đó là một môi trường hoàn toàn mới cho mỗi task, mỗi session (theo cách anh mô tả trong video đăng ngày 11/10/2026).

Vì vậy, mỗi thread bạn thấy trong Claude Code, Codex Cloud hay Devin là một sandbox riêng: nó clone repo, inject token và chạy agent. Một sandbox cho mỗi session? Anh trả lời: đúng vậy. Mỗi session, hay mỗi thread, nhận một sandbox mới, có thể là một Docker container (theo anh, video đăng ngày 11/10/2026). Trang "One sandbox per session?" trên bảng của anh ghi thêm cảnh "nhìn vào bên trong một sandbox của Devin": thư mục ~/repos có thêm một repo, và repo cũ không có node_modules, nghĩa là cài đặt cũ đã mất, không phải cùng một máy; repo cũ vẫn được clone lại; và nếu các session từng dùng chung một máy, git worktree sẽ giữ các việc song song tách nhau. Anh nói sẽ cho xem ngay trên Codex Cloud của mình để mọi thứ rõ hơn.

7. Demo Codex Cloud: dựng một trang portfolio trên cloud

Anh mở Codex Cloud (giao diện như trong video đăng ngày 11/10/2026). Ở đây có thể tạo environment mới; một environment mới nghĩa là một repository mới. Khi refresh, bạn sẽ thấy mọi repository đã kết nối với tài khoản GitHub của mình, tất cả hiện ra ở đây. Anh đã kết nối sẵn một environment, tức một repository, và có thể làm việc trên đó.

Anh bắt đầu một chat mới. Trên màn hình (video đăng ngày 11/10/2026), anh chỉ ra rằng có thể chọn "this computer", tức máy của chính anh, hoặc chọn cloud; cũng chọn được environment, tạo environment mới hoặc chọn một environment đã tạo. Rồi anh giao task: tạo một trang portfolio cho anh, hãy vào xem kênh của anh. Anh dán link kênh YouTube của mình vào.

Can you create a portfolio website for me so you can visit my yt channel

Anh để nó ở fast mode, và nói fast mode sẽ đốt nhiều credit của anh hơn, nhưng không sao (theo lời anh trong video đăng ngày 11/10/2026). Lúc này task đang chạy trên cloud chứ không chạy trên máy của anh. Anh mở file system của cloud ra cho thấy: có một folder codex cloud đang trống, nó đã khởi tạo git repository, có scratch, shared, downloads. Tất cả những file đó nằm trên cloud, không nằm trên máy local (demo trong video đăng ngày 11/10/2026).

Anh để nó chạy tiếp và dựng toàn bộ trang. Một lúc sau, agent hỏi lại: kênh của anh nói về những chủ đề gì, và anh muốn một đoạn bio ngắn thế nào trên portfolio? Trên màn hình, ngay trước câu hỏi đó, Codex ghi rằng YouTube đang chặn truy cập vào kênh nên nó chưa xác minh được video hay bio (demo trong video đăng ngày 11/10/2026). Anh trả lời:

Can you grab them from the channel only and no need to ask me any other questions?

Anh chỉ ra điểm chính của demo: những gì đang hiện ra trên giao diện của chat thread này, thực chất đang chạy trên một VM của Codex Cloud (demo trong video đăng ngày 11/10/2026). Anh để nó "cook" tiếp, trong lúc bàn thêm vài chuyện.

8. Agent loop chạy ở đâu: trong hay ngoài sandbox

Câu hỏi tiếp theo: agent loop chạy ở đâu? Từ đầu video anh vẫn nói nó chạy trên cloud. Nhưng nó chạy bên trong sandbox hay bên ngoài sandbox? Anh nói có thể bạn đã đoán ra khi nhìn màu trên bảng: nó không chạy bên trong chính cái sandbox được tạo ra. Ở bước trước, sandbox được tạo, repo được clone vào sandbox, và việc chạy agent diễn ra; nhưng agent không chạy trong sandbox này, mà chạy riêng ra (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

Anh vẽ ra: ta có frontend, có backend, frontend nối tới backend. Ta giao một task, ví dụ "create me dark mode in my portfolio website" (anh viết tay chữ này lên bảng). Sau khi giao task, nó đi tới backend. Backend gửi task tới agent, một thành phần riêng. Hai việc diễn ra song song: backend tạo sandbox. Sandbox có thể là E2B hay Daytona; anh nhắc thêm Docker, nói Docker đã giới thiệu một Docker agent cloud. Tất cả những dịch vụ đó cung cấp sandbox cho bạn (theo anh, video đăng ngày 11/10/2026). Bạn cũng có thể tự quản lý sandbox trên EC2 hay bất kỳ loại VM nào: ví dụ bạn mua một máy EC2 từ AWS rồi tự tạo các Docker container bên trong máy EC2 đó.

9. Bốn mảnh ghép: frontend, backend, agent, sandbox

Như vậy, backend kết nối tới sandbox và tới agent, còn agent chạy riêng chứ không chạy trong sandbox. Anh nói sẽ quay lại chuyện hai thứ này kết nối với nhau thế nào, tức agent nói chuyện với sandbox ra sao. Trước hết, theo anh, agent chẳng qua là LLM cộng với tool, và agent sẽ dùng một số tool để kết nối tới sandbox. Vậy là có bốn mảnh quan trọng: frontend, backend, agent và sandbox (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

10. WebSocket, và những gì chạy bên trong sandbox

Anh chuyển sang toolbox mà agent nên có. Agent cần một bash shell tool, thứ có thể tạo, xoá, sửa, đọc, làm gì cũng được. Editor là một tool riêng: đó là code editor mà đôi khi bạn thấy. Anh nói Codex Cloud chưa có phần này vào thời điểm video đăng (11/10/2026), nên anh không cho xem được trên máy mình. Nhưng nếu bạn dùng Devin hay thứ gì tương tự, bạn có cả trải nghiệm VS Code, cả VS Code được đưa vào một trang web. Anh hẹn quay lại chuyện này sau.

Đây chưa phải toàn bộ toolbox. Agent có một loạt tool để gọi; qua đó nó thực hiện thao tác trên sandbox và nhận kết quả về. Còn có database: agent nói chuyện được với database, backend cũng vậy. Theo cách anh vẽ (video đăng ngày 11/10/2026), kết nối frontend tới backend là WebSocket, và kết nối frontend tới sandbox cũng là WebSocket.

Tại sao frontend lại nối thẳng tới sandbox? Anh giải thích: có một code IDE mà bạn dùng ngay trong browser, và IDE đó đang chạy trên sandbox. Vì thế website frontend được nối trực tiếp tới sandbox. Bạn thậm chí có thể chạy một browser bên trong sandbox và xem nó từ frontend. Tất cả những thứ đó đều là kết nối WebSocket (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

Vậy cái gì chạy bên trong sandbox? Theo anh (video đăng ngày 11/10/2026): có code của bạn; có dev server, tức npm install, cargo install hay pip install tuỳ ngôn ngữ bạn dùng, nó cài mọi thứ rồi start server, có thể ở port 3000 hay port khác; có một browser thật, được stream về cho bạn dưới dạng video qua WebSocket; và có code-server, tức VS Code trong browser, chính là thứ anh nhắc ở trên. Mỗi chat thread có Docker container riêng.

11. Bash có đủ không: toolbox đầy đủ và bản V1 cần gì

Tiếp theo anh hỏi: bash có đủ không? Theo anh, còn một loạt thứ khác (video đăng ngày 11/10/2026). Có bash tool. Có code-server, VS Code trong browser như đã nói, đang chạy. Có LSP. LSP là gì? Anh giải thích: LSP chính là phần định nghĩa và kiểu dữ liệu mà bạn thấy trong VS Code. LSP gắn với VS Code hay bất kỳ loại IDE nào: khi bạn hover lên một function, một biến hay một cú pháp, nó hiện định nghĩa, đúng không? Nó cũng có sẵn các type. Tất cả những thứ đó chạy bên trong sandbox. Browser cũng chạy trong sandbox. Có thể còn vài MCP server chạy trong sandbox. Có kết nối GitHub trong sandbox.

Rồi tới "ask user": có hẳn một tool để hỏi user. Giả sử agent không chắc về điều gì, nó có thể hỏi user. Nó cũng có một deploy tool, để sau khi mọi thứ đã được push lên GitHub, nó còn deploy được cả app (theo cách anh liệt kê trong video đăng ngày 11/10/2026).

Đó là danh sách những thứ sandbox có. Với bản V1, theo anh, có thể bỏ qua vài thứ. Deployment khó implement hơn một chút, có thể để sau. Cho nhu cầu cơ bản (theo anh, video đăng ngày 11/10/2026):

• Bash tool, tức shell.
• Code editor, lý tưởng là code-server.
• Ask the user.
• GitHub connection: theo anh là bắt buộc, không có thì không làm việc được (video đăng ngày 11/10/2026).
• Browser: có thì tốt (nice to have), vì theo anh thêm tích hợp browser vào một setup Docker container cũng không dễ (video đăng ngày 11/10/2026).

Trang "What a V1 needs" trên bảng của anh (video đăng ngày 11/10/2026) liệt kê đúng năm mục Shell, Editor, Ask the user, Git / GitHub, Browser (nice to have), kèm hai ghi chú: dùng lại pi agent như một service riêng, phần mới là đưa repo vào sandbox; và một phần khó âm thầm là giữ giao diện đồng bộ, ví dụ agent mở một shell thì có tab mới bật lên không, việc mà bảng gọi là "more full-stack than AI".

12. Agent bên ngoài, tool bên trong: tool-call queue

Tiếp theo là câu "agent outside, tools inside". Quay lại sơ đồ: agent nằm ngoài sandbox, đúng không? Vậy làm sao nó chạy tool bên trong? Theo cách anh phác thảo (video đăng ngày 11/10/2026), có một tool queue nằm giữa agent loop và sandbox. Agent gọi tool để chạy thứ gì đó trong sandbox.

Anh lấy ví dụ: giả sử đây là một queue, và đây là task đầu tiên. Agent muốn xem toàn bộ file, đó là một task; rồi nó cần tạo một folder mới. Đó là những task được xếp hàng vào queue, và agent đẩy tất cả vào đây dưới dạng một publish event. Theo anh, hệ thống này có cả pub/sub lẫn queue. Mọi thứ được đẩy vào queue này, và sandbox sẽ lấy ra từng cái một, chạy bên trong sandbox. Ngoài ra còn có một result queue: sandbox đẩy toàn bộ kết quả ngược vào queue đó, và kết quả đi về agent. Agent biết rằng lệnh nó gửi vào sandbox đã được thực thi (theo cách anh phác thảo trong video đăng ngày 11/10/2026).

"Đơn giản vậy thôi", anh nói. Ta có agent, có worker, và một queue ở giữa để mọi thứ đáng tin cậy hơn nhiều. Theo anh, agent thậm chí có thể gọi thẳng vào môi trường sandbox (video đăng ngày 11/10/2026).

13. Bức tranh đầy đủ: pub/sub và ba subscriber

Vậy làm sao một câu "hi" đi tới backend? Theo anh, đó là WebSocket như đã nói. Anh đưa ra bức tranh đầy đủ, trong đó pub/sub được implement như sau (theo cách anh phác thảo trong video đăng ngày 11/10/2026). Frontend nói chuyện với backend qua WebSocket. Frontend cũng nói chuyện với sandbox qua WebSocket. Tại sao lại nối tới sandbox? Vì frontend sẽ xem IDE, tức code-server, và cũng xem browser đang chạy trong sandbox; cho cả hai thứ đó, ta cần kết nối WebSocket thẳng tới sandbox.

Còn agent thì publish mọi hành động, mọi thứ nó đang làm, vào một queue pub/sub. Database, backend và sandbox là ba subscriber. Bất cứ điều gì agent nói ra đều phải được cả ba bên này nhận. Anh hỏi người xem: bạn có biết tại sao không? Vì giả sử agent cần gọi một tool, sandbox phải nhận được lời gọi đó, đúng không? Nên sandbox subscribe vào các event đó (theo mô hình anh vẽ trong video đăng ngày 11/10/2026).

Phòng khi bạn chưa biết pub/sub, anh mở thêm một trang trắng và vẽ lại. Trong pub/sub, có agent, và agent đang publish một thứ gì đó; đây là queue mà ta có. Đó là toàn bộ setup của pub/sub: ta có DB, có backend, có sandbox; agent publish event vào queue này, và cả ba đều subscribe vào event đó (hình vẽ trong video đăng ngày 11/10/2026).

Anh quay lại demo Codex Cloud của mình. Nó đã tạo xong landing page (demo trong video đăng ngày 11/10/2026). Anh chỉ vào các lệnh trong thread, như lệnh ls, và giải thích theo mô hình của mình: đó là những lệnh agent đưa ra; sandbox kéo chúng về vì nó subscribe vào queue của agent, tức pub/sub; backend cũng kéo về và hiện lên frontend những lệnh đang chạy; còn database lưu lại mọi thứ cần lưu. Đó là ba consumer, hay ba subscriber, nối vào pub/sub này.

14. Vì sao khó hơn Lovable

Vì sao thứ này khó hơn Lovable? Lovable cũng làm việc tương tự, đúng không? Như anh nói từ đầu, cloud agent là kiểu Lovable bản nâng cao. Theo anh (video đăng ngày 11/10/2026), ở Lovable, bạn nhận một React template; nó deploy lên static CDN, chủ yếu là frontend. Về backend, anh nói anh nghĩ họ đã tích hợp backend rồi, nhưng trước đây họ chỉ có frontend.

Về editor, anh nói Lovable thậm chí không có editor UI riêng, không có cả hệ thống file code và mọi thứ đi kèm; bạn sẽ không có trọn trải nghiệm IDE bên trong Lovable, đúng không? Bạn chỉ có khung chat ở panel bên trái, và bên phải là giao diện được sinh ra (theo lời anh, video đăng ngày 11/10/2026). Trên bảng, ô Editor của cột Lovable ghi "its own editor UI".

Còn ở các cloud agent thì sao? Theo anh (video đăng ngày 11/10/2026): mọi repo, mọi stack, trong khi ở Lovable bạn chỉ thấy React stack. Có cả backend: nó xử lý cả các project backend của bạn, có thể deploy project backend lên Fly.io, mà anh gọi là một nhà cung cấp cloud serverless. Nó có rất nhiều tool như LSP, cỡ cả trăm tool chứ không phải một nhúm. Nó có VS Code editor thật, không chỉ một giao diện riêng. Ngoài những thứ nâng cao đó, bạn còn có browser và một loạt thứ khác trong các cloud agent mà theo anh Lovable không cung cấp.

15. Tới lượt bạn: build một bản V1, và loại agent "luôn sống"

"Tôi nghĩ vậy là hết", anh nói. Bạn có thể coi những điều này là một thử thách. Anh nói sẽ chia sẻ slide deck này. Đây là cách thiết kế cả một cloud agent. Theo anh (video đăng ngày 11/10/2026), build một nền tảng đơn giản như thế này không phải là phần khó; scale nó mới là chuyện khó. Bạn có thể build đúng những gì anh đã liệt kê ở đây, theo checklist sau khi build.

Checklist V1 trên trang cuối của bảng (video đăng ngày 11/10/2026):

• GitHub App + callback
• Installation token một giờ
• Một sandbox cho mỗi session
• Agent loop là một service riêng
• Shell, editor, ask-user, git
• Stream event về một giao diện đơn giản

Anh gọi đây là kiến trúc full stack cộng architecture, và nói nó sẽ là tài liệu phỏng vấn rất tốt cho mọi người (trang cuối ghi "full-stack + this architecture = great interview material"). Trang "Where to go next" ngay trước đó gợi hai hướng: build một "fixer agent" theo dõi production và tự sửa (Sentry hay Datadog phát hiện bug, tìm PR gây ra nó, revert hoặc fix, deploy rồi verify); và thử thách viết một eval: tìm một task thật mà một frontier model không giải được trong khoảng 100 bước, rồi đóng gói nó bằng Harbor, framework đứng sau Terminal-Bench (bảng trắng trong video đăng ngày 11/10/2026).

uv tool install harbor

Anh nói thêm một điều cuối. Theo anh (video đăng ngày 11/10/2026), dạo gần đây có Grok Bot, có Dots, có Muse Agent; tất cả đều là cloud agent, nhưng là loại agent luôn sống (always alive), và kiến trúc của chúng hơi khác so với những gì video vừa bàn. Loại agent luôn sống này có thêm một loạt thứ khác, chẳng hạn nó có personality.

Anh hy vọng mọi thứ đã rõ và mọi người thích video. Anh cảm ơn mọi người, và hẹn gặp lại ở video sau.