--- title: "Vibe coding làm prototype trong một ngày: khi nào nên, khi nào nguy hiểm" url: https://www.thinnd.site/tu-duy-san-pham/vibe-coding-prototype-mot-ngay/ language: vi author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "Tư duy sản phẩm" tags: ["vibe coding", "prototype", "AI", "sản phẩm", "bảo mật", "MVP"] summary: "Vibe coding, tức để AI viết code mà không đọc kỹ, phù hợp để làm prototype dùng một lần: kiểm chứng ý tưởng, demo cho người thật, công cụ cá nhân. Nó trở nên nguy hiểm khi có người dùng thật, dữ liệu cá nhân, đăng nhập hoặc thanh toán, vì lỗi dễ nằm ở phần người ta không đọc. Quy tắc: coi prototype là đồ bỏ đi, ghi rõ ngày bỏ, và chỉ đưa lên môi trường thật sau khi rà bằng danh sách kiểm bảo mật và kiểm thử." license: "Cite with the author name and the canonical URL above." --- # Vibe coding làm prototype trong một ngày: khi nào nên, khi nào nguy hiểm > Dành cho người làm sản phẩm, lập trình viên và người mới thử làm ứng dụng bằng AI. Từ kỹ thuật nào cũng có giải thích ngắn. > > Số liệu lấy từ nguồn công khai ở cuối bài, nhiều nguồn do hãng bảo mật hoặc báo chí công bố nên cần đọc thận trọng. Nhân vật "Lan" là ví dụ minh họa dựng lại cho dễ hình dung, không phải người thật. --- ## Tóm tắt nhanh - **Vibe coding** là để AI viết code và không đọc kỹ. Rất hợp để làm prototype **dùng một lần** trong một ngày. - Nó trở nên **nguy hiểm khi có người dùng thật, dữ liệu cá nhân, đăng nhập hoặc tiền**, vì lỗi thường nằm đúng ở chỗ không ai đọc. - Quy tắc ngón tay cái: **ai chịu hậu quả?** Chỉ mình bạn thì thoải mái. Người khác thì phải đọc, kiểm thử và rà bảo mật. - Kế hoạch một ngày gồm **năm chặng**: hỏi vấn đề, phác màn hình, dựng khung, thêm dữ liệu giả, cho người thật dùng thử. - Cuối ngày phải **quyết định**: bỏ, viết lại hay làm cứng. Đừng để prototype lặng lẽ thành sản phẩm. --- ## Từ khó, nói dễ | Thuật ngữ | Nói dễ hiểu | |---|---| | **Vibe coding** | Mô tả điều muốn bằng lời, để AI viết code, chạy thử, nếu hỏng thì nhờ AI sửa tiếp, không đọc kỹ code. | | **Prototype** | Bản chạy thử để kiểm chứng ý tưởng, chưa phải sản phẩm. | | **MVP** | Phiên bản đủ nhỏ để cho người dùng thật thử, nhưng đủ chắc để họ tin cậy. | | **Nợ kỹ thuật** | Phần làm vội hôm nay, sau này phải trả bằng thời gian sửa. | | **Row level security (RLS)** | Quy tắc cơ sở dữ liệu nói mỗi người chỉ đọc được dòng dữ liệu của mình. | | **Throwaway** | Bỏ đi được. Làm để học, không để giữ. | --- ## 1. Vibe coding là gì, và ranh giới ở đâu Thuật ngữ này xuất hiện từ bài đăng của Andrej Karpathy vào khoảng đầu 2/2025: để AI viết hết, thuận theo "cảm giác", và không bận tâm đến việc code ra sao. Sau đó, nhiều người dùng chữ này cho **mọi** việc lập trình có AI hỗ trợ. Simon Willison vạch một đường rõ hơn: nếu bạn **xem xét, kiểm thử và giải thích được** code, đó là lập trình có AI hỗ trợ, không phải vibe coding. Theo cách nói của ông, vibe coding hợp cho công cụ cá nhân mà chỉ bạn chịu hậu quả, và không hợp cho code người khác dùng. Mình dựa vào bài viết công khai của ông, chưa kiểm lại từng câu nguyên bản. Trong bài này, vibe coding nghĩa là **chạy mà không đọc**. Điều đó không xấu bản thân nó. Cái xấu là đem nó đến nơi cần đọc. --- ## 2. Vì sao một ngày là đủ cho prototype Giá trị của prototype không nằm ở code, mà ở **câu trả lời** mà bạn nhận được từ người thật: họ có hiểu không, họ có cần không, họ vướng ở đâu. Khi AI rút việc dựng khung từ vài tuần xuống vài giờ, bạn có thể thử **nhiều hướng** trước khi chọn một. Điều này đúng nhất khi: - Chi phí **thất bại thấp**, vì chưa có dữ liệu thật hay tiền. - Mục tiêu là **học**, không phải giao hàng. - Bạn **bỏ được** nó mà không tiếc. --- ## 3. Khi nào nên vibe coding | Tình huống | Vì sao ổn | |---|---| | Kiểm chứng ý tưởng với 5 đến 10 người | Bỏ được sau tuần thử. Mục tiêu là hiểu, không phải giữ. | | Demo cho khách hoặc đồng đội | Cần thấy và chạm vào, không cần vững. | | Công cụ cá nhân (tự động hóa việc của bạn) | Chỉ bạn chịu hậu quả. | | Thử nhiều hướng giao diện | Rẻ hơn họp tranh luận. | | Làm để học một ý tưởng mới | Xem AI làm, rồi đọc lại phần hay. | --- ## 4. Khi nào nguy hiểm | Tình huống | Vì sao nguy hiểm | |---|---| | Có đăng nhập, phân quyền | Lỗi ở phần này là lỗi để lộ dữ liệu người khác. | | Dữ liệu cá nhân hoặc nhạy cảm | Rò rỉ có hậu quả pháp lý và niềm tin. | | Thanh toán, hoàn tiền, số dư | Sai một dòng là mất tiền thật. | | Nhiều người cùng dùng, chạy lâu | Lỗi nhỏ lặp lại thành lỗi lớn, khó sửa vì không ai hiểu code. | | Tích hợp với hệ thống của công ty | Một lỗi có thể lan sang hệ thống khác. | **Một ví dụ có thật.** CVE-2025-48757 là lỗ hổng liên quan đến thiếu hoặc yếu chính sách row level security trong ứng dụng do Lovable, một công cụ tạo ứng dụng bằng AI, sinh ra. Theo bản phân tích của Superblocks, hơn 170 ứng dụng bị ảnh hưởng, có bảng dữ liệu đọc được mà không cần đăng nhập. Nhà nghiên cứu Matt Palmer báo cho Lovable ngày 21/3/2025. Số lượng này do một hãng bên thứ ba công bố, nên hãy coi là con số tham khảo và kiểm tra bản ghi CVE nếu cần. Có thể đọc điều này theo hai cách: công cụ chưa hoàn hảo, và **người dùng chưa đọc phần quyền truy cập vì nó không hiện ra khi bấm thử**. Với vibe coding, phần chạy được thì thấy, phần **ai được đọc cái gì** thì không. Ngoài ra, một khảo sát nhỏ của bên thứ ba (VibeWrench, 3/2026, 100 ứng dụng vibe coding) báo cáo nhiều ứng dụng thiếu bảo vệ cơ bản. Mình chưa kiểm chứng độc lập, nên không dẫn từng con số. --- ## 5. Kế hoạch một ngày, năm chặng *Ví dụ minh họa, nhân vật dựng lại.* Lan là quản lý sản phẩm, muốn thử ý tưởng "ứng dụng đặt lịch họp nhóm không cần email". Cô dành một ngày. | Giờ | Việc | Đầu ra | |---|---|---| | 8:30 đến 9:30 | **Hỏi vấn đề.** Viết ba câu: ai gặp vấn đề, họ đang làm gì, thế nào là thành công. | Trang giấy một mặt | | 9:30 đến 11:00 | **Phác màn hình.** Vẽ tay ba màn hình, mô tả cho AI. | Ba ảnh phác | | 11:00 đến 13:00 | **Dựng khung.** Nhờ AI dựng màn hình chính, dữ liệu giả. | Bản chạy được trên máy | | 14:00 đến 16:00 | **Thêm dữ liệu giả và vài ca lạ.** Danh sách trống, tên dài, lỗi mạng. | Bản đủ để cho xem | | 16:00 đến 17:30 | **Cho 3 đến 5 người dùng thử.** Ghi lại họ vướng ở đâu. | Ghi chú phản hồi | | 17:30 đến 18:00 | **Quyết định.** Bỏ, viết lại hay làm cứng. | Một dòng quyết định | Điều Lan làm đúng: **không có dữ liệu thật, không đăng nhập, không tiền**, và ghi "PROTOTYPE, bỏ ngày 15/11" ngay trên màn hình đầu. Điều cô được là câu trả lời: hai trong năm người dùng thử không hiểu chữ "nhóm", và cả năm người muốn xem lịch trên điện thoại. --- ## 6. Từ prototype tới sản phẩm: danh sách kiểm Nếu quyết định giữ, đừng thêm người dùng trước khi qua đủ các mục sau. 1. **Đăng nhập và phân quyền.** Ai đọc được dữ liệu của ai? Thử đăng nhập bằng tài khoản khác và xem. 2. **Quyền truy cập cơ sở dữ liệu.** Mỗi bảng có chính sách giới hạn dòng chưa? Thử truy cập không đăng nhập. 3. **Đầu vào.** Mọi ô nhập đều được kiểm tra chưa? 4. **Bí mật.** Khóa API, mật khẩu có nằm trong code, tệp, hay lịch sử Git không? 5. **Kiểm thử.** Có test cho đường chính và vài ca lạ không? Test có thất bại khi code sai không? 6. **Thư viện.** Mọi thư viện có thật, còn được bảo trì không? 7. **Sao lưu và khôi phục.** Có sao lưu dữ liệu và thử khôi phục chưa? 8. **Người đọc.** Có ít nhất một người đã đọc code và hiểu nó chưa? Danh sách chi tiết hơn nằm ở bài [Duyệt code do AI viết](https://www.thinnd.site/ky-thuat/duyet-code-do-ai-viet/). Nhiều nhóm chọn **viết lại phần lõi** và giữ lại giao diện cùng bài học từ prototype. Cách đó thường sạch hơn là vá từng chỗ. --- ## 7. Ba thói quen giúp vibe coding an toàn hơn - **Đặt thời hạn.** Ghi ngày bỏ prototype lên màn hình. Prototype không có ngày bỏ sẽ thành sản phẩm. - **Dùng dữ liệu giả.** Không đưa dữ liệu thật của khách vào công cụ chưa rà. - **Giữ ranh giới ngoài môi trường thật.** Prototype không kết nối đến cơ sở dữ liệu, thanh toán, hay hệ thống thật. --- ## 8. Nhìn cân bằng - **Vibe coding không phải mọi lúc đều nhanh.** Nghiên cứu của METR (7/2025) trên 16 lập trình viên giàu kinh nghiệm thấy họ chậm hơn khoảng 19% khi dùng công cụ AI đầu 2025 trong dự án quen thuộc, dù tin mình nhanh hơn. Mẫu nhỏ và công cụ đã đổi, nhưng cảm giác nhanh không phải số đo. - **"Gần đúng" là điều phiền nhất.** Khảo sát Stack Overflow 2025 ghi nhận khoảng 66% người dùng nói gặp giải pháp "gần đúng nhưng chưa đúng", và khoảng 45% nói gỡ lỗi code do AI viết mất nhiều thời gian hơn. Khi không đọc code, bạn khó biết "chưa đúng" ở đâu. - **Vòng lặp "nhờ sửa rồi lại hỏng".** Một người viết blog gọi đó là vòng lặp nhắc đi nhắc lại, mỗi lần sửa sinh thêm lỗi mới. Đó là dấu hiệu nên dừng lại và đọc code. - **Công cụ đang cải thiện.** Những giới hạn ở đây có thể thay đổi, nhưng cách nghĩ về ranh giới **ai chịu hậu quả** thì vẫn đúng. --- ## 9. Kết luận Vibe coding là cách rẻ nhất để biết ý tưởng của bạn có đáng làm hay không. Nó nguy hiểm nhất khi nó quên rằng mình chỉ là prototype. Hãy dùng nó cho thứ bỏ đi được, ghi ngày bỏ, và dùng danh sách kiểm trước khi bất kỳ ai khác phụ thuộc vào nó. Thử ngay: viết ba câu về một vấn đề của bạn, dựng một màn hình bằng AI, và tìm ba người nhìn vào đó trong cùng ngày. --- ## Nguồn tham khảo - [Simon Willison về vibe coding](https://simonwillison.net/tags/vibe-coding/) - [Superblocks: Lovable vulnerability, 170+ ứng dụng bị lộ](https://www.superblocks.com/blog/lovable-vulnerabilities) và [bản ghi CVE-2025-48757](https://cvemon.intruder.io/cves/CVE-2025-48757) - [Stack Overflow Developer Survey 2025, phần AI](https://survey.stackoverflow.co/2025/ai) - [Simon Willison về nghiên cứu năng suất của METR](https://simonwillison.net/2025/Jul/12/ai-open-source-productivity/) - Bài liên quan trong blog: [Duyệt code do AI viết](https://www.thinnd.site/ky-thuat/duyet-code-do-ai-viet/), [Vì sao không nên tin AI tuyệt đối](https://www.thinnd.site/ky-thuat/khong-nen-tin-ai-tuyet-doi/)