Nếu Canva xuất hiện để đơn giản hóa việc thiết kế, thì vibe coding được nhắc đến như “democratization of code” – dân chủ hóa coding. Tức là không cần biết code, ai cũng có thể tạo ra sản phẩm công nghệ với điều kiện bắt buộc là biết sử dụng “ngôn ngữ tự nhiên”.
Khái niệm
Thuật ngữ “vibe coding” được Andrej Karpathy – cựu Giám đốc AI của Tesla – đề cập lần đầu trên Twitter vào đầu năm 2025. Trong một chuỗi tweet, ông chia sẻ trải nghiệm dùng ChatGPT để lập trình mà hầu như không cần viết code thủ công. Ông mô tả trải nghiệm này như một “conversation with a robot sidekick” — tức là chỉ cần nói chuyện với AI, ra lệnh, mô tả yêu cầu, và AI sẽ generate code. Từ đó, cộng đồng công nghệ nhanh chóng lan truyền và phát triển thêm ý tưởng, biến “vibe coding” thành một khái niệm mang tính phong trào — vì còn quá sớm để kết luận “kiểu” code này có thực sự tạo nên cuộc cách mạng trong làng tech hay không.
Với Py, vibe coding giúp rút ngắn toàn bộ quá trình phát triển sản phẩm (SDLC) xuống còn vài giờ — tùy vào mức độ phức tạp của sản phẩm/tính năng — đồng thời giảm lượng nhân sự trong scrum team chỉ còn một. Cụ thể hơn, chỉ cần bạn có ý tưởng, AI sẽ giúp bạn handle phần công việc của PO, QC, Developers (từ FE đến BE), và tất cả những gì bạn cần làm là… chat.
Lý tưởng là vậy.
Đến thời điểm này, vibe coding không còn là điều xa lạ — chỉ cần vài từ khóa, bạn sẽ tìm thấy hàng loạt video trên YouTube hướng dẫn chi tiết: từ kiến thức nền tảng đến trải nghiệm dựng cả một sản phẩm hoàn chỉnh bằng chính các cuộc hội thoại với AI. Cùng với đó, ngày càng có nhiều công cụ được phát triển để hỗ trợ trải nghiệm vibe code trở nên trực quan và hiệu quả hơn, bên cạnh các LLM phổ biến như GPT hay Gemini.
Theo Py tìm hiểu nhanh, một số nền tảng như lovable.dev, bolt.new hay cursor.com đang được khá nhiều bạn non-tech — như PO, Designer hay Marketer — sử dụng. Vì yêu cầu công việc hiện tại, Py chưa có cơ hội “chạm sâu” vào các công cụ này để có thêm cảm nhận thực tế. Nói cách khác, trải nghiệm vibe coding của Py vẫn còn ở mức nhập môn — phần lớn là với GPT và Claude — cũng là các tools Py sẽ dùng để minh họa ở phần tiếp theo của bài viết này.
Thực hành
Py tiếp cận với vibe coding chủ yếu vì tò mò, nên những gì Py chia sẻ dưới đây thiên về ý kiến chủ quan là chính. Cụ thể hơn, đây chỉ là vài bước gợi ý đơn giản để bạn có thể bắt đầu ngay, dù chưa từng viết dòng code nào trước đó. Vì vibe coding vẫn là một hành trình mới, nơi mỗi người tự mày mò, va chạm và đúc kết cách làm riêng của mình, nên Py vẫn chưa thấy có framework nào thực sự được công nhận rộng rãi. Dù vậy, Py có sưu tầm được một vài bài viết khá hay và đáng tham khảo — sẽ để link ở cuối bài, mong có dịp cùng bạn trao đổi thêm, biết đâu chính bạn sẽ là người tìm ra “quy trình chuẩn” đó.
1. Lên ý tưởng
Lý tưởng là hãy bắt đầu từ việc hiểu người dùng đang có pain point nào cần giải quyết, verify thêm về việc họ đang có những lựa chọn thay thế nào, và những lựa chọn đó đáp ứng được bao nhiêu phần trăm nhu cầu của họ.
Với các bạn đã quen với việc làm product, chừng đó thông tin cũng đủ để gợi ra những suy nghĩ như: “What if có một cái app/web có thể [khả năng A] và [khả năng B]…” Và đó chính là ý tưởng.
Chẳng hạn, khi đang prompting với GPT để tìm hiểu nhanh về vibe code, Py chợt nghĩ đến việc hay là làm luôn một sản phẩm nhỏ để minh họa cho bài viết. Và loại sản phẩm đơn giản nhất mà Py biết là Chrome extension — vậy cứ thử làm một cái xem sao. Use case đơn giản nhất là log thời gian burn trên một tab, có thể dùng để tracking xem bản thân dành bao nhiêu thời gian trên Google Docs để hoàn thành một blog cũng được.
2. Xác định MVP
Khi đã có một ý tưởng sơ khởi, bước tiếp theo là tưởng tượng: nếu sản phẩm này thật sự tồn tại, nó sẽ trông như thế nào? Nó có thể làm được gì?
Thông thường, với vai trò Product Owner, Py sẽ nhảy ngay vào việc vẽ wireframe để hình dung cấu trúc cơ bản. Nhưng trong thế giới vibe coding, bạn hoàn toàn có thể nhờ Claude “vẽ giùm” một giao diện UI tương đối hoàn chỉnh — chỉ cần mô tả bằng lời. Một điều Py khá thích khi làm việc với Claude là bạn có thể kiểm chứng ngay logic của từng tương tác: nếu nhấn nút này thì chuyện gì sẽ xảy ra, màn hình sẽ thay đổi như thế nào? Cứ từ tốn prompt và chỉnh sửa từng chút một, bạn sẽ dần nhìn thấy UI ưng ý.
Tuy nhiên, điều quan trọng hơn cả UI chính là cách bạn mô tả MVP — sản phẩm khả dụng tối thiểu. Hãy viết thật chi tiết, thật cụ thể về những gì bạn mong muốn sản phẩm có thể làm được. Bạn có thể thử bắt đầu với format user story (“As a user, I want to…”) hoặc khung JTBD (Jobs To Be Done). Và tất nhiên, AI cũng có thể hỗ trợ bạn trau chuốt lại phần mô tả này để rõ ràng, logic và dễ triển khai hơn.
3. Vibe Code
Khi đã có một bản thiết kế tạm gọi là ưng ý, việc tiếp theo gần như là… đưa cho AI làm phần còn lại. Tùy vào công cụ bạn chọn và độ phức tạp của sản phẩm, thời gian để có một bản chạy thử có thể chỉ mất vài giờ, vài ngày, hoặc lâu hơn.
Với case của Py, từ lúc có ý tưởng đến khi có một bản extension đơn giản hoạt động được, Py mất khoảng hơn một tiếng đồng hồ. Những đoạn đầu khá suôn sẻ — chỉ cần prompt 1–2 lượt để AI hướng dẫn bạn thực hiện những việc bắt buộc phải làm, ví dụ như tạo các file cần thiết trên máy (chắc chắn AI chưa thể làm giúp). Thật ra cũng chỉ là tạo file, copy–paste nội dung và đảm bảo file được lưu đúng định dạng. Tiếp đến là upload những file này lên Chrome (cũng theo hướng dẫn của AI), và lúc này, hành trình mới thật sự bắt đầu.
Khi sản phẩm đã “chạy được”, bạn sẽ bắt đầu nhìn thấy những thứ mình chưa nghĩ tới — hoặc đã nghĩ tới nhưng chưa đủ kỹ. Những tình huống tréo ngoe xuất hiện: dữ liệu cập nhật sai, thao tác không phản hồi… Thế là vòng lặp quay lại: bổ sung requirements, chỉnh sửa file, reload lại sản phẩm, rồi test thử. Lặp đi lặp lại như thế. Có những đoạn code chạy được rồi nhưng không đúng như mong đợi, và bạn sẽ phải giải thích với AI rằng: “Cái này là bug nhé, vì đáng lẽ khi làm A thì phải ra B, chứ không phải C.” Việc mô tả bug sao cho AI hiểu đúng và sửa đúng thật sự là “kỹ năng sinh tồn” — cụm từ Py thường dùng để nói về những gì một PO cần có để hành nghề.
Và đây là thành quả sau cùng:
Bài học
Hơn một tiếng vibe code thật sự giống như simulate lại quá trình làm PO, nhất là ở đoạn delivery. Thay vì phải mô tả yêu cầu với Dev hay QC, giờ đối tượng Py cần trao đổi là AI. Điểm khác biệt lớn nhất có lẽ nằm ở “context window” — khi làm việc với team, mọi người thường đã có nền tảng hiểu biết chung về người dùng, vấn đề, hay mục tiêu. Còn với AI thì không. Mỗi lần prompt (nên) giống như bắt đầu lại từ đầu, như thể cùng làm một task mà PIC cứ thay đổi liên tục.
Chia sẻ thêm, trong đoạn vibe code này Py cũng không dùng template prompt chuẩn nào cả. Có lẽ vì đã quen với việc “nói chuyện” với AI nên không phải lúc nào cũng cần văn mẫu. Vả lại, giữa việc viết ra một prompt hoàn hảo và cứ liên tục prompt rồi iterate thì rõ ràng vế sau khả thi hơn.
Vài “bài học” khác của Py là:
- Mô tả có chọn lọc: Nói rõ những gì cần thay đổi và những gì không cần thay đổi. AI cũng có giới hạn nhất định về “context window”, nên không phải lúc nào cũng sẽ “nhớ” toàn bộ cuộc hội thoại từ đầu đến cuối và tự xác định những gì không cần thay đổi.
- Đa dạng input: Hãy dùng thêm hình ảnh hay tài liệu tham khảo khi prompt vì mục tiêu cuối cùng là để AI thực sự hiểu cần phải làm gì.
- Rõ ràng ngay từ đầu: Hãy nói rõ bạn muốn gì trước, rồi mới giải thích thêm vì sao hoặc đưa ngữ cảnh. Càng mạch lạc, càng dễ để AI giúp đúng thứ bạn cần.
Ngoài ra, từ trải nghiệm cá nhân, Py nhận ra vibe code không thật sự dành cho tất cả mọi người. Nếu bạn chưa có nền tảng về cách “cấu tạo” của một sản phẩm công nghệ — như hiểu sơ về cấu trúc file, logic hiển thị, hoặc cách một hệ thống “nói chuyện” với nhau — thì việc hiểu và làm theo hướng dẫn của AI có thể hơi khó, nhất là khi không có nhiều thời gian để mày mò. Dù vậy, vibe code phát huy tác dụng rõ nhất trong việc làm prototype — hay nói cách khác, trình bày ý tưởng. Ở giai đoạn này, tốc độ và tính linh hoạt quan trọng hơn sự hoàn hảo. Chỉ là, khi bạn muốn biến prototype đó thành một sản phẩm có thể vận hành ổn định ở quy mô lớn, thì câu chuyện lại hoàn toàn khác. Vì các sản phẩm vibe code nhìn chung khó đảm bảo được tính scalable. Chẳng hạn, bạn có thể vibe code một app mới hoàn toàn, app có thể phục vụ 100 người dùng, nhưng khi con số tăng lên 1 triệu, kiến trúc ban đầu — vốn không được hoạch định cho lượng traffic như vậy — sẽ bắt đầu gặp vấn đề. Và đến lúc đó, việc thuê một đội dev để tối ưu lại vibe code đôi khi còn tốn kém hơn cả việc code lại từ đầu.
Thông qua bài “thực hành” này, Py cũng nhận ra rằng việc deliver một sản phẩm công nghệ giờ đây đã đơn giản hơn rất nhiều. Chỉ cần một ý tưởng đủ rõ, phần lớn công đoạn còn lại — từ thiết kế đến chạy thử — đều có thể được AI hỗ trợ ở mức khá trọn vẹn. Điều này đồng nghĩa với việc người làm sản phẩm, đặc biệt là PO, sẽ có nhiều không gian hơn cho phần quan trọng nhất: product discovery — tìm đúng vấn đề đáng để giải quyết. Bởi vì, dù sản phẩm có “hay” hay “mới” đến mấy, người dùng cũng chỉ ở lại trong chốc lát vì tò mò. Để họ thực sự gắn bó, sản phẩm phải thật sự chạm được vào điều gì đó họ cần. Và đó vẫn là phần công việc mà chỉ con người — với khả năng cảm nhận và đặt mình vào vị trí người dùng — mới có thể làm được.
Vibe Coding 101 – Replit Docs: Hướng dẫn cơ bản nhưng rất dễ hiểu, giải thích khái niệm “vibe coding” và cách bạn có thể bắt đầu tạo ra sản phẩm đầu tiên của mình.
Hoặc nếu bạn tiêu thụ nội dung dạng âm thanh và hình ảnh hiệu quả hơn thì có thể tham khảo Vibe Coding Fundamentals In 33 minutes
Còn đây là video vibe code thực tế của một designer: Vibe code with me ♡ Build an App with 0 Coding Experience (Cozy Vlog)
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply