Vụ hack OpenCode và cách tự vệ bằng agent loop

1. OpenCode bị hack, và distillation attack là gì

Trong video ngày 18/10/2026, David Ondrej mở đầu bằng một tin nóng: OpenCode vừa bị hack. Anh giới thiệu đây là một trong những công cụ AI coding phổ biến nhất hiện có (tính đến 10/2026), về cơ bản là một phiên bản open source của Claude Code, và theo anh vụ này là một trong những vụ rò rỉ lớn nhất năm nay. Anh nói rất có thể nhiều người đang xem video cũng bị ảnh hưởng.

Anh đọc lại bài đăng ngày 17/10/2026 của tài khoản chính thức OpenCode. Bài viết nói: đêm trước đó họ gặp một sự cố bảo mật liên quan tới một distillation attack quy mô lớn, ảnh hưởng tới 1,4% người dùng OpenCode Console. Con số 1,4% nghe có vẻ không nhiều, David nói, cho tới khi bạn nhận ra rằng có tới hàng triệu người đang dùng OpenCode.

Lời khuyên đầu tiên của anh rất đơn giản: nếu bạn là người dùng OpenCode, hãy kiểm tra email. Nếu bạn bị ảnh hưởng, bạn sẽ thấy thư thông báo. Nhưng phần đáng sợ, theo David trong video ngày 18/10/2026, là đây là một distillation attack. Theo anh, đây không phải một vụ rò rỉ ngẫu nhiên, cũng không phải một cá nhân đơn lẻ làm, mà là một distillation attack quy mô lớn.

Vậy distillation attack nghĩa là gì? Trong video ngày 18/10/2026, David giải thích đây là một thuật ngữ khá mới, được phổ biến chủ yếu bởi Anthropic, dù các lab khác cũng dùng. Nó có nghĩa là dùng một model cụ thể của người khác để train model của chính mình theo một cách bất hợp pháp, một cách vi phạm điều khoản dịch vụ (terms of service). Trên slide của anh ghi: "A relatively new term popularized by Anthropic" và "It means using other companies models to train your own models in an illegal way".

Cụ thể, bạn lấy một model lớn hơn, như Opus hay Fable, rồi distill nó vào một model nhỏ hơn, tức là lấy về một lượng lớn dữ liệu miễn phí. Theo David (video ngày 18/10/2026), đây là một trong những cách chính để tiếp cận token ở quy mô lớn từ một model thông minh hơn, dùng nó để build model của riêng mình, rồi bán lại với giá rẻ hơn.

Câu hỏi tiếp theo là: ai đứng sau vụ này? Trên slide của David (video ngày 18/10/2026) có hai chữ "Company? State?" (một công ty hay một nhà nước?). David nói anh sẽ quay lại câu hỏi đó ở phần sau, cùng một vài bằng chứng.

Anh nêu rõ những gì video sẽ làm. Thứ nhất, giải thích chuyện gì đã thực sự xảy ra với OpenCode; trên slide của anh (video ngày 18/10/2026) ghi rõ "it wasn't a normal hack" (đây không phải một vụ hack bình thường). Thứ hai, vì sao đây mới chỉ là phần nổi của tảng băng khi nói tới hacking bằng AI (AI-powered hacking), và nó có ý nghĩa gì với anh và với người xem. Lý do anh đưa ra: nếu OpenCode, một công ty AI tương đối lớn, có thể bị hack theo cách này, thì chắc chắn anh và bạn có hệ thống bảo mật kém hơn. Cuối video, anh sẽ cho xem bạn có thể làm gì để tự bảo vệ, và chính anh đang làm gì để bảo vệ bản thân và công ty của mình.

2. Sáng hôm sau: hoá đơn API tăng vọt, và mục tiêu mới là người dùng thường

Theo David Ondrej trong video ngày 18/10/2026, đây là những gì mọi người thức dậy và nhìn thấy (slide "People woke up to this..."): có người mất 200, 300 đô, có người mất 168 đô, một người mất tới 1.700 đô, tất cả chỉ trong một đêm (các con số người dùng chia sẻ trên X). Hoá đơn API credit của họ tăng vọt. Đây là token từ OpenAI và Anthropic: những API key do OpenAI và Anthropic cấp, mà người dùng gắn vào OpenCode theo kiểu "bring your own keys", tức tự mang key của mình vào công cụ.

Nhưng điều tệ nhất, theo David trong video ngày 18/10/2026, không phải là số tiền bị mất (trên slide ghi "But the worst part isn't the money that was lost"). Theo anh, điều tệ nhất là đây không phải một vụ hack ngẫu nhiên, mà là một cuộc tấn công có chủ đích, quy mô lớn, nhắm thẳng vào OpenCode, một lần nữa, một trong những startup AI lớn nhất, được hàng triệu người dùng.

Anh chuyển sang chủ đề synthetic data (dữ liệu tổng hợp). Trước đây, distillation attack chủ yếu nhắm vào Anthropic và OpenAI, các lab AI lớn. Vì sao? Vì họ có token, họ có những model tốt nhất (theo David, tính đến 10/2026). Điều đó hợp lý. Tuy nhiên, theo anh, vụ hack ngày 17/10/2026 nhắm vào OpenCode, và nó "mở ra cả một hộp sâu mới" (opens a whole new can of worms). Theo David, đây là distillation attack quy mô lớn đầu tiên nhắm vào người tiêu dùng, tức người bình thường, những người như anh và bạn (đánh giá của anh trong video ngày 18/10/2026).

Theo David, trước đây những người làm distillation, phần lớn thường là các lab Trung Quốc, nhắm vào OpenAI và Anthropic: họ tạo ra hàng nghìn tài khoản để distill token của Claude và token của GPT. Còn bây giờ họ nhắm vào những người như anh và bạn: đánh cắp chính API key của chúng ta và dùng những key đó để làm distillation (theo David Ondrej trong video ngày 18/10/2026).

3. Chuyện gì đã thực sự xảy ra

Trong video ngày 18/10/2026, David hứa sẽ chỉ ngay cách biết bạn có bị ảnh hưởng hay không, và câu trả lời nhanh là: nếu bạn dùng OpenCode, hãy kiểm tra email. Phần sau của video, anh sẽ giải thích cách tự bảo vệ trước những vụ hack dùng AI như thế này, vì theo anh bạn không thể làm việc đó theo cách truyền thống. Nếu có người đang dùng các model AI open source không bị giới hạn (unrestricted) để tấn công bạn, thì bạn cũng phải dùng AI để tự bảo vệ. Bạn không thể mong mình tự chống lại một hacker đang có 100 agent, chỉ bằng một mình bạn, hay bạn với một agent. Bạn cần nâng cấp khả năng phòng thủ, và anh sẽ cho xem anh đang làm gì để mọi người có thể chép lại.

Vậy chuyện gì đã thực sự xảy ra? Theo David Ondrej trong video ngày 18/10/2026, kẻ tấn công đã xâm nhập vào một hệ thống cũ (legacy system) mà OpenCode sắp tắt. Theo anh, OpenCode đang trong quá trình ngừng dùng hệ thống đó, và anh đoán chỉ vài ngày hay vài tuần nữa là họ không dùng tới nó. Nhưng chính hệ thống cũ đó đã bị xâm nhập.

Về danh tính kẻ tấn công, David nói trong video ngày 18/10/2026 rằng có một số bằng chứng cho thấy đó là người Trung Quốc, vì người ta có thể nhìn vào cách các key bị xâm phạm đã được dùng: rất nhiều trong số đó là các câu hỏi bằng tiếng Trung. Đây là nhận định của anh, dựa trên những gì người ta quan sát được từ cách dùng các key đó.

Theo David Ondrej trong video ngày 18/10/2026, kẻ tấn công lấy các API key mà người dùng đã liên kết, chủ yếu là của OpenAI, Anthropic và Google. Theo anh, đó là ba mục tiêu lớn, vì đó chính là thứ token người ta muốn. David đề nghị người xem thử nghĩ: nếu hôm nay bạn mở một lab mới, bạn muốn synthetic data từ đâu? Có lẽ là từ GPT-6 Astra và Sol, có lẽ từ Opus 5.5, mà theo anh chắc chắn là model tốt nhất lúc này (đánh giá của anh tính đến 18/10/2026), hoặc Fable 5.1, và có lẽ thêm một ít Gemini 4 Argon "cho thêm gia vị", để có sự đa dạng.

Theo bài đăng ngày 17/10/2026 của OpenCode, khoảng 1,4% người dùng bị ảnh hưởng. David nói thêm rằng kể cả nhân sự của OpenCode cũng bị tấn công: Dax viết trên X ngày 17/10/2026: "my personal accounts are being attacked now too, whole new world with ai powered hacking" (các tài khoản cá nhân của tôi giờ cũng đang bị tấn công, một thế giới hoàn toàn mới với hacking bằng AI).

Đây là một thế giới mới với AI-powered hacking, David nhấn mạnh trong video ngày 18/10/2026. Nếu bạn không coi chuyện này là nghiêm túc, sẽ đến lúc có thứ gì đó của bạn bị xâm phạm. Có thể bạn đang cài một package bị nhiễm độc trong một project nào đó. Có thể ai đó nhắm thẳng vào bạn. Không ai biết được.

Anh hy vọng không có gì xảy ra, nhưng anh nói không thể hứa với bạn điều đó, vì như thế là nói dối. Bạn sẽ là đối tượng của AI-powered hacking. Sẽ có người dùng các model AI không bị giới hạn, hoặc đơn giản là bất kỳ model AI nào chạy trong một agent harness, để tấn công bạn hoặc công ty của bạn. Nếu bạn không chuẩn bị, bạn sẽ phải học bài học này theo cách khó khăn.

4. Xem trước: các agent loop tự chạy để giữ an toàn

Để người xem hình dung trước cách anh xử lý chuyện này, David cho xem phần thiết lập của mình: nhiều agent loop chạy tự động, hoàn toàn tự động, bằng các frontier model, mỗi loop kiểm tra một phần khác nhau trong codebase của anh. Mọi demo trong video chạy trong Cloudroom, công cụ chạy agent trên cloud mà David đang xây.

Các loop này chạy hoàn toàn trên cloud. Một loop kiểm tra sức khoẻ hệ thống (system health) mỗi 15 phút. Một loop kiểm tra tất cả các dependency khác nhau trong codebase mỗi giờ. Một loop làm một đợt rà soát bảo mật diện rộng (broad security sweep) mỗi hai giờ. Sau đó anh có thể xem lại kết quả của chúng.

Một số loop sẽ chờ feedback của anh khi chúng tìm thấy vấn đề. Một số khác chạy hoàn toàn tự động, và có một cách để xem lại chúng theo một dòng thời gian rõ ràng.

5. Vì sao OpenCode bị nhắm: các lab lớn đã đánh trả

Lý do OpenCode trở thành mục tiêu, theo David trong video ngày 18/10/2026, là vì các lab lớn như Anthropic và OpenAI đã đánh trả: họ làm hệ thống bảo mật của chính mình mạnh lên rất nhiều. Anh kể rằng đầu năm nay Anthropic đã phát hiện DeepSeek, Moonshot cùng một lab Trung Quốc thứ ba dùng tổng cộng hơn 24.000 tài khoản giả để distill Claude. Bài viết "Detecting and preventing distillation attacks" của Anthropic, đăng ngày 23/02/2026, ghi các lab này đã tạo ra hơn 16 triệu lượt trao đổi với Claude qua khoảng 24.000 tài khoản gian lận.

Theo David, giờ đây các lab bảo vệ mình rất kỹ. Về cơ bản, họ dùng một thứ gọi là behavioral fingerprinting (nhận diện qua "dấu vân tay" hành vi) để phát hiện những kẻ đang distill và cấm họ. Họ thậm chí còn kéo cả "súng lớn" vào: các cơ quan của chính phủ Mỹ, NSA, CISA và FBI. Theo David (video ngày 18/10/2026), các cơ quan này nói rằng các lab có trụ sở ở Trung Quốc đã lấy đi hàng tỷ token. Trên slide của David có ảnh chụp một khuyến cáo an ninh mạng (Cybersecurity Advisory) tựa đề "China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies", ghi ngày phát hành 08/09/2026.

6. Bài viết của Anthropic và biểu đồ log scale

David mở bài viết thứ hai của Anthropic, đăng cách đó khoảng năm ngày: "Strengthening our defenses against distillation attacks" (ngày 12/10/2026), nói về cách họ đang củng cố phòng thủ trước distillation attack. Anh sẽ để link bên dưới video và khen đây là một bài đọc rất chắc. Nhưng thứ anh muốn cho xem cụ thể là một biểu đồ.

Biểu đồ trong bài của Anthropic ngày 12/10/2026 cho thấy các safeguard mới, tức các lớp bảo vệ mới. Khi Anthropic bật chúng lên, số lần distill thành công giảm mạnh. Trên trục Y là bội số so với những ngày yên tĩnh nhất. Ngày yên tĩnh nhất là mốc so sánh; David đoán là bài viết ghi ngày 19/9. Trên chú thích của biểu đồ thì ngày 0 (19/9) là ngày đầu tiên safeguard được bật hoàn toàn, còn ngày yên tĩnh nhất đo được là ngày +7 (26/9).

Theo biểu đồ trong bài ngày 12/10/2026, mức trung bình trước đó là 8.800 lần. Như David nói, đây không phải chuyện vài token; đó là gần 9.000 lần, và đây còn là thang logarit. Ngày tệ nhất là 56.000 lần, tức lượng token bị lấy đi trong ngày đó gấp 56.000 lần ngày yên tĩnh nhất. Anh sửa lại cách nói: không phải "bị đánh cắp" mà là "bị distill", nhưng về cơ bản thì cũng là bị đánh cắp.

Sau khi Anthropic deploy các safeguard mới nhất của họ, mức trung bình giảm từ 8.800 xuống chỉ còn 135 lần (số liệu trong bài của Anthropic ngày 12/10/2026). Nghĩa là nó chưa bị chặn hẳn. Đây giống một trò mèo vờn chuột, và sẽ luôn có những cách mới để distill model.

7. Model nào rồi cũng bị distill, và chuyện DeepSeek

Trong video ngày 18/10/2026, David nói thêm về một cách distill khác mà anh cho là một ý tưởng khá độc đáo: với đủ thời gian, model nào cũng sẽ bị distill. Hãy nghĩ thử: người ta đang dùng Opus 5.5 và GPT-6 Astra để viết bài, viết email, viết bài đăng mạng xã hội. Tất cả những thứ đó sẽ bị thu thập (scrape) vào thế hệ model tiếp theo.

Tất nhiên đây là một dạng distillation chậm hơn, vì bạn không thể kiểm soát hoàn toàn người ta hỏi gì, nhưng nó vẫn là một dạng distillation: chỉ đơn giản là người dùng các model mới này. Kết quả là trong một năm nữa, internet sẽ đầy token của Opus 5.5, và bất kỳ ai train model một năm sau sẽ không tránh khỏi việc có rất nhiều dữ liệu của Opus 5.5 trong đó. Theo David (video ngày 18/10/2026), mọi thứ rồi sẽ bị distill. Chuyện đang bàn ở đây là nhắm mục tiêu và ngăn chặn kiểu distillation có chủ đích, tức là đi săn một model cụ thể.

Ví dụ, mọi người đang trêu DeepSeek. DeepSeek vừa phát hành một model mới. Nhân tiện, David đùa rằng ai làm marketing ở DeepSeek thì làm rất tệ: sao không gọi đơn giản là DeepSeek V4.2, mà lại đặt tên là "4.1 Flash 1017"? Theo anh cái tên đó thật tệ, chỉ làm mọi người rối.

Dù vậy, ý chính là đây là một model rất tốt. Đó là một model nhỏ, open source, hay ít nhất là open weights, và theo David thì khá sát frontier so với nhiều model khác. Nhưng nếu bạn chat với nó, như có người đã thử, thì khoảng 26 trên 30 lần nó bắt đầu trả lời bằng câu "I'm ChatGPT, an assistant developed by OpenAI" (tôi là ChatGPT, trợ lý do OpenAI phát triển). Rồi người ta đào sâu hơn và phát hiện "dấu vân tay" (fingerprint) của nó bị nhận diện đúng là GPT-6 Astra. Một bài đăng anh cho xem viết, được dịch từ tiếng Trung: fingerprint của ds-4.1-flash-1017 được nhận diện là 6-astra.

Nói cách khác, theo David, chuyện xảy ra ở đây là DeepSeek vừa distill GPT-6 Astra, cộng với rất nhiều cải tiến khác, tất nhiên. Anh nói phải công bằng: DeepSeek đã làm những việc rất lớn trong việc open source nghiên cứu của họ và mang lại nhiều giá trị cho cộng đồng AI. Nhưng họ cũng đang distill. Không phải chỉ một trong hai. Họ đã distill Astra rất nhiều ở đây. Nên về cơ bản, nếu bạn muốn có phần lớn hiệu năng của Astra với giá rẻ hơn rất, rất nhiều, thì model này dành cho bạn. Đây là nhận định của David trong video ngày 18/10/2026, dựa trên các bài kiểm tra người dùng đăng trên X.

8. Chúng ta là mục tiêu, nên phải dùng AI để tự vệ

Theo David trong video ngày 18/10/2026, tất cả những điều đó gợi ý ai có thể đứng sau vụ OpenCode: anh đoán nhiều khả năng là một lab Trung Quốc, có khi là nhiều lab Trung Quốc cùng nhau, không ai biết. Lý do chính là những bài như bài của Anthropic, nơi họ đã củng cố phòng thủ. Giờ thì tấn công trực tiếp Anthropic hay OpenAI là quá khó, nên họ tìm những mục tiêu dễ hơn, như OpenCode, một công ty tương đối nhỏ so với Anthropic và OpenAI. Tất nhiên OpenCode vẫn là một công ty lớn hơn một startup mới. Đây là suy luận của anh, không phải một kết luận chính thức về thủ phạm.

Điểm David muốn nói, vẫn trong video ngày 18/10/2026, là xu hướng: mục tiêu đang dịch xuống dưới. Theo anh, với kẻ tấn công, việc hack một loạt người tiêu dùng, lấy API key của những người như anh và bạn, rồi đốt các key đó trước khi chúng ta kịp biết, và dùng nó để distill, là dễ hơn. Kiểu distill này cũng khó hơn nhiều để Anthropic và OpenAI phát hiện, vì một lần nữa, lưu lượng distill đến từ người bình thường, từ người dùng thông thường.

Đó chính là phần đáng sợ của tất cả chuyện này: tất cả chúng ta đều là mục tiêu. Chúng ta, những người bình thường, những người dùng AI thông thường, giờ là mục tiêu của, như David nói, anh thậm chí dám nói là của cả các nhà nước (nation states). Có thể đó chỉ là một lab hay vài lab AI, nhưng theo anh (video ngày 18/10/2026) tất cả họ đều được các nhà nước này cấp vốn và hỗ trợ hoàn toàn, và đây là công nghệ quan trọng nhất mọi thời đại. Và giờ chúng ta là mục tiêu.

Vậy làm gì? Theo David, bạn cần dùng AI để tự bảo vệ, và anh sẽ cho xem chính xác anh đang làm gì. Trong công cụ của mình, anh có nhiều agentic loop, về cơ bản đều nhắm tới việc làm cho hệ thống của chính anh vững hơn.

Điều bạn cần làm là dùng các frontier model như Opus 5.5, GPT-6.1 Sol, GPT-6 Astra hay Fable 5.1, hoặc kết hợp vài model, để củng cố phòng thủ của chính mình. Bạn cần chạy chúng trên project của mình, trên codebase của mình, và làm theo một cách có chiến lược, tức là tự động hoá. Bạn không chạy một lần rồi coi như xong. Theo David (video ngày 18/10/2026), các vụ rò rỉ xảy ra liên tục, và số lượng của chúng đang tăng tốc.

Để minh hoạ, ngay trong lúc nói anh gõ một yêu cầu cho agent: tìm dữ liệu của a16z về việc số vụ tấn công mạng đang tăng thế nào và cho anh xem biểu đồ. Ý anh muốn nói là chuyện này sẽ chỉ xảy ra ngày càng nhiều. Nếu bạn nghĩ chạy một lần là ổn, thì không ổn đâu; theo anh như vậy là hoàn toàn ảo tưởng. Và đó là lý do bạn cần có những agentic loop nhằm bảo vệ chính mình.

9. Security sweep, dependency sweep và hai biểu đồ của a16z

David có nhiều loop chạy trên cloud và cũng có nhiều loop chạy trên MacBook của anh. Và bạn thật sự cần nhắm chúng một cách có chiến lược. Anh có một security sweep (rà soát bảo mật) tổng quát. Rồi một dependency sweep (rà soát dependency). Theo anh (video ngày 18/10/2026), loop thứ hai rất quan trọng, vì phần lớn các vụ rò rỉ đến từ một dependency.

Theo David (video ngày 18/10/2026), vụ OpenCode thì khác: đó là hệ thống của chính họ, lỗi của chính họ. Nhưng nhiều vụ khác diễn ra thế này: bạn đang dùng một package, một thư viện nào đó, và nó bị xâm phạm. Kẻ tấn công ship ra một phiên bản bị nhiễm độc, hệ thống của bạn cập nhật lên phiên bản đó, trong khi code của bạn không có vấn đề gì. Bạn chỉ đơn giản là build trên một dependency nhất định, và dependency đó bị xâm phạm.

Anh giải thích thêm rằng loop mới anh sắp cho xem thì dành riêng cho web app, và cách bạn chia loop sẽ tuỳ vào cách bạn kiến trúc codebase của mình, ví dụ bạn có tách frontend và backend hay không. Đúng lúc đó agent trả về kết quả tìm dữ liệu a16z, gồm hai biểu đồ.

Biểu đồ thứ nhất cho thấy rủi ro an ninh mạng đang tăng theo hình parabol. Bắt đầu từ khoảng quý 1, quý 2 năm nay, số lỗ hổng mức high và cả mức critical tăng vọt. Theo David, điều đó thật điên rồ, và nó sẽ chỉ tiếp tục. AI agent chỉ ngày càng giỏi hơn, harness chỉ ngày càng tốt hơn, các model không bị giới hạn cũng chỉ ngày càng mạnh hơn. Chuyện này sẽ không dừng lại.

Theo anh, ai cũng sẽ phải trở thành một chuyên gia an ninh mạng, ít nhất là ở mức kiến thức cơ bản mà một chuyên gia an ninh mạng cần có vài năm trước. Tất cả chúng ta sẽ phải đạt mức đó, hoặc ít nhất phải làm việc cùng agent để đạt mức đó, vì như anh nói, đây mới chỉ là những ngày đầu.

Biểu đồ thứ hai: thời gian từ lúc công bố tới lúc bị khai thác gần như bằng không, gần 90% số lần. Đây là tỷ lệ phần trăm các CVE bị khai thác trước hoặc ngay vào ngày công bố (disclosure). Nghĩa là bạn không còn thời gian. Trước đây bạn còn có thời gian để bảo vệ mình và hệ thống của mình. Bây giờ thì không (theo David trong video ngày 18/10/2026, dựa trên số liệu 2026 của hai biểu đồ). Kẻ tấn công dùng LLM để làm việc đó ngay trong ngày, trong vài giờ, có khi chỉ trong vài phút. Vì vậy điều bạn cần làm là tự bảo vệ, và David chuyển sang cho xem một loop mới anh vừa tạo.

10. Một loop web test tạo bằng một prompt

Theo David, tạo các agentic loop chạy hoàn toàn trên cloud là việc rất dễ trong công cụ của anh. Nên kể cả khi máy tính của bạn đang gập lại, loop vẫn chạy và vẫn đang phòng thủ hệ thống của bạn: nó đi tìm lỗ hổng, nó pen test (kiểm thử xâm nhập) chính phần mềm của bạn.

Anh cho xem loop mới: anh tạo nó bằng đúng một prompt, nói bằng tiếng Anh thông thường, và thế là có loop. Lần chạy đó đã làm một đợt web test, không tìm thấy gì, và tự archive. Theo anh đó chính là điều bạn muốn khi không có gì được tìm thấy.

Cách nghĩ về chuyện này, theo David, là nó tương đương với việc thuê một hacker mũ trắng (white hat hacker) chuyên nghiệp, một penetration tester, để phân tích toàn bộ codebase của bạn; trong trường hợp này là riêng phần web app. Người đó quay lại và nói: "Nghe này, tôi đã làm một đợt audit đầy đủ và không tìm thấy gì", và đó chính xác là điều bạn muốn. Trong trường hợp này kết quả rất tốt. Có những lần nó tìm ra một lỗ hổng, hoặc một chỗ có thể làm chắc hơn. Và đó chính là toàn bộ ý nghĩa của nó.

Bạn chạy nó tự động trên cloud. Anh chỉ vào màn hình: đây là một cloud thread, nên máy tính của anh có hết pin hay đang tắt cũng không quan trọng. Loop dùng model mà theo David là tốt nhất có thể (tính đến 10/2026): Opus 5.5 bản 1 million (context 1 triệu token) với mức reasoning effort tối đa. Theo David, hạn mức trong gói Claude Code rộng tới mức bạn có thể chạy các loop này liên tục (theo anh trong video ngày 18/10/2026).

Điều anh đang cố làm, theo lời anh, là build tương lai của agentic engineering, một tương lai không chỉ là bạn gửi một prompt. Điều nhiều người sẽ làm ở đây là chọn project rồi gõ đại loại: phân tích project của tôi, đảm bảo mọi thứ về bảo mật đều ổn. Anh nói tất nhiên như thế cũng được, còn hơn không, nhưng bạn sẽ không tự bảo vệ được bằng cách đó, bạn sẽ bị "huỷ diệt". Cách đó có lẽ ổn vào sáu tháng hay một năm trước. Còn giờ bạn cần tự động hoá nó, và đó là lúc agentic loop và software factory vào cuộc.

Việc bạn cần tìm ra là: trong hệ thống của bạn, đâu là điểm yếu? Có thể là authentication, có thể là API, có thể frontend của bạn chứa quá nhiều logic, hoặc có thể là backend với rất nhiều dependency. Tuỳ vào thứ bạn đang build. Và thật ra bạn có thể hỏi thẳng agent bằng một prompt.

11. Tìm điểm yếu của chính mình, và loop phải chạy không cần bạn

David gõ prompt sau vào một thread mới (trên màn hình, thread chạy với Opus 5.5 1M, mức High, ở chế độ Local) và mời người xem cứ việc "lấy trộm" prompt này để chạy trên project của mình:

In this project, what do you think are the biggest weaknesses in terms of cybersecurity and in terms of what somebody could exploit? Give me the top five

Sau đó, bạn cần tạo những agentic loop riêng cho năm điểm yếu đó, những loop chạy mà không cần bạn. David nhắc lại lần nữa: bất cứ việc gì bạn làm về an ninh mạng cũng phải chạy mà không cần bạn. Vì nếu bạn phải tự khởi động nó mỗi lần có chuyện, thì sẽ quá muộn. Sẽ quá muộn, và lúc đó bạn đã bị xâm phạm rồi. Vì vậy bạn cần tạo các agentic loop.

Anh mở loop kiểm tra sức khoẻ hệ thống. Loop này không phải về an ninh mạng, nhưng cứ 15 phút nó lại kiểm tra system health. Anh nhắn thêm vào thread của loop đó, nói rõ là đang quay video nên đừng làm lộ thông tin riêng tư, rồi bảo nó giải thích bằng tiếng Anh đơn giản xem hệ thống có vấn đề gì không, hay có mối lo nào về an ninh mạng trong 24 giờ qua, phân tích lại và trả lời ngắn. Tin nhắn hiện trên màn hình:

I'm recording videos so don't leak any private info but basically in plain English explain to me if there's any issues with the system or if there's like some cybersecurity concerns from the last 24 hours. Analyze it again and answer it short.

Theo David, bạn có thể gửi những tin như vậy bất cứ lúc nào. Loop này tự động cập nhật cho anh mỗi 15 phút, và anh có một bản log về những gì đã xảy ra trong suốt ngày hôm qua. Đó là phần sức khoẻ chung của hệ thống, để không có gì sập.

Anh nói phần này thật ra không liên quan nhiều tới bảo mật, nhưng mọi người cứ lấy cảm hứng từ nó. Bạn nên kiểm tra sức khoẻ của database, tốc độ load của frontend; tất cả những vấn đề đó đều có thể được xử lý chủ động. Một số việc bạn hoàn toàn không cần agent trong vòng lặp, vì có thể phát hiện bằng lập trình thông thường; rất nhiều thứ làm được chỉ bằng code thuần. Nhưng khi nói tới agentic pentesting, tức người khác cố hack bạn và bạn cố hack chính mình, thì đó mới là điểm mấu chốt. Theo David, bạn cần hack chính mình trước khi người khác làm việc đó.

12. Tốn token, và vì sao phải chia nhỏ codebase

Đúng vậy, nó tốn token, David thừa nhận. Tất nhiên là nó dùng rất nhiều token. Và anh có nhiều gói subscription Claude chính vì lý do đó. Nhưng theo anh, nếu bạn không làm, bạn sẽ không build được phần mềm tốt. Đó là thực tế chúng ta đang sống.

Anh nói bạn không thể cãi lại dữ liệu này. Những biểu đồ kia không phải dữ liệu của anh, mà từ a16z, theo anh là quỹ VC số một thế giới. Họ đã phân tích các công ty như Adobe, AMD, Apple, AWS, Google, GitHub, toàn những công ty lớn. Vậy mà họ vẫn đang tìm thấy lỗ hổng, vì AI agent giờ đã giỏi code ở mức siêu phàm.

David quay lại loop anh tạo ngay trước khi bắt đầu quay. Lý do anh tạo nó: anh muốn có thêm độ bao phủ riêng cho web app, vì anh đã có loop cho database, cho billing và những phần tương tự, nhưng chưa có loop nào dành riêng cho web app.

Để giải thích, anh mở một bảng vẽ và vẽ. Giả sử bạn có một codebase, nó là cái hộp này. Bạn có thể chạy một loop trên toàn bộ codebase đó. Chắc chắn như thế còn hơn không, nhưng đó không phải cách tốt nhất. Nếu bạn chạy một agent loop trên cả codebase, vấn đề là model có thể bị phân tán. Có thể nó chỉ đi vào một chỗ, rồi lần sau vẫn đi vào đúng chỗ đó. Model sẽ có một kiểu thiên hướng riêng, và chúng sẽ bỏ qua một số "góc khuất" của codebase. Chúng đi vào chỗ này, nhìn chỗ kia, và bạn sẽ không thật sự test hết mọi thứ. Vì vậy khi có một project, bạn cần chia nó ra (segment).

Và một lần nữa, bạn có thể làm việc cùng model. Bất cứ việc gì bạn cũng làm tốt hơn khi hỏi ý model và tự học thêm. Thay vì phân tích mọi thứ một lúc, bạn có thể chia ra. David nói, kể cả bước đầu tiên cũng đã là một bước tiến lớn đúng hướng: nếu bạn chỉ làm vậy thôi, thật lòng anh cũng thấy vui. Nếu bạn tạo một agent loop phân tích toàn bộ repo của mình hai lần mỗi ngày, bạn đã đi trước 90% số người.

Nhưng nếu bạn muốn đi trước 99% số người, bạn cần chia nhỏ codebase. Bạn cần nghĩ xem nên chia nó thế nào, ví dụ thành chín phần. Bạn chia thành chín phần, rồi chạy các agentic loop tập trung vào từng phần, và chúng có thể được tuỳ chỉnh. Có thể một vài phần không quan trọng lắm, nên bạn không cần dùng Opus 5.5 mà dùng Sonnet 5.5 hay một model khác. Hoặc nếu một phần không quan trọng, bạn chỉ chạy nó mỗi 24 giờ.

13. Tuỳ chỉnh từng loop, rồi tự đưa mình ra khỏi vòng lặp

Ví dụ, David có những loop đang chạy mỗi giờ, hay mỗi 30 phút. Và có lẽ chẳng có gì thay đổi: trừ khi bạn vừa ship thay đổi vào đúng phần đó của codebase trong 30 phút qua, kết quả có lẽ vẫn như cũ. Nên bạn có thể chạy nó mỗi năm giờ thay vì mỗi giờ. Bạn tuỳ chỉnh được, và bạn có thể dùng các model khác nhau. Một lần nữa: bạn cần chia nhỏ codebase và tạo các agent loop này.

Anh cho xem việc đó dễ thế nào. Anh có nhiều loop: security sweep chạy mỗi hai giờ dưới dạng cloud agent loop, dependency sweep chạy mỗi bốn giờ. Anh nghĩ có lẽ nên đổi loop thứ hai, nên anh bấm reply và gõ yêu cầu đổi nó sang chạy mỗi giờ. Dễ như vậy đó, chỉ bằng tiếng Anh thông thường.

Theo David, trong tương lai chúng ta sẽ chạy hàng trăm, rồi hàng nghìn agent, và chúng cần chạy một cách hiệu quả. Lúc này (tính đến 10/2026), nếu bạn khởi động hàng nghìn agent, bạn sẽ không biết chuyện gì đang diễn ra. Chìa khoá ở đây là "hiệu quả" (productively), và để tới đó, chúng ta phải tự đưa mình ra khỏi vòng lặp.

Bạn không thể tự làm mọi thứ. Để chứng minh, anh hỏi agent bằng CLI của công cụ: hiện anh đang có bao nhiêu thread mở, dặn nó đừng tiết lộ thông tin riêng tư vì anh đang quay một video YouTube mà hàng chục nghìn người sẽ xem, và trả lời ngắn. Trong lúc chờ, anh nói: chính con người chúng ta là điểm nghẽn (bottleneck). Lúc này, với Opus 5.5, điểm nghẽn không còn là Claude Code, Codex hay Pi nữa; các agent đã đủ giỏi (đánh giá của anh tính đến 18/10/2026). Nên việc bạn cần làm, công việc của bạn trở thành, là tự đưa mình ra khỏi vòng lặp.

Thay vì phải tự khởi động một đợt quét bảo mật codebase, bạn nên nghĩ cách biến nó thành một agentic loop. Và khi bạn có nhiều agentic loop, bạn đang tạo và build software factory của chính mình. Anh thừa nhận việc đi từ con số không tới một software factory có thể đáng sợ. Đó là lý do bạn cần bắt đầu từ việc tạo agent loop đầu tiên, rồi cái thứ hai, rồi cái thứ ba. Và khi bắt đầu, bạn vẫn chưa trao cho chúng toàn quyền tự chủ.

14. Tab Review: tương lai của công việc là xem lại

Khi có vấn đề, phần lớn các loop sẽ chờ anh. David mở tab Review, mà theo anh vừa được ship trong bản mới nhất của công cụ lúc quay video, phiên bản 107 (tháng 10/2026). Tab Review cho bạn thấy chuyện gì đã xảy ra.

Anh chỉ vào loop kiểm tra side effects (tác dụng phụ): nó vừa tự khởi động ngay trong lúc anh đang quay, để kiểm tra các tác dụng phụ của những thay đổi gần đây. Cách nó hoạt động: nó xem những gì đã được ship trong khoảng 24 tới 48 giờ qua, rồi tìm các hệ quả bậc hai (second order consequences). Theo David, rất nhiều bug và edge case ra đời theo cách đó.

Bạn thay đổi một thứ, có thể là một nút ở frontend, và bạn nghĩ chẳng sao cả. Nhưng có một phần khác của codebase dùng cùng logic đó, và thế là một edge case xuất hiện. Loop này kiểm tra chính xác loại chuyện đó.

Một loop khác kiểm tra feedback từ khách hàng. Bất kỳ ai dùng công cụ của anh cũng có thể nói kiểu "report to David that the app is feeling slow today" (báo với David là hôm nay app có vẻ chậm). Hoặc khi đang chat và gặp một vấn đề cụ thể, bạn có thể bấm "report a bug" ngay đó, hoặc bảo agent dùng công cụ feedback để báo cho David. Anh có một agent loop kiểm tra tất cả những báo cáo đó, để đảm bảo khi người dùng báo điều gì, nó được điều tra và sửa.

Tiếp theo là loop web test. Ở đây, theo David, bạn có thể thấy tương lai sẽ thiên về việc xem lại công việc. Bạn chỉ cần xem qua: ổn, ổn. Nếu có gì đó trông không ổn, bạn điều tra. Có thể bạn cần cho agent thêm quyền truy cập. Có thể bạn cần chỉnh system prompt. Có thể nó đang thiếu một API key, một MCP, hay thứ gì đó. Hoặc nó thật sự tìm ra một vấn đề. Hoặc nó quá nhạy, phát hiện vấn đề ngay cả khi không có vấn đề nào, và bạn cần chỉnh lại.

Theo David, đó sẽ là hình dạng của công việc trong tương lai (anh có một video gần đây về chủ đề này): chúng ta điều phối các agent, tạo các agent loop khác nhau, và quản lý software factory của chính mình sao cho nó chạy trơn tru. Và phần quan trọng nhất của tất cả là bảo mật.

15. Tạo một loop mới trên cloud, và vì sao mỗi agent cần sandbox riêng

David kêu gọi người xem build agent loop đầu tiên của mình, cho bất cứ thứ gì đang build. Kể cả khi bạn không build sản phẩm phần mềm nào, không điều hành công ty phần mềm nào, bạn vẫn cần một agent loop bảo vệ mình: bảo vệ hệ thống, chiếc MacBook, sự hiện diện trên mạng của bạn, bất kể là gì. Và một lần nữa, về cơ bản là cố pen test và hack chính mình trước khi người khác hack bạn.

Anh nói việc này rất dễ, và cho xem lại ví dụ: bạn chỉ cần nói kiểu "hãy tạo một cloud automation mới". Prompt anh đã dùng để tạo loop web test, như hiện trên màn hình:

Let's create a new cloud automation that tests our web app, both frontend and backend for security issues. Make sure to use opus 5.5 max as the model and should be a new Cloudroom loop, a new agent loop inside of Cloudroom and not a local one, it should be a cloud one. Make sure to set it up properly so that each execution starts a new thread, it should not run all in the same thread and really make sure to use opus 5.5 1 million max as the model.

Chỉ vậy thôi là agent tạo xong loop. Agent làm việc khoảng tám phút: đọc các skill về automation và bảo mật có sẵn trong repo để loop khớp với cách anh đang làm, xem chính web app để prompt của loop có đường dẫn thật, rồi viết prompt và tạo loop. Kết quả nó báo lại: loop "Web security test" chạy trên cloud mỗi bốn giờ theo giờ Los Angeles, với Opus 5.5 1M ở mức max; mỗi lần chạy mở một cloud thread mới trong sandbox riêng; mỗi lần chạy tự kiểm tra model và effort của chính nó trước, sai thì dừng và báo; mỗi lần chạy xem các thay đổi trong thư mục web của tám giờ qua rồi đào sâu vào một trong sáu khu vực theo lượt, như đăng nhập và admin, hay quyền API (người dùng có đọc được dữ liệu của người khác không).

Agent còn ghi "hai điều cần biết". Điều đầu tiên, David đọc lại: loop sẽ không tấn công trang đang chạy thật (live site), vì nó test một bản sao trong sandbox riêng. David nói thêm một điều nữa: mỗi cloud thread như vậy chạy trong sandbox riêng của nó, tức một máy tính cô lập riêng.

Anh cho xem các sandbox đó trông thế nào. Chế độ riêng tư đã được bật nên tên cụ thể không bị lộ, nhưng đây là các sandbox cô lập: mỗi cái là một hệ thống Linux, nơi agent tự chạy một mình.

Theo David, chạy agent ở local có một vấn đề lớn: kể cả khi bạn dùng worktree, các agent vẫn tranh nhau tài nguyên, cùng CPU, GPU và RAM. Còn vấn đề của worktree là chúng chiếm rất nhiều dung lượng ổ đĩa. Dùng worktree vài ngày, bạn sẽ thấy và tự hỏi 100 GB, 200 GB ổ đĩa của mình đi đâu hết rồi. Câu trả lời là worktree.

Vậy là giờ bạn hiểu vì sao cần cloud thread, và vì sao việc cho mỗi agent một sandbox cô lập riêng là kiến trúc tối ưu, theo David. Giống như khi bạn thuê một nhân viên vào công ty, bạn cho mỗi người một máy tính riêng để họ làm việc mà không bị chậm, không phải dùng chung một máy với năm người khác. Và bạn vẫn quyết định được cho từng thread, chạy trên cloud hay chạy local; hoàn toàn trong tầm kiểm soát của bạn.

16. Mọi harness trong một giao diện, và lời kêu gọi cuối

David cho xem thêm rằng mỗi thread trong công cụ của anh có thể chạy một harness khác nhau, với các subscription anh đang có. Anh chỉ lần lượt các thread: thread này chạy Claude Code CLI bên dưới, thread này chạy Codex CLI, thread này chạy Cursor CLI, thread này chạy Pi, thread này chạy Hermes, thread này chạy OpenCode. Theo anh, dù có công cụ mới nào ra đời, bạn vẫn dùng cùng một giao diện, cùng một công cụ, để dùng bất kỳ model, bất kỳ harness nào với các subscription bạn đã trả tiền.

Theo David, nếu bạn muốn có lợi thế vượt trội so với người khác, bạn không thể làm điều ai cũng làm. Bạn cần nhìn ra tương lai đang đi về đâu và bước những bước đúng hướng. Một việc hiển nhiên nên làm là tạo các agent loop và software factory chạy trên chính codebase của bạn, để tìm ra mọi lỗi bảo mật, mọi vấn đề, mọi lỗ hổng trước khi những kẻ xấu và hacker tìm ra và khai thác chúng trên công việc kinh doanh và cuộc sống của bạn.

Anh tổng kết video ngày 18/10/2026: giờ bạn đã biết cách làm. Theo anh, chúng ta đang sống trong thời đại của các vụ hack chạy bằng agent (agent-powered hacks), sự cố OpenCode là một bằng chứng lớn cho điều đó, và nó sẽ chỉ tệ hơn. Nếu bạn không muốn kết cục như OpenCode, bạn biết phải làm gì: mô tả bằng tiếng Anh thông thường, dùng một frontier model, Opus 5.5 hay GPT-6.1 Sol tuỳ bạn, và bắt đầu tạo agent loop đầu tiên của mình.

Đó là lời kêu gọi chính của video: hãy bắt đầu tạo các agent loop nhắm vào chính project của bạn, chính codebase của bạn. Nếu không, theo David, bạn đang chấp nhận một rủi ro không cần thiết, và việc bạn bị xâm phạm chỉ còn là chuyện sớm hay muộn.

Anh cảm ơn mọi người đã xem, hy vọng video hữu ích, và chúc mọi người một tuần làm việc thật hiệu quả.