Tại sao vibe coding đang dần bị thay thế?

Vibe coding (lập trình theo cảm hứng) là cách dùng mô hình ngôn ngữ lớn (LLM) để xây dựng phần mềm từ mô tả ngôn ngữ tự nhiên, thay vì gõ mã nguồn thủ công.

Người viết thường phó mặc cho "vibes" (cảm nhận) của trí tuệ nhân tạo (AI): bỏ qua việc đọc kỹ mã nguồn, hoặc thiếu nền tảng kỹ thuật để thẩm định kết quả.

Nhìn từ góc độ kỹ thuật hệ thống, đây là cách tiếp cận đầy rủi ro. Sau giai đoạn bùng nổ của những bản demo bóng bẩy, thực tế khắc nghiệt đang lộ ra: sự thiếu kỷ luật tạo ra "nợ nhận thức" (cognitive debt) khổng lồ, kéo theo lỗ hổng bảo mật (security vulnerabilities) nghiêm trọng và hệ thống không thể bảo trì. Ngành đang dịch chuyển sang lối làm kỷ luật hơn: AI thực thi, còn con người làm chủ kiến trúc.

Vibe coding có những cấp độ nào?

Vibe coding chia thành bốn cấp độ theo mức độ người dùng còn kiểm soát mã nguồn — từ Loại A (vẫn đọc và hiểu từng dòng) đến Loại C (người không chuyên phó mặc hoàn toàn cho AI).

Thuật ngữ này được Andrej Karpathy đưa ra để mô tả trạng thái lập trình viên chìm hẳn vào luồng tư duy của AI, quên cả sự tồn tại của mã nguồn bên dưới. Nhưng một kỹ sư thực thụ cần phân biệt rạch ròi giữa dùng AI hiệu quả và phó mặc cho may rủi. Nếu bạn mới nghe khái niệm này, bài giải thích vibe coding đi sâu hơn vào cách nó vận hành.

Bốn cấp độ đó như sau:

• Loại A: Dùng ngôn ngữ tự nhiên nhưng vẫn đọc, hiểu và kiểm soát mã.
• Loại B: Phụ thuộc hoàn toàn vào AI, nhận mã mà không kiểm tra — "chạy được là xong".
• Loại C: Người không chuyên (non-coder) dựng ứng dụng hoàn toàn qua AI.
• Loại D: Dùng tính năng tự động hoàn thành (autocomplete) trong IDE.

Ranh giới nguy hiểm nhất nằm ở Loại B và C. Một người dùng AI không có giám sát kỹ thuật không còn là lập trình viên, mà thành người "thuê khoán" cả một đội AI không người chỉ huy. Hệ quả lộ ra đúng lúc khó nhất: khi hệ thống cần mở rộng, hoặc khi bị tấn công.

Tại sao vibe coding thất bại trong môi trường thực tế?

Khoảng cách giữa một bản demo "trông có vẻ chạy" và một hệ thống sẵn sàng vận hành (production-ready) là rất lớn. Vibe coding thất bại vì nó bỏ qua những nguyên tắc cơ bản của kỹ thuật phần mềm, để lộ ba lỗ hổng chí tử:

1. Lỗ hổng bảo mật quy mô lớn. Các tác nhân AI (AI agent) nhân bản lỗi bảo mật với tốc độ rất nhanh. Một hệ thống tự động tạo 1.000 yêu cầu kéo (pull request) mỗi tuần chỉ cần sai 1% là đã đủ đẻ ra 10 lỗ hổng nghiêm trọng mỗi tuần. Nhiều ứng dụng vibe-coded đã sập chỉ sau vài ngày vì những lỗi sơ đẳng: không xác thực API endpoint, lưu mật khẩu dạng văn bản thuần (plain-text), mở những cổng (port) không cần thiết, hoặc thiếu chứng chỉ SSL.
2. Nợ nhận thức và kiến trúc không thể bảo trì. Vibe coding thường bỏ qua khâu thiết kế. Vài tháng sau, mã nguồn thành một mớ hỗn độn mà cả người lẫn AI đều không hiểu vì sao nó tồn tại. Chi phí để hiểu, gỡ lỗi và tái cấu trúc đống "AI slop" này thường đắt hơn nhiều so với xây bài bản từ đầu.
3. Sự sụp đổ ngữ cảnh (context collapse). Khi dự án lớn dần, AI mất dấu các quyết định logic ban đầu, khiến mã mới tự mâu thuẫn với mã cũ. Nếu người viết không đọc từng dòng thay đổi (diff), hệ thống sẽ mục từ bên trong mà không ai hay.

Tốc độ tạo mã không đồng nghĩa với giá trị phần mềm. Khối lượng mã khổng lồ mà AI sinh ra chỉ là gánh nặng nếu thiếu tư duy hệ thống để quản trị nó.

Kỹ thuật tác nhân (Agentic Engineering) khác gì vibe coding?

Ngay cả Karpathy cũng đã chuyển sang khái niệm kỹ thuật tác nhân (Agentic Engineering) — một cách tiếp cận chuyên nghiệp và kỷ luật hơn.

Những công ty như TELUS (tiết kiệm 500.000 giờ), Zapier (89% nhân viên dùng AI) hay Stripe (hơn 1.000 pull request mỗi tuần) thành công không nhờ "vibe", mà nhờ dựng được quy trình quản trị (governance) và kiểm soát chặt các tác nhân AI. Một Staff Engineer hiểu rằng AI viết được mã, nhưng chỉ con người mới biết khi nào nên ưu tiên độ trễ (latency) thay vì băng thông (throughput) trong một bối cảnh kinh doanh cụ thể.

"Lập trình thuật ngữ" (Term coding) đóng vai trò gì?

Kinh nghiệm chuyên môn ngày nay không nằm ở tốc độ gõ phím, mà ở khả năng dùng thuật ngữ chuyên ngành để neo logic cho AI, chặn hiện tượng sụp đổ ngữ cảnh.

Hãy so hai yêu cầu (prompt) cùng dựng một hệ thống xác thực:

• Người nghiệp dư: "Làm cho tôi hệ thống đăng nhập bằng email hoặc Google, miễn chạy không lỗi." Kết quả: AI dễ tạo ra mã thiếu bảo mật, hở sườn cho tấn công.
• Chuyên gia (term coding): "Xây hệ thống xác thực dùng Argon2id để băm mật khẩu, triển khai OAuth 2.0, lưu session trong HTTP-only cookie, chống CSRF, XSS và giới hạn tần suất (rate limiting)."

Dùng thuật ngữ chính xác, bạn buộc AI tuân theo tiêu chuẩn công nghiệp cao nhất. Với người không chuyên, lời khuyên là áp dụng công thức 20 giờ của Josh Kaufman để nắm 90% từ vựng chuyên ngành trước khi ra lệnh cho AI. "Đầu vào rác thì đầu ra rác" — AI chỉ là đội quân cần một người chỉ huy hiểu rõ ngôn ngữ chiến trường.

Vai trò của lập trình viên thay đổi như thế nào?

Giá trị của kỹ sư hiện đại nằm ở khả năng thẩm định nhiều hơn là sản xuất. Chúng ta đang chuyển từ người gõ mã sang kiến trúc sư hệ thống (architect).

• Tư duy hệ thống. Hiểu cách các thành phần tương tác và dự báo điểm hỏng hóc.
• Thẩm định bảo mật và đánh đổi. AI viết tốt những hàm chuyển đổi dữ liệu (ORM) đơn giản, nhưng với hệ thống cực phức tạp như FIX execution report trong tài chính, nó thường thất bại vì yêu cầu độ chính xác tuyệt đối, tuân thủ giao thức nghiêm ngặt và độ trễ cực thấp.
• Thiết kế API và quản trị hạ tầng. Dựng giao diện để các module — và AI — tích hợp sạch sẽ mà không làm phình nợ kỹ thuật (technical debt).

Lập trình viên giỏi dành nhiều thời gian nghĩ về độ bền của hệ thống hơn là tốc độ hoàn thành tính năng.

Làm thế nào để áp dụng quy trình lập trình với AI hiệu quả?

Để không bị đào thải và tránh tạo ra thảm họa kỹ thuật, hãy theo một quy trình bốn bước bắt buộc:

1. Viết tài liệu thiết kế (spec) trước. Nghĩ về mô hình dữ liệu và các tình huống lỗi trước khi chạm vào AI. Spec là bản đồ giữ cho AI không đi chệch hướng.
2. Chia nhỏ tác vụ (scoped task). Thay vì "xây app", hãy yêu cầu "triển khai luồng reset mật khẩu qua email, dùng Redis với TTL 15 phút".
3. Đọc kỹ từng dòng thay đổi (diff). Đây là quy tắc bất di bất dịch. AI đổi 200 dòng thì bạn đọc đủ 200 dòng. Đừng xác nhận nếu chưa hiểu AI vừa làm gì.
4. Kiểm thử liên tục. Viết kiểm thử trước (test-driven) hoặc nhờ AI viết, nhưng chính bạn phải chạy và thẩm định kết quả.

Ba thói quen nên đổi ngay trong tuần này:

• Viết ít nhất một đoạn spec cho mỗi module.
• Kiểm tra độ an toàn của các cổng kết nối (port), SSL và cơ chế băm mật khẩu.
• Coi mã AI như mã của một lập trình viên tập sự: phải review cực kỳ khắt khe.

Điểm chính

• Vibe coding dựng prototype rất nhanh nhưng thường đẻ ra 'AI slop' — mã nguồn rác, khó bảo trì và khó vận hành trong môi trường thực tế.
• Khác biệt giữa người nghiệp dư và kỹ sư chuyên nghiệp không nằm ở công cụ, mà ở kỷ luật kiểm soát mã nguồn và quản lý rủi ro.
• 'Lập trình thuật ngữ' (term coding) là chìa khóa buộc AI tạo ra mã an toàn, chính xác, thay cho những câu lệnh mơ hồ.
• Lập trình viên đang dịch chuyển từ người gõ mã sang kiến trúc sư hệ thống (architect): thiết kế, thẩm định, cân nhắc đánh đổi.

Tài liệu tham khảo

• Is Vibe Coding Dying? — Gary Marcus
• Vibe Coding Is Dead. Here's What Replaced It. — Plain English
• Vibe Coding Is Dead (Learn This Instead) — Surendra Pandar
• Vibe Coding Is Dead — Hacker News discussion
• Why Vibe Coding Won't Destroy Software Engineering — freeCodeCamp

Bài viết được đăng lần đầu trên camnangai.com.