Tools, Sandboxes, and the Plumbing of Agentic Development

1. Vấn đề: bạn đang là người điều phối toàn thời gian

Oleg mở đầu từ chỗ hầu hết chúng ta đang đứng. Bạn giao cho agent vài việc, và agent làm thay bạn được: bạn cho phép nó chạy lệnh, chạy test, chạy native code trên máy bạn, làm đủ thứ tốt. Hệ thống vì thế tự chủ hơn một chút. Nhưng kết quả là chính bạn trở thành người điều phối (coordinator), và rất thường xuyên như vậy.

Anh mô tả một ngày điển hình: bạn bảo một agent implement thay đổi, nó làm xong, bạn phải review, nhìn lại, rồi chuyển kết quả sang chỗ khác để điều phối tiếp, hoặc để review, hoặc bạn push code lên GitHub rồi nhờ cloud agent review thay đổi. Đâu đó giữa chừng, các quyết định sản phẩm rất quan trọng phải xen vào, ở những chỗ agent không tự giải được sự mơ hồ trong yêu cầu của bạn. Thế là bạn làm cả hai việc: bạn làm việc toàn thời gian, cố giữ toàn bộ context trong đầu, và cùng lúc điều phối nhiều phần của một hệ agentic trong khi agent đang chạy.

Theo Oleg, muốn hệ này năng suất hơn thì chỉ có một cách: gỡ bạn ra khỏi càng nhiều chỗ trong các agentic loop càng tốt.

Vì vậy trong buổi này anh sẽ thử dựng một "coding factory" nhỏ từ các primitive có sẵn ngay bây giờ. Trong đó dĩ nhiên có Docker Sandboxes, vì theo ý kiến cá nhân anh, đó là isolation primitive hợp lý nhất hiện nay cho agent chạy local. Anh cũng dùng vài công nghệ và project open source mà anh thấy hữu ích. Anh nói rõ: đây không phải là sự chứng thực (endorsement) của Docker, quan điểm chính thức của công ty có thể khác. Đây chỉ là setup anh thấy rất hữu ích, và anh đã chạy nó ít nhất một tháng.

Mục tiêu trong 27 phút còn lại: đưa người nghe từ chỗ chạy một agent trên máy sang chạy một hệ nhiều agent, tự chủ nhất có thể, thành một coding factory nhỏ ngay trên máy mình. Có nhiều cách làm, nhưng hình dạng anh muốn là: thay vì bạn tự viết prompt cho agent, task chảy vào từ một hệ thống nào đó, rồi trong coding factory các agent khác nhau làm phần việc của mình.

2. Coding factory muốn đạt tới đâu, và bài toán mẫu

Trong factory, agent phải chạy được ứng dụng của bạn, sửa ứng dụng, và tự kiểm xem thay đổi có hợp lý không, test có qua không, tự chạy test. Tức là vừa làm developer (chỉ việc sửa code), vừa có thể review, nhìn thay đổi một cách phê phán và nói "cái này sai rồi", mà không cần bạn đứng ra điều phối.

Khi agent có câu hỏi, khi thật sự có chỗ mơ hồ nó không tự giải được, thì nó nên chờ người đưa input. Còn lại, nó cứ đi tiếp và tạo ra kết quả. Kết quả đó phải là một dạng artifact bạn cầm lên và làm tiếp được.

Oleg nhấn mạnh: đây không phải chuyện xây những "dark factory" thần kỳ tự làm mọi thứ. Đây là chuyện chuyển giao phần lớn công việc điều phối mà ngày nào bạn cũng đang làm bằng tay, và chỉ để bạn ở lại những chỗ mà chuyên môn của bạn, tư duy hệ thống, thiết kế và sản phẩm của bạn, thật sự có ích cho hệ.

Bài toán mẫu: mở lại một incident đã resolve

Ứng dụng mẫu là một app Node.js rất đơn giản, một dashboard kiểu incident review. Việc cần làm là một thay đổi có ý nghĩa: khi một incident đã được đánh dấu resolved, người dùng muốn reopen được nó. Developer nào cũng từng gặp: có sự cố, bạn resolve, rồi hoá ra vẫn chưa chạy, phải mở lại.

Nghe thì đơn giản, nhưng nó đi qua mọi tầng của ứng dụng: phải đổi UI, phải đổi API, phải kiểm rằng trạng thái thật sự đã xuống tới database cần tới. Nên đây là một thay đổi phức tạp, không phải thứ đơn giản nhất. Họ sẽ chạy agent để làm việc này, và chạy agent trong Docker Sandbox.

Docker Sandboxes là một primitive mới của Docker để chứa và cô lập AI agent (trang sản phẩm Docker Sandboxes).

3. Docker Sandboxes và chiếc laptop là kho bí mật

Docker có nhiều kinh nghiệm xây container, cô lập và đóng gói ứng dụng, nên dĩ nhiên họ muốn làm một thứ tương tự cho agent, và Oleg nghĩ họ làm khá tốt. Docker Sandbox là một binary riêng bạn cài vào máy, tên là sbx. Bạn chạy coding agent bên trong nó với cảm giác sử dụng (ergonomics) giống như trước đây dùng container. Ví dụ gõ sbx run claude là Claude Code chạy bên trong một microVM, bọc quanh bởi một networking proxy. Nhờ vậy bạn kiểm soát hoàn toàn: file system, network, và credentials bạn muốn chia cho agent (tài liệu CLI: sbx reference).

Anh giải thích vì sao chạy agent local theo kiểu này là hợp lý: "your laptop is the treasure trove of secrets", laptop của bạn là một kho báu toàn bí mật, dù bạn có tin hay không.

Anh hỏi khán giả: bao nhiêu người chạy agent trên laptop? Bao nhiêu người chạy ở chế độ YOLO (bỏ qua mọi hỏi quyền)? Anh giục: "Come on, be honest", anh không thấy mặt ai nên cũng không mách sếp được. Ai cũng muốn làm vậy, vì không ai muốn làm "con khỉ bấm approve, approve, approve". Mà bạn cũng chẳng đọc mấy cái prompt xin quyền đó, vì có quá nhiều. Nên xin hãy chạy trong môi trường cô lập.

Anh đề nghị một thí nghiệm: lần tới, trước khi cho agent làm việc hữu ích, hãy bảo nó đi tìm mọi bí mật nó với tới được. Bảo nó lục SSH key, cloud key, password, và bash history để tìm những API token bạn từng dán vào history ba năm trước rồi quên. Rồi nhìn kết quả và sợ đi: bạn chỉ cách việc tất cả những thứ đó lên Internet đúng một lần prompt injection, tức là chỉ cách việc thành một tin tức bạn không hề muốn đúng một lần prompt injection. Oleg nói: nếu không nhớ gì khác từ buổi này, hãy sợ một chút về chuyện đó.

Sandbox triệt tiêu hẳn rủi ro này. Agent chạy trong sandbox: có thể là Claude trong sandbox, hoặc Codex trong sandbox. Nhưng như vậy vẫn chưa đưa ta tới gần hệ thống muốn xây, vì ta vẫn phải tự prompt agent, và trong đó mới chỉ có một agent.

4. Bên trong sandbox: vòng lặp Observe, Decide, Act

Đây là thứ họ sẽ dựng trong sandbox. Có một agent. Agent chạy được container bên trong sandbox, vì nó phải làm developer: nó chạy Docker container native bên trong microVM, với một Docker daemon cô lập riêng, điều Oleg thấy rất hay. Thư mục project trên máy được map vào theo kiểu hai chiều (bi-directional), nhưng agent không có quyền vào phần còn lại của máy.

Bên trong đó, agent nhận task và bắt đầu vòng lặp: implement thay đổi (Act), quan sát kết quả của thay đổi (Observe), rồi phải quyết định (Decide). Đây là vòng lặp phát triển bình thường. Chỗ quan trọng chính là khối Decide: ở đó agent phải nói được một trong ba điều:

• "OK, việc của tôi xong rồi";
• "Tôi cần thêm thông tin từ người" (nhánh Ask);
• "Tôi cần chuyển vai": thôi làm developer implement, đổi sang vai reviewer hoặc QA để xét lại các thay đổi vừa làm.

Với bài toán mẫu, có sẵn một chỗ mơ hồ thật: khi reopen incident, có giữ lịch sử hay không? Có muốn thấy nó từng được resolve hay không? Nên agent buộc phải hỏi người một điều, và họ sẽ thử thấy chuyện đó trong demo.

5. Ba vai trò, ba mindset

Oleg nói vai trò của bạn khi làm developer thật ra chỉ gồm ba việc: nhận task, implement thay đổi, và kiểm tra thay đổi. Hệ thống của bạn cũng phải làm đúng ba việc đó.

Và mỗi việc cần một mindset hơi khác nhau:

• Khi nhận task và nghĩ xem thật sự cần implement gì, bạn cần product mindset.
• Khi implement, bạn cần developer mindset, phải hiểu sâu các chi tiết của công nghệ. Ví dụ system prompt có thể ghi: "Bạn là chuyên gia Node.js, đừng dùng những thư viện kiểu left-pad, tự viết lấy."
• Khi kiểm tra, bạn cần một mindset thứ ba (QA, reviewer).

Vì vậy khó có chuyện một agent duy nhất trong coding factory làm cả ba việc cùng lúc mà làm tốt.

6. Herdr, "tmux cho agent", và vì sao agent giữ goal phải nằm trong sandbox

Vậy cần nhiều agent, và cần orchestration cho các agent đó. Tất cả vẫn có thể chạy trong một sandbox, trong cùng một ranh giới cô lập, vì cô lập các agent rồi để chúng làm việc cùng nhau là hợp lý.

Để orchestration, Oleg dùng Herdr (herdr.dev, mã nguồn GitHub), thứ giống như tmux cho agent, một agent multiplexer. Giống như bạn mở nhiều tab trong terminal, Herdr mở nhiều agent chạy thành các process, rồi quản lý vòng đời (lifecycle) của chúng, theo dõi trạng thái (status) của chúng, và quản lý giao tiếp giữa các agent (cross-agent communication).

Có những project khác làm việc tương tự, nhưng Herdr là thứ anh thích: open source, viết bằng Rust nên nhanh, gọn, nhẹ, và có nhiều tính năng hay như kết nối từ xa (remote connection). Bạn hoàn toàn có thể dùng thứ khác. Ngay Docker cũng có Docker Agent, cho phép chạy một team agent mô tả bằng một file YAML duy nhất (Docker Agent docs, repo docker/docker-agent).

Anh chọn Herdr cho setup này vì nó hợp hơn với subscription của các agent. Anh hỏi: bao nhiêu người chạy bằng subscription? Phần còn lại dùng API key. Anh đùa: "Không nhiều người giàu ở đây, tôi đoán vậy." Nếu bạn chạy bằng subscription thì hệ thống cũng phải hỗ trợ việc đó, và hiện tại làm với Herdr dễ hơn một chút, nên anh đưa nó vào ví dụ.

Vậy Herdr là orchestrator trong sandbox. Bên trong microVM đó, cần đặt Herdr và hướng dẫn nó quản lý team agent, mỗi agent một vai. Sẽ có một agent làm coordinator trong sandbox. Nó nhận goal, tức là task cần làm.

Điểm Oleg nói là "very, very important": agent nhận goal (thường là hệ /goal có trong mọi coding agent) không được nằm ngoài sandbox. Bạn có thể nghĩ: developer, đứa thật sự sửa code và cài đặt đồ, đã ở trong sandbox rồi thì coordinator ở ngoài cũng được. Sai. Chính goal là thứ làm agent cực kỳ bền bỉ và sáng tạo trong việc tìm đường vượt qua mọi chướng ngại bạn dựng lên. Agent giữ goal mà ở ngoài sandbox thì nó sẽ tìm cách vượt rào.

7. Mỗi vai một model, và bước sang kits

Vậy agent có goal phải nằm trong sandbox, rồi nó được tự spawn thêm agent khi cần. Cần developer thì nó dựng một developer và giao feature; Herdr lo phần giao tiếp giữa chúng. Đó là điều ta muốn trong coding factory: các agent khác nhau chạy các vai khác nhau, vì như vậy mỗi agent có context riêng.

Và vì mỗi vai là một agent riêng, bạn có thể cho chúng dùng model khác nhau. Oleg nói điều này rất, rất quan trọng khi implement coding factory: không model nào nên review code do chính model đó viết. Hai lần chạy của cùng một model sẽ trùng nhau ở những pattern mà nó được train, và reviewer sẽ nói "tuyệt vời", vì nếu là nó thì nó cũng viết y như vậy, do được train giống hệt. Nên hãy để một model khác review thứ model kia viết.

Cụ thể: coordinator dùng Pi làm harness (pi.dev, coding agent tối giản của Mario Zechner) chạy với Gemini Flash. Theo kinh nghiệm của anh, Gemini Flash không phải model code toàn diện nhất, nhưng rất giỏi về chữ, giao tiếp rất bình thường, dễ hiểu, và rất, rất nhanh, nên anh thích dùng cho vai điều phối. Developer là model Claude chạy trong Claude Code bên trong instance sbx. Reviewer là Codex.

Nếu bạn không có subscription hoặc API key cho cả ba, cứ cắm thứ bạn có. Có Grok thì cho Grok làm reviewer, kiểu vậy. Hoặc dùng Pi làm harness cho cả ba vai, chỉ đổi model và vai trò.

Đó là thứ họ sẽ xây. Nhưng câu hỏi là: làm sao nhét tất cả vào? Rất nhiều công nghệ: cần Herdr, cần Pi, cần Claude Code, cần Codex. Sandbox là một microVM, mặc định trống trơn. Câu trả lời là dùng những primitive được thiết kế để sandbox lặp lại được và dùng được: đó là kits. Kits là lớp cấu hình (configuration layer) cho sandbox, và kit là một "sinh vật" thú vị vì nó định nghĩa điều gì sẽ xảy ra bên trong sandbox.

8. Kit là gì: plugin cho sandbox, trong và ngoài

Hãy nghĩ kit như một hệ plugin cho sbx. Nó là một file cấu hình, có thể hình dung như danh sách các lệnh cần chạy. Các lệnh đó có thể là cài phần mềm agent cần dùng, cài chính các agent, hoặc cung cấp tool bên trong sandbox (tài liệu: sbx kit).

Ví dụ: bạn muốn một sandbox mà agent làm việc trơn tru với Google Cloud. Bên trong, bạn gần như chắc chắn cần CLI gcloud, và có thể cần Python hoặc Node.js, tuỳ thứ bạn viết. Những thứ đó phải có trong sandbox. Còn bên ngoài sandbox, bạn cần cấu hình: đảm bảo instance sbx này được phép gọi tới các hostname của Google Cloud, tức là cấu hình network. Chưa hết, lý tưởng là cấu hình luôn credential injection: credential Google Cloud trên host được chèn vào traffic đi ra từ sandbox. Như vậy bạn không phải đưa password tài khoản hay API key vào sandbox, nơi chúng có thể bị lộ nếu agent dính prompt injection.

Tóm lại, kit cho phép bạn chỉ định cả điều xảy ra trong sandbox lẫn cấu hình ngoài sandbox. Ở giai đoạn hiện tại nó trông như sau: một file YAML "khổng lồ", nhưng anh nói cũng không tệ lắm. Đó là spec cho kit dùng trong setup dựa trên Herdr. Nó cài mọi tool cần thiết và cấu hình mọi thứ, thông qua vài primitive:

• Base image cho sandbox đã có sẵn Claude Code.
• Cấu hình các provider: Anthropic API key cho Claude; OpenAI, cả key lẫn OAuth; và cấu hình Google.
• Networking: cho phép đi tới tất cả các service đó, cộng APT, GitHub, v.v.
• Cài Codex lên trên. Claude có từ base image, Codex cài thêm, rồi cài Pi và mọi thứ còn lại lên trên nữa.

9. Kits xếp chồng bằng sbxenv, và skills

File đó khá dài nhưng không khó. Và điều hay của kits là chúng xếp chồng được. Bản chất kit chỉ là khả năng chỉ định các lệnh chạy ở một thời điểm nào đó trong vòng đời sandbox. Có nhiều cách tiếp cận, và Docker đang cải tiến để kit declarative hơn, bớt kiểu "npm install cái này, npm install cái kia"; anh hẹn sẽ nói thêm ở các buổi sau. Nhưng điều đó không đổi phần cốt lõi: kit cung cấp tool bên trong sandbox và cấu hình bên ngoài.

Ví dụ ở đây: một kit "Codex và mọi thứ", ở chỗ khác có kit cài Pi, kit cài Herdr. Chúng được xếp chồng lại bằng file sbxenv, một file YAML nói rõ muốn chạy sandbox nào, cấu hình ra sao (có mở port hay không), và muốn chồng những kit nào (Sandbox environment files, sbx env). Trong ví dụ, chồng gồm: kit nền multi-provider, kit cho Pi, kit cho Herdr, kit cho tiện ích đưa skills vào, v.v.

sbxenv là thứ làm hệ thống lặp lại được (repeatable). Nó là file YAML, bạn commit vào repo, và ai làm project đó cũng dựng lại được đúng setup. Chỉ có credentials là lấy từ máy của từng người: họ dùng API key hoặc subscription của chính họ, nhưng chạy cùng một setup. Nên nó vừa chia sẻ được, vừa lặp lại được, mà không cần chia quyền truy cập của bạn cho ai. Oleg gọi đó là một hệ rất đẹp.

Bạn cũng cần skills. Đó là một ví dụ riêng, và ở workshop đi kèm talk này họ nói kỹ vì sao cần skills ở đây. Nhưng bạn cần một cách để sandbox nhận skills theo kiểu lặp lại được. Trong ví dụ này anh thích dùng Agent Context Registry của người bạn Baruch Sadogursky (trang speaker của Baruch tại WeAreDevelopers; bài liên quan của anh về skills registry: Tessl blog; link chính chủ của riêng "Agent Context Registry": chưa tìm được nguồn). Baruch cũng có một session ở hội nghị; Oleg nhắn: gặp anh ấy thì gửi lời chào và hỏi anh ấy về skills.

10. Skills cho mọi sandbox, và thứ còn thiếu: phụ thuộc bên ngoài

Baruch sẽ có rất nhiều thông tin về chủ đề đó. Trong setup này có một kit cho Agent Context Registry, nên không chỉ vai trò của agent được đưa vào sandbox mà cả skills. Nếu bạn có một coding policy, hay một skill về cách review thay đổi, thì skill đó cũng được cung cấp cho mọi instance của sandbox.

Lý do: nhớ lại hình ban đầu. Task đi vào, rồi phải có thứ gì đó dựng các môi trường này ngay lúc cần (on the fly). Các môi trường đó phải lặp lại được, vì tất cả phải tuân cùng coding policy, cùng review skill, cùng mọi điều bạn muốn dặn. Nên mọi cấu hình đó phải đến từ bên ngoài. Bạn không thể làm một lần rồi quên, vì bạn cần nó rất nhiều lần.

Đến đây ta có một hệ: có task, khởi chạy task, thấy team làm việc và thấy kết quả. Tới lúc này bạn tưởng sẽ có demo. Nhưng chưa. Oleg hỏi hai lần: còn thiếu gì trong bức tranh?

Câu trả lời: các phụ thuộc bên ngoài (external dependencies). Khi agent làm việc trong môi trường cô lập, chúng không truy cập được gì cả. Điều đó tốt, vì không truy cập được thì không làm lộ được, và không đi lấy về những chỉ dẫn bạn không đưa. Nhưng cũng xấu, vì chúng không đi lấy thêm context được. Nếu task phụ thuộc thứ khác, thì cũng như bạn là developer, agent nên lục hệ thống quản lý task để tìm các task liên quan.

Task nằm ở hệ thống bên ngoài, mà ta không thể mở quyền không giới hạn. Nên họ dùng MCP (Model Context Protocol), đặt MCP server trên máy host, bên ngoài sandbox, và cho phép agent kết nối tới MCP đó theo từng cái một. Trong ví dụ, đó là một MCP mẫu đi vào backlog trên host để đọc task, và khi xong việc thì cập nhật task với ghi chú kiểu "xong rồi, đã làm cái này".

11. Điều không nên làm với MCP, và câu hỏi nào mới nên tới tay người

Dĩ nhiên bạn thay được MCP đó bằng bất kỳ MCP nào. Nhưng Oleg kể đã thấy người ta chạy MCP search web trên host để lách network policy: agent không được đi tới host lạ từ sandbox, nhưng lại gọi được MCP server, và MCP server đó thì đi tới bất cứ host nào từ máy bạn. "Don't do that, don't try that at home." Cấu hình MCP server là thứ project sandbox có hỗ trợ, và họ chạy MCP theo cách đúng.

Như vậy agent sẽ có hai loại câu hỏi: câu hỏi về quyền truy cập và câu hỏi về lựa chọn sản phẩm.

Câu hỏi về quyền truy cập nên là quyết định policy: network, MCP tool nào được và không được chạy, các quyết định hạ tầng. Những thứ đó không nên đến tay bạn. Agent không nên hỏi bạn "tôi vào website đó được không?", vì bạn không thể quyết đúng ngay trong khoảnh khắc đó; bạn thậm chí sẽ không đọc hết prompt. Còn lựa chọn sản phẩm, như nút màu gì, thì đó là thứ bạn muốn trả lời được.

Bắt đầu demo

Tới đây là demo. Oleg xem còn bao nhiêu thời gian, và nói "sau demo không còn slide nào, rất tốt". Anh mở hai tab. Một tab chạy trên host, có "cái thứ đầy màu" (màn hình bị lỗi màu; anh đùa: đó là vấn đề phần cứng, mà developer thì không xử lý vấn đề phần cứng). Tab đó là macOS host.

Trên host anh có hệ quản lý task tên Beans (github.com/hmans/beans), một task tracker dựa trên các file markdown. Nó là công cụ dòng lệnh, cài được, và rất hợp cho agent vì chỉ là file markdown nằm local. Dĩ nhiên chỗ này có thể thay bằng tích hợp với Jira, với Linear, hay gì cũng được, nhưng Beans đơn giản và dễ chịu. Trong Beans có task "reopen the resolved incident", viết theo kiểu product people có thể đã viết. Anh nhắc: có người nghĩ product people sẽ là nhóm đầu tiên bị AI thay thế.

12. Demo: task trong Beans, team agent chạy trong sandbox

Oleg không nghĩ vậy. Anh nghĩ ngược lại: developer sẽ phải tiếp nhận nhiều hơn tư duy sản phẩm (product-driven thinking).

Vào demo. Đây là máy host, task nằm trong Beans. Đây là sandbox: anh đang chạy trong sandbox đã được khởi tạo sẵn; anh đã cho nó vài lệnh để đọc task, và nó cũng đang chạy ứng dụng. Anh cho thấy mình đang ở trong sandbox: gõ ps thì thấy Postgres chạy bên trong sandbox; còn trên host, docker ps thậm chí không chạy Docker. Rõ ràng là một Docker daemon khác.

Anh gõ crew, lệnh tắt tới Herdr, rồi submit task. Việc đó kích hoạt coordinator, developer và reviewer/QA chạy theo vai. Anh xem bằng crew logs (ví dụ log của developer) để biết chuyện gì đang xảy ra. Nó làm một loạt việc, chạy, và cần hỏi anh vài câu. Anh thử crew watch (gõ nhầm thành "crew watc h" và nhận "Unknown command. Use crew help.", thấy trong ảnh). Có thể nó vẫn đang nghĩ.

Hệ thống trong sandbox đang chạy coordinator, coordinator chạy developer, chúng chuyền tin cho nhau, và làm việc trên hệ thống khi cần. Có thể thấy tiến độ. Vì nằm trong sandbox, có thể kết nối vào bằng SSH, và cũng có thể trả lời ngay tại đó, ví dụ "do position A" (chọn phương án A); lần này thao tác đó không chạy, "doesn't matter".

Không đủ thời gian chờ team implement xong, nhưng khi xong, chúng sẽ cập nhật Beans trên host qua MCP server. Bằng cách này bạn xây được một hệ mà các thành phần cắm vào tuỳ ý: đổi task tracker khác, đổi coding agent khác trong sandbox, đổi team orchestrator khác (không bắt buộc là Herdr), cắm skills theo cách khác. Nhưng bạn cần đủ các thành phần đó.

Ai muốn tìm hiểu sâu setup này thì cuối ngày, khoảng 4 giờ chiều, có workshop hai tiếng dựng lại hệ này từng mảnh (repo workshop: shelajev/wad-sbx-workshop, "Hands-on Docker Sandboxes workshop: from one agent to a software factory").

13. Kết: gỡ mình ra khỏi các vòng lặp bên trong

Có thể tới workshop đi kèm, hoặc xem các repo và tự dựng lại từ đúng các thành phần của session này. Setup chạy hoàn toàn local trên máy anh, chạy theo cách dự đoán được: dựng các agent khác nhau, chúng làm việc cùng nhau, và chỉ làm phiền anh đúng lúc cần quyết định của anh.

Đó là thứ họ muốn xây: factory chạy với ít can thiệp của người nhất có thể. Hãy gỡ mình ra khỏi các inner loop để chúng chạy nhanh, để cả hệ chạy nhanh hơn.

Nếu chỉ mang về một điều, Oleg đề nghị: nghĩ về những gì bạn làm trong ngày, và tìm một handoff bạn đang làm bằng tay mà có thể tự động hoá. Đó có thể là việc cung cấp context? Có thể là giới hạn quyền truy cập? Có thể là kiểm bằng chứng tự động rằng việc đã xong, ví dụ dùng các model khác nhau để đánh giá các phần việc khác nhau? Bạn cũng có thể tự xem workshop, nhưng hãy nghĩ xem bước tiếp theo của mình trong "agentic journey" là gì.

Và vì phần lớn lý do anh có mặt ở đây là Docker, anh mời mọi người xem Docker giúp cô lập và "chăn dắt" agent ở quy mô lớn thế nào, cả cho từng người trên laptop lẫn các gói cho doanh nghiệp để quản lý tập trung cho mọi developer.