Từ vibe coding lên hệ thống chạy thật: việc phải làm trước khi mở cho khách

Ứng dụng dựng bằng AI chạy mượt trên máy, người dùng thử khen nhanh, rồi đến lúc khách hàng thật sắp nhập dữ liệu và tiền vào thì chợt nảy ra câu hỏi: cái này có đủ vững để mở không? Vibe coding lên hệ thống chạy thật cần đi qua năm nhóm việc mà bản demo thường bỏ qua: kiểm bảo mật cho phần code AI viết, tách khoá bí mật khỏi code, dựng dữ liệu có sao lưu và khôi phục thử được, viết kiểm thử cho các luồng chính, và có cách vận hành gồm log, cảnh báo, quay lui. Bài này đi qua từng nhóm, kèm đoạn lệnh mẫu và các số liệu đã công bố về chất lượng bảo mật của code do mô hình ngôn ngữ sinh ra. Nguồn tra ngày 05/10/2026.

Vibe coding là gì và khoảng cách từ bản chạy được tới bản chạy thật

Andrej Karpathy đặt tên cho cách làm này vào tháng 02/2025. Theo trang tổng hợp trên Wikipedia, bài đăng gốc mô tả việc “hoàn toàn thả theo cảm giác, đón nhận cấp số nhân, và quên rằng code tồn tại”. Người làm mô tả bằng lời cái mình muốn, AI viết code, người làm chạy thử và dán lỗi ngược lại cho AI sửa. Cách này cho ra bản chạy được rất nhanh, và chính tốc độ đó làm mất một thứ: không ai đọc kỹ code đã sinh ra.

Một bản demo chỉ cần chạy đúng trong ba phút trình diễn. Hệ thống thật phải chạy đúng khi người dùng nhập dữ liệu lạ, khi hai người sửa cùng một bản ghi, khi máy chủ khởi động lại lúc nửa đêm và khi có người cố truy cập dữ liệu không phải của họ. Khoảng cách này lớn hơn người dựng demo thường nghĩ. Bảng dưới liệt kê tám khía cạnh thường khác nhau giữa hai trạng thái, và mỗi dòng là một câu hỏi cần trả lời trước khi mở cho khách. Đó là phần việc bản demo chưa làm.

Số liệu đã công bố về bảo mật của code do AI viết

Ngày 30/07/2025, Veracode công bố báo cáo bảo mật code do AI sinh ra năm 2025. Nghiên cứu cho hơn 100 mô hình ngôn ngữ làm 80 bài lập trình, trong đó mỗi bài có một cách viết an toàn và một cách viết không an toàn. Kết quả: khi được chọn, các mô hình chọn cách không an toàn trong 45% trường hợp. Con số này không nhỏ. Nó có nghĩa gần một nửa lần, mô hình viết ra đoạn code chạy được nhưng để hở.

Theo cùng báo cáo, tỉ lệ trượt kiểm tra bảo mật của Java vượt 70%, còn Python, C# và JavaScript nằm trong khoảng 38% đến 45%. Với hai lỗi phổ biến, tỉ lệ trượt là 86% cho cross-site scripting và 88% cho log injection. Nhận xét của Veracode đáng chép lại: mô hình ngày càng viết code chạy đúng hơn nhưng không tiến bộ tương ứng về bảo mật. Hai mảng đó phát triển lệch nhau, và người dùng AI phải tự bù phần thiếu.

Con số này đo trên các bài kiểm tra có chủ đích, chưa phải phép đo trên ứng dụng thực tế của một doanh nghiệp cụ thể. Điều rút ra cho người làm sản phẩm khá thực dụng: code chạy đúng chức năng chưa cho biết gì về chuyện nó có an toàn hay không, nên phần kiểm bảo mật phải được làm riêng, không dựa vào việc AI đã “viết cẩn thận”.

Bảo mật: dùng OWASP Top 10:2025 làm danh sách kiểm

OWASP công bố Top 10:2025 gồm mười nhóm rủi ro, từ A01 Broken Access Control đến A10 Mishandling of Exceptional Conditions. Với một ứng dụng web dựng bằng AI, sáu nhóm dưới đây hay lộ ra sớm nhất. Cột cuối cho cách kiểm cụ thể, đủ để một người đọc code trong buổi chiều đầu tiên.

Nhóm A01 đáng làm trước tiên vì lỗi này gây lộ dữ liệu khách mà bản demo không bao giờ bộc lộ. Một bài kiểm thử tự động rất ngắn là đủ để bắt nó. Lỗi này rất hay gặp. Ví dụ minh hoạ viết theo kiểu pytest:

def test_khach_khong_xem_duoc_don_cua_nguoi_khac(client, khach_a, don_cua_b):
    r = client.get(f"/api/don-hang/{don_cua_b.id}", headers=khach_a.auth)
    assert r.status_code in (403, 404)

Khi cần kiểm sâu hơn một danh sách mười nhóm rủi ro, OWASP có ASVS, bộ yêu cầu kiểm chứng bảo mật ứng dụng web, phiên bản mới nhất ghi trên trang dự án là 5.0.0. MONA đã tổng hợp cách dùng hai tài liệu này trước nghiệm thu phần mềm trong bài chín cửa kiểm tra bảo mật.

Khoá bí mật nằm trong biến môi trường, không nằm trong code

AI hay viết sẵn khoá API vào thẳng tệp code để ví dụ chạy được ngay, và người làm demo hay giữ nguyên. Nguyên tắc của twelve-factor app là lưu cấu hình trong biến môi trường, kèm một phép thử dễ nhớ: nếu mã nguồn bị công khai ngay hôm nay thì có lộ thông tin xác thực nào không. Nếu có, khoá đó phải chuyển ra ngoài, và vì khoá đã nằm trong lịch sử git thì phải tạo khoá mới thay thế, xoá khoá cũ chưa đủ.

# .gitignore
.env
.env.*

# .env (không đưa lên git, mỗi môi trường một bản)
DATABASE_URL=postgres://ung_dung:***@db.noi-bo:5432/ban_hang
THANH_TOAN_API_KEY=***

Hai khoá riêng cho môi trường thử và môi trường thật cũng quan trọng không kém. Khi dùng chung một khoá, một lần chạy kiểm thử có thể ghi đè dữ liệu của khách thật. Khoá đã lộ thì phải đổi. Việc tách khoá ngay từ đầu rẻ hơn nhiều so với sửa sau một sự cố.

Dữ liệu: cơ sở dữ liệu riêng, thay đổi có phiên bản, sao lưu phải khôi phục thử được

Ứng dụng thật cần một cơ sở dữ liệu tách hẳn khỏi môi trường thử, với tài khoản ứng dụng chỉ có quyền tối thiểu (đọc ghi trên các bảng của nó, không có quyền xoá bảng hay tạo người dùng khác). Mọi thay đổi cấu trúc bảng đi qua tệp migration có số phiên bản, để máy chủ mới dựng lên có cấu trúc giống hệt máy cũ. Phiên bản phần mềm nền cũng cần kiểm lịch hỗ trợ: bài lịch vá bảo mật của 11 công nghệ MONA tổng hợp cho thấy tính đến ngày 05/10/2026, PostgreSQL 14 hết hỗ trợ ngày 12/11/2026, PHP 8.2 hết ngày 31/12/2026 và Node.js 22 hết ngày 30/04/2027. Một mẫu code AI viết theo ví dụ cũ rất dễ kéo theo phiên bản sắp hết hạn.

Sao lưu chưa có giá trị cho tới khi đã khôi phục thử thành công. Với PostgreSQL, một vòng kiểm tra tối thiểu gồm hai lệnh: tạo bản sao lưu, rồi dựng một cơ sở dữ liệu trống và nạp bản sao lưu đó vào.

pg_dump --format=custom --file=sao-luu-$(date +%F).dump "$DATABASE_URL"
createdb kiem_tra_khoi_phuc
pg_restore --dbname=kiem_tra_khoi_phuc sao-luu-$(date +%F).dump

Lịch chạy và nơi lưu bản sao lưu phải nằm ở chỗ khác với máy chủ chứa dữ liệu gốc. Nếu không, một sự cố ổ đĩa mất cả hai cùng lúc. Nếu ứng dụng lưu dữ liệu cá nhân của khách, bài CRM xử lý dữ liệu khách hàng đúng luật của MONA tổng hợp các nghĩa vụ theo Luật Bảo vệ dữ liệu cá nhân 2025 và Nghị định 356, có hiệu lực từ 01/01/2026.

Kiểm thử các luồng chính, và thử phá để biết kiểm thử có tác dụng

Không cần kiểm thử mọi dòng code. Chọn năm luồng mà hỏng thì mất tiền hoặc mất uy tín: đăng ký và đăng nhập, phân quyền xem dữ liệu, tạo và sửa bản ghi chính, thanh toán và xác nhận thanh toán, gửi email giao dịch. AI viết kiểm thử rất nhanh, nên phần việc của người làm là kiểm tra kiểm thử đó có bắt được lỗi hay không.

Cách thử đơn giản: cố ý sửa sai code ở chỗ được kiểm, chẳng hạn bỏ dòng kiểm quyền, rồi chạy lại bộ kiểm thử. Nếu nó vẫn báo đạt thì đó là kiểm thử trang trí. Cần viết lại. Sau mỗi lần triển khai nên chạy thêm một kiểm tra khói (smoke test) gồm vài request vào các trang và API chính, để biết bản mới lên máy chủ thật còn sống hay không. Cách làm này chỉ cần vài lệnh. Luồng thanh toán có thêm điểm cần chú ý về xác thực chữ ký của thông báo gửi về, bài webhook thanh toán mô tả cách kiểm.

Vận hành: môi trường thử, triển khai quay lui được, log và cảnh báo

Hệ thống chạy thật cần ít nhất hai môi trường, một để thử bản mới và một phục vụ khách. Triển khai đi theo quy trình lặp lại được, và bản trước vẫn còn đó để quay lui trong vài phút nếu bản mới lỗi. Người trực cũng cần biết bản nào đang chạy và lỗi bắt đầu từ lúc nào. Bảng dưới là mức vận hành tối thiểu.

Khâu hạ tầng có nhiều cách làm. MONA Cloud cho phép đưa ứng dụng lên chạy từ Claude Code hoặc Codex bằng một dòng lệnh, thanh toán bằng VND có VAT. MONA Base bản beta cung cấp Postgres 17, Auth, Storage, Realtime và pgvector trên hạ tầng Việt Nam. Ứng dụng cần gửi OTP hoặc email xác nhận đơn có thể dùng MONA Mail qua một API, còn nhu cầu máy chủ riêng hoặc tên miền thì có MONA Host.

Danh sách kiểm trước khi mở ứng dụng cho khách thật

1. Đã đọc code đăng nhập, phân quyền, thanh toán và xử lý tệp tải lên, không chỉ chạy thử.
2. Có bài kiểm thử tự động bắt lỗi truy cập dữ liệu của người khác (nhóm A01).
3. Không còn khoá bí mật trong code hay lịch sử git; khoá thử và khoá thật tách riêng.
4. Mọi truy vấn dùng tham số, không ghép chuỗi.
5. Chế độ debug tắt, CORS giới hạn đúng tên miền, cơ sở dữ liệu không mở ra internet.
6. Danh sách thư viện đã khoá phiên bản và quét lỗ hổng.
7. Cơ sở dữ liệu riêng cho môi trường thật, tài khoản ứng dụng quyền tối thiểu.
8. Sao lưu chạy theo lịch và đã khôi phục thử ít nhất một lần.
9. Triển khai quay lui được; có log và cảnh báo khi ứng dụng ngừng phản hồi.
10. Nếu thu tiền hoặc giữ dữ liệu cá nhân, đã có người ngoài nhóm dựng app rà lại phần đó.

Khi nào tự làm tiếp được, khi nào cần đội kỹ thuật rà soát

Ứng dụng nội bộ cho vài người dùng, không chứa dữ liệu cá nhân của khách và không thu tiền thì doanh nghiệp tự đi hết danh sách trên được, không cần thuê ai. Khi ứng dụng bắt đầu nhận tiền, lưu thông tin cá nhân của nhiều khách, kết nối API ngân hàng hay chạy cho nhiều chi nhánh, mức rủi ro đổi hẳn. Khi đó nên có một lượt rà soát độc lập trước khi mở.

MONA nhận hai kiểu việc ở giai đoạn này. Một là rà soát và kiểm tra bảo mật cho ứng dụng đã dựng, theo OWASP, trước khi nghiệm thu. Hai là viết lại phần lõi cần độ tin cậy cao (đăng nhập, phân quyền, thanh toán, dữ liệu) thành web app hoặc ứng dụng di động theo yêu cầu, giữ nguyên phần giao diện đã được khách thử. Phần vận hành và IT dùng chung nằm ở trang dịch vụ IT, còn toàn bộ khả năng viết phần mềm nằm ở trang viết phần mềm cho doanh nghiệp. Gọi hotline 1900 636 648, gửi mô tả ứng dụng đang chạy kèm số người dùng dự kiến, MONA cho biết nhóm việc nào cần làm trước.

Hỏi đáp

Vibe coding có dùng được cho phần mềm doanh nghiệp không?

Dùng được để dựng nhanh bản đầu, thử ý tưởng và làm công cụ nội bộ nhỏ. Cách làm này chỉ dừng lại ở bản demo khi người dùng thật bắt đầu nhập dữ liệu thật, từ lúc đó phần code AI viết cần được đọc, kiểm thử và kiểm bảo mật như code do người viết.

Làm sao biết code AI viết có lỗ hổng bảo mật?

Bắt đầu bằng nhóm A01 và A05 của OWASP vì lỗi ở hai nhóm này dễ tìm nhất: thử truy cập dữ liệu của tài khoản khác và tìm chỗ ghép chuỗi vào câu truy vấn. Công cụ quét lỗ hổng phụ thuộc và quét code tĩnh bổ sung thêm phần máy tự kiểm, nhưng không thay được bước đọc những đoạn nhạy cảm bằng mắt người.

Có thể nhờ chính AI kiểm bảo mật cho code nó vừa viết không?

Nhờ được, và nên làm như một lượt rà đầu tiên. Dữ liệu Veracode cho thấy mô hình chọn cách không an toàn trong 45% trường hợp, nên kết quả rà của AI phải được đối chiếu với danh sách OWASP và kiểm thử thật, không dùng thay cho chúng.

Sao lưu cơ sở dữ liệu bao lâu một lần là đủ?

Tần suất tuỳ lượng dữ liệu mới phát sinh mỗi ngày và mức mất mát chấp nhận được: ứng dụng nhận đơn hàng liên tục cần sao lưu thường xuyên hơn công cụ nội bộ ít thay đổi. Câu hỏi đầu tiên cần trả lời là doanh nghiệp chịu mất tối đa bao nhiêu giờ dữ liệu, rồi đặt lịch theo đó và khôi phục thử mỗi lần đổi cách sao lưu.

Ứng dụng dựng bằng AI nên chạy ở đâu?

Chạy ở nơi có môi trường thử tách khỏi môi trường thật, có sao lưu và log, thanh toán được theo cách doanh nghiệp quen. Với doanh nghiệp Việt, hạ tầng đặt trong nước giúp giảm độ trễ và thanh toán bằng VND, các lựa chọn của MONA nêu ở mục vận hành phía trên.

Đọc thêm

• AI Agent là gì và doanh nghiệp nên giao việc nào cho AI Agent
• MCP server là gì và cách cho AI Agent dùng phần mềm nội bộ an toàn