Vibe Coding Thực Chất Là Gì?

Thuật ngữ "vibe coding" lan truyền nhanh chóng trong 2024-2025 vì nó đặt tên cho thứ gì đó mà nhiều nhà phát triển đã yên lặng thực hiện: mô tả những gì họ muốn bằng tiếng Anh bình thường cho một mô hình như GPT-4, Claude, hoặc một công cụ như Cursor hoặc GitHub Copilot, rồi để nó tạo ra phần lớn mã thực tế. Lập trình viên vẫn nằm trong vòng lặp, nhưng vòng lặp trông khác so với lập trình truyền thống.

Định nghĩa thực tế

Andrej Karpathy đã tạo ra cụm từ này, mô tả một quy trình làm việc nơi bạn "hoàn toàn đơn thân theo cảm giác" — bạn prompt, chấp nhận các gợi ý, chạy mã, xem cái gì bị hỏng, rồi prompt lại. Bạn không đọc từng dòng diff. Bạn điều hướng theo kết quả: ứng dụng có làm được việc đó không, test có pass không, trang có render đúng không. Kỹ năng chuyển từ viết cú pháp sang mô tả ý định rõ ràng và nhận ra khi nào kết quả sai.

Điều này khác với chỉ sử dụng autocomplete. Những gợi ý inline kiểu Copilot vẫn giả định bạn đang viết hàm của mình với một số trợ giúp hoàn thành các dòng. Vibe coding giả định mô hình viết hàm, tệp, đôi khi toàn bộ tính năng, và bạn đang xem xét và chuyển hướng thay vì tác giả từ đầu.

Một phiên làm việc thực tế trông như thế nào

Một vòng lặp vibe-coding điển hình với một công cụ như Cursor hoặc chế độ Agent của Replit diễn ra khoảng như sau:

1. Prompt: "Thêm một rate limiter vào Express API này, 100 yêu cầu mỗi 15 phút trên mỗi IP, trả về 429 với một phần thân lỗi JSON."
2. Mô hình chỉnh sửa middleware/rateLimit.js, kết nối nó vào app.js, có thể kéo vào express-rate-limit.
3. Bạn chạy npm test hoặc hit endpoint với curl trong một vòng lặp để kiểm tra 429 thực sự kích hoạt.
4. Có gì đó không ổn — limiter reset trên mỗi deploy vì nó là in-memory. Bạn nói như vậy.
5. Mô hình hoán đổi trong một Redis-backed store, thêm dependency ioredis, cập nhật tệp docker-compose.
6. Bạn test lại, nó hoạt động, bạn commit.

Không có dòng nào của middleware đó được gõ bằng tay. Nhưng sáu hoặc bảy lệnh phán đoán được thực hiện bởi một con người: limit nên là bao nhiêu, lưu trữ in-memory là sai cho production, tệp docker-compose cũng cần cập nhật.

Nó hoạt động tốt ở đâu

Vibe coding mạnh mẽ đối với công việc nặng nề boilerplate: các endpoint CRUD, xác thực biểu mẫu, test scaffolding, các tệp cấu hình, glue code giữa hai API bạn đã hiểu. Nó cũng tốt để tạo nguyên mẫu — tạo một demo hoạt động của một ý tưởng trong một giờ thay vì một ngày, sau đó quyết định xem nó có giá trị xây dựng đúng cách không.

Nó thực sự nhanh cho các nhà phát triển solo và các nhóm nhỏ vận chuyển các công cụ nội bộ hoặc MVP nơi chi phí của một lỗi thấp và tốc độ lặp lại quan trọng hơn tính tinh khiết của kiến trúc.

Nó hỏng ở đâu

Chế độ thất bại mà mọi người không nói đủ: các mô hình tạo mã chạy nhưng sai một cách tinh tế theo những cách không xuất hiện cho đến sau. Một truy vấn SQL được tạo có thể hoạt động cho happy path nhưng dễ bị injection vì việc nối chuỗi trông ổn đối với mô hình. Một kiểm tra auth được tạo có thể vượt qua các test nhưng bỏ qua kiểm tra vai trò trên một route. Nếu bạn không đọc mã, bạn sẽ không bắt được điều đó — bạn sẽ chỉ thấy các test pass và ship nó.

Điều này quan trọng hơn trong mã nhạy cảm về bảo mật hơn hầu hết bất kỳ nơi nào khác. Simon Willison và những người khác đã chỉ ra rằng các dự án vibe-coded với dữ liệu người dùng thực cần cùng mức độ xem xét nghiêm ngặt như bất kỳ mã nào khác, có thể còn hơn, vì người "viết" nó có thể không thể giải thích nó làm gì từng dòng một.

Các hệ thống phức tạp có rất nhiều trạng thái ngầm — concurrency, phân tán transactions, bất cứ thứ gì có các lỗi timing tinh tế — cũng là một fit tồi. Các mô hình có xu hướng tạo mã trông hợp lý cho những trường hợp này mà thất bại theo những cách khó debug chính xác vì không ai, con người hay mô hình, hoàn toàn mô hình hóa các trường hợp edge từ đầu.

Kỹ năng thực sự quan trọng bây giờ

Nếu bạn đang vibe coding, kỹ năng có giá trị không phải là tốc độ gõ, đó là thông số kỹ thuật. Các prompt mơ hồ được mã mơ hồ, có lỗi. Các prompt cụ thể — với tên thư viện chính xác, kỳ vọng xử lý lỗi và các trường hợp edge được gọi ra — được kết quả tốt hơn nhiều. Kỹ năng quan trọng thứ hai là đọc mã đủ nhanh để bắt được cái gì sai, có nghĩa là bạn vẫn cần hiểu ngôn ngữ và miền ngay cả khi bạn không gõ từng ký tự.

Xử lý mã do AI tạo theo cách bạn sẽ xử lý một pull request từ một nhà phát triển junior nhanh nhưng đôi khi quá tự tin: hữu ích, thường đúng, nhưng đáng giá một xem xét thực tế trước khi nó chạm production.

Bạn muốn tìm hiểu sâu hơn về viết mã với các công cụ AI mà không mất quyền kiểm soát chất lượng? Kiểm tra các phân đoạn AI và Python của Korra Studio để xem qua thực hành.