Chúng ta cần ngừng gọi mọi thứ là Vibe Coding

Tôi quay lại lập trình sau một khoảng nghỉ dài, và Lovable là nơi tôi tiếp tục. Các ứng dụng trông tuyệt vời, hoạt động ngay lần đầu nhìn, và được hoàn thiện trong vài giờ. Ban đầu, điều đó thật đáng chú ý. Nhưng nó không còn đủ khi tôi muốn biết mã đang làm gì – và tại sao. Đó là lúc cách tiếp cận của tôi bắt đầu thay đổi.

Sự khác biệt không phải về công cụ, hay lượng mã AI viết cho bạn. Nó liên quan đến hợp đồng bạn chấp nhận với sản phẩm của mình: liệu bạn có thể giải thích những gì bạn vừa phát hành ra thế giới, hay không.

Vibe coding, trong nghĩa gốc, có nghĩa là chấp nhận phần mềm do AI tạo ra mà không kiểm tra hoặc hiểu đúng những gì nằm dưới nó. Phát triển hỗ trợ AI lại khác. Mô hình vẫn có thể viết phần lớn mã, nhưng người xây dựng hệ thống vẫn chịu trách nhiệm hiểu hành vi của nó, kiểm tra các giả định và quyết định liệu nó đã sẵn sàng để phát hành hay chưa.

Đối với một thí nghiệm tạm thời không bao giờ rời khỏi máy của bạn, sự khác biệt có thể có ít hậu quả. Khi phần mềm được triển khai, được người khác sử dụng hoặc kết nối với dữ liệu thực, nó lại quan trọng đến mức đáng kể.

Cách “Vibe Coding” Mất Ý Nghĩa

Thuật ngữ “vibe coding” được đặt ra vào tháng 2 năm 2025 bởi Andrej Karpathy, đồng sáng lập OpenAI. Ví dụ của ông cố ý mang tính ngẫu hứng: một “dự án cuối tuần dùng xong bỏ” được tạo bằng cách tự động bấm “Chấp nhận tất cả”, bỏ qua các khác biệt và để mã phát triển vượt quá khả năng hiểu của chính mình.

Vài tuần sau, nhà phát triển kiêm người tạo công cụ Simon Willison nhận thấy thuật ngữ này đang được dùng theo một nghĩa rất khác: như cách gọi thay cho mọi hình thức lập trình có AI hỗ trợ, điều mà ông cho rằng làm loãng khái niệm và tạo ấn tượng sai về những gì phát triển có AI hỗ trợ một cách có trách nhiệm có thể đạt được.

Điều đáng chú ý là cuối cùng Karpathy đã đồng ý. Một năm sau, ông đưa ra một thuật ngữ khác cho cách làm việc kỷ luật hơn với tác nhân lập trình. Ông mô tả “kỹ thuật tác nhân” là quy trình trong đó nhà phát triển chỉ đạo và giám sát tác nhân thay vì chỉ chấp nhận sản phẩm chúng tạo ra. Sự phân biệt này quan trọng: phát triển chuyên nghiệp có AI hỗ trợ cần lập kế hoạch, xem xét kỹ lưỡng và chịu trách nhiệm theo cách mà vibe coding tùy hứng không có.

Ranh Giới Là Trách Nhiệm

Quy tắc của Willison đơn giản và là phép thử cho bất kỳ ai: đừng cam kết đoạn mã mà bạn không thể giải thích cho người khác. Điều đó không có nghĩa là đọc từng dòng; khi tác nhân tạo hàng trăm dòng cùng lúc, ngay cả nhà phát triển giàu kinh nghiệm cũng không còn làm vậy. Nó có nghĩa là hiểu logic cốt lõi và có thể giải thích chính xác vì sao mã hành xử như thế. Nếu làm được, việc mã do mô hình hay do bạn viết không quan trọng: đó không phải vibe coding, mà là dùng công cụ để xây dựng phần mềm.

Nghiên cứu công bố tháng 12 năm 2025 ủng hộ sự phân biệt này. Dựa trên quan sát thực địa và khảo sát định tính với nhà phát triển chuyên nghiệp, các nhà nghiên cứu thấy rằng người có kinh nghiệm vẫn giữ quyền kiểm soát thiết kế và triển khai phần mềm thay vì giao toàn bộ quá trình cho AI. Họ xem tác nhân là cộng sự, lập kế hoạch công việc cẩn thận và tiếp tục tham gia giám sát.

Vì vậy, chỉ kinh nghiệm thôi chưa giải thích được khác biệt. Vấn đề là bạn có sẵn lòng chịu trách nhiệm cho những gì AI tạo ra hay không. Mỗi nhà phát triển phải đưa ra quyết định đó lại từ đầu ở từng dự án.

Điều Gì Xảy Ra Khi Thiếu Kiểm Soát

Hệ quả của việc phát hành phần mềm mà không hiểu hoặc xác minh tính bảo mật không hề trừu tượng. Tea, ứng dụng nhằm giúp phụ nữ an toàn khi hẹn hò, đã làm lộ hàng chục nghìn ảnh giấy tờ tùy thân và hơn một triệu tin nhắn riêng tư qua hai sự cố bảo mật. Các lỗi gồm một vùng lưu trữ không được bảo vệ và một cơ sở dữ liệu riêng có thể truy cập mà không cần xác thực.

Vấn đề nền tảng tương tự — phần mềm có vẻ hoạt động nhưng logic phân quyền lại sai một cách nguy hiểm — xuất hiện trong ứng dụng xây dựng trên nền tảng Lovable: nghiên cứu bảo mật phát hiện logic phân quyền bị đảo ngược, khóa người dùng đã đăng nhập nhưng cho kẻ tấn công chưa xác thực tự do truy cập, ảnh hưởng hơn 18.000 người dùng, trong đó có sinh viên.

Đây không phải những trường hợp riêng lẻ chỉ xảy ra với dự án “tồi”. Theo Google’s 2025 DORA report, 90% nhà phát triển hiện dùng AI trong công việc, trong khi khoảng một phần ba cho biết họ ít hoặc không tin tưởng sản phẩm AI tạo ra.

Việc dùng AI nay đã phổ biến dù mức độ tin tưởng còn hạn chế. Điều đó khiến việc xem xét kỹ càng đặc biệt quan trọng khi mã được tạo xử lý xác thực, quyền hạn hoặc dữ liệu nhạy cảm.

Kiểm Soát Được Xây Dựng Theo Tầng, Không Cùng Lúc Một

Trong trường hợp của tôi, tôi không bắt đầu bằng cuộc kiểm toán bảo mật chính thức. Tôi chỉ đơn giản từ chối đi tiếp mỗi khi không thể giải thích vì sao một thứ hành xử theo cách đó — bản năng tự nhiên từ công việc phân tích. Tôi ít quan tâm đến cú pháp hơn việc kết quả có khớp nhu cầu ban đầu hay không. Khi không khớp, tôi tiếp tục đào sâu.

Quy trình của tôi trở nên có cấu trúc hơn khi dự án nghiêm túc hơn. Thay vì chỉ dựa vào lời nhắc, tôi bắt đầu chuẩn bị đặc tả trước khi tạo bất cứ thứ gì. Tôi ghi lại yêu cầu kinh doanh, ngăn xếp công nghệ và các tích hợp. Sau đó là kiểm thử đơn vị và kiểm thử Playwright cho hành trình người dùng chính.

Các kiểm tra bảo mật được bổ sung theo cách tương tự. Tôi xem xét thư viện AI chọn và thêm quét phần mềm độc hại cho tệp tải lên. Mỗi kiểm tra xuất phát từ câu hỏi điều gì có thể sai tiếp theo, thay vì làm theo danh sách kiểm soát chuẩn bị từ đầu.

Thói quen đó đã phát hiện một vấn đề trong dự án. AI đưa vào một thư viện không tương thích với phiên bản framework tôi dùng. Ứng dụng chưa hỏng hoàn toàn nên điểm không tương thích rất dễ bị bỏ qua. Nếu phát hiện muộn hơn, nguyên nhân sẽ khó xác định hơn nhiều.

So với các trường hợp Tea và Lovable, đây là vấn đề bình thường. Tôi tìm thấy sớm, sửa và tiếp tục. Đó là hình dạng thường thấy của việc rà soát trong thực tế. Phần lớn thời gian, nó ngăn vấn đề nhỏ phát triển thành vấn đề lớn.

Tôi không nghi ngờ mã chỉ vì AI tạo ra nó. Tôi cũng không tin mã chỉ vì ứng dụng chạy được. Kiểm thử và rà soát là cách tôi xác định nó có hành xử đúng như dự định hay không.

Từ Vibe Coding Đến Agentic Engineering

Việc chính Karpathy chuyển từ “vibe coding” sang “kỹ thuật tác nhân” không chỉ là thay đổi từ ngữ. “Kỹ thuật tác nhân” cho ta một tên gọi hữu ích hơn cho hướng đi của phát triển chuyên nghiệp. Nhà phát triển có thể tự viết ít dòng hơn nhưng trách nhiệm không giảm. Công việc chuyển sang xác định hệ thống phải làm gì, chỉ đạo tác nhân, kiểm thử đầu ra và quyết định điều gì đủ an toàn để phát hành.

Nguy hiểm không phải AI tạo mã nhanh chóng. Mà là việc quá trình tạo mã có thể nhanh hơn khả năng hiểu. Khi điều đó xảy ra, năng suất bề ngoài che giấu những rủi ro mà không ai đã kiểm tra kỹ lưỡng.

Một Quy Tắc Đáng Giữ

Hãy ngừng dùng “vibe coding” làm nhãn cho mọi dạng phát triển có AI hỗ trợ — điều đó làm loãng thuật ngữ và xóa đi sự khác biệt quan trọng về quyền kiểm soát. Hãy đặt một quy tắc đơn giản: đừng phát hành thứ bạn không thể giải thích. Đồng thời, xây dựng kiểm soát theo sự phát triển của dự án, từng lớp một, bổ sung kiểm tra tương ứng với rủi ro xuất hiện.

AI có thể viết phần lớn mã. Nó không thể chịu trách nhiệm phát hành nó. Điều đó vẫn thuộc về chúng ta.