AI IDE, Gemma 4, MCP: lập trình kiểu cũ đã chết chưa?

AI đang đảo lộn giới lập trình: nếu bạn chỉ “biết nhiều” thì đã thua rồi

TL;DR

• AI IDE như Cursor 3 đang chuyển từ “công cụ hỗ trợ” sang “agent chủ động” điều khiển cả quy trình phát triển.
• Gemma 4 cho thấy tương lai on-device AI: mô hình nhỏ, chạy ngay trên thiết bị, bớt phụ thuộc hạ tầng đắt đỏ.
• AI có thể tự làm thuế, viết code, audit bảo mật — nhưng giá trị thật nằm ở người biết kiểm tra và chỉnh sửa kết quả.
• MCP đang dần trở thành “hệ thần kinh” của AI agent, nối thẳng agent với dịch vụ, dữ liệu và công cụ ngoài.
• Tấn công chuỗi cung ứng phần mềm và đe doạ hậu lượng tử buộc lập trình viên phải coi bảo mật là kỹ năng cốt lõi.

Mục lục

• Cursor 3 với Agent-First UI đang thay đổi cách lập trình như thế nào?
• Google Gemma 4 là gì và tại sao on-device AI lại quan trọng?
• AI làm thuế: đòn đánh thẳng vào “giá trị kiến thức” truyền thống?
• G-Stack, 694K dòng code và cú lừa về “năng suất lập trình”
• MCP server đang hồi sinh và trở thành hạ tầng bắt buộc ra sao?
• Tấn công Axios & LiteLLM nói gì về bảo mật chuỗi cung ứng phần mềm?
• Quantum computing có đang biến ECC-256 thành bom hẹn giờ?
• 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

---

Cursor 3 với Agent-First UI đang thay đổi cách lập trình như thế nào?

Cursor 3 là một bản cập nhật AI IDE đưa mô hình “agent-first” lên vị trí trung tâm, thay thế hoàn toàn tư duy “trình soạn thảo trước, AI sau”. Nhìn qua các bản demo thực tế, cảm giác giống dùng một app quản lý công việc có AI hơn là một IDE cổ điển.

Related: AI và tương lai nghề lập trình 2026 | 12 bài học sống còn

Related: AI và tương lai nghề lập trình: 12 insight then chốt

Related: AI coding assistant đã phá hủy năng suất dev của bạn?

Related: MCP trong Claude là gì? Biến chatbot thành AI agent 2026

Phiên bản đầu tiên của Cursor về cơ bản là một bản fork của VS Code — dev nhảy vào dùng ngay, không phải học lại. Cursor 2 thêm agent nhưng vẫn giữ dáng dấp IDE quen thuộc. Cursor 3 thì khác hẳn: sidebar bên trái là danh sách thread theo từng task, vùng nội dung chính là giao diện chat giống Claude Code hoặc app Codex của OpenAI.

Điểm thực sự đáng giá không chỉ ở UI. Trải nghiệm chuyển giao công việc giữa local và cloud mới là phần thú vị: bạn giao việc cho agent trên điện thoại, sau đó mở lại trên laptop và tiếp tục xem kết quả. Với dev web hay bị gián đoạn giữa nhiều dự án, workflow này rất hợp lý.

Mô hình “giao việc – chờ kết quả – rà soát” phù hợp với cả freelancer lẫn team nhỏ. Không phải vì nghe hay, mà vì nó khớp với cách người ta thực sự làm việc khi bị cắt ngang liên tục.

Cursor 3 vẫn có giới hạn rõ ràng. Web stack thì chạy tốt, nhưng phát triển native — macOS hay iOS — chưa được tối ưu. Đội Cursor rõ ràng chọn đánh mạnh vào web dev trước, nơi AI có nhiều ngữ cảnh và best practice để bám vào hơn.

Agent-first IDE sẽ thay thế lập trình kiểu cũ như thế nào?

Agent-first IDE là cách tiếp cận trong đó bước đầu tiên không còn là “mở file rồi gõ code”, mà là “mở agent rồi giao việc”. Cursor 3 thể hiện rõ điều này: giao diện chính là chat, còn file chỉ là tài sản mà agent thao tác bên dưới.

Thay vì tự tay tạo folder, cấu hình webpack, chỉnh eslint, bạn chỉ cần mô tả yêu cầu. Agent sẽ đề xuất kiến trúc, sinh code khung, chạy thử ở mức cho phép, rồi đưa diff để bạn duyệt.

Khi thử mô phỏng workflow này với Claude Code và Replit Ghostwriter, điều rõ nhất là vai trò của con người dịch chuyển: từ người gõ code sang người viết spec và người review. Cursor 3 tiến thêm một bước khi biến mỗi yêu cầu thành một task riêng trong sidebar. IDE đang tiến hoá thành công cụ quản lý task có khả năng tự thực thi, chứ không chỉ là trình soạn thảo thông minh.

Bạn cần nhớ gì?

• Cursor 3 đưa agent-first lên trung tâm, biến chat thành giao diện lập trình chính.
• Web dev được ưu tiên tối ưu; native app dev vẫn còn thô.
• Vai trò lập trình viên chuyển từ viết code sang giao việc, soát code và quyết định chấp nhận thay đổi.

---

Google Gemma 4 là gì và tại sao on-device AI lại quan trọng?

Google Gemma 4 là một dòng mô hình ngôn ngữ nhỏ gọn tối ưu cho on-device inference, có kích thước từ 2B đến 31B tham số. Khác với các model hàng trăm tỷ tham số đòi hỏi cụm GPU khổng lồ, Gemma 4 được thiết kế để chạy trực tiếp trên điện thoại hoặc máy cá nhân. Khi so biểu đồ ELO trên arena.ai, Gemma 4 cho thấy hiệu suất ngang ngửa nhiều model top với kích thước nhỏ hơn rõ rệt.

Lợi thế chiến lược của Google nằm ở “nhỏ, nhanh, rẻ”. Dòng Gemini Flash và Flash-Lite đã chứng minh điều này trong các tác vụ cần tốc độ và chi phí thấp. Gemma 4 tiếp tục củng cố vị thế đó, trong khi các model Gemini Pro ở phân khúc cao vẫn bị đánh giá là yếu thế hơn GPT-4o hay Claude 3.5 Sonnet.

Nhưng phần hấp dẫn nhất là liên minh với Apple. iOS 26 bắt đầu tích hợp LLM on-device, nghĩa là nhiều tác vụ AI sẽ chạy thẳng trên iPhone mà không cần lên server. Trong bối cảnh đó, khả năng Gemma 4 — đặc biệt bản 2B — được nén và tối ưu cho Apple Silicon là hoàn toàn có lý.

Ví dụ cụ thể: app ghi chép chi tiêu như “Split My Expenses” không cần gọi API để phân loại từng giao dịch. Model trên máy đủ thông minh để xử lý ngay lập tức, không chờ mạng, không rò dữ liệu.

On-device AI sẽ thay đổi trải nghiệm người dùng như thế nào?

On-device AI là cách triển khai trong đó mô hình chạy trực tiếp trên thiết bị người dùng, không cần gọi về server cho mỗi yêu cầu. Ba lợi ích rõ nhất: tốc độ phản hồi gần như tức thì, dữ liệu nhạy cảm không rời khỏi thiết bị, và chi phí hạ tầng GPU phía server giảm đáng kể.

Khi dùng model nhỏ trên laptop để tóm tắt tài liệu nội bộ, cảm giác “mở ra là dùng, không sợ lộ dữ liệu” tạo ra thói quen sử dụng thường xuyên hơn rất nhiều so với phải gọi API ngoài. Đó là sự khác biệt về hành vi, không chỉ là kỹ thuật.

Sự kết hợp giữa phần cứng ML của Apple và chuyên môn LLM của Google có tiềm năng tạo ra thứ mà đến nay hầu hết app AI trên iOS và Android vẫn chưa đạt được: AI luôn sẵn sàng, phản hồi tức thì, không sợ rớt mạng hay nghẽn server.

Bạn cần nhớ gì?

• Gemma 4 là dòng mô hình nhỏ, tối ưu cho on-device, với hiệu suất ấn tượng so với kích thước.
• Google đang chọn chơi “vũ khí hạng nhẹ” thay vì đua model siêu to.
• Kết hợp Apple Silicon và Gemma 4 mở ra thế hệ app mobile AI chạy offline, bảo mật hơn và nhanh hơn.

---

AI làm thuế: đòn đánh thẳng vào “giá trị kiến thức” truyền thống?

AI cho khai thuế là trường hợp cho thấy ranh giới của lao động tri thức đang bị xóa mờ. Câu chuyện bùng nổ khi Daniel Vassallo — cựu kỹ sư Amazon và sáng lập Small Bets — công khai nói rằng anh dùng Claude để tự khai thuế. AI tìm đủ các khoản miễn giảm, không phán xét, không bắt chờ, và đương nhiên không gửi hóa đơn.

Phát biểu đó châm ngòi tranh luận dữ dội giữa cộng đồng kế toán và giới công nghệ. Một bên cảnh báo AI không chịu trách nhiệm khi bị kiểm toán. Bên kia tuyên bố cực đoan: “CPA sắp tuyệt chủng, 100 đô AI làm hết.” Nhưng đọc kỹ chia sẻ của Daniel, thứ anh so sánh không phải “trí tuệ AI vs CPA”, mà là “trải nghiệm AI vs trải nghiệm CPA tệ”.

Daniel còn public cả prompt, cho thấy anh dùng AI như đối tác để hỏi về mã số thuế, luật áp dụng và từng khoản miễn giảm. Giá trị anh nhận được nằm ở chỗ: có thể hỏi bất cứ thứ gì, bất cứ lúc nào, không sợ bị đánh giá hay bị làm khó. AI không “xấu tính” nếu bạn hỏi câu “ngớ ngẩn” — nên người dùng dám hỏi đến cùng thay vì gật cho xong.

Perplexity AI sau đó cũng quảng bá khả năng hỗ trợ khai thuế, khiến tranh cãi càng lan. Một đồng dẫn podcast là CPA đã thử so sánh kết quả AI với TurboTax và nhận ra sự khác biệt đáng kể. Nếu thiếu dữ liệu đầy đủ và prompt kỹ lưỡng, AI chưa thể đáng tin 100%.

AI có giết nghề hay chỉ giết mô hình kinh doanh cũ?

Tranh luận này thực ra dẫn đến một kết luận khá rõ: “biết nhiều” không còn là lợi thế bền vững. Kiến thức thuế — giống như kiến thức lập trình hay bảo mật — đều có thể được AI truy xuất và áp dụng với chi phí gần như bằng 0.

Điều AI chưa làm được là chịu trách nhiệm khi kiểm toán, đứng ra giải trình bối cảnh cụ thể với cơ quan thuế, và thiết kế chiến lược thuế dài hạn gắn với mục tiêu tài chính thực sự của cá nhân hay doanh nghiệp.

Khi dùng AI để rà soát hợp đồng và tài liệu pháp lý, điều rõ ràng là AI rất giỏi chỉ ra điều khoản. Nhưng quyết định “chấp nhận rủi ro đến đâu” vẫn cần người có kinh nghiệm thực chiến. Đó là sự khác biệt mà không prompt nào bù đắp được.

“Nếu lợi thế của bạn chỉ là kiến thức, thì đó là lợi thế rất mong manh. Lợi thế nên nằm ở quan hệ, trách nhiệm và trải nghiệm mà bạn mang lại, chứ không chỉ là thông tin.”

Bạn cần nhớ gì?

• AI có thể tự động hoá phần lớn nghiệp vụ khai thuế nếu được cung cấp dữ liệu và prompt tốt.
• Giá trị của CPA và dịch vụ tư vấn đang chuyển từ “giữ kiến thức” sang “đồng hành, chịu trách nhiệm và lên chiến lược”.
• Mô hình kinh doanh dựa thuần vào “tôi biết thứ bạn không biết” sẽ bị bào mòn rất nhanh.

---

G-Stack, 694K dòng code và cú lừa về “năng suất lập trình”

G-Stack là một stack phát triển phần mềm dựa trên AI agent do Gary Tan — CEO Y Combinator — xây dựng, dùng Claude Code như điều phối viên cho nhiều vai trò: CEO, designer, engineer, release manager, người viết tài liệu. Gary tuyên bố trong năm 2026 anh tạo ra 694.000 dòng code với hệ thống này và đạt năng suất gấp 90 lần so với chính mình ở trạng thái đỉnh cao.

G-Stack nhanh chóng thu hút hơn 60.000 sao trên GitHub. Nhưng một kỹ sư đã bỏ thời gian review sâu phần code Gary public, và kết luận khá lạnh: code chạy được, nhưng còn cách chuẩn production của các công ty phần mềm lớn khoảng 30–40% về performance, best practice và accessibility.

Điều này đặt ra câu hỏi thẳng thắn: 694K dòng code có thực sự là điểm cộng? Hay đó chỉ là con số phồng to của bloat — mã thừa, khó bảo trì? So với ví dụ Andrej Karpathy viết một LLM hoạt động được trong khoảng 90 dòng Python, bức tranh trở nên rõ: ít mà tinh vẫn ấn tượng hơn nhiều mà rối.

“Tôi thà có ít code nhưng làm đúng việc, còn hơn 500.000 dòng rác” — đó là thái độ nhiều senior engineer đang nhắc lại sau câu chuyện này. Và tôi thấy họ có lý.

Tại sao “vibe coding” trông đã mắt nhưng bên trong lại tệ?

Cấu trúc tranh luận quanh G-Stack rất giống câu chuyện AI khai thuế. Nếu bạn không có chuyên môn sâu, sản phẩm AI trông sẽ rất ổn: màn hình đẹp, flow chạy, số dòng code khổng lồ, cảm giác như làm được nhiều. Nhưng khi một chuyên gia soi vào, lỗi thiết kế, performance, bảo mật, maintainability lộ ra từng mảng.

Các công cụ vibe coding như Replit hay Lovable cũng bị phê bình tương tự: giao diện web lung linh, bên dưới là hàng chục folder và JavaScript chất đống. AI chưa thể thay con người từ A đến Z với chế độ hoàn toàn rảnh tay.

Khi dùng AI sinh code cho các script nội bộ, kết quả lần đầu hiếm khi dùng thẳng được. Điều đáng giá là AI vượt qua phần nhàm chán — boilerplate — còn phần kiến trúc và review vẫn phải tự làm. Trải nghiệm thực tế là vậy, dù quảng cáo có hứa hẹn đến đâu.

Bạn cần nhớ gì?

• Số dòng code không phản ánh chất lượng; đôi khi càng nhiều càng tệ.
• AI agent có thể đẩy sản lượng code lên cao, nhưng khoảng cách với production-grade vẫn là 30–40%.
• Kỹ năng quan trọng nhất với dev không phải sinh code, mà là review, audit và giữ codebase gọn — rõ — bền.

---

MCP server đang hồi sinh và trở thành hạ tầng bắt buộc ra sao?

MCP (Model Context Protocol) là một giao thức chuẩn hoá giúp AI agent kết nối tới công cụ, dịch vụ và nguồn dữ liệu bên ngoài một cách thống nhất. Khi mới xuất hiện, MCP khá hàn lâm: chỉ vài công ty tiên phong dựng server, client thì nghèo nàn, trải nghiệm thực tế chưa đủ hấp dẫn. Nhưng đến 2026, model mạnh hơn, client tốt hơn và ngày càng nhiều dịch vụ ra server chính thức đã đưa MCP sang giai đoạn thực dụng thực sự.

Ứng dụng dễ thấy nhất là trong hệ sinh thái Apple. MCP server cho App Store Connect cho phép agent truy cập metadata app — tên, mô tả, screenshot — và thậm chí đệ trình build mới cho review. Về cơ bản, agent có thể thay bạn lo toàn bộ “paperwork” khi ship app lên App Store.

Hopper MCP server kết nối vào các ứng dụng macOS như VS Code để hỗ trợ reverse engineering — phân tích cấu trúc nội bộ của ứng dụng. BodySpec MCP server tập trung vào sức khoẻ, cho phép agent truy xuất dữ liệu DEXA scan theo thời gian để rút ra insight về mỡ, cơ và sức khoẻ tổng thể.

MCP không còn là đồ chơi cho dev. Nó đã chạm đến sức khoẻ, kinh doanh, vận hành — và đang lan ra nhanh hơn nhiều người nghĩ.

MCP hay CLI: cái nào là tương lai cho AI agent?

CLI cho phép kết hợp lệnh Bash rất linh hoạt và từ lâu là công cụ chủ lực cho automation. Nhưng khi để AI điều khiển, CLI bộc lộ hai vấn đề: khó kiểm soát phạm vi và quyền hạn, và dễ gây thiệt hại nếu AI “gõ nhầm” lệnh nguy hiểm.

MCP đi theo hướng khác. Mỗi server thể hiện một tập khả năng rõ ràng, với schema, permission và giới hạn được mô tả tường minh. Agent gọi công cụ nào, bạn thấy ngay trong log và UI.

Khi kích hoạt cùng lúc MCP của Stripe, RevenueCat và các dịch vụ khác trong một app như Codex, bạn có thể yêu cầu agent tổng hợp và so sánh doanh thu, retention, churn trong 6 tháng qua. Agent gọi mọi MCP, gom dữ liệu, phân tích — bạn quay lại sau 20–30 phút để xem báo cáo. MCP đang trở thành “API hub” chuẩn hoá cho agent, giống vai trò mà REST và GraphQL từng đóng cho web app.

Tài liệu chính thức về Model Context Protocol: https://docs.anthropic.com/en/docs/agents-and-tools/model-context-protocol

Bạn cần nhớ gì?

• MCP là giao thức chuẩn giúp agent nói chuyện với công cụ và dịch vụ ngoài một cách an toàn, có cấu trúc.
• MCP server thực sự hữu dụng đã xuất hiện trong App Store Connect, reverse engineering, sức khoẻ, thanh toán.
• Với Cursor, Codex, Claude đều hỗ trợ MCP ở mức ưu tiên cao, MCP đang trở thành hạ tầng mặc định của thời đại agent.

---

Tấn công Axios & LiteLLM nói gì về bảo mật chuỗi cung ứng phần mềm?

Tấn công chuỗi cung ứng phần mềm là kiểu tấn công chèn mã độc vào thư viện mã nguồn mở mà hàng triệu dự án đang tin dùng. Axios — thư viện HTTP client JavaScript với hơn 100 triệu lượt tải mỗi tuần trên npm — là một nạn nhân mới nhất. Axios không chỉ được dev cài trực tiếp, mà còn là phụ thuộc sâu trong vô số framework và package phổ biến.

Bản Axios bị cài mã độc chỉ tồn tại khoảng một giờ trước khi bị phát hiện. Nhưng từng đó là đủ để nhiều hệ thống CI/CD tự động tải về. Payload đã cố cài một package crypto bị làm rối mã để đánh cắp dữ liệu hệ thống. Với doanh nghiệp dùng CI/CD tự động cập nhật phụ thuộc, nguy cơ lộ API key hoặc secret là rất thật.

Gần như cùng thời điểm, LiteLLM — thư viện Python được tải hơn 3,5 triệu lần mỗi ngày, khoảng 95 triệu lượt mỗi tháng — cũng bị tấn công. Tần suất hiện tại: mỗi tháng lại có ít nhất một gói hàng chục triệu lượt tải bị xâm nhập. Đây không còn là trường hợp ngoại lệ.

Dev nên phòng thủ thế nào trước chuỗi cung ứng “bẩn”?

Một biện pháp đang được cộng đồng kỹ sư bàn nhiều là cấu hình package manager — npm, pip — để không tự động cài phiên bản phát hành dưới 7 ngày, và chỉ cập nhật tự động với package đã qua “thời gian an toàn” này.

Lý do đơn giản: đa số các cuộc tấn công chuỗi cung ứng bị phát hiện và thu hồi trong vài giờ đến vài ngày. Chỉ cần trì hoãn cập nhật, bạn đã né được phần lớn mũi tên.

Dùng AI để audit bảo mật cũng là chiến lược đáng làm ngay. Với prompt kiểu “Hãy thực hiện kiểm tra bảo mật sâu cho codebase này theo chuẩn OWASP” — bộ chuẩn an ninh ứng dụng web phổ biến, xem thêm tại https://owasp.org — agent có thể chỉ ra lỗ hổng xác thực, phụ thuộc dễ bị tấn công và chỗ có nguy cơ lộ dữ liệu.

Khi dùng AI rà soát code nội bộ theo cách này, cảm giác như có một junior security engineer miễn phí chạy qua mọi file và gợi ý những chỗ cần soi kỹ hơn. Không hoàn hảo, nhưng tốt hơn không làm gì.

Bạn cần nhớ gì?

• Tấn công chuỗi cung ứng qua Axios và LiteLLM cho thấy đây là mối đe doạ thường xuyên, không còn hiếm.
• Trì hoãn auto-update ít nhất 7 ngày giúp tránh phần lớn bản phát hành độc hại.
• Dùng AI audit bảo mật theo chuẩn OWASP là cách rẻ nhưng hiệu quả để phát hiện rủi ro trong codebase.

---

Quantum computing có đang biến ECC-256 thành bom hẹn giờ?

Quantum computing là nhánh tính toán dùng qubit thay vì bit, mở ra khả năng phá vỡ nhiều thuật toán mã hoá hiện tại nhanh hơn rất nhiều. Một nghiên cứu gần đây của đội Google đã gây chấn động cộng đồng mật mã khi cho thấy ECC-256 — chuẩn mã hoá dựa trên đường cong elliptic đang bảo vệ phần lớn blockchain và kết nối an toàn hiện nay — có thể trở nên dễ bị tấn công sớm hơn dự đoán.

ECC-256 là nền tảng bảo mật của nhiều hệ thống, trong đó có Bitcoin. Nếu thuật toán này bị phá bởi máy tính lượng tử đủ mạnh, kẻ tấn công về lý thuyết có thể giả mạo chữ ký, chiếm đoạt tài sản hoặc giải mã giao tiếp được mã hoá. Nghiên cứu của Google đẩy mốc chuyển sang mã hoá hậu lượng tử lên năm 2029 — sớm hơn nhiều ước tính trước đó.

Nick Carter, một nhà đầu tư nổi bật trong giới crypto, đã chia sẻ nghiên cứu này và nhấn mạnh: “Lý do Google cập nhật deadline 2029 cho chuyển đổi hậu lượng tử chính là đây.” Thông điệp rõ: nếu không chủ động chuyển sang thuật toán mới an toàn trước máy tính lượng tử, hạ tầng bảo mật Internet hiện tại có thể trở nên lỗi thời trong vài năm.

Có phải đã đến lúc hoảng loạn với hậu lượng tử?

Tại một meetup về AI, có người đưa ra góc nhìn thú vị: Bitcoin là “bằng chứng khổng lồ” rằng ECC đang an toàn, vì nếu đã phá được thì hẳn ai đó đã âm thầm đánh cắp lượng lớn Bitcoin từ lâu rồi. Lập luận này nhắc lại sự khác biệt giữa “khả năng lý thuyết” và “khả năng thực tế” — và đó là một điểm đáng suy nghĩ.

Nhưng lập trình viên và doanh nghiệp không thể ngồi chờ. Các chuẩn mã hoá hậu lượng tử (Post-Quantum Cryptography) đang dần được chuẩn hoá, và 2029 đang được nhiều bên coi là mốc phải bắt đầu dịch chuyển hạ tầng. Các thư viện, giao thức và tiêu chuẩn TLS sắp tới cũng sẽ phải cập nhật theo.

AI đang phá vỡ mô hình lao động tri thức. Quantum computing đe doạ nền tảng “niềm tin số” mà thế giới đang dựa vào. Hai mối đe doạ này đang xảy ra cùng lúc — và cả hai đều cần được chú ý ngay bây giờ.

Bạn cần nhớ gì?

• Quantum computing đe doạ trực tiếp ECC-256, nền tảng bảo mật của blockchain và nhiều hệ thống Internet.
• Google dự báo 2029 là thời hạn hợp lý để bắt đầu chuyển sang mã hoá an toàn trước máy tính lượng tử.
• Các công ty và dev cần chuẩn bị cho chuẩn mã hoá hậu lượng tử, không đợi đến khi có sự cố mới hành động.

---

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

Lộ trình 30 ngày là một kế hoạch ngắn hạn giúp bạn chuyển từ “nghe thời sự công nghệ” sang “thực sự hành động”. Mỗi tuần chỉ cần làm vài việc nhỏ nhưng cụ thể — bạn đã tiến khá xa so với phần lớn dev vẫn còn đứng ngoài cuộc.

Tuần 1: Làm quen với agent-first và on-device AI

Cài và thử Cursor 3 hoặc một AI IDE tương tự, tập trung dùng giao diện chat để sinh và review code. Song song đó, tải một model nhỏ tương đương Gemma 4 2B về chạy trên máy, thử tóm tắt tài liệu hoặc sinh code đơn giản.

Tuần 2: Dùng AI cho audit — từ thuế đến code

Lấy một bộ tài liệu nghiệp vụ hoặc mô phỏng khai thuế cá nhân, thử cho AI phân tích và gợi ý câu hỏi bạn nên hỏi lại chuyên gia. Chọn một repo nhỏ, yêu cầu AI audit theo chuẩn OWASP và ghi lại các vấn đề nó phát hiện.

Tuần 3: Chơi với MCP và workflow agent dài hơi

Cài một client hỗ trợ MCP như Codex hay Cursor, nối thử ít nhất 2 MCP server — Stripe sandbox, một dịch vụ nội bộ. Giao cho agent một phân tích dài như tổng hợp log doanh thu, lỗi, ticket hỗ trợ, rồi quay lại xem kết quả sau 20–30 phút.

Tuần 4: Siết bảo mật và nghĩ về hậu lượng tử

Thêm quy tắc trì hoãn 7 ngày khi auto-update dependency trong CI/CD pipeline. Đọc tài liệu giới thiệu về Post-Quantum Cryptography trên NIST hoặc tài liệu chính thức khác, đánh dấu những chỗ hệ thống của bạn sẽ phải thay đổi.

---

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

Vấn đề	Việc bạn nên làm ngay
Agent-first IDE có thực sự hữu dụng hay chỉ là trend?	Cài Cursor 3 hoặc tương đương, dành 1–2 ngày chỉ làm việc qua giao diện chat để tự đánh giá.
AI có đủ tin cậy để làm thuế, audit code, audit bảo mật?	Dùng AI làm thử trên dữ liệu không quá nhạy cảm, rồi nhờ chuyên gia trong lĩnh vực đó review chéo.
Code do AI tạo ra có “chất lượng production” không?	Thiết lập quy trình review và test bắt buộc với mọi PR do AI sinh ra, không merge nếu chưa qua bước này.
Chuỗi cung ứng phần mềm có đang là điểm yếu?	Bật cơ chế trì hoãn update dependency, và chạy AI security audit cho repo chính theo chuẩn OWASP.
Hậu lượng tử có liên quan gì tới hệ thống của tôi?	Kiểm kê các nơi đang dùng ECC-256, TLS, crypto library; lên danh sách hạng mục cần cập nhật trong 2–3 năm tới.

Thực ra, AI đang biến “biết nhiều” thành thứ mà ai cũng có thể thuê được với giá vài đô mỗi tháng. Thứ còn lại tạo ra sự khác biệt là khả năng đánh giá, hoài nghi đúng lúc và dám chịu trách nhiệm với quyết định của mình. Cho nên, dù bạn là dev, CPA, security engineer hay founder, đừng bám víu vào “mình biết nhiều hơn khách hàng”.

Quay về những gì AI khó copy: cách bạn đặt câu hỏi, cách bạn thiết kế hệ thống an toàn, cách bạn chăm sóc mối quan hệ và đứng ra chịu trách nhiệm khi mọi thứ không như mong đợi. Người thắng cuộc trong vài năm tới không phải là người dùng AI để sinh ra nhiều thứ nhất — mà là người biết cách buộc AI phải đưa ra thứ đúng nhất trong hoàn cảnh cụ thể.

---

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

Q: Agent-first IDE như Cursor 3 khác gì với việc dùng plugin AI trong VS Code?

A: Agent-first IDE coi agent là trung tâm — mọi thao tác lập trình xoay quanh việc giao task và review kết quả trong giao diện chat. Plugin AI trong VS Code chỉ thêm tính năng gợi ý hoặc sinh code, còn workflow tổng thể vẫn do con người điều khiển theo kiểu mở file rồi gõ code. Với agent-first, IDE bắt đầu giống một hệ thống quản lý công việc có thể tự thực thi hơn là công cụ soạn thảo đơn thuần.

Q: Gemma 4 nhỏ như vậy có làm được gì nghiêm túc không?

A: Gemma 4 được thiết kế nhỏ để chạy on-device nhưng vẫn đạt điểm ELO ngang nhiều model lớn trên bảng xếp hạng arena.ai. Nó phù hợp với tác vụ như tóm tắt, phân loại, sinh gợi ý, hỗ trợ app di động — chứ không nhắm tới thay thế hoàn toàn các model khổng lồ trong bài toán cực khó. Điểm mạnh là tốc độ, chi phí thấp và bảo mật dữ liệu do chạy trực tiếp trên thiết bị.

Q: Có nên dùng AI để khai thuế thật không?

A: Dùng AI để hỗ trợ khai thuế — tìm miễn giảm, giải thích quy định — rất hữu ích, nhất là khi bạn muốn hiểu bản chất vấn đề. Nhưng kết quả cuối cùng nên được người có kiến thức về thuế xem lại, đặc biệt nếu tình hình tài chính phức tạp hoặc số tiền lớn. AI hiện tại không đứng ra chịu trách nhiệm nếu có sai sót khi bị kiểm toán.

Q: Làm sao để tin code do AI sinh ra đủ an toàn để đưa lên production?

A: Tuyệt đối không bỏ qua review và test chỉ vì “AI viết”. Hãy áp dụng quy trình code review nghiêm túc, test tự động, và có thể dùng thêm một AI khác để audit theo chuẩn OWASP. Thực tế cho thấy AI rất giỏi tạo boilerplate, nhưng phần kiến trúc, hiệu năng và bảo mật vẫn cần mắt của người có kinh nghiệm.

Q: Tấn công chuỗi cung ứng như Axios, LiteLLM có ảnh hưởng đến dự án nhỏ không?

A: Có. Dự án nhỏ thường dựa nhiều vào thư viện mã nguồn mở và hay bật auto-update mà không kiểm soát chặt. Chỉ cần một bản phát hành độc hại được cài vào CI/CD là API key, secret hoặc dữ liệu nhạy cảm có thể bị rò rỉ. Dù là team nhỏ, bạn vẫn nên trì hoãn cập nhật dependency và chạy kiểm tra bảo mật định kỳ.