Agentic engineering đã giết chết cách deploy AI cũ

Đừng deploy AI Agent thêm nữa trước khi hiểu “Agentic Engineering” là gì

TL;DR

• AI agent đang chuyển từ tạo code vụn vặt sang tự chạy cả quy trình — đòi hỏi “agentic engineering” thay vì chỉ vibe coding.
• Software 3.0 biến LLM thành “interpreter” mới, nơi prompt chính là ngôn ngữ lập trình và nhiều app truyền thống trở nên thừa.
• Miền nào có thể tự động kiểm tra kết quả (verifiable) thì AI sẽ bùng nổ; vùng “mù kiểm thử” sẽ rất chập chờn.
• Vibe coding nâng trình chung, nhưng agentic engineering mới là thứ tạo ra năng suất vượt xa “10x engineer”.
• Càng nhiều việc giao cho agent, con người càng phải mạnh ở hiểu hệ thống, thiết kế spec, judgment và taste.

Mục lục

• Tại sao 2025 lại là bước ngoặt của AI agent?
• Software 3.0 là gì và LLM đang thay đổi lập trình ra sao?
• Vì sao “verifiability” quyết định tốc độ tự động hóa AI?
• Vibe coding khác gì agentic engineering trong thực chiến?
• Con người còn giữ lợi thế gì khi agent làm gần như mọi thứ?
• Agent-native là gì và tại sao mọi hạ tầng sẽ phải thiết kế lại?
• Vì sao “hiểu” (understanding) càng ngày càng đắt giá?
• Founder và team kỹ thuật nên sống sót thế nào trong kỷ nguyên Software 3.0?
• Nên bắt đầu từ đâu? Lộ trình hành động trong 30 ngày
• Hệ thống lại & bước tiếp theo
• Câu hỏi thường gặp

---

AI agent không còn chỉ gợi ý code nữa. Chúng đang tự suy nghĩ, tự lặp lại và hoàn thành cả một quy trình — không cần bạn chen vào. Andrej Karpathy gọi đây là kỷ nguyên “software 3.0”, và theo ông, nếu bạn vẫn dùng AI theo kiểu ChatGPT hỏi–đáp, bạn đang tụt lại khá xa so với những gì thực sự đang diễn ra.

Related: Harness Engineering là gì? Thiết kế AI Agent 2026

Related: Harness Engineering là gì? Chuẩn hóa code AI trong team

Related: AI website na ná nhau: nguyên nhân & cách sửa | Hướng dẫn

Related: AI agent công nghiệp: sự thật khiến chatbot đã chết?

Bài này xây dựng lại từ các chia sẻ gần đây của Karpathy, nhưng theo góc nhìn thực dụng cho founder và kỹ sư ở Việt Nam. Tôi sẽ đi qua: bước ngoặt cuối 2025, khái niệm software 3.0, vai trò của “verifiability”, sự khác biệt giữa vibe coding và agentic engineering, và những kỹ năng con người chưa thể giao cho agent.

---

Tại sao 2025 lại là bước ngoặt của AI agent?

Mốc cuối 2025 là thời điểm Karpathy tự nhận “tụt hậu nhất đời lập trình viên” vì tốc độ tiến hóa của agent. Hiểu điều gì đã thay đổi ở đây giúp bạn định vị lại cách dùng AI: từ toy demo sang hạ tầng sản xuất thực sự.

Karpathy đã dùng các công cụ agentic khoảng một năm, ban đầu như trợ lý tạo “mẩu code”. Đôi lúc chúng sai, ông sửa tay — trải nghiệm khá giống nhiều dev Việt đang dùng ChatGPT, Claude hoặc Copilot để generate hàm nhỏ.

Bước ngoặt đến vào tháng 12/2025. Ông nhận ra mình hầu như không còn phải sửa nữa. Agent không chỉ trả về một đoạn code ổn, mà liên tục trả về nhiều đoạn, ráp lại thành hệ thống chạy được. Ông không nhớ lần cuối chạm tay vào sửa là khi nào.

Theo Karpathy, đó không phải cải thiện dần đều mà là một “cú nhảy pha” rõ rệt: từ hỗ trợ lặt vặt sang tự chạy cả workflow.

Điều này kéo ông hoàn toàn vào thế giới “vibe coding”: mô tả bằng ngôn ngữ tự nhiên, để agent tự bơi trong codebase, tài liệu, CLI, rồi tự lặp, tự sửa lỗi đến khi chạy được. Tôi đã thử mô phỏng cách làm này với một số công cụ hiện có — cảm giác chuyển từ “code trực tiếp” sang “điều khiển” thực sự rất khác. Không hẳn là nhẹ hơn, nhưng là một loại tập trung khác hẳn.

Làm sao biết mình đã bước sang thời đại vibe coding?

Một vài dấu hiệu Karpathy mô tả khá rõ:

• Bạn bắt đầu khó nhớ lần cuối mình tự gõ tay cả file code.
• Công việc chủ yếu là: mô tả yêu cầu, xem kết quả, chỉnh prompt, merge.
• “Gõ code chi tiết” bắt đầu có cảm giác… hơi phí thời gian.

Nhưng ông cũng cảnh báo: phần lớn thế giới vẫn nghĩ AI chỉ là chatbot. Họ chưa nhận ra rằng agent đang bắt đầu vận hành những workflow nhất quán, lặp đi lặp lại, gần như không cần ai chen vào.

Tóm lại: Cuối 2025, khả năng của agent nhảy vọt từ trợ lý code sang triển khai cả workflow. Vibe coding là trạng thái bạn chủ yếu “mô tả & duyệt”, ít còn “gõ tay & sửa”. Đa số vẫn đang đánh giá thấp mức độ thay đổi này.

---

Software 3.0 là gì và LLM đang thay đổi lập trình ra sao?

Software 3.0 là một mô hình lập trình mới, nơi LLM đóng vai “interpreter” và prompt chính là ngôn ngữ lập trình. Phần này quan trọng vì nó giải thích tại sao nhiều loại app truyền thống — kể cả thứ bạn đang định build — có thể sẽ không nên tồn tại.

Karpathy chia tiến hóa phần mềm thành 3 lớp:

• Software 1.0: dev viết code tường minh để điều khiển máy.
• Software 2.0: dev chuẩn bị dataset, huấn luyện neural network, để mô hình “tự học” hàm số.
• Software 3.0: dev “lập trình” bằng prompt tự nhiên, còn LLM là interpreter thi hành.

LLM được huấn luyện trên dữ liệu ở quy mô Internet, trở thành một “programmable computer” dạng mới. Cái “cần gạt” duy nhất bạn cầm trên tay là context window — nhét dữ liệu, ngữ cảnh và yêu cầu vào đó.

Nói thẳng hơn: programming paradigm bây giờ là “mảnh text nào để copy–paste cho agent”, chứ không còn là “hàm nào để import”.

Ví dụ MenuGen và cái chết lặng lẽ của nhiều app

Karpathy từng build một app tên MenuGen: chụp menu quán ăn, app dùng OCR, tạo ảnh, deploy lên Vercel. Ngay sau đó, ông nhận ra mình có thể đưa tấm ảnh đó thẳng cho một LLM hiện đại, bảo nó dùng một tool như NanoBrowser để vẽ overlay trực tiếp lên menu — không cần app riêng.

Kết luận của ông rất phũ: “Toàn bộ app MenuGen của tôi lẽ ra không nên tồn tại.”

Trong Software 3.0, rất nhiều app thực chất chỉ là “prompt + orchestration” mà LLM có thể làm inline ngay lúc cần. Nếu bạn đang định build một SaaS chỉ wrap LLM bằng một lớp UI mỏng, hãy tự hỏi: liệu vài tháng nữa người dùng có thể làm điều đó trực tiếp qua agent của họ không?

Tổ chức code và hệ thống thế nào trong Software 3.0?

1. Đưa logic tĩnh vào nơi agent dễ “nhìn thấy”. Thay vì bury logic trong 100 file, hãy có tài liệu, spec, README rõ ràng để agent đọc và thao tác được.

2. Thiết kế mọi thứ như API cho agent. Ngay cả khi khách hàng cuối là con người, hãy nghĩ: nếu ngày mai họ dùng agent để điều khiển sản phẩm, API và docs của bạn đã sẵn sàng chưa?

3. Tập trung vào phần “không thể prompt được”. Tích hợp đặc thù ở Việt Nam — hóa đơn điện tử, ngân hàng nội địa, constraint pháp lý cụ thể — vẫn cần rất nhiều domain knowledge.

Để đào sâu hơn về LLM như “interpreter”, tài liệu chính thức là điểm bắt đầu tốt: OpenAI Docs và Anthropic Docs.

Tóm lại: Software 3.0 là kỷ nguyên prompt là ngôn ngữ lập trình, LLM là interpreter trung tâm. Nhiều app “wrapper” sẽ trở nên thừa. Chiến lược đúng là nghĩ sản phẩm như API + spec cho agent, không chỉ là UI cho người.

---

Vì sao “verifiability” quyết định tốc độ tự động hóa AI?

Verifiability là khả năng tự động kiểm chứng kết quả trong một miền cụ thể — và nó quyết định nơi nào AI sẽ bùng nổ trước. Với founder, đây gần như là “radar” để chọn thị trường và bài toán.

Karpathy mô tả: truyền thống, máy tính tự động hóa những thứ ta viết được thành code. LLM thì tự động hóa những thứ ta có thể kiểm chứng đầu ra.

• Với code và toán: chạy test, check proof, đo performance được → cực kỳ verifiable.
• Với câu hỏi như “đi bộ hay lái xe khi cách 50 mét”: không có ground truth rõ ràng, khó encode thành reward → ít verifiable.

Các mô hình frontier hiện nay đều được train trong môi trường reinforcement learning quy mô lớn, nơi “verification reward” là tín hiệu chính. Lĩnh vực nào định nghĩa được reward rõ ràng, lĩnh vực đó bùng nổ năng lực model.

Đó là lý do cùng một mô hình có thể refactor 100k dòng code, tìm zero-day, nhưng trả lời những câu đời thường lại rất ngớ ngẩn.

“Trí thông minh lồi lõm” và sự lệ thuộc vào big lab

Karpathy gọi đây là “jagged intelligence” — trí thông minh lồi lõm, chỗ rất cao, chỗ lại cực thấp. Hai nguyên nhân chính:

• Bài toán đó có nằm trong “mạch” RL hay không.
• Big lab có đưa dữ liệu của miền đó vào pre-training dataset hay không.

Ví dụ, trình độ cờ vua của GPT-4 cao hơn GPT-3.5 không chỉ vì mô hình “mạnh hơn chung chung”, mà vì ai đó trong OpenAI đã quyết định nhét thêm rất nhiều dữ liệu cờ vào dataset. Điều này có nghĩa: ở nhiều lĩnh vực, bạn đang phụ thuộc vào ưu tiên của vài lab lớn.

Chiến lược thực dụng cho founder, CTO, tech lead

Nếu miền của bạn verifiable:

• Xây RL environment riêng, tự thu thập log, feedback và fine-tune model.
• Bạn không cần chờ big lab — chỉ cần build đủ vòng lặp kiểm thử và reward.

Nếu miền của bạn khó verifiable:

• Giảm kỳ vọng: agent sẽ rất “chập chờn”.
• Tập trung vào human-in-the-loop, UX cho việc review, chỉnh sửa, approve.
• Đầu tư vào data collection và fine-tune theo ngữ cảnh cục bộ — quy định Việt Nam, tiếng lóng trong ngành.

Câu hỏi cần đặt ra: Miền này có thể thiết kế test case tự động, chấm điểm, cho điểm thưởng không? Nếu câu trả lời là “có”, đây là ứng viên tốt cho sản phẩm AI-first.

Để hình dung cách RL với LLM được thiết kế: RLHF & alignment và TRL overview.

Tóm lại: Verifiability quyết định nơi AI thống trị trước. Trí thông minh LLM rất lồi lõm vì phụ thuộc vào RL pipeline và dữ liệu big lab chọn. Founder nên ưu tiên bài toán verifiable để tự xây environment riêng, tạo lợi thế thực sự.

---

Vibe coding khác gì agentic engineering trong thực chiến?

Agentic engineering là kỷ luật kỹ thuật mới để dùng agent mà vẫn giữ — thậm chí nâng — chất lượng phần mềm chuyên nghiệp. Phần này đặc biệt quan trọng nếu bạn là lead hoặc đang tuyển dev: dùng sai tư duy, tổ chức sẽ chìm trong nợ kỹ thuật do agent tạo ra.

Karpathy phân biệt rõ:

• Vibe coding: nâng “mặt bằng sàn” — ai cũng có thể lắp ghép ý tưởng thành prototype nhanh.
• Agentic engineering: giữ “thanh tiêu chuẩn” của phần mềm chuyên nghiệp, nhưng đẩy tốc độ lên nhiều lần nhờ agent.

Trong agentic engineering, một số thứ không được đánh đổi: bảo mật, khả năng bảo trì, và trách nhiệm kỹ sư. Bạn vẫn là người chịu trách nhiệm cuối cùng với hệ thống.

Nhiệm vụ cốt lõi theo Karpathy: “Làm sao điều phối một tập agent chập chờn, hay mắc lỗi nhỏ, để tổng thể vẫn vượt qua ngưỡng chất lượng chuyên nghiệp.”

Năng suất “hơn cả 10x” và vấn đề tuyển dụng mới

Karpathy cho rằng “10x engineer” giờ đã trông… hiền. Những người nắm agentic engineering tốt không chỉ code nhanh hơn, mà làm được kiểu việc trước đây đơn giản là bất khả thi.

Khi thử để agent triển khai end-to-end — từ tạo spec, code backend, frontend, viết test đến deploy — tôi nhận ra vai trò engineer gần như biến thành “đạo diễn kỹ thuật”: quyết định gì làm, khi nào dừng. Không còn là “công nhân code” nữa.

Karpathy cho rằng quy trình tuyển dụng hiện tại gần như không đo được năng lực agentic engineering. Bài test giải thuật hay cấu trúc dữ liệu đơn lẻ không nói lên được gì nhiều.

Thay vào đó, ông gợi ý:

• Giao ứng dụng cỡ Twitter clone.
• Bắt ứng viên dùng agent để triển khai và deploy thực sự.
• Sau đó chạy 10 instance kiểu Codex “tấn công” hệ thống đó, xem nó trụ đến đâu.

Bài test như vậy đo được cả khả năng điều khiển agent lẫn judgment về bảo mật và kiến trúc hệ thống.

Tóm lại: Vibe coding là tầng thử nghiệm nhanh, không thay thế kỷ luật kỹ thuật. Agentic engineering dùng agent như turbo, không buông tay. Tuyển dụng cần chuyển sang dạng bài thực chiến với agent.

---

Con người còn giữ lợi thế gì khi agent làm gần như mọi thứ?

Những gì AI agent làm tốt đang mở rộng rất nhanh. Nhưng có vài năng lực con người vẫn giữ “độc quyền” — và theo Karpathy, chúng đang trở nên đắt giá hơn, không phải rẻ hơn.

Khi agent giống như “thực tập sinh siêu năng lực”, vai trò con người dịch chuyển sang đạo diễn, người thiết kế spec và hệ thống. Ai nhận diện được shift này sớm sẽ học đúng thứ hơn, thay vì cố nhớ từng hàm API.

Những năng lực trở nên quan trọng hơn khi agent mạnh lên:

• Taste: chọn hướng nào là “đẹp”, “sạch”, “đáng làm”.
• Judgment: khi nào nên chấp nhận trade-off, khi nào cần dừng agent lại.
• System understanding: biết kiến trúc bên dưới đang vận hành ra sao.
• Spec design: chuyển business goal thành đặc tả đủ rõ cho agent thi hành.

Karpathy ví các agent hiện tại như thực tập sinh: có lúc làm được việc “siêu nhân”, nhưng cũng có thể phạm lỗi rất cơ bản. Trong dự án MenuGen, agent đề xuất match người dùng bằng cách so sánh email Google với email Stripe — bỏ qua khả năng người dùng dùng email khác nhau cho mỗi dịch vụ.

Common sense và phán đoán về hành vi con người vẫn là thứ agent thiếu trầm trọng.

“Plan mode” và cách thiết kế spec cùng agent

Karpathy đề xuất một “plan mode” thực dụng: con người giữ vai trò định nghĩa tổng thể — mục tiêu, constraint, các module lớn — rồi cùng agent “khai triển” spec chi tiết: API, schema, edge case, quy trình cụ thể.

Agent không thay thế giai đoạn hiểu và thiết kế. Nó khuếch đại năng lực của người đang hiểu. Tôi đã thử mô hình này khi thiết kế một hệ thống nhỏ: tôi phác thảo architecture, để agent đề xuất thêm case, sửa tên, thêm test — tốc độ và độ bao quát tăng thấy rõ.

Tách “chi tiết API” khỏi “hiểu sâu hệ thống”

Karpathy nêu ví dụ với PyTorch và NumPy: việc nhớ chi li keepdim hay keepdims, dim hay axis, reshape hay permute — hãy để agent làm. Nhưng hiểu cách tensor lưu trữ, biến đổi view, khi nào gây copy bộ nhớ — con người phải nắm.

Đừng cạnh tranh với khả năng “ghi nhớ API” của agent. Hãy tập trung vào mô hình tinh thần về hệ thống, invariants, constraint thiết kế, và hệ quả dài hạn của mỗi quyết định kỹ thuật.

Karpathy cũng thừa nhận thẳng: nhìn vào code agent sinh ra, nhiều khi “tim rơi thịch” — chạy được nhưng phình to, dư thừa, lặp lại copy–paste, dựa trên abstraction mỏng manh. Muốn sửa được điều này, cần đưa code aesthetics vào reward function của RL — thứ hệ thống hiện tại chưa làm được.

Tóm lại: Judgment, taste, hiểu hệ thống và thiết kế spec là những thứ agent chưa thay thế được. Hãy coi agent như intern siêu năng lực, không phải kiến trúc sư trưởng. Ghi nhớ API có thể giao cho agent; hiểu cơ chế bên dưới thì không.

---

Agent-native là gì và tại sao mọi hạ tầng sẽ phải thiết kế lại?

Agent-native là thế giới nơi mọi thứ — hạ tầng, tài liệu, dịch vụ — được thiết kế với khách hàng chính là AI agent, không phải con người. Phần này quan trọng nếu bạn đang làm công cụ, nền tảng hay tài liệu kỹ thuật.

Gần như mọi thứ bạn đang dùng đều “human-first”: docs để con người đọc, giao diện để con người bấm. Nhưng trong thế giới agent-native, những thứ đó cần chuyển thành “machine-readable, agent-usable” trước.

Karpathy phàn nàn về một vấn đề thực tế: tài liệu framework, tutorial, trang cấu hình dịch vụ đều giả định người đọc là con người. Nhưng thực ra, ông chỉ muốn biết:

“Hãy nói cho tôi biết đoạn text nào tôi cần copy–paste cho agent. Đừng bắt tôi tự tay làm từng bước nữa.”

Trong trải nghiệm triển khai MenuGen lên Vercel, phần deploy còn mệt hơn viết chính app. URL phải mở thủ công. Dropdown phải con người click. DNS phải cấu hình tay. Tất cả đều chưa agent-friendly.

Agent-native nghĩa là gì về mặt thiết kế?

1. Docs như “spec cho agent”, không chỉ là hướng dẫn cho người. Cấu trúc rõ ràng, có ví dụ end-to-end, có phần “prompt template” để người dùng copy–paste vào agent.

2. Giao diện cấu hình tự động hóa được. Mọi thao tác gọi được qua API, không bị khóa trong UI web. Các step phải đủ rõ để agent điều hướng được.

3. Hạ tầng “Agent First”. Từ CI/CD đến monitoring, mọi thứ đều có đường hook cho agent tham gia — đọc log, đề xuất rollback, chạy test — mà không cần bạn mở dashboard thủ công.

Karpathy hình dung một tương lai: neural network trở thành “host process”, CPU chỉ là “co-processor” cho một số tác vụ nhất định. Cá nhân và tổ chức đều có “agent đại diện”, trao đổi với nhau để đặt lịch, đàm phán, chuẩn bị tài liệu.

“Agent của tôi sẽ nói chuyện với agent của bạn về lịch họp” — không còn là chuyện đùa nữa.

Để hình dung cách agent tương tác với hạ tầng: Function Calling và Anthropic Agents.

Tóm lại: Agent-native là khi docs, hạ tầng, dịch vụ được thiết kế cho agent dùng trực tiếp. Phần lớn thế giới vẫn human-first, nhưng cơ hội lớn nhất nằm ở việc đảo chiều đó. Deploy, cấu hình, tích hợp sẽ ngày càng được tự động hóa qua agent.

---

Vì sao “hiểu” (understanding) càng ngày càng đắt giá?

Understanding là mức độ bạn thực sự nắm được hệ thống và ý nghĩa thông tin — không chỉ “biết cách hỏi AI”. Ai bỏ qua phần này sẽ dễ biến thành người điều khiển agent hời hợt, không tạo được giá trị sâu.

Karpathy trích một câu khiến ông “bị sốc” và thay đổi cách nghĩ về học tập:

“Bạn có thể outsource việc suy nghĩ, nhưng bạn không thể outsource việc hiểu.”

Ý rất thực tế: dù agent thông minh đến đâu, bạn vẫn là một phần của hệ thống quyết định. Thông tin cuối cùng vẫn phải đi vào não bạn để bạn quyết định làm gì tiếp, việc đó có đáng không, và agent nên được “điều quân” như thế nào.

LLM rất giỏi thực thi — generate, chạy, lặp. Nhưng “hiểu đúng” theo nghĩa sâu, liên kết nhiều bối cảnh, đánh giá giá trị dài hạn — đó là thứ chúng vẫn làm rất tệ.

Khi thực tế làm việc với AI, tôi nhận thấy: những người dùng AI hiệu quả nhất không phải người gõ prompt hay nhất. Mà là người hiểu vấn đề sâu đến mức nhận ra ngay khi nào agent bắt đầu “bịa” hoặc trượt khỏi đường ray.

Dùng LLM để xây knowledge base cá nhân

Karpathy thích ý tưởng LLM knowledge base — để model xây một “wiki cá nhân hoặc tổ chức”, rồi tương tác với nó như công cụ xử lý thông tin. Quy trình đơn giản:

1. Đọc một bài báo, tài liệu, sách.
2. Chắt lọc nội dung, nạp vào wiki cá nhân do LLM quản lý.
3. Đặt câu hỏi, yêu cầu nó chiếu lại từ góc nhìn mới — sinh ra insight mới.

LLM ở đây là bộ chuyển hóa từ tri thức rời rạc sang cấu trúc dễ “tiêu hóa”. Nhưng quyết định đọc gì, giữ lại gì, xâu chuỗi thế nào — đó là phần “hiểu” bạn không thể giao hẳn cho máy.

Tóm lại: Bạn có thể giao phần “nghĩ” cho agent, nhưng phần “hiểu” thì không. LLM knowledge base là công cụ mạnh để xử lý thông tin — miễn là bạn dùng nó để đào sâu, không phải để né việc hiểu. Chất lượng quyết định của bạn trong kỷ nguyên agent sẽ tỷ lệ thuận với chiều sâu understanding.

---

Founder và team kỹ thuật nên sống sót thế nào trong kỷ nguyên Software 3.0?

Software 3.0 yêu cầu chiến lược hoàn toàn khác: không phải “làm cái cũ nhanh hơn”, mà tìm thứ chưa từng khả thi trước đây.

Nếu tiếp tục tư duy “làm app, làm SaaS” kiểu cũ mà không tính đến agent, khả năng cao là bạn sẽ build thứ bị “bốc hơi” giá trị rất nhanh. Nhưng nếu chọn đúng nơi đặt cược, bạn có thể mở ra lớp giá trị hoàn toàn mới.

Một vài nguyên tắc Karpathy đưa ra:

1. Đừng hỏi “làm cái này nhanh hơn bao nhiêu?” — hãy hỏi “bây giờ lần đầu tiên có thể làm được điều gì?”

Ví dụ: tổ chức knowledge base dựa trên LLM không chỉ là “tìm kiếm nhanh hơn”, mà là khả năng tái cấu trúc tri thức liên tục theo đúng bối cảnh mỗi lần hỏi.

2. Săn tìm miền verifiable chưa được big lab chú ý.

Nếu bạn tìm được bài toán có thể thiết kế RL environment rõ ràng nhưng chưa ai khai thác nghiêm túc, bạn có cơ hội tạo lợi thế lớn bằng cách thu thập log, feedback có cấu trúc và fine-tune model xoay quanh reward đó.

3. Đầu tư sâu vào tool agentic, như dev đời trước đầu tư vào editor.

Ngày xưa là Vim, VS Code. Hôm nay là Claude Code, GitHub Copilot, các framework agentic và công cụ orchestration, monitoring cho agent.

Trên thực tế, sự khác biệt giữa “người dùng AI tàm tạm” và “AI-native engineer” nằm ở mức độ họ biết rõ công cụ làm được gì, không làm được gì — và khả năng đọc code agent sinh ra, nhận diện nợ kỹ thuật rồi sửa lại có hệ thống.

Hạ tầng và toolchain hiện tại vẫn quá human-first. Từ docs, API design đến pipeline deploy đều là cơ hội để thiết kế lại theo “Agent First” — tương tự như web những năm 1990, mobile đầu 2010s, hay SaaS đầu 2020s.

Tóm lại: Chiến lược Software 3.0 là tìm giá trị mới chưa từng khả thi, không chỉ tối ưu cái cũ. Ưu tiên bài toán verifiable để xây RL environment riêng. Trở thành AI-native engineer bằng cách đầu tư sâu vào công cụ agentic và hiểu hệ thống ở meta-level.

---

Nên bắt đầu từ đâu? Lộ trình hành động trong 30 ngày

Lộ trình 30 ngày giúp chuyển từ “hiểu khái niệm” sang “chạm tay vào thực hành”. Theo kinh nghiệm của tôi, chỉ cần một tháng tập trung, bạn đã có thể thay đổi hẳn cách làm việc với AI.

Tuần 1 — Làm quen với vibe coding có kiểm soát

Chọn một project cá nhân nhỏ — tool nội bộ cho team, script tự động hóa công việc lặp lại. Dùng một agent hoặc IDE AI (Claude Code, Copilot, v.v.) để implement 70–80% code, bạn chỉ review và sửa. Mục tiêu không phải viết ít hơn, mà là học cách quan sát agent làm việc.

Tuần 2 — Thử xây một workflow agentic

Thiết kế một quy trình 3–5 bước có thể tự động hóa — crawl dữ liệu Shopee/Tiki, phân tích, xuất báo cáo. Để agent thực hiện từng bước, bạn viết spec chi tiết và thêm kiểm thử ở mỗi bước. Đây là lúc bạn cảm nhận rõ nhất sức mạnh của verifiability.

Tuần 3 — Tập trung vào understanding và spec design

Mỗi khi dùng AI, ghi lại: input, output, và lý do bạn chấp nhận hoặc không chấp nhận kết quả. Song song đó, xây một mini knowledge base cá nhân dùng LLM làm backend để lưu tài liệu, note, câu hỏi–trả lời.

Tuần 4 — Tái thiết kế một phần hạ tầng theo hướng agent-native

Chọn một tool hoặc service bạn dùng hàng ngày — CI/CD, tool quản lý tài liệu nội bộ. Soạn lại docs nội bộ, script, API sao cho agent có thể thao tác end-to-end với càng ít click tay càng tốt.

---

Hệ thống lại & bước tiếp theo

Vấn đề / Câu hỏi	Việc bạn nên làm ngay
Không rõ AI agent đã đủ “nghiêm túc” để dùng cho sản xuất chưa	Chạy một project nhỏ theo kiểu vibe coding và đo số lần bạn phải sửa tay
Sợ sản phẩm mình build sẽ trở nên “MenuGen thứ hai”	Kiểm tra xem use case của bạn có thể được làm trực tiếp bằng agent + prompt không
Không biết chọn bài toán AI nào để khởi nghiệp	Tìm miền có verifiability cao, thiết kế thử bộ test và reward đơn giản
Lo ngại bị agent thay thế trong công việc	Đầu tư học understanding hệ thống, judgment, spec design thay vì chỉ học thêm framework
Hạ tầng nội bộ chưa phù hợp cho agent	Chọn một quy trình (deploy, báo cáo, crawl dữ liệu) và “agent hóa” từng bước

Agent hiện tại đã đủ mạnh để tự tạo, sửa, deploy code trong nhiều kịch bản. Nhưng cách phần lớn đội ngũ dùng AI vẫn dừng ở mức chatbot hỏi–đáp. Khoảng cách không nằm ở công cụ — nằm ở tư duy.

Trong 1–2 năm tới, sự chênh lệch giữa người dùng AI kiểu copy–paste vài đoạn code và người nắm vững agentic engineering sẽ nới rộng rất nhanh. Ở phía kia của khoảng cách đó, khái niệm “10x engineer” sẽ trông rất… bảo thủ.

Nếu phải chọn một việc để làm ngay hôm nay: chọn một quy trình thực, mang lại giá trị thật, và buộc bản thân phải vận hành nó qua agent từ đầu đến cuối. Chính trải nghiệm “vừa sợ vừa phê” đó sẽ cho bạn cảm giác rõ ràng nhất về tương lai mình đang bước vào.

---

Câu hỏi thường gặp

Q: Software 3.0 khác gì so với việc dùng ChatGPT để code như hiện nay?

A: Software 3.0 coi LLM là interpreter trung tâm và prompt là ngôn ngữ lập trình — nghĩa là cả hệ thống, từ spec, code đến deploy, đều được thiết kế quanh khả năng này. Dùng ChatGPT để generate vài hàm chỉ là một mảnh rất nhỏ, chưa chạm tới việc để agent điều phối toàn bộ workflow. Software 3.0 yêu cầu bạn tổ chức code, docs, hạ tầng sao cho agent có thể “đọc–hiểu–hành động” end-to-end.

Q: Vibe coding có đủ an toàn cho sản phẩm production không?

A: Không đủ, nếu dừng lại ở đó. Vibe coding giúp prototype nhanh nhưng không đảm bảo bảo mật, độ ổn định và khả năng bảo trì. Với sản phẩm production, bạn cần chuyển sang agentic engineering: vẫn giữ review, test, bảo mật chặt — chỉ dùng agent để tăng tốc, không buông tay hoàn toàn. Vibe coding phù hợp với thử nghiệm; agentic engineering mới phù hợp với sản xuất.

Q: Làm sao biết bài toán của tôi có “verifiability” tốt?

A: Tự hỏi: “Tôi có thể tự động viết test chấm điểm đầu ra không? Có metric khách quan nào đo chất lượng không?” Nếu có thể thiết kế bộ test, rule, reward để đánh giá kết quả mà không cần con người can thiệp từng lần, miền đó có verifiability tốt. Ngược lại, nếu mọi output đều cần con người “cảm nhận” mới biết tốt hay xấu, verifiability đang thấp.

Q: Tôi nên học gì để không bị agent thay thế?

A: Ưu tiên những năng lực agent còn rất yếu: hiểu sâu hệ thống, kiến trúc, thiết kế spec, judgment về trade-off và taste về sản phẩm. Đồng thời, học cách dùng agent như intern siêu năng lực — biết giao việc, kiểm tra, sửa sai. Cố cạnh tranh với agent về tốc độ gõ code hay nhớ API là chiến lược thua chắc.

Q: Agent-native có ý nghĩa gì nếu tổ chức của tôi còn khá nhỏ?

A: Với team nhỏ, đây lại là lợi thế. Agent-native giúp bạn “nhân bản” lực lượng mà không cần tuyển thêm người. Nếu hạ tầng, docs, script được thiết kế để agent có thể thao tác, bạn bớt phải làm việc vặt như deploy thủ công, cấu hình tay, copy–paste dữ liệu. Thời gian đó giải phóng để tập trung vào chiến lược, product-market fit và những quyết định cần understanding sâu.