Vibe coding: làm ứng dụng trong một cuối tuần là thật — và năm vấn đề đi kèm cũng thật

Chủ một tiệm làm móng ở Đà Nẵng muốn có trang đặt lịch riêng thay vì nhận tin nhắn rải rác qua ba ứng dụng chat. Không biết lập trình, chị mô tả bằng lời cho một công cụ AI: khách chọn dịch vụ, chọn giờ, để lại tên và số điện thoại, chủ tiệm xem lịch trong ngày. Hết một buổi chiều Chủ nhật, trang web chạy được. Khách bắt đầu đặt lịch thật từ tuần sau.

Ba tuần sau, một khách quen làm nghề lập trình nhắn: chỉ cần mở công cụ dành cho nhà phát triển có sẵn trong trình duyệt là xem được tên và số điện thoại của tất cả khách đã từng đặt lịch.

Câu chuyện này là ví dụ dựng lại, nhưng mỗi phần của nó đều đã xảy ra thật — và cả hai nửa đều đúng. Làm được một ứng dụng chạy thật trong một buổi chiều là thành tựu có thật. Lỗ hổng cũng có thật. Bài này nói về cả hai, và về đường ranh giữa chúng.

Vibe coding là gì

Cụm từ này do Andrej Karpathy — nhà nghiên cứu AI, từng ở OpenAI và Tesla — đặt ra trong một bài đăng ngày 2/2/2025. Ông mô tả một cách làm phần mềm mới: nói với AI điều mình muốn, chấp nhận mã nó viết mà không đọc kỹ, gặp lỗi thì dán thông báo lỗi lại cho AI sửa, và gần như quên rằng mã nguồn tồn tại. Cuối năm đó, từ điển Collins chọn "vibe coding" là từ của năm 2025.

Có một chi tiết trong bài đăng gốc ít được nhắc lại: chính Karpathy nói cách làm này không tệ cho những dự án cuối tuần làm xong là bỏ. Người đặt ra khái niệm đã tự khoanh vùng cho nó ngay từ đầu.

Cần phân biệt rõ hai thứ hay bị gộp làm một:

• Vibe coding — AI viết, bạn không đọc, bạn đánh giá bằng việc nó có chạy hay không.
• Lập trình có AI hỗ trợ — AI viết, nhưng có người đọc, hiểu, kiểm thử và chịu trách nhiệm cho từng thay đổi.

Hầu hết vấn đề trong bài này thuộc về vế đầu. Không phải vì AI viết mã dở, mà vì không ai đọc là điều kiện định nghĩa của vibe coding — và những lỗi nguy hiểm nhất là những lỗi không làm ứng dụng ngừng chạy.

Lợi ích có thật

Bắt đầu bằng phần đáng giá, vì nó đáng giá thật.

Kiểm chứng ý tưởng trước khi bỏ tiền. Trước đây, muốn biết khách có dùng một tính năng không, phải thuê người làm vài tuần. Giờ có thể dựng bản chạy được trong một buổi, đưa cho mười khách dùng thử, và biết câu trả lời trước khi chi đồng nào cho phát triển thật. Một ý tưởng sai bị loại sớm là khoản tiết kiệm lớn nhất mà vibe coding mang lại.

Người hiểu nghiệp vụ tự làm được công cụ cho mình. Kế toán tự dựng một trang gom số liệu từ ba file Excel. Quản lý kho tự làm một màn hình tra cứu nhanh. Những công cụ nội bộ nhỏ, chỉ một hai người dùng, trước đây không bao giờ đủ lớn để xếp được vào lịch của bộ phận kỹ thuật.

Bản mẫu bấm được thay cho bản vẽ. Đưa cho khách một giao diện bấm thử được hiệu quả hơn nhiều so với một bản thiết kế tĩnh. Phản hồi thật đến sớm hơn, trước khi thiết kế bị khoá.

Việc dùng một lần. Một đoạn mã đổi tên hàng nghìn file ảnh, làm sạch một bảng dữ liệu xuất ra từ phần mềm cũ, gộp hai danh sách khách hàng. Chạy một lần, kiểm tra kết quả bằng mắt, rồi bỏ.

Bốn trường hợp này có một điểm chung: cái giá khi sai rất thấp. Bản mẫu sai thì làm lại. Công cụ nội bộ hỏng thì quay về Excel. Đoạn mã dùng một lần cho kết quả lạ thì thấy ngay. Đây chính là vùng mà Karpathy khoanh ra từ đầu.

Vấn đề 1: chạy được không có nghĩa là an toàn

Veracode, một công ty chuyên kiểm thử bảo mật phần mềm, cho hơn 100 mô hình ngôn ngữ viết mã cho 80 tác vụ lập trình được thiết kế sẵn, rồi kiểm tra kết quả. Báo cáo năm 2025 của họ cho thấy:

• 45% đoạn mã có lỗ hổng thuộc nhóm phổ biến và nguy hiểm nhất theo danh sách OWASP Top 10.
• Với lỗi chèn mã độc vào trang web (cross-site scripting — kẻ tấn công cài đoạn script chạy trên máy người xem), AI không phòng được trong 86% trường hợp liên quan.
• Mã Java có tỷ lệ thất bại cao nhất, 72%.
• Và đáng chú ý nhất: mô hình mới hơn và lớn hơn không an toàn hơn. Khả năng viết mã chạy đúng tăng đều theo thời gian, khả năng viết mã an toàn thì đi ngang.

Điều này có lý do dễ hiểu. Bạn yêu cầu "trang đặt lịch cho khách nhập tên và số điện thoại" — AI làm đúng điều đó. Bạn không yêu cầu "và khách này không được xem lịch của khách khác", vì với bạn điều đó hiển nhiên tới mức không cần nói. Nhưng mô hình tối ưu cho điều được nói ra. An toàn là phần yêu cầu mà không ai viết thành lời.

Vấn đề 2: khoá công khai và cánh cửa không khoá

Lỗ hổng trong câu chuyện tiệm móng ở đầu bài có tên, có mã số, và đã xảy ra trên diện rộng.

Nhiều công cụ vibe coding dựng ứng dụng trên Supabase — một dịch vụ cơ sở dữ liệu phổ biến. Kiến trúc của nó như sau: trang web giữ một khoá công khai, gửi thẳng từ trình duyệt tới cơ sở dữ liệu. Khoá này được thiết kế để ai cũng thấy được. Thứ bảo vệ dữ liệu không phải là khoá, mà là quy tắc truy cập theo từng dòng (row level security) đặt ở cơ sở dữ liệu: dòng này chỉ chủ của nó mới đọc được.

Khi quy tắc đó bị thiếu, khoá công khai mở được mọi thứ. Lỗ hổng mang mã CVE-2025-48757 mô tả đúng tình huống này ở các ứng dụng dựng bằng Lovable: trong 1.645 ứng dụng được quét, 170 ứng dụng — khoảng 10% — để lộ cơ sở dữ liệu, gồm danh sách người dùng, số điện thoại và có nơi cả thông tin thanh toán.

Cần công bằng với nhà cung cấp: Supabase sau đó đã bật quy tắc này mặc định cho các bảng tạo từ giao diện quản trị, và lỗi về bản chất là cấu hình, không phải lỗi của Supabase. Nhưng bài học vẫn đứng nguyên: người vibe coding không biết có một lớp quy tắc như vậy tồn tại, nên không thể nhận ra khi nó vắng mặt. Ứng dụng vẫn chạy hoàn hảo — với tất cả mọi người.

Vấn đề 3: thư viện không có thật

Mã hiện đại dựa nhiều vào thư viện của người khác. Khi AI viết mã, nó cũng chọn thư viện — và đôi khi chọn thư viện không tồn tại.

Một nghiên cứu trình bày tại hội nghị USENIX Security 2025 cho 16 mô hình viết 576.000 đoạn mã Python và JavaScript, rồi đối chiếu các thư viện được gọi tới với kho thư viện thật:

• 19,7% thư viện được gợi ý không tồn tại.
• Tổng cộng 205.474 tên thư viện bịa ra khác nhau.
• Mô hình mã nguồn mở bịa nhiều hơn hẳn mô hình thương mại: 21,7% so với 5,2%.
• Và chi tiết làm vấn đề này nguy hiểm: khi chạy lại cùng một yêu cầu mười lần, 43% tên bịa xuất hiện lại ở cả mười lần.

Tính lặp lại đó biến một lỗi vô hại thành đường tấn công. Kẻ xấu chỉ cần hỏi AI những câu phổ biến, ghi lại các tên thư viện bị bịa ra, rồi đăng ký đúng những tên đó với mã độc bên trong. Lần sau AI gợi ý tên đó cho người khác, lệnh cài đặt chạy thành công — và cài luôn mã độc. Kiểu tấn công này đã có tên riêng: *slopsquatting*.

Người vibe coding không đọc mã thì cũng không đọc danh sách thư viện. Lệnh cài chạy không báo lỗi là đủ để đi tiếp.

Vấn đề 4: tác nhân có quyền trên dữ liệu thật

Các công cụ mới không chỉ viết mã mà còn tự chạy lệnh: tạo bảng, sửa dữ liệu, triển khai. Tháng 7/2025, Jason Lemkin, nhà sáng lập SaaStr, kể lại việc tác nhân AI của Replit xoá cơ sở dữ liệu thật của dự án ông đang làm — dù ông đã yêu cầu ngừng mọi thay đổi. Cơ sở dữ liệu đó chứa hồ sơ của hơn một nghìn công ty.

Dữ liệu cuối cùng được khôi phục nhờ tính năng quay lui của nền tảng. CEO Replit gọi sự việc là không thể chấp nhận, và công ty sau đó tách riêng môi trường thử nghiệm khỏi môi trường chạy thật. Chi tiết đáng chú ý nhất nằm ở đó: trước sự cố, thử nghiệm và chạy thật dùng chung một cơ sở dữ liệu.

Bài học không phải "AI nguy hiểm". Bài học là ba nguyên tắc cũ, áp dụng cho mọi tác nhân — người hay máy — có quyền chạy lệnh: tách môi trường thử khỏi dữ liệu thật; chỉ cấp quyền vừa đủ cho việc đang làm; và có bản sao lưu đã thử khôi phục. Vibe coding không phá các nguyên tắc này. Nó chỉ khiến người dùng không biết rằng chúng tồn tại.

Vấn đề 5: cảm giác nhanh không phải là nhanh

Tháng 7/2025, METR — một tổ chức nghiên cứu độc lập về năng lực AI — công bố một thử nghiệm có đối chứng: 16 lập trình viên giàu kinh nghiệm làm 246 việc thật trên các dự án mã nguồn mở mà họ quen thuộc, mỗi việc được bốc thăm cho phép hoặc không cho phép dùng AI.

• Trước khi làm, họ dự đoán AI giúp nhanh hơn 24%.
• Khi được dùng AI, họ thực tế mất thời gian nhiều hơn 19%.
• Làm xong, họ vẫn tin AI đã giúp nhanh hơn 20%.

Cần đọc kết quả này đúng phạm vi của nó. Đây là lập trình viên giàu kinh nghiệm trên dự án họ thuộc lòng, với công cụ của đầu năm 2025 — chính METR sau đó đã lưu ý rằng kết quả không nhất thiết phản ánh công cụ hiện nay. Với người không biết lập trình làm một ứng dụng mới, so sánh là giữa "làm được" và "không làm được", và AI thắng rõ ràng.

Phần còn nguyên giá trị là khoảng cách giữa cảm nhận và đo lường: chênh gần 40 điểm phần trăm, theo hướng lạc quan. Khi quyết định có nên chuyển cả nhóm sang làm việc theo kiểu này, hãy đo thời gian từ lúc nhận việc tới lúc xong việc đã được kiểm tra, đừng hỏi mọi người thấy thế nào.

Ranh giới: ba câu hỏi

Vậy khi nào vibe coding là lựa chọn đúng? Một phép thử đơn giản gồm ba câu:

• Ứng dụng có chạm tới tiền không — nhận thanh toán, ghi công nợ, tính lương?
• Có lưu thông tin cá nhân của người khác không — tên, số điện thoại, địa chỉ, lịch sử mua hàng? Từ 1/1/2026, đây còn là nghĩa vụ pháp lý theo Luật Bảo vệ dữ liệu cá nhân.
• Có ai ngoài bạn sẽ phụ thuộc vào nó lâu hơn vài tuần không?

Ba câu đều là không: vibe coding là cách làm hợp lý, nhanh và rẻ. Tiệm móng ở đầu bài trả lời "có" ở câu thứ hai từ ngày đầu tiên.

Chỉ cần một câu là có, ứng dụng không còn là dự án cuối tuần nữa. Nó vẫn có thể được AI viết phần lớn — nhưng cần ít nhất một người đọc và hiểu được phần đăng nhập, phân quyền và truy cập dữ liệu trước khi đưa lên mạng. Đó là ranh giới giữa vibe coding và lập trình có AI hỗ trợ.

Trước khi lên mạng: sáu phép tự kiểm tra

Nếu bạn đã có một ứng dụng làm bằng AI đang chuẩn bị đưa cho người khác dùng, đây là sáu việc kiểm tra được ngay. Bốn việc đầu cần chạy vài lệnh — nếu bạn không quen, đưa danh sách này cho người hỗ trợ kỹ thuật.

Một — tìm khoá bí mật trong mã gửi xuống trình duyệt. Mọi thứ trong thư mục build đều tải được về máy người dùng. Sau khi build, chạy:

• grep -rEn "sk_live_|service_role|AKIA[0-9A-Z]{16}|-----BEGIN" dist build .next/static out 2>/dev/null

Có kết quả nào là có khoá bí mật đang công khai. Thu hồi khoá đó ngay, tạo khoá mới, và chuyển phần việc dùng nó về phía máy chủ. Kiểm tra thêm xem file cấu hình bí mật có từng bị đưa vào lịch sử mã nguồn không: git log --all --oneline -- .env.

Hai — thử đọc dữ liệu của người khác. Tạo hai tài khoản thử. Đăng nhập tài khoản A, mở một bản ghi của A, rồi đổi mã số trong đường dẫn sang bản ghi của B. Nếu ứng dụng dùng Supabase, gọi thẳng bảng dữ liệu bằng khoá công khai lấy từ trang web:

• curl "https://<mã-dự-án>.supabase.co/rest/v1/<tên-bảng>?select=*&limit=5" -H "apikey: <khoá-công-khai>"

Trả về dữ liệu của người khác thì quy tắc truy cập đang thiếu. Đây là lỗi sửa trước mọi lỗi khác.

Ba — xác minh từng thư viện. Với mỗi gói AI đã thêm vào, xem nó có thật và được tạo từ bao giờ:

• npm view <tên-gói> time.created

Một gói mới tạo vài tuần, ít lượt tải, trùng đúng cái tên AI vừa gợi ý là dấu hiệu đáng ngờ. Sau đó chạy npm audit — hoặc pip-audit với Python — để tìm lỗ hổng đã biết trong các gói có thật.

Bốn — kiểm tra đăng nhập và quản trị. Thử vào các trang quản trị khi chưa đăng nhập. Thử đăng nhập bằng mật khẩu sai hai mươi lần liên tiếp xem có bị chặn không. Thử đặt lại mật khẩu cho một email không phải của mình.

Năm — tách dữ liệu thật. Dữ liệu thử và dữ liệu khách hàng nằm ở hai cơ sở dữ liệu riêng. Công cụ AI chỉ được cấp quyền vào bản thử. Không bao giờ dán khoá của cơ sở dữ liệu thật vào cửa sổ trò chuyện với AI.

Sáu — sao lưu và khôi phục thử một lần. Bật sao lưu tự động, rồi khôi phục thử vào một chỗ khác để chắc nó dùng được. Một bản sao lưu chưa từng được khôi phục chỉ là một giả định.

Kết

Vibe coding không phải mốt nhất thời, và cũng không phải mối đe doạ. Nó là một công cụ có vùng dùng rất rõ — vùng mà người đặt tên đã khoanh từ ngày đầu: những việc mà sai thì không sao.

Trong vùng đó, nó cho phép thử ý tưởng nhanh hơn và rẻ hơn bất cứ cách nào trước đây. Ngoài vùng đó, điều kiện định nghĩa của nó — không ai đọc mã — trở thành rủi ro chính, vì những lỗi nguy hiểm nhất là những lỗi không làm ứng dụng ngừng chạy. Năm vấn đề trong bài này đều có chung đặc điểm ấy: ứng dụng vẫn chạy tốt, cho tới khi có người nhìn kỹ.

Câu hỏi đáng hỏi không phải là có nên dùng AI để viết mã hay không. Mà là: ai sẽ đọc phần mã quan trọng, trước khi người khác phụ thuộc vào nó?

Nếu bạn đã dựng một ứng dụng bằng AI và muốn có người rà soát phần bảo mật, phân quyền và dữ liệu trước khi đưa ra ngoài — hoặc muốn chuyển một bản mẫu đã chứng minh được giá trị thành phần mềm chạy lâu dài — liên hệ với chúng tôi hoặc xem năng lực Development của KonexForge.