Triển khai backend bằng AI: đừng để sự tự tin thay thế quy trình production

Một bài đang được anh em r/vibecoding bàn tán khá đúng tâm trạng: có người xem một dev tạo nguyên backend bằng AI tool, rồi tiến thẳng tới production với “pure confidence”. Câu đùa nghe buồn cười, nhưng nó chạm đúng một rủi ro rất thật của năm 2025: AI làm phần dựng khung quá nhanh, nên cảm giác “xong rồi” đến sớm hơn năng lực kiểm chứng của cả team.

Mình nghĩ đây không chỉ là chuyện meme. Nó là tín hiệu rằng quy trình production phải được thiết kế lại cho thời kỳ vibe coding.

AI có thể dựng nhanh, nhưng production vẫn đòi bằng chứng

Khi dùng Claude, ChatGPT, Cursor hay các agent code khác, backend có thể xuất hiện trong vài giờ: auth, CRUD, schema, endpoint, webhook, background job. Vấn đề là tốc độ sinh code không đồng nghĩa với độ hiểu hệ thống.

Một backend “chạy được trên máy mình” vẫn có thể thiếu:

• kiểm soát quyền truy cập theo từng role;
• validation đầu vào và giới hạn rate limit;
• migration rollback;
• log đủ để truy vết lỗi;
• test cho nhánh lỗi, không chỉ happy path;
• cách xử lý secret, token, webhook signature;
• cảnh báo khi latency, error rate hoặc chi phí tăng bất thường.

Điểm nguy hiểm nhất là AI thường tạo ra code trông rất hợp lý. Nếu mình chỉ đọc lướt và chạy thử vài case, rất dễ nhầm “có cấu trúc” với “đã sẵn sàng vận hành”.

Checklist tối thiểu trước khi đẩy backend AI-generated lên production

Nếu anh em đang vibe code backend, mình sẽ không cấm deploy nhanh. Nhưng trước khi mở public traffic, nên có một checklist cứng như sau.

1. Viết lại threat model trong 10 phút

Không cần tài liệu dài. Chỉ cần trả lời rõ:

• Ai có thể gọi API này?
• Endpoint nào thay đổi dữ liệu hoặc tiền?
• Dữ liệu nào không được lộ?
• Nếu user gửi payload rất lớn, rất nhiều request, hoặc dữ liệu sai kiểu thì sao?
• Nếu job chạy lại hai lần thì có gây double charge, double email, double booking không?

AI có thể giúp liệt kê rủi ro, nhưng người chịu trách nhiệm phải chọn rủi ro nào là thật với sản phẩm.

2. Bắt AI viết test phá hệ thống, không chỉ test chứng minh hệ thống đúng

Prompt hữu ích hơn “write unit tests” là:

Hãy tìm các cách API này có thể bị dùng sai, gọi sai thứ tự, thiếu quyền, payload bất thường, hoặc retry nhiều lần. Viết test cho các case đó trước.

Mục tiêu là chuyển AI từ vai trò “người xây nhanh” sang “người phản biện”. Với backend, test đáng tiền thường nằm ở permission, idempotency, boundary case và failure path.

3. Không deploy nếu chưa có migration và rollback rõ ràng

Nhiều backend vibe-coded sinh schema rất nhanh nhưng phần migration lại mơ hồ. Production không chỉ cần tạo bảng, mà cần biết:

• migration có chạy lại an toàn không;
• dữ liệu cũ được chuyển thế nào;
• rollback có làm mất dữ liệu không;
• deploy code mới và migration DB theo thứ tự nào.

Nếu chưa trả lời được, đó là bản demo, chưa phải production.

4. Thêm quan sát trước khi thêm tính năng

Một lỗi phổ biến là dùng AI để thêm feature liên tục, trong khi hệ thống chưa có mắt. Tối thiểu nên có:

• structured logs cho request quan trọng;
• error tracking;
• metric cho latency, status code, queue length;
• alert cho spike lỗi và chi phí;
• dashboard đơn giản cho luồng chính.

Backend không có observability giống như lái xe ban đêm mà tắt đèn. Có thể đi được một đoạn, nhưng khi có sự cố thì chỉ còn đoán.

Quy trình “vibe deploy” an toàn hơn

Một flow gọn cho team nhỏ:

1. AI dựng prototype.
2. Người review kiến trúc và dữ liệu nhạy cảm.
3. AI tạo test phá hệ thống.
4. Chạy lint, typecheck, test, migration dry-run.
5. Deploy staging với dữ liệu giả hoặc dữ liệu đã ẩn danh.
6. Bật logging, metric, alert.
7. Canary production cho một phần nhỏ traffic.
8. Sau 24-48 giờ ổn định mới mở rộng.

Nghe nhiều bước, nhưng phần lớn có thể template hóa. Cái cần giữ bằng tay là quyết định rủi ro nào không được phép bỏ qua.

Bài học chính

Tin tức nhỏ từ cộng đồng vibe coding lần này phản ánh một thay đổi lớn hơn: AI làm tốc độ viết code tăng mạnh, nhưng tốc độ chịu trách nhiệm production không tăng tương ứng nếu quy trình vẫn cũ.

Mình thấy cách dùng AI tốt nhất không phải là “generate xong rồi tin”. Hãy để AI tạo nhanh, rồi tiếp tục dùng chính AI để soi lỗi, viết test, tạo checklist vận hành và mô phỏng sự cố. Khi đó vibe coding không chỉ là một cú nhảy liều, mà trở thành một vòng lặp build-review-harden nhanh hơn.

Nếu backend sinh bởi AI chưa có bằng chứng vận hành, hãy gọi nó là prototype. Khi đã có test, rollback, observability và kế hoạch deploy từng bước, lúc đó mới nên gọi là production.