Vì sao agentic engineer giỏi đang rời khỏi vòng lặp

1. Alien engineer: vì sao bạn còn ngồi trong vòng lặp?

Dan (IndyDevDan) mở đầu bằng một khẳng định: theo anh (video đăng ngày 26/10/2026), agent giờ mắc ít lỗi hơn cả bạn lẫn anh, ngay cả vào những ngày phong độ cao của chính mình với tư cách engineer. Đừng tin lời anh, anh nói: hãy giao cho Opus 5.5 một task khó rồi đọc trace. Nghiêm túc đấy, hãy đọc trace. Theo Dan, trace đó giờ trông như của một "alien engineer" (kỹ sư đến từ hành tinh khác), chạy những lệnh bash và những tổ hợp tool call "obscene" tới mức khó tin, và đó không phải chuyện xảy ra một lần. Anh nói Opus và Astra làm như vậy hết lần này tới lần khác (theo Dan, video đăng ngày 26/10/2026).

"Bạn và tôi đều thông minh, vậy hãy đặt những câu hỏi thông minh", Dan nói. Nếu agent là một lập trình viên giỏi hơn khi ở bên trong vòng lặp (loop), thì tại sao bạn vẫn còn ngồi trong đó? Theo anh (video đăng ngày 26/10/2026), trí thông minh của các model gần đây đã mở ra một cấp năng lực mới mà những engineer giỏi nhất đang bị cuốn vào. Nếu bạn muốn biết cấp năng lực mới đó là gì, anh nói bạn đang xem đúng video.

Dan kể (video đăng ngày 26/10/2026) anh làm việc với language model và agent từ khi việc đó bắt đầu khả thi. Trước đó, anh train những model scikit-learn cổ điển. Và bên dưới tất cả là hơn 15 năm kinh nghiệm software engineering. Chính vì vậy anh mới nói: kinh nghiệm đó không tự động mở khoá cấp năng lực mới này trong thời đại AI. Kinh nghiệm của bạn chỉ được đền đáp nếu bạn thay đổi cách mình vận hành. Không phải ai trong chúng ta cũng sẽ nhảy được bước này. Vì sao? Vì chúng ta vẫn đang làm mọi thứ theo cách người ta làm ngày hôm qua.

2. Metaskill, orchestration và hệ thống để build hệ thống

Opus, Astra và DeepSeek là gì? Theo Dan (video đăng ngày 26/10/2026), đó là những công cụ mới, không hơn, không kém. Nhưng nếu xếp đủ nhiều công cụ như vậy vào đúng kiến trúc, bạn có thể thay đổi điều gì là khả thi, bằng cách thay đổi cách mình vận hành.

Và theo anh (video đăng ngày 26/10/2026), bạn đã đang làm việc này rồi. Thay vì tự viết skill, bạn dạy agent cách viết skill cho mình: metaskill, xong. Thay vì tự chạy 10 agent, bạn chạy một agent để prompt chín agent kia: orchestration, xong. Thay vì kẹt trong vòng lặp, bạn bắt đầu nhận ra mình có thể build cái hệ thống để build hệ thống (build the system that builds the system).

Theo Dan, đây là khởi đầu của một hành trình quan trọng: từ human in the loop, sang near the loop, rồi cuối cùng là out the loop. Đó là chủ đề trung tâm của video. Anh hứa sẽ cho xem ba trong số nhiều near-loop agent anh đang chạy (tính đến video đăng ngày 26/10/2026), những agent làm việc thật trước khi anh ngồi vào bàn. Và tới cuối video, anh nói bạn sẽ biết chính xác cách nâng cấp agentic engineering của mình. Anh mời người xem ở lại để cùng hiểu in loop, near loop và out loop.

3. In loop, near loop, out loop: Prompt, Click, Cron

"What if your agents never stopped?", tức: nếu agent của bạn không bao giờ dừng thì sao? Theo Dan (video đăng ngày 26/10/2026), câu hỏi lớn là: thứ gì tiếp theo có thể chạy mà không cần bạn? Đây là câu hỏi dẫn đường. Nó đưa ta từ in loop sang near the loop rồi ra out the loop. Ta liên tục build cái hệ thống để build hệ thống; anh nói đó là chủ đề xuyên suốt ở đây.

Anh tóm nó trong ba chữ (video đăng ngày 26/10/2026): Prompt, Click, Cron. Rồi anh giải thích từng chữ.

• In loop: chỉ có bạn và terminal. Bạn liên tục dồn sự chú ý vào việc viết prompt.
• Near loop: bạn click, bạn phản hồi, bạn góp ý, bạn đưa feedback.
• Out loop: hoàn toàn là cron. Bạn đã bước ra ngoài. Bạn không còn là điều kiện bắt buộc nữa.

Theo Dan (video đăng ngày 26/10/2026), đây là mental model mới để hiểu kỹ năng agentic engineering của bạn qua kết quả bạn đạt được. Nếu bạn đang tiến bộ, nghĩa là bạn đang build thêm những hệ thống không cần bạn ở trong vòng lặp: thêm nhiều hệ thống near loop, thêm nhiều hệ thống out loop.

4. Bạn và tôi là bottleneck

Vậy vì sao ở trong vòng lặp lại là vấn đề? Dan đặt câu hỏi và tự trả lời: vấn đề của việc ở trong vòng lặp là bạn và anh, như bạn đã biết, chính là giới hạn. Bạn và anh giờ là bottleneck. Theo anh (video đăng ngày 26/10/2026), agent có thể làm được nhiều hơn rất nhiều nếu ta có đúng kỹ năng, đúng tool, đúng công nghệ, và nếu ta vận hành đúng cách. Ngưỡng năng lực mới này đòi hỏi bạn thay đổi cách vận hành, chính vì bạn và anh là bottleneck.

Và sự thật khó nghe ở đây, theo Dan (video đăng ngày 26/10/2026): 80% hoặc hơn toàn bộ công việc ta đang làm có thể chạy mà không cần bạn, không cần anh, nếu có đúng hệ thống.

Câu hỏi tiếp theo: hệ thống đó là gì, và lối nghĩ đó là gì? Như tiêu đề video đã nói, câu trả lời là out loop. Nhưng ngay lập tức một vấn đề khác nảy ra, theo Dan (video đăng ngày 26/10/2026): nhảy thẳng từ in loop sang out loop là rất khó. Vậy làm gì?

5. Bước ở giữa: reactive hay proactive

Theo Dan (video đăng ngày 26/10/2026), ta tạo ra một bước ở giữa, một chặng chuyển tiếp. Một đầu là trạng thái "butts in seats" (phải ngồi lì trên ghế): bạn dồn toàn bộ sự chú ý vào prompt tiếp theo, bạn ngồi canh agent. Đầu kia là out loop, và nhảy thẳng tới đó thì khó, đầy thử thách. Vậy ta tiến lại gần vòng lặp: near the loop. Ta từng bước tiến về tương lai. Điều ta muốn tạo ra là những hệ thống vận hành cho ta mà không cần ta, bằng cách trước hết bước ra ngoài, rồi bước vào khi được cần tới.

Vậy khác biệt lớn nằm ở đâu? Theo Dan (video đăng ngày 26/10/2026): bạn đang proactive (chủ động) hay reactive (bị động)? Anh muốn bạn proactive, tức build những hệ thống bắt đầu làm việc cho bạn trước khi bạn ngồi xuống. Anh cho xem nó trông như sau.

Thay vì bạn là trigger, bạn có một event cụ thể. Dan liệt kê: hãy nghĩ tới webhook, tới cron, tới một hành động của user trên giao diện, tới Jev đang phân loại một event từ log stream của bạn. Có cả triệu cách khác để khởi động agent. Vậy sao bạn vẫn là người khởi động chính? Theo Dan (video đăng ngày 26/10/2026), đó là agentic coding phase một và phase hai; đó là in loop; đó là lợi thế của ngày hôm qua, và nó đã bão hoà hoàn toàn.

Anh muốn bạn chuyển sang nghĩ về proactive agent, về hệ thống proactive agent: thứ mà agent cần sẽ kích hoạt nó. Và nếu bạn chưa nhận ra, anh nói, thứ agent cần không phải là bạn. Nó cần thông tin, và là đúng thông tin. Theo Dan (video đăng ngày 26/10/2026), việc của agentic engineer giờ là đưa đúng thông tin tới đúng agent.

6. Công việc diễn ra trước và sau lúc bạn check in

Tại sao làm vậy? Ai quan tâm tới proactive agent? Dan trả lời: vì công việc diễn ra trước và sau lúc bạn check in. Theo anh (video đăng ngày 26/10/2026), đó là thành quả của việc đầu tư, bỏ thời gian ra tạo một hệ thống chỉ cần bạn ở near loop. Near loop khác hẳn in loop, nhưng vẫn đủ gần để bạn không cảm thấy bị tách rời quá mức.

Anh đi qua một use case thật, một ví dụ kinh điển (theo Dan, video đăng ngày 26/10/2026). Một event đi vào event stream, vào log stream của bạn. Triage diễn ra: bạn dùng Jev để phân loại event. Bạn chuẩn bị patch, rồi agent trình nó cho bạn. Đây là lúc bạn check in: bạn đưa ra một quyết định cụ thể. Và rồi, đoán xem, bạn có thể đi tiếp, vì bạn đã build sẵn mọi thứ vào hệ thống.

Chuyện gì xảy ra tiếp theo? Theo Dan, bạn có một AI developer workflow chạy thay bạn: detect event, triage, patch, ask (hỏi bạn), apply thay đổi, verify thay đổi, lưu kết quả. Đây là human near the loop: công việc diễn ra trước và sau lúc bạn check in. Anh nói nó rất, rất có giá trị (video đăng ngày 26/10/2026).

7. Các yếu tố cốt lõi của near loop: durable agent, sandbox, lớp API

Vậy cần hiểu những yếu tố cốt lõi nào để build các hệ thống near loop? Dan nói đây là những chủ đề theo anh đang rất quan trọng (video đăng ngày 26/10/2026), là thông tin "high signal".

Mục thứ nhất là durable agent. Vì sao cần durable agent? Vì sao không thể cứ ném Pi nguyên bản, Claude Code nguyên bản, Codex nguyên bản vào bài toán này? Theo Dan (video đăng ngày 26/10/2026), vì ta cần sống sót qua crash, qua restart, qua laptop bị gập lại. Nói tới laptop gập lại, anh cho rằng bước nâng cấp lớn ở đây là một chủ đề kinh điển đang lan khắp ngành phần mềm: bạn muốn đặt agent vào sandbox riêng của chúng, cho chúng CPU compute riêng, và với các lab thì cả GPU compute.

Vì sao? Theo Dan, vì như vậy agent luôn bật (always on). Nó tách biệt (isolated). Nó an toàn, nếu bạn sandbox đúng cách. Và quan trọng nhất, anh nói, nó tự chủ (autonomous). Bạn đang mở rộng agent vào những môi trường riêng, nơi chúng làm việc được như bạn vì có mọi tool bạn có; và tool quan trọng nhất là một chiếc máy tính đầy đủ (theo Dan, video đăng ngày 26/10/2026).

Nhưng chỉ vậy thì chưa thành near-loop agent, Dan nói. Bạn cần thêm một thứ: một lớp API rõ ràng để nối nhiều loại trigger vào kích hoạt hệ thống. Lại câu hỏi đó: có cả triệu cách khởi động agent, vậy sao bạn vẫn là người khởi động chính? Theo anh (video đăng ngày 26/10/2026), tự hỏi câu đó giúp bạn thiết kế hệ thống để đi từ in loop sang near loop.

Các trigger đều đúng như bạn đoán: cron trigger, log event, ticket, giao diện cho user, event kéo thả ảnh, và tất nhiên cả các CLI agent tự làm việc theo nhịp riêng, tự làm việc của chúng, rồi kích hoạt hệ thống near loop của bạn. Theo Dan (video đăng ngày 26/10/2026), đó là những gì cần có, những yếu tố cốt lõi của một hệ thống near loop.

8. Durable agent cộng trigger trong sandbox bằng proactive agent

Theo Dan, khi build xong, những thứ này tạo ra một thứ rất mạnh. Điều thật sự làm nên bước nhảy, một bậc nâng cấp năng lực, là: một durable agent cộng một trigger, đặt trong một sandbox, cho bạn một proactive agent. Agent này không chờ bạn làm việc. Nó làm việc cho bạn, rồi chờ. Anh nói đây là một mức kết quả engineering khác hẳn mà kiến trúc này giúp bạn đạt được (video đăng ngày 26/10/2026).

Hãy thử bảo một vibe coder vibe-code thứ này, Dan nói, họ sẽ không làm được. Theo anh (video đăng ngày 26/10/2026), đó là lý do GrokBot, Dots, Claude Cowork và toàn bộ hạ tầng của chúng tồn tại: các bên đó đang cố commoditize thứ này cho người dùng phổ thông, và nói thẳng ra là cho cả một số engineer lười. Nếu bạn là một trong số đó thì cũng không sao, anh nói. Nhưng anh rất khuyến khích bạn sở hữu công nghệ này, vì theo anh nó sẽ là một phần then chốt của việc engineer ra những kết quả có đòn bẩy cực lớn nghiêng về phía bạn.

Một lần nữa, durable agent tồn tại bền (persist). Theo Dan, đó là điều làm chúng mạnh: vì tồn tại bền, chúng có thể hỏi bạn, có thể sống sót qua restart, rồi làm xong trọn vẹn công việc. Nhưng chúng phải ghi lại mọi thứ một cách liên tục, lặp đi lặp lại. Durable agent cần memory. Anh nói agent in-the-loop thông thường sẽ không đủ cho những hệ thống như vậy (video đăng ngày 26/10/2026), và anh mong điều đó đã rõ.

9. Use case một: proactive on-call agent

Khi đã chạy được, chúng trở nên rất mạnh, Dan nói. Ví dụ thứ nhất là incident response agent. Một incident xảy ra, agent chạy một AI developer workflow rõ ràng, một developer workflow mà trước đây bạn tự chạy. Nếu bạn là engineer trực incident (on call), bạn detect, bạn investigate, bạn phân tích root cause, bạn fix, rồi bạn chuẩn bị cho review. Khác biệt, theo Dan (video đăng ngày 26/10/2026), là giờ bạn có thể build một proactive agent bên trong một hệ thống near loop để làm việc đó thay bạn. Và rồi, đoán xem, bạn chỉ còn là reviewer: bạn review bản fix rồi deploy nó.

Dan nhấn mạnh đây không phải chuyện viển vông ("pie in the sky"). Anh mở giao diện thật của một mock example cho thấy hệ thống này trông thế nào. Đó là một client tách rời (disconnected client) với các event được stream vào; anh dùng Jev để phân loại event, và on-call agent đã tìm ra vấn đề. Việc còn lại của bạn chỉ là hiểu nó rồi bấm deploy (demo trong video đăng ngày 26/10/2026).

Theo Dan (video đăng ngày 26/10/2026), anh đã nói chuyện với nhiều engineer, và họ đang tích cực roll out kiểu hệ thống này ngay lúc này vì value prop có thật. Anh nói proactive agent cho bạn giá trị ngay bây giờ, thật và hữu hình. Trong demo, agent đã đi hết AI developer workflow, chờ bạn duyệt, và dùng Jev để đánh giá từng dòng event.

Anh cũng nói vẫn còn chỗ cần cải thiện. Theo lời anh (video đăng ngày 26/10/2026): nếu bạn không nhận mã lỗi HTTP 4XX hay 5XX thì bạn không cần Jev cho việc đó; thứ bạn thật sự cần Jev là phân loại thông tin thật, thật nhanh, để biết dựa trên hệ thống của bạn thì đó có phải là sự cố hay không. Đó là một ví dụ thật.

10. Use case hai: Durable News Agent chạy suốt tuần rưỡi

Còn gì nữa? Proactive agent còn dùng vào việc gì? Một cách dùng khác là dùng Jev để lọc bỏ hype, phân tích facts, rồi giữ lại signal mà mình thật sự quan tâm, tức thông tin bạn có thể hành động theo. Theo anh (video đăng ngày 26/10/2026), nhiều engineer, nhiều content creator, YouTuber, người đăng bài và giới media chỉ "hand wave" (khua tay nói suông) về chuyện này. Anh cũng thích khua tay, theo nghĩa đen, và nói về nó, nhưng anh còn thích chứng minh, để bạn hiểu rõ hơn chuyện gì đang diễn ra và điều gì là khả thi, để bạn vượt được những gì đối thủ làm được và thật sự hành động theo thông tin này.

"Ta đã làm việc này", Dan nói. Giao diện là thật, và anh mở được ngay. Nó chạy trên một sandbox, cụ thể là trên chiếc M4 Mac mini ngay cạnh anh. Anh vào idd-agents, bấm Enter. Đây là một durable agent luôn bật: nó làm việc cho anh, rồi chờ anh. Theo Dan (video đăng ngày 26/10/2026), nó đã bật được một tuần rưỡi; anh để nó chạy suốt và sẽ không tắt, vì nó liên tục mang lại giá trị cho anh.

Anh vào đây để ingest tin tức "với tốc độ ánh sáng": thông tin được kéo tới chỗ anh, anh không bị clickbait kéo vào đâu cả, vì anh đã chuẩn hoá cách mình muốn xem thông tin theo hướng không thiên lệch (theo Dan, video đăng ngày 26/10/2026). Đó là một ví dụ cụ thể, thứ anh đang build, thứ anh vẫn cùng các engineer khác build.

Dan đọc một tin trên màn hình: loomcycle, decision model đạt 40 trên 40 ở bài test prompt injection. "Thú vị", anh nói, rồi upvote tin đó. Theo anh (demo trong video đăng ngày 26/10/2026), làm vậy là gửi signal cho proactive agent, để nó tiếp tục đặt cho anh những câu hỏi nó có, và tiếp tục củng cố data flywheel anh đang build với kiểu micro product này.

Theo Dan (video đăng ngày 26/10/2026), đây là một điểm khác biệt then chốt: những engineer giỏi nhất đang chuyển từ build từng engineering agent riêng lẻ sang những product agent thật sự, tập trung vào một use case cụ thể và vượt bản mặc định một khoảng rất xa. Anh nói đây là một trong nhiều hệ thống near loop anh đang build rất mạnh tay, vì nó sẽ làm việc cho anh mà không cần anh. Rồi anh vào, lấy giá trị ra, cho feedback, và nó sẽ tiến bộ lên.

11. Use case ba: Deep Jev UI replicator

Kết quả cụ thể tiếp theo là một hệ thống Dan chưa từng công bố, có từ khi Jev 1.14 ra mắt (theo Dan, video đăng ngày 26/10/2026). Anh thả vào các thiết kế UI, các mock design, rồi một vòng RSI sơ khai (primitive RSI loop) chạy: nó build theo mock, so sánh, lặp đi lặp lại cho tới khi UI khớp với mock anh đưa vào. Vòng đó là fix, build, screenshot, Jev. Theo anh, nó tuỳ chọn dùng hai agent trở lên, và mục tiêu chỉ là vượt một ngưỡng similarity cho UI; trên slide minh hoạ, ngưỡng đó là 85.

Hệ thống này tên là Deep Jev UI replicator. Anh đã thả vào đó screenshot của một landing page. Nó cứ lặp, hill-climb trên mục tiêu anh giao, làm mãi, làm mãi. Anh có thể đổi model, đổi comparison agent, chỉnh core four của hệ thống. Theo Dan (video đăng ngày 26/10/2026), bạn không thể build những hệ thống này nếu không hiểu core four: context, model, prompt, tools, phần anh sẽ nói ngay sau. Đó là những kỹ năng then chốt cần biết và cần học.

"Bam, đây rồi", Dan nói. Bản này chạy trên một cloud sandbox, không nằm local ở đâu cả. Anh giao cho Astra mirror UI này, và nó đạt 86.1 match; anh chỉ kéo thả một ảnh vào, và nó lặp trên ảnh đó (demo trong video đăng ngày 26/10/2026). Trên màn hình, dự án ghi GPT-6 Astra, matched sau 2 trong 8 lần lặp.

Ví dụ thứ hai là mirror một landing page khác. Nó hill-climb chầm chậm về phía mục tiêu, ra kết quả khá ở lần lặp thứ ba, rồi không mirror thêm được nữa. Lần đó dùng Sonnet 5.5, "không tệ", anh nói (demo trong video đăng ngày 26/10/2026). Theo anh, đây là một hệ thống mang lại kết quả cụ thể: anh vào, yêu cầu một thứ, rồi rời đi; anh bỏ đi trong lúc nó làm. Theo số đo của Dan (video đăng ngày 26/10/2026), toàn bộ các lần lặp mất khoảng 30 phút để về cơ bản tiến dần một cách đệ quy tới ví dụ.

12. Chỉ là client, và vì sao build durable agent

Theo Dan (video đăng ngày 26/10/2026), đó đều là những ý tưởng lớn, những chủ đề lớn. Anh nói bước nhảy tiếp theo đã ở đây, và anh sẽ cố hết sức truyền đạt nó cho bạn, những "cracked engineer" từ mid tới senior trở lên. Mọi thứ dẫn tới những hệ thống mạnh như vậy.

Anh nhấn mạnh thêm lần nữa: những giao diện này chỉ là client. Anh kết nối qua browser, có lúc qua terminal hay điện thoại, và tất cả đều chạy trên một sandbox nào đó phía sau. Vì, một lần nữa, proactive agent luôn bật, không tắt. Ngược lại, theo Dan (video đăng ngày 26/10/2026), khi bạn rời một phiên làm việc, cuối ngày bạn đóng Claude Code, đóng Codex, đóng Pi, thế là phiên đó kết thúc.

Giá trị bạn nhận được khi build một hệ thống như vậy là rất lớn, Dan nói. Sẽ có những vấn đề mới ở level tiếp theo, những bottleneck thế hệ mới xuất hiện. Nhưng theo anh, tính đến video đăng ngày 26/10/2026, mục tiêu là đi từ in loop sang near loop rồi out loop. Vì vậy kiến trúc sandbox rất, rất quan trọng: bạn không muốn agent bị giới hạn bởi thiết bị của mình.

Vì sao build durable agent? Theo Dan (video đăng ngày 26/10/2026), những agent này tồn tại bền trên thiết bị, và anh đưa ra bốn lý do, cộng một hệ quả:

• Proactive: chúng bắt đầu làm việc trước khi bạn xuất hiện, trước khi bạn thức dậy (theo Dan, 26/10/2026).
• Multi-client: browser, terminal, phone; ai cũng có thể kết nối, ở bất cứ đâu. Anh nói điều này rất quan trọng với sản phẩm (26/10/2026).
• Multiplayer: bạn, product, design, support. Nếu bạn build và cho họ đúng tool, họ có thể vào đúng agent để làm xong việc nhanh hơn nhiều so với bình thường (theo Dan, 26/10/2026).
• Long-running: durable agent sống sót qua crash, qua restart, và anh nói chúng bắt buộc phải có tính chất này (video đăng ngày 26/10/2026).
• Và cuối cùng, tất cả dẫn tới chỗ bạn chuyển được sang near loop. Nó rút cái ghế khỏi dưới người bạn: bạn không phải ngồi ở ghế dev nữa. Anh gọi đó là một bước mở khoá lớn (video đăng ngày 26/10/2026).

13. Core four: context, model, prompt, tools

Vậy những kỹ năng cốt yếu cần học là gì? Theo Dan (video đăng ngày 26/10/2026), đó là những thứ nền tảng, "bread and butter": context, model, prompt, tool. Anh nói đây là thước đo bạn có thể đi ra xa tới đâu. Context, model, prompt, tools: mọi thứ đều quay về đây. Agent được làm từ bốn thứ này.

Bạn đã nghe về tất cả những kỹ năng này, đã học và mở rộng năng lực của mình với chúng, Dan nói. Theo anh (video đăng ngày 26/10/2026), phần lớn engineer, phần lớn content creator, phần lớn những người nói về agent chỉ đang tập trung vào bốn thứ này.

Nhưng theo Dan, giờ đây chúng là những primitive cấp thấp mới. Thứ thật sự đáng dành nhiều sự chú ý và thời gian khi bạn lên level trung bình và nâng cao là harness engineering, vì nó bắt đầu bọc trí thông minh mạnh mẽ này vào một hệ thống có thể vượt baseline và làm những việc rất riêng (theo Dan, video đăng ngày 26/10/2026). Anh nói đó là lý do anh liên tục nhắc tới Pi Coding Agent và Pi Durable: ở đó bạn thật sự mở rộng được, cho agent thêm hành động, và tuỳ biến kết quả chúng tạo ra.

Chuyên môn hoá (specialization) là lợi thế. Theo Dan (video đăng ngày 26/10/2026), nhiều engineer đang nhận ra điều này khi ai cũng có thể, từ mẹ họ, anh trai, chị gái, cho tới bố họ, prompt và build một "application" (anh nói kèm chữ "air quote", tức đặt trong ngoặc kép), hay reverse engineer bất cứ thứ gì. Khi đó lợi thế nằm ở chỗ: bạn chuyên biệt hoá kết quả của mình thế nào? Bạn build được hệ thống làm điều người khác không làm được ra sao? Và anh nói đây là chỗ software engineer có lợi thế cực lớn. Đó là ý lớn.

14. Tokenomics, prompt, harness, nhân với software engineering

Dan đi lần lượt từng kỹ năng. Làm chủ context engineering. Làm chủ tokenomics cho model bạn chọn: model đó phải đủ hiệu năng để làm xong việc, nhưng không đắt tới mức làm bạn cháy túi. Theo anh (video đăng ngày 26/10/2026), những subscription đang được trợ giá điên rồ này sẽ không kéo dài mãi. Vậy hãy hiểu tokenomics; anh gửi lời "shout out" tới DeepSeek.

Rồi tất nhiên là prompt engineering, cách bạn chỉ dẫn agent ngay từ đầu. Theo Dan (video đăng ngày 26/10/2026), nếu bạn không viết được một system prompt tốt, nếu bạn kẹt với các thiết lập mặc định, bạn sẽ rất khó chuyển sang near loop và out loop. Bạn phải hiểu cả user prompt bạn đưa vào liên tục, lẫn system prompt để thay đổi "luật" cho agent. Và tất nhiên là tool, tức harness. Đây là một mục lớn.

Bốn thứ đó hợp thành core four. Theo Dan, bạn phải học những kỹ năng này để chuyển ra ngoài vòng lặp. Nếu không, anh nói (video đăng ngày 26/10/2026), bạn sẽ kẹt ở level thấp nhất vì phải dựa vào Claude Code nguyên bản, Codex nguyên bản, trải nghiệm out-of-the-box của agent harness, những kết quả out-of-the-box mà giờ ai cũng nhận được. Theo anh, lợi thế của một agent đơn lẻ ở cấu hình mặc định đã bão hoà hoàn toàn, và đã như vậy được một thời gian.

Ai cũng đang trông vào việc model tự tốt lên, Dan nói (video đăng ngày 26/10/2026). Nhưng đó chỉ là một trong bốn chiều mà bạn, người engineer, có thể khai thác để nhân đòn bẩy của mình. Agentic engineering là hiểu bốn thứ này: context, tokenomics, prompt, và harness engineering của bạn.

Và điều lớn mà theo Dan cả ngành đang phát cuồng vì nó (video đăng ngày 26/10/2026) là: tất cả những thứ này được nhân lên bởi software engineering của bạn, vì đó là thứ bạn biết. Đó là những câu hỏi bạn đặt ra được, những kiến trúc bạn build được, chuyên môn trong lĩnh vực của bạn mà bạn đã tích luỹ năm này qua năm khác. Anh nói giá trị của nó giờ không thể nói quá, vì giờ bạn dùng được những thứ còn lại, những paradigm mới này, để nhân lên. Và anh nói anh thật sự có ý "nhân lên" những gì bạn làm được.

Dan thừa nhận nghe thật "cringe" khi cứ tung ra những từ như multiply, exponential, parabolic, nhưng anh nói nó đúng, đúng về mặt sự thật. Theo anh (video đăng ngày 26/10/2026), điều này mở ra cho bạn vì bạn dùng được những công cụ thông minh mới, mạnh mẽ này, rồi áp kiến thức và context của mình, áp tokenomics, prompt, chỉ dẫn, áp vào các harness của bạn. Anh nói khoảng cách dành cho những engineer thật sự nâng cấp agentic engineering của mình chưa bao giờ lớn như vậy. "Như tôi vẫn luôn nói", anh nhắc: vibe coding là sàn, agentic engineering là trần.

15. Một ví dụ cụ thể, và vibe coding khác agentic engineering ở đâu

Ý anh là gì? Dan đưa một ví dụ cụ thể. Bạn chọn một model cụ thể với cân bằng đúng giữa cost, performance và tốc độ. Rồi bạn build một custom agent harness bằng bất kỳ SDK nào bạn muốn; anh khuyên dùng Pi (theo Dan, video đăng ngày 26/10/2026). Như vậy bạn bắt đầu harness engineering những tool cụ thể để tạo ra kết quả cụ thể cho sản phẩm hay ứng dụng của mình.

Rồi bạn nhận ra agent có thể bắt đầu bắn ra những lệnh nguy hại. Bạn làm gì? Bạn thêm Jev Damage Control. Có thể bạn bỏ hẳn Bash tool, vì bạn nhận ra nó nguy hiểm thế nào, và chỉ đưa cho agent đúng những kết quả nó muốn. Theo Dan (video đăng ngày 26/10/2026), đó là agentic engineering.

Đây là một ví dụ cụ thể về việc bạn áp chuyên môn của mình, nhận thức của mình, hiểu biết của bạn về bảo mật, về sản phẩm, về những gì sản phẩm cần, hiểu biết về model selection, tokenomics, harness engineering, và việc bạn đưa đúng prompt vào hệ thống. Theo Dan (video đăng ngày 26/10/2026), đó là những kỹ năng làm nên agentic engineering, và đó là cách bạn đi từ in, sang near, ra out: bạn build hệ thống tốt tới mức không cần nhìn xem chúng đang làm gì. Anh nói đó là điểm mấu chốt.

"Không phải để chê bai các bạn vibe coder, shout out các bạn", Dan nói, nhưng theo anh (video đăng ngày 26/10/2026): vibe coding là không biết hệ thống của mình làm gì, và không nhìn. Agentic engineering là biết hệ thống của mình làm gì rõ tới mức không cần nhìn. Anh nói khác biệt đó là rất lớn.

16. Thước đo mới: bao nhiêu agent đang làm việc cho bạn ngay lúc này

Dan mô tả trông nó thế nào. Bạn đang build tầng application. Bạn đang prompt agent của mình. Ta muốn chuyển sang paradigm mới, nơi bạn build một hệ thống rồi hệ thống đó build hệ thống thay bạn. Đó là mục tiêu. "Build the system that builds the system" là câu kim chỉ nam anh dùng, và theo anh câu đó vẫn đúng (video đăng ngày 26/10/2026).

Vậy đây là thước đo thành công bây giờ, theo Dan (video đăng ngày 26/10/2026). Anh nói bạn có thể dùng nó như một mô hình cụ thể, một framework cụ thể anh khuyên các engineer dùng, và là thứ anh đang bị ám ảnh: thước đo thành công của bạn là có bao nhiêu agent đang làm việc cho bạn ngay lúc này, ngay giây phút này.

Tất nhiên, anh nói (video đăng ngày 26/10/2026), anh không nói tới chuyện "token maxing". Ai cũng có thể dựng một while loop và để agent làm những thứ linh tinh. Anh nói về việc hữu ích mà bạn cần làm xong, và việc đó đang diễn ra; việc hữu ích có thể nhân năng lực của bạn theo những cách bạn hiểu, và cả những cách bạn chưa lường trước. Anh nói về những sản phẩm bạn build với agent bên trong, chạy cho bạn mà không cần bạn. Anh nói về near loop và out loop.

Theo Dan (video đăng ngày 26/10/2026), lợi thế rất rõ. Bạn chỉ tập trung được chừng đó. Bạn chỉ chia sự chú ý qua được chừng đó terminal trước khi phát điên và mất tập trung. Rồi cả ba luồng việc biến thành ba luồng mà bạn không biết chuyện gì đang xảy ra. Bạn chỉ còn ngày càng tin model nhiều hơn. Anh nói đó không phải engineering. Engineering là build những hệ thống mà bạn biết chắc chúng sẽ làm gì để ra được kết quả bạn muốn.

Đây là thước đo bây giờ, Dan nói (video đăng ngày 26/10/2026): bước chuyển từ agentic engineering đòn bẩy thấp, lên đòn bẩy cao hơn, tới đòn bẩy cao. Bạn build hệ thống tốt tới mức bạn bước ra được, vì bạn nhận ra chính mình là bottleneck.

17. Prompt, approve, observe: cách ra khỏi vòng lặp

Theo Dan (video đăng ngày 26/10/2026), bước nhảy tiếp theo đã tới. Anh gọi phase ba là giai đoạn deprecate: augment, automate, deprecate, mà theo anh là chu kỳ ba giai đoạn của mọi cuộc cách mạng công nghệ. Đây là nơi anh áp dụng ZTE, zero-touch engineering.

Sự chuyển dịch này là gì, và vì sao nó quan trọng? Dan tóm lại: ta đi từ in loop, nơi bạn prompt, sang near loop, nơi bạn approve, tới out loop, nơi bạn observe. Theo anh (video đăng ngày 26/10/2026), đó là dòng chảy then chốt, là lộ trình cho agentic engineer.

Vậy làm thế nào để thật sự ra khỏi vòng lặp? Dan đưa ra các bước:

1. Làm chủ core four, làm chủ những gì cấu thành agent.
2. Dùng durable agent để giải một bài toán thật. Agent này chạy liên tục, tìm kiếm trigger (theo Dan, video đăng ngày 26/10/2026).
3. Build những hệ thống để build hệ thống. Theo Dan (video đăng ngày 26/10/2026), đây là điều then chốt mà software engineer làm được còn những người khác thì không. Anh nói vẫn luôn như vậy, nhưng giờ nó rõ hơn bao giờ hết vì đòn bẩy cao hơn bao giờ hết.

Dan nói đây là cơ hội đáng kinh ngạc nhất từng có cho những engineer như anh và bạn. Có thể bạn đã lỡ cuộc cách mạng internet. Có thể bạn đã lỡ cuộc cách mạng mobile. Có thể bạn đã lỡ social, lỡ crypto. Nhưng bạn và anh đang ở đây, ngay lúc này, trong thời đại của agent (theo Dan, video đăng ngày 26/10/2026). Hãy tận dụng nó.

Mỗi khi bạn ngồi xuống trước terminal, khi bạn đặt mình vào ghế, Dan muốn bạn thật sự dừng lại và tự hỏi: có lý do gì để tôi vẫn còn ở trong vòng lặp cho việc này không? Và theo anh (video đăng ngày 26/10/2026), câu trả lời chỉ thật sự nên là "có" nếu bạn đang build cái hệ thống để build hệ thống. Anh cảm ơn mọi người đã xem tới cuối, rồi chào: "Stay focused and keep building."