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 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 là gì?
Thuật ngữ vibe coding đượ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.
Có thể chia vibe coding thành bốn cấp độ theo mức độ kiểm soát mã nguồn:
- 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ử:
- 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.
- 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.
- 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.
| Đặc điểm | Vibe coding | Agentic Engineering |
|---|---|---|
| Tư duy | Ưu tiên cảm hứng (YOLO) | Ưu tiên cấu trúc và kỷ luật |
| Kiểm soát | Chạy được là xong, không xem lại mã | AI thực thi, con người sở hữu kiến trúc |
| Trách nhiệm | Phó mặc cho AI | Con người chịu trách nhiệm chất lượng, bảo mật |
| Đánh đổi | Bỏ qua đánh đổi kỹ thuật | Cân nhắc độ trễ, hiệu suất và chi phí |
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ừ "author" (người viết) sang "architect" (kiến trúc sư).
- 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.
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:
- 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.
- 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".
- Đọ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ì.
- 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.
Các câu hỏi thường gặp
Vibe coding có thực sự chết không? Nó vẫn hữu ích để làm demo hay công cụ cá nhân. Nhưng với tư cách một phương pháp xây phần mềm chuyên nghiệp, vibe coding đã hết thời — kỷ luật kỹ thuật đã quay lại chiếm ưu thế.
Người không chuyên có nên dùng AI để viết app không? Có. Nhưng nếu không học thuật ngữ cơ bản về bảo mật và kiến trúc, bạn đang tạo ra một "quả bom hẹn giờ" về dữ liệu và tài chính.
Tôi nên học gì để không bị đào thải? Học thiết kế hệ thống (systems thinking), bảo mật, quản trị đám mây và cách đánh giá các lựa chọn kỹ thuật, thay vì chỉ học cú pháp ngôn ngữ.