Stop Vibe Coding Every Damn Time!

Đừng Vibe Coding Mỗi Lần Chết Tiệt Nữa!
Bạn điều khiển công cụ hay công cụ điều khiển bạn?
Aditya Oberai
30 tháng 5, 2025

Dạo này, độ “hype” quanh vibe coding lên vô cực. Tool nào cũng hứa hẹn biến ý tưởng của bạn thành app chỉ với vài dòng chat prompt. Nhưng vào tháng 3 năm nay, tôi thấy một tweet của một dev phát hiện ra một trong số những tool đó, Lovable, đang để lộ Supabase API key của người dùng. Dù đó là một API key “có thể public”, nó lại chẳng có quyền hạn hay giới hạn gì, và dev kia có thể truy cập toàn bộ dữ liệu của app mà không cần xác thực, chỉ bằng cách xem bản build public.

Đây không phải là đổi mới. Đây là một lỗ hổng bảo mật chực chờ nổ tung.

 

 

Đó là điều xảy ra khi người ta dựa quá đà vào “vibe”. Họ xây phần mềm theo bản năng, bỏ qua nền tảng cơ bản, và tin rằng công cụ luôn biết điều đúng. Nhưng khi bạn đang ship sản phẩm xử lý dữ liệu thật, người dùng thật, và hậu quả thật, thì chỉ “vibe” thôi là không đủ.

Chào mừng đến năm 2025, nơi các công cụ sinh code bằng AI có thể đưa bạn đi được 80% chặng đường. Thế mà vẫn có quá nhiều dev mới vào nghề build phần mềm như đang đọc thơ ở một buổi open mic. Không cấu trúc, không kế hoạch, không hiểu biết. Chỉ có vibe. Đến lúc phải sửa lại trò đó rồi!

 

Vibe Coding và AI-Assisted Coding có phải là một không?

Trước tiên, nói cho rõ: Vibe coding không giống với việc dùng AI assistant.

Vibe coding là khi bạn build phần mềm mà chẳng hiểu cái gì vận hành ra sao, phó mặc hoàn toàn cho công cụ vá víu chỗ trống. Bạn quăng cho ChatGPT một prompt lơ mơ, kéo về vài khối code sinh ngẫu nhiên, nối vài cái nút, rồi cầu Trời cho nó chạy. Bạn ship mà không test. Bạn copy code mà bạn không hiểu. Bạn build bằng vibes, không phải bằng logic.

Còn AI-assisted coding thì ngược lại — có chủ ý. Bạn vẫn lên kế hoạch cho tính năng. Bạn vẫn hiểu hệ thống của mình khớp với nhau thế nào. Bạn chỉ đi nhanh hơn vì có một “đồng đội AI” phụ bạn viết mấy thứ boilerplate, giải thích chỗ rối rắm, và gợi ý những thứ bạn cũng sẽ viết y như vậy.

Khác nhau nằm ở tư duy. Dev dùng AI có chủ đích vẫn là kiến trúc sư, còn vibe coder thì hy vọng căn nhà đứng vững vì ai đó đã vẽ sẵn bản thiết kế.

 

Căn bản vẫn quan trọng

Kể cả có AI, bạn vẫn phải làm dev. Nếu bạn chưa làm mấy chuyện dưới đây, thì bắt đầu luôn từ hôm nay nhé!

#1: Học xem mình đang xây cái gì

Muốn nhảy cóc phần học trước khi build là lý do số một tạo ra đống code sinh ra cẩu thả ngoài kia. Chính xác là cách dev đánh mất quyền kiểm soát thứ mình đang làm.

Nếu bạn đang xây hệ thống xác thực, bạn không thể không biết token là gì, session hoạt động thế nào, và vì sao lưu mật khẩu dạng plaintext là ý tưởng tồi tệ. Nếu bạn gọi API, bạn phải hiểu request được cấu trúc ra sao, status code nghĩa là gì, và cách xử lý lỗi cho tử tế. Nếu bạn lưu dữ liệu, bạn nên biết khác biệt giữa cơ sở dữ liệu quan hệ và NoSQL, khi nào dùng index, và trade-off của từng quyết định về schema.

AI có thể giúp bạn viết code, nhưng nó không thể dạy bạn biết quan tâm. Phần đó là của bạn. Và trong trường hợp này, “quan tâm” cũng chính là “kiểm soát”. Mỗi quyết định bạn giao phó khi chưa hiểu chính là một quả mìn chôn sẵn (không nổ hôm nay thì cũng nổ ngày mai!).

#2: Tạm dừng và đánh giá

Trước khi mở Cursor, bắt đầu nối UI, hay quất một API, hãy dừng lại và tự hỏi:

• Mình thực sự đang cố xây cái gì?

• Mình có thể mô tả luồng lõi của tính năng này bằng lời hoặc trên giấy không?

• Có giải pháp đơn giản nào đang trốn sau phương án màu mè kia không?

Mỗi phút nghĩ trước khi build sẽ tiết kiệm cho bạn mười phút debug sau đó. Khoảng dừng đó có thể là ranh giới giữa việc ra mắt một tính năng chạy ổn và việc ship một thứ âm thầm phá hỏng dữ liệu người dùng ở production. Đôi khi, code tốt nhất là không cần code (hoặc chỉ là một cái điều kiện đặt đúng chỗ). Nhưng bạn sẽ chẳng nhận ra điều đó nếu lao vào prompt trước khi lên kế hoạch.

#3: Lập kế hoạch trước khi code

Thiết kế vẫn quan trọng — thậm chí bây giờ còn hơn xưa. Bắt đầu phác tính năng, vẽ hành trình người dùng, và viết pseudocode nếu nó giúp bạn sắp xếp logic.

Chỉ một bản kế hoạch cơ bản, vài bullet cho những gì hàm cần làm, cũng đủ dẫn AI assistant đến output tốt hơn. Nếu bạn chỉ prompt kiểu “build cho tôi tính năng upload”, kết quả sẽ trôi nổi vô phương. Nhưng nếu bạn đã lên plan: “Mình cần cho người dùng upload file PDF tối đa 10MB, lưu vào S3 bucket, và gắn tag theo user ID”, thì bạn đã có thêm chút rõ ràng (vẫn cần thêm nữa, nhưng mà bắt đầu thế là ổn).

Hãy nghĩ về cách dữ liệu chảy qua app, người dùng tương tác ra sao, và điểm nào có thể gãy. Những thói quen này biến dev junior thành dev senior. AI có thể viết snippet, nhưng không thể kiến trúc hệ thống. Việc đó vẫn là của bạn.

#4: Prompt cho ra hồn

AI không phải thánh đọc ý nghĩ. Prompt mơ hồ thì câu trả lời mơ hồ. Mà trả lời mơ hồ thì tính năng toạc.

Bạn phải cụ thể. Nêu tech stack của bạn: React với backend Express, hay Python dùng FastAPI. Xác định phạm vi: “Chỉ cho tôi handler phía server, phần frontend tôi tự nối.” Kèm ràng buộc: “Kích thước file dưới 5MB, dùng storage tương thích S3.” Nếu có gì không chạy, bạn phải tinh chỉnh prompt, chứ không phải bấm retry mù quáng. Bẻ nhỏ vấn đề. Lặp như khi làm với đồng đội bằng xương bằng thịt.

Và luôn test thứ nó đưa cho bạn. Đừng mặc định là đúng. Chạy code. Đọc output. Check edge case. Prompt càng tốt, kết quả càng tốt (và bạn học được càng nhiều). Prompting là một kỹ năng. Càng sớm coi nó là kỹ năng, bạn càng thăng tiến nhanh.

Xem công cụ là cộng tác viên, không phải nạng chống

AI không phải phép màu. Nó là một “junior” code nhanh nhưng cần chỉ dẫn. Vậy nên hãy đối xử với nó như thế. Tức là bạn:

• Review mọi thứ nó trả về

• Test như thể đó là code của một người lạ (vì đúng là vậy)

• Hỏi nó giải thích, nhưng vẫn đi đọc docs

Bạn không thể dùng những công cụ này để tránh nghĩ, chỉ có thể dùng để đi nhanh sau khi đã nghĩ xong. Vì mục tiêu không phải là ship nhanh. Mục tiêu là ship thứ không nổ tung.

AI tool sẽ còn ở đây dài dài. Và điều đó thật tuyệt. Nhưng nếu bạn là dev, đặc biệt là ở giai đoạn đầu sự nghiệp, bạn không có quyền né học. Không, nếu bạn muốn xây những thứ bền vững. Vậy nên, đừng vibe coding mỗi lần chết tiệt nào cũng lôi ra dùng. Dừng lại. Nghĩ. Prompt có chủ ý. Học liên tục.

Code cho đáng mặt code.

 

 

Link bài viết gốc: 

https://newsletter.oberai.dev/p/stop-vibe-coding-every-damn-time