Mình là PM trong một công ty startup nhỏ. Đội dev thì luôn kín lịch với sản phẩm chính, mà mình thì có cả đống ý tưởng muốn thử - từ chuyển đổi blog công ty sang kiến trúc mới, đến tạo hệ thống để đồng nghiệp tự viết bài mà không cần biết kỹ thuật.
Nên mình tự build bằng vibe coding.
Nói đơn giản, vibe coding là mình mô tả thứ mình muốn bằng ngôn ngữ tự nhiên > AI viết code > mình xem kết quả rồi điều chỉnh. Công cụ mình dùng là Claude Code - một AI chạy ngay trong terminal, có thể đọc code của dự án, viết file mới, chạy lệnh, và deploy. Mình chỉ cần nói "chuyển blog từ lưu trữ file sang database" và nó tự lên kế hoạch > viết code > chạy thử.
Tuần trước, blog công ty mình đã tích lũy được 118 bài viết thuộc 13 danh mục sau hơn nhiều năm hoạt động. Mình cần chuyển toàn bộ từ cách lưu trữ cũ sang database mới - tương đương việc dọn 118 cuốn sách từ kệ cũ sang tủ mới có đánh index, phân loại, tìm kiếm được. Với Claude Code, mình làm xong trong 4 giờ. Thuê người làm thì ít nhất cả tuần.
Rồi mình setup thêm một headless CMS (Keystatic) để đồng nghiệp không biết kỹ thuật có thể tự viết blog - thay vì bắt họ commit file markdown trực tiếp. Sau vài lượt prompt với AI, mọi thứ có vẻ rất hợp lý..nhưng nó không hoạt động. Cùng một lỗi mà lặp đi lặp lại cả chục lần. Mình sửa theo gợi ý của AI - đổi URL > tạo lại secret > kiểm tra biến môi trường - nhưng vẫn gặp lỗi tương tự.
Mất gần cả nửa ngày sau thì mình mới phát hiện ra: AI đã hướng dẫn mình tạo sai loại ứng dụng ngay từ bước đầu tiên.
Chuyện gì đã xảy ra
Keystatic cần kết nối với GitHub qua OAuth để đồng nghiệp có thể đăng nhập và chỉnh sửa nội dung. Để làm được, mình cần tạo một "ứng dụng" trên GitHub cấp quyền truy cập cho Keystatic.
Nghe có vẻ đơn giản, nhưng vấn đề ở đây là GitHub có hai loại ứng dụng, tên gần giống nhau, nằm cạnh nhau trong cùng trang Developer settings:
- OAuth Apps - chỉ cấp access token (chìa khóa tạm), hết hạn là phải đăng nhập lại
- GitHub Apps - cấp cả access token lẫn refresh token (chìa khóa gia hạn), tự động gia hạn phiên làm việc
Keystatic bắt buộc cần refresh token. AI hướng dẫn mình tạo OAuth Apps - loại không có refresh token.
Mọi cấu hình trông có vẻ đúng - có Client ID, có Client Secret, callback URL chính xác. Nhưng Keystatic luôn báo lỗi xác thực vì không nhận được refresh token.
Mình mất nửa ngày xoay quanh các chi tiết - đổi callback URL > tạo lại Client Secret > kiểm tra biến môi trường trên server - trong khi vấn đề nằm ở bước đầu tiên: sai loại ứng dụng.
Cuối cùng, mình yêu cầu AI hướng dẫn lại từ đầu, kiểm tra từng bước một. Lúc đó nó mới nhận ra - và mình mới biết - rằng mình đang dùng OAuth Apps thay vì GitHub Apps.
Đây không phải lỗi duy nhất
Nhìn lại cả tuần build, mình thấy ít nhất 3 lần AI đưa ra gợi ý sai hoặc thiếu sót:
Lần 1: Mình cần đồng nghiệp không biết kỹ thuật có thể tự viết blog. AI đề xuất dựng thêm Payload CMS - một ứng dụng web riêng biệt chỉ để quản lý nội dung. Nghe thì có vẻ hợp lý, nhưng thực ra có cách nhẹ hơn nhiều: thêm Keystatic - headless CMS tích hợp ngay trong repo hiện tại, không cần hosting riêng. Mình phát hiện được vì mình hiểu nhu cầu đội nhóm tốt hơn AI - đồng nghiệp chỉ cần viết và đăng bài, không cần một hệ thống quản lý nội dung full-featured.
Lần 2: AI lên kế hoạch tự động hóa việc đăng bài bằng cách gọi seed script mỗi khi có bài mới, nhưng không đề cập đến rủi ro khi chạy. Seed script đó hoạt động kiểu: mỗi lần chạy, nó xóa sạch toàn bộ các bài viết đang có rồi chèn lại từ đầu - kiểu truncate rồi re-insert. Đồng nghĩa mỗi lần đồng nghiệp bấm "Đăng bài", website sẽ mất toàn bộ nội dung trong 3-5 giây - ai vào đúng lúc đó sẽ thấy blog trống không. Mình phát hiện được vì mình hỏi: "Nó thay thế toàn bộ, hay chỉ thêm bài mới?"
Lần 3: Sai loại ứng dụng GitHub - câu chuyện ở trên. Mình không phát hiện được cho đến khi quay lại kiểm tra từ bước đầu.
Tại sao lần thứ 3 mình không phát hiện được?
Vì ở lần 1 và 2, mình có bối cảnh.
Lần 1, mình hiểu rõ đội nhóm cần gì. Khi AI đề xuất Payload CMS, mình có đủ hiểu biết về workflow để hỏi "có cách nào nhẹ hơn không?"
Lần 2, mình hiểu một phần cách hệ thống vận hành. Mình không tự nhận ra seed script có vấn đề, nhưng khi AI mô tả quy trình, mình biết hỏi đúng câu: "Nó thay thế toàn bộ hay chỉ thêm mới?"
Lần 3, mình không biết gì. Mình không biết GitHub có 2 loại ứng dụng. Mình không biết refresh token là gì. Mọi hướng dẫn của AI đều trông có vẻ hợp lý vì mình không có cơ sở nào để nghi ngờ.
Mấu chốt vấn đề là: mọi gợi ý của AI đều trông tự tin như nhau, bất kể nó đang nói điều đã kiểm chứng hay đang đoán. Nó cứ hướng dẫn một cách rất tự tin, và mình đã đặt hết niềm tin vào nó..!! Khi mình không có bối cảnh, mình không có cách nào phân biệt lúc nào nên tin và lúc nào nên hỏi lại.
3 vùng khi làm việc với AI
Sau tuần đó, mình tự đúc kết ra một cách phân loại giúp mình biết lúc nào cần cảnh giác. Không phải framework từ sách hay nghiên cứu nào - hoàn toàn từ việc nhìn lại những lần mình "dính" và những lần mình "né" được.
Vùng A - Mình hiểu rõ bối cảnh. Nhu cầu đội nhóm, workflow, mục tiêu kinh doanh. Đây là nơi mình có lợi thế hơn AI. Ở vùng này, mình đủ khả năng để đặt câu hỏi sâu hơn cho AI: "Tại sao cách này mà không phải cách khác? Có giải pháp nào phù hợp hơn với bối cảnh của mình không?"
Vùng B - Mình hiểu một phần. Mình biết hệ thống có database, biết data flow tổng quan, nhưng không nắm chi tiết implementation bên trong. Ở vùng này, mình yêu cầu AI giải thích trước khi làm: "Có mấy cách? Trade-off là gì? Rủi ro của mỗi cách?"
Vùng C - Mình chưa biết gì. OAuth, token, GitHub Apps - tất cả đều mới. Đây cũng là một vùng nguy hiểm - vì mình không biết thứ mình không biết. AI nói gì cũng nghe có vẻ hợp lý. Ở vùng này, mình cần phải lý trí để chậm lại thay vì làm theo ngay.
Phần lớn thời gian lãng phí xảy ra ở vùng C. Và phần lớn giá trị mình tạo ra xảy ra ở vùng A.
4 thói quen mình rút ra
1. Hỏi "cái này là gì" trước khi hỏi "làm cái này thế nào"
Khi AI hướng dẫn làm thứ gì đó mình chưa từng nghe, mình dừng lại và hỏi 3 câu:
- "Cái này là gì? Giải thích concept cho mình hiểu trước."
- "Có mấy lựa chọn? Liệt kê hết, bao gồm ưu nhược điểm."
- "Nếu chọn sai thì hậu quả là gì?"
Nếu mình hỏi "GitHub có mấy loại ứng dụng? Khác nhau chỗ nào?" trước khi tạo, AI sẽ liệt kê cả OAuth Apps lẫn GitHub Apps, và mình thấy sự khác biệt về refresh token. 5 phút hỏi thôi mà có thể tiết kiệm được cả nửa ngày.
2. Lỗi lặp lại 2 lần thì dừng sửa chi tiết, kiểm tra lại giả định gốc
Đây là quy tắc cứng mình tự đặt ra:
- Lỗi lần 1 > sửa theo gợi ý AI. Bình thường.
- Lỗi lần 2 mà cùng vấn đề > dừng, không sửa tiếp nữa.
Thay vào đó, mình hỏi: "Liệt kê tất cả giả định đang có. Cái nào có thể sai?" Hoặc đơn giản hơn: "Hướng dẫn lại từ đầu, kiểm tra từng bước."
Tại sao 2 lần mà không phải 3? Vì lần thứ 3, 4, 5 thường cũng sửa cùng hướng sai. Càng sửa nhiều, càng xa gốc vấn đề.
3. Tách "tìm hiểu" và "xây dựng" thành 2 giai đoạn
Trước khi build bất kỳ thứ gì phức tạp, mình dành 30 phút đến 1 giờ chỉ để brainstorm với AI: concept triển khai là gì, có bao nhiêu cách làm, trade-off ra sao. Lúc này cần brainstorm thật kỹ, khoan hẳn nhảy vào triển khai luôn.
Sau giai đoạn này, mình có đủ "bản đồ" trong đầu để nhận ra khi AI đi lệch.
Mình làm đúng điều này khi chọn CMS - nghiên cứu 4 phương án trước khi quyết định. Nhưng mình bỏ qua khi setup GitHub Apps - nhảy thẳng vào làm theo hướng dẫn. Kết quả là mất gần cả nửa ngày.
4. Bắt AI tự đánh giá mức độ tự tin của câu trả lời
AI trình bày mọi thứ bằng giọng tự tin như nhau. Nhưng khi được hỏi thẳng "Bạn có chắc không hay đang suy luận?", nó thường thành thật hơn: "Mình đang suy luận dựa trên pattern chung" hoặc "Để mình kiểm tra lại."
Câu hỏi này nghe đơn giản nhưng khá là hiệu quả. Vì nếu không hỏi, AI mặc định đề xuất câu trả lời tự tin nhất - không phải câu trả lời chính xác nhất.
Không phải vibe coding là vấn đề, vấn đề là thiếu "bộ lọc"
Tenzai, một công ty chuyên kiểm tra bảo mật, đã thử nghiệm 5 công cụ vibe coding phổ biến (Claude Code, Codex, Cursor, Replit, Devin) vào tháng 12/2025. Họ cho mỗi công cụ build cùng 3 ứng dụng từ cùng yêu cầu, rồi kiểm tra kết quả. Phát hiện chính: AI giỏi tránh lỗi kinh điển - kiểu lỗi mà ai cũng biết cần tránh. Nhưng AI sai ở những chỗ đúng hay sai phụ thuộc vào ngữ cảnh cụ thể.
Câu chuyện GitHub Apps của mình là ví dụ: cả OAuth Apps lẫn GitHub Apps đều "đúng" trong trường hợp chung. Chỉ sai khi đặt vào đúng ngữ cảnh - Keystatic cần refresh token mà chỉ GitHub Apps mới cấp.
Christopher Penn - một người làm marketing chuyển sang tự build sản phẩm bằng AI - chia sẻ trên podcast Trust Insights rằng với mỗi 1 giờ vibe coding, anh cần 10-20 giờ kiểm tra và sửa lỗi. Con số này đang giảm khi AI thông minh hơn, nhưng chưa bao giờ về 0.
5 thói quen ở trên không tốn nhiều thời gian - thêm khoảng 30-60 phút mỗi task lớn. Nhưng chúng giúp mình phát hiện sai sớm, thay vì mất nửa ngày để debug theo sai hướng.
Cuối cùng thì, mình nghĩ vibe coding hay dùng AI cũng chẳng có gì không tốt cả, nhưng mà dùng nó thế nào mới là điều quan trọng. Thay vì làm theo mọi gợi ý mà không suy nghĩ, mình nên dừng lại hỏi bản thân: "Liệu mình có thực sự hiểu điều AI vừa nói không?"
Nếu câu trả lời là KHÔNG - đó là lúc mình cần chậm lại, không phải là lúc tăng tốc.