Chuyện chọn cách viết code, không phải chọn phe
Vấn đề không nằm ở việc bạn dùng vibe coding hay AI-assisted engineering, mà là bạn có biết mình đang dùng cái nào hay không.
Có giai đoạn tôi vibe rất nhiều. Có giai đoạn tôi gần như không cho phép mình vibe. Không phải vì một cách “đúng” hơn cách kia, mà vì bối cảnh khác nhau thì cách dùng AI cũng phải khác. Sau một thời gian quan sát chính mình và những người xung quanh, tôi nhận ra vấn đề không nằm ở việc có vibe hay không, mà nằm ở việc mình có biết khi nào nên vibe, và khi nào không.
Vibe coding, nếu nói cho công bằng, là một trải nghiệm rất thú vị. Có những lúc tôi chỉ muốn nhanh chóng kiểm tra một ý tưởng, dựng một prototype, hoặc thử xem một flow có khả thi hay không. Khi đó, vibe coding là lựa chọn hoàn hảo. Tôi mô tả ý tưởng, để AI triển khai nhanh phần xương sống, rồi nhìn tổng thể hệ thống hoạt động ra sao. Không áp lực, không cầu toàn, không cần tối ưu ngay. Mục tiêu lúc đó là tốc độ và cảm giác tiến về phía trước.
Nhưng tôi cũng rất rõ ràng với bản thân: những đoạn code vibe ra trong giai đoạn này không đại diện cho năng lực kỹ sư của tôi. Nó chỉ là bản nháp. Một bản phác thảo. Và nếu đoạn code đó bắt đầu tiến gần đến production, tôi sẽ đổi chế độ.
Đó là lúc tôi quay về với AI-assisted engineering.
Ở chế độ này, AI không còn là người “viết hộ” nữa, mà là người hỗ trợ. Tôi đã có sẵn mô hình trong đầu: dữ liệu đi thế nào, ranh giới module ở đâu, chỗ nào có rủi ro, chỗ nào cần giữ đơn giản. AI giúp tôi tiết kiệm thời gian gõ phím, gợi ý cú pháp, nhắc lại những pattern quen thuộc. Nhưng quyết định vẫn là của tôi. Nếu code có bug, tôi không hỏi “AI sai ở đâu”, mà hỏi “tôi đang hiểu sai điều gì”.
Sự khác biệt lớn nhất giữa hai cách dùng AI, với tôi, nằm ở trách nhiệm.
Khi vibe coding, tôi chấp nhận rủi ro. Tôi biết mình đang đánh đổi sự chắc chắn để lấy tốc độ. Và tôi chấp nhận việc sau này có thể phải đập đi làm lại. Nhưng khi bước sang AI-assisted engineering, tôi không còn cho phép mình “đoán mò”. Tôi phải hiểu code đủ sâu để chịu trách nhiệm cho nó – cả khi hệ thống chạy tốt lẫn khi nó gặp sự cố lúc nửa đêm.
Điều khiến tôi băn khoăn là nhiều kỹ sư mới không phân biệt được hai trạng thái này. Họ vibe trong mọi tình huống. Vibe khi thử nghiệm thì không sao, nhưng vibe cả khi code đã đi vào core logic, data pipeline, hay business-critical flow thì rủi ro bắt đầu xuất hiện. Code chạy được, test pass, nhưng không ai trong team thực sự sở hữu hiểu biết về nó. Và khi vấn đề xảy ra, phản xạ đầu tiên không phải là phân tích hệ thống, mà là… hỏi lại AI.
AI không có lỗi ở đây. Lỗi nằm ở việc người dùng không chuyển vai đúng lúc.
Cá nhân tôi tin rằng:
- Vibe coding phù hợp khi khám phá, thử nghiệm, hoặc cần momentum.
- AI-assisted engineering là bắt buộc khi xây thứ sẽ tồn tại lâu dài, cần bảo trì, cần scale, và cần con người đứng ra chịu trách nhiệm.
Vấn đề không phải là “đừng vibe”, mà là đừng nhầm vibe với năng lực. AI có thể giúp bạn đi rất nhanh, nhưng chỉ tư duy kỹ sư mới giúp bạn đi được đường dài. Nếu bạn dùng AI để tăng tốc cho những thứ bạn đã hiểu, bạn đang học rất nhanh. Nhưng nếu bạn dùng AI để thay thế việc hiểu, thì bạn chỉ đang trì hoãn cái giá phải trả.
Tôi vẫn vibe. Nhưng tôi luôn biết khi nào mình đang vibe, và tôi không bao giờ để vibe quyết định những thứ mà sau này tôi phải gánh.
Có lẽ, kỹ năng quan trọng nhất trong thời đại AI không phải là viết prompt hay, mà là biết lúc nào nên tin AI, và lúc nào phải tin chính mình.