Gần đây, khi các công ty AI đua nhau giới thiệu tính năng mới với lời hứa hẹn mang đến trải nghiệm “lười biếng” hơn cho user, Py cũng tranh thủ thử lại vibe code – một “món” mà Py highly recommend mọi PO nên thử qua ít nhất một lần. Lần trước Py mất hơn một tiếng. Lần này mất khoảng 4+ tiếng. Nhưng khoảng cách giữa hai lần đó không chỉ là thời gian.

Lên ý tưởng

Như các bước Py đã chia sẻ trong bài Vibe Coding (1), thứ tối thượng mà PO nên ưu tiên trước khi bắt tay vào build bất cứ thứ gì vẫn là: xác định vấn đề. Lần này Py chọn đối tượng quan sát là chính mình.

Context:

• Py viết blog được khoảng 2 năm, đồng nghĩa đã có một lượng content kha khá để sẵn sàng cho các bước tiếp theo trong hành trình xây dựng thương hiệu cá nhân – cụ thể hơn là cần phân phối những nội dung này lên social. Đồng thời Py cũng cần một nơi có thể dễ dàng quản lý mỗi bài đã được share trên kênh nào, với caption gì.
• Thêm nữa, Py muốn upgrade skill vibe code của bản thân theo cách toàn diện hơn – tức là tự build hoàn toàn một “product” từ A đến Z mà không cần sự hỗ trợ từ Dev. Và AI thì được gắn thêm vào, để hỗ trợ phần nào trong việc soạn thảo văn bản.

Pain point: Không đủ resource – cụ thể là thời gian, sức lực và tiền bạc – để research hoặc adapt các tools sẵn có trên thị trường.

Solution: vibe code lại một tool theo nhu cầu của chính mình.

MVP: Bằng kinh nghiệm define không-nhớ-nổi số tính năng và release hơn hai-bàn-tay products, Py xác định MVP dưới dạng một user flow đơn giản:

Bài lên WordPress → Tool tự kéo về → AI draft post LinkedIn và Facebook theo giọng Anpy → Py review → 1 click đăng.

Disclaimer: Trên thực tế hai bước xác định vấn đề và define MVP có thể chiếm của PO kha khá thời gian, và không thể thiếu cơ số các lần tự đặt giả định, chứng minh mình sai, tìm ra hướng có vẻ đúng mới, bằng số liệu, lập luận, paper, feedbacks từ users, khảo sát… Và như Py cũng chia sẻ trong nhiều bài viết, product discovery vẫn là bộ lọc rõ ràng nhất cho năng lực của người làm sản phẩm, nhất là trong bối cảnh ngày càng có nhiều công cụ AI giúp đẩy nhanh tốc độ deliver tính năng. Trong bối cảnh bài Vibe Coding (2), phần này được viết đơn giản để dành “dung lượng” cho việc Py tự build giải pháp cho mình như thế nào – chứ không phải vì phần việc này đơn giản và dễ thực hiện.

Vibe Code

Đây là happy path được ghi lại từ lúc bắt đầu cho đến khi done tool. Ngoài việc trình bày các steps, Py cũng sẽ để lại cảm nhận của bản thân như người dùng khi dùng các tools này.

1/ Planning với Claude

Theo trải nghiệm của Py thì Claude mạnh ở những tác vụ đòi hỏi tính logic cao, thế nên ở giai đoạn cần xác định trước tính năng cũng như cấu trúc của tool, Py ưu tiên chọn Claude. Cụ thể, Py bắt đầu từ việc mô tả:

1. Mình có vấn đề gì
2. Idea về giải pháp
3. Mong muốn giải pháp này sẽ trông như thế nào

Kết quả, Py nhận được:

• Toàn bộ codebase ở dạng một folder đã được nén và có thể download ngay.
• Kèm theo đó là docs hướng dẫn từng bước cho các tác vụ phải thực hiện manual – như đăng ký Vercel, GitHub, Neon, lấy Gemini API key. Py cứ theo guideline là done.

Nói chung các bước liên quan đến tạo tài khoản, lấy API key, copy credentials, điền .env.local, và cập nhật Redirect URL sau khi deploy đều phải làm tay – không có cách nào delegate cho tool. Ước tính khoảng 1-2 tiếng cho lần đầu, phần lớn thời gian nằm ở LinkedIn App và Facebook App. Phần còn lại – cài app, chạy local, debug lỗi, push GitHub, và mọi thay đổi về tính năng sau này – đều có thể xử lý qua vibe code tool.

2/ Developing với Cursor và Codex

Thật ra có thể tiếp tục dùng Claude, nhưng Py muốn trải nghiệm tool mới nên chuyển sang Cursor. Chủ yếu Py chỉ cần chụp màn hình lỗi, mô tả cho Cursor, nhấn “Allow” để nó tự sửa. Nhưng vì chưa trả phí và chưa có đủ knowhow về code để sense được cách làm của Cursor đã tối ưu hay chưa, Py tốn khá nhiều thời gian mà tool vẫn còn lỗi. Nên khi hết free quota của Cursor, Py chuyển sang Codex.

Đến đoạn này thì Py “có kinh nghiệm” hơn, thay vì mô tả lỗi chung chung, Py chủ động hơn trong cách fix lỗi:

1. Yêu cầu gắn log vào đúng chỗ đang nghi ngờ
2. Hướng dẫn thao tác reproduce từng bước
3. Thêm UI trực tiếp trên tool để hiển thị log – tiện copy nguyên văn paste vào Codex

Cách này gọn hơn nhiều. Mỗi vòng debug chỉ đụng đúng chỗ đang lỗi, không viết lại những gì đang ổn.

Cuối cùng, Py done.

Lookback

Nếu Vibe Coding (1) Py đề cập việc AI có thể build được, thì qua lần này Py thấy rõ hơn một bậc: AI không chỉ build được – mà build nhanh hơn, và ngày càng ít cần được giải thích hơn.

Lần một mất hơn một tiếng để có chrome extention đơn giản. Lần hai scope lớn hơn nhiều – full-stack web tool với database, OAuth, AI integration, deploy lên production – nhưng thời gian chỉ gấp khoảng 4–5 lần, không phải 10 hay 20 lần. Khoảng cách đó, theo Py, nói lên nhiều hơn về tốc độ tiến hóa của tool – chứ không chỉ về khả năng của người dùng.

Nhìn lại 4+ tiếng đó, có một sự phân công khá rõ – dù Py không chủ động đặt ra từ đầu.

AI lo phần kỹ thuật: generate codebase, đề xuất architecture, viết API routes, tạo docs hướng dẫn, debug lỗi, fix production, clean UI. Những việc trước đây cần developer ngồi vài ngày, giờ xong trong vài phút đến vài chục phút.

Py lo phần còn lại: xác định vấn đề cần giải quyết, quyết định MVP trông như thế nào, chọn hướng khi AI đề xuất nhiều option, biết khi nào là “done” thay vì “thêm một tính năng nữa thôi”. Và khi tool báo xong nhưng vẫn còn thứ chưa ổn, Py là người nhận ra – không phải vì hiểu code, mà vì hiểu product mình muốn.

Thật ra đó là mô tả khá chuẩn cho vai trò PO trong một team dev bình thường. Điểm khác là lần này không có team – chỉ có Py và các tool. Và product vẫn được ship. Suy cho cùng, AI đang nén lại thời gian từ ý tưởng đến prototype. Nhưng nó không nén được khoảng cách giữa prototype và product thật sự có giá trị. Phần đó vẫn cần người.

Challenge thật sự cho PO trong giai đoạn này, theo Py, không phải là học cách dùng tool – mà là học cách giữ chất lượng quyết định khi tốc độ deliver tăng lên gấp nhiều lần. Khi từ ý tưởng đến prototype chỉ còn tính bằng giờ, áp lực “thêm một tính năng nữa thôi” sẽ lớn hơn rất nhiều. Và đó là lúc discipline của người làm product – biết dừng đúng chỗ, ship đúng lúc, học đúng thứ – trở thành thứ khan hiếm nhất.

Và trong bối cảnh các công ty AI đang liên tục ra tính năng mới – đến mức tool Py dùng ở lần một và lần hai đã khác nhau đáng kể – thì đây chắc không phải lần cuối quy trình này thay đổi. Nên thứ PO cần luyện có lẽ không phải là thành thạo một tool cụ thể, mà là khả năng orient nhanh trong môi trường liên tục thay đổi.

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