Vibe Coding như một team phát triển phần mềm

Vì sao nhiều app vibe coding "sập" sau vài tuần

Vibe coding hiệu quả nhất khi mình thôi coi AI là một cái máy nhả code, mà bắt đầu điều hành nó như một team phát triển phần mềm thu nhỏ. Chỉ một thay đổi đó thôi là khác biệt giữa một bản demo hỏng sau ba ngày và một app đẹp, dễ dùng, an toàn, và còn phát triển tiếp được.

Chắc bạn đã gặp cảnh này. Gõ "làm cho mình app đặt lịch", AI trả về một thứ nhìn rất ấn tượng, mình mừng rỡ. Rồi mình xin thêm một feature. Màu bắt đầu lệch. Một nút tự nhiên không bấm được. Cái bug đã sửa tuần trước lại quay về. Ba tuần sau, không ai hiểu app được ráp nối ra sao — kể cả AI.

AI không dở. Cái dở là quy trình. Một team phần mềm thật không bao giờ vào là gõ code ngay. Họ nói chuyện với user, thống nhất cần build cái gì, chọn framework phù hợp, dựng design system, viết test, review chéo cho nhau, rồi ship từng bước nhỏ, an toàn. Thói quen nào cũng có lý do cả — vì từng có người bỏ qua và đã phải trả giá.

Tin vui là: mình hoàn toàn có thể "cài" những thói quen đó cho AI. Chỉ cần biết yêu cầu, và yêu cầu đúng thứ tự.

Làm như một team, đừng làm như một coder đơn lẻ

Ý tưởng rất đơn giản: mỗi vai trong một product team tốt sẽ là một "chiếc mũ" mà AI đội lần lượt, còn mình luôn là người ra quyết định. Mỗi vai giữ một chất lượng của app.

Product manager / BA

- AI làm: phỏng vấn mình, viết PRD, user story, acceptance criteria

- Mình làm: trả lời thật, quyết định cái gì quan trọng nhất

- Giữ được: đúng feature, đúng market fit

Designer

- AI làm: dựng design token, component dùng lại, trang style guide

- Mình làm: duyệt giao diện, cảm giác

- Giữ được: đẹp, đồng bộ, dễ hiểu

Architect

- AI làm: chọn framework hợp với app, thiết kế data model và cấu trúc

- Mình làm: xác nhận các đánh đổi

- Giữ được: dễ scale, dễ maintain

Developer

- AI làm: viết code theo TDD, từng feature một

- Mình làm: mỗi lần chỉ giao một việc

- Giữ được: feature chạy đúng, ít lỗi lặp lại

QA tester

- AI làm: bấm thử app trên browser thật, chụp screenshot

- Mình làm: xem screenshot, tự bấm thử

- Giữ được: dễ dùng, chạy thật

Security reviewer

- AI làm: soát các lỗ hổng phổ biến trước mỗi lần release

- Mình làm: không dán password vào chat

- Giữ được: an toàn ngay từ thiết kế

DevOps

- AI làm: dựng hosting, test tự động, deploy an toàn

- Mình làm: duyệt cái gì được lên production

- Giữ được: ổn định, dễ rollback

Để ý vai trò của mình đã đổi thế nào. Mình không còn ngồi viết code hay debug nữa. Mình làm đúng việc của một founder hay product lead: quyết định build cái gì, đánh giá nó đã đúng chưa, và duyệt cái gì được ship.

Nói chuyện thật nhiều trước, build sau

Giờ đáng giá nhất là giờ trước khi có dòng code nào. Build sai một cách nhanh chóng thì vẫn là build sai — mà AI thì giúp mình build sai nhanh cực kỳ.

Nên hãy bắt đầu bằng một cuộc trò chuyện, đừng bắt đầu bằng một mệnh lệnh. Bảo AI đóng vai senior product manager và phỏng vấn mình trước:

Đóng vai một senior product manager. Mình muốn build [ý tưởng] cho [đối tượng user].
Trước khi viết gì, hỏi mình tối đa 10 câu để hiểu vấn đề, user và thế nào là thành công.
Chờ mình trả lời xong rồi mới làm tiếp.

Một buổi discovery tốt cần đi qua 5 chuyện:

1. User và vấn đề. App này cho ai dùng? Hiện giờ họ đang xoay xở ra sao? Họ bực nhất chuyện gì?
2. Feature. Cái gì bắt buộc phải có ở bản đầu (MVP), cái gì để sau được? Ở đây hãy bắt AI phản biện lại mình — bản đầu tiên thường ôm đồm quá nhiều.
3. Market fit. Ai đang giải quyết chuyện này rồi? Vì sao user phải chuyển sang dùng app của mình? Mình làm tốt hơn đúng điểm nào?
4. Roadmap. Bản 1, bản 2 và về sau sẽ có gì? Phải đạt điều gì mới qua giai đoạn tiếp theo?
5. Thành công trông ra sao. Sau một tháng, nhìn vào con số hay hành vi nào để biết app đang chạy tốt?

Từ cuộc nói chuyện đó, nhờ AI viết PRD (product requirements document) có user story và acceptance criteria theo dạng Given / When / Then:

Given khách đã đăng nhập và có hàng trong giỏ, when khách bấm Thanh toán, then hệ thống hiện tổng tiền và form thanh toán.

Mấy dòng acceptance criteria này quan trọng hơn mình tưởng. Về sau chúng biến thẳng thành test case — đó là cách để biết chắc AI build đúng cái mình đã thống nhất.

Đừng vội ở bước này. Cứ hỏi qua hỏi lại. Cãi với AI cũng được. Hỏi nó xem mình còn thiếu gì. Vài vòng hỏi thêm ở đây sẽ tiết kiệm cả tuần làm lại về sau.

Đặt nền móng trước feature đầu tiên

Biết rõ mình build cái gì rồi thì dựng nền móng. Bước này mất vài tiếng, nhưng chính nó giữ cho app đẹp, scale được và dễ maintain sau này.

Chọn framework hợp với nhu cầu. Nhờ AI đề xuất stack dựa trên PRD, và giải thích đánh đổi bằng lời dễ hiểu. Một trang nội dung, một app chat realtime và một dashboard nhiều dữ liệu cần những thứ rất khác nhau. Nên ưu tiên framework trưởng thành, có convention rõ (ví dụ Laravel cho PHP, hay Next.js cho JavaScript): chúng lo sẵn đăng nhập, bảo mật, kết nối database, và AI viết rất tốt vì đã thấy quá nhiều ví dụ.

Dựng design system trước khi làm màn hình. Đây là bí quyết để app vibe coding nhìn chuyên nghiệp, không bị chắp vá. Nhờ AI định nghĩa design token (tên gọi cho màu, font, khoảng cách, bo góc), biến chúng thành component dùng lại (button, card, form, modal), rồi làm một trang style guide hiển thị tất cả. Sau đó đặt một luật: không màn hình nào được dùng màu hay kích thước nằm ngoài token. Đổi một token là cả app đổi theo.  Bạn có thể tham khảo và tải design token ở https://designmd.ai

Cho dự án một "bộ nhớ". AI quên sạch mọi thứ giữa các session. Bốn file ngắn sẽ giải quyết chuyện đó:

• CLAUDE.md: luật chơi của dự án (stack, lệnh hay dùng, "luôn viết test trước", "không commit password")
• architecture.md: app được ráp nối ra sao, dữ liệu nằm ở đâu
• memory.md: cái gì xong rồi, đã quyết gì và vì sao, việc tiếp theo
• deployment.md: deploy thế nào, rollback thế nào

Session nào cũng mở đầu bằng "đọc mấy file này" và kết thúc bằng "cập nhật memory.md". Giống hệt một team tốt bàn giao trong buổi standup.

Dựng test và bảo mật ngay từ ngày đầu. Cài test framework và tool test trên browser (như Playwright) trước khi viết feature nào. Password và API key để trong file .env, không bao giờ dán vào chat. Gắn hai thứ này vào về sau khó hơn rất nhiều so với làm ngay từ đầu.

Vòng lặp build: mỗi lần một feature

Có nền móng rồi thì việc build trở thành một vòng lặp nhẹ nhàng, lặp lại được. Chạy một vòng cho mỗi feature:

1. Đọc context. AI đọc các file dự án để biết đang ở đâu.
2. Viết test trước. AI biến acceptance criteria thành test, chạy cho thấy test đang fail. Đây là TDD (test-driven development), và nó là "hợp đồng": test còn đỏ thì AI không được nói là xong.
3. Viết code vừa đủ. Chỉ dùng component có sẵn trong design system.
4. Chạy toàn bộ test, không chỉ test mới. Code mới không được âm thầm làm hỏng feature cũ.
5. Kiểm tra trên browser thật. AI bấm thử đúng flow như một user, chụp screenshot trên desktop và mobile.
6. Mình xem và bấm thử. Thấy chỗ nào kỳ thì nói cụ thể: "Ở màn hình thanh toán, xóa món hàng mà tổng tiền không cập nhật."
7. Lưu lại. Cập nhật memory.md và commit lên Git, để lúc nào cũng quay lại được bản chạy tốt gần nhất.

Trước mỗi lần release, thêm hai vòng soát. Soát UX: AI nhìn từng màn hình như một user lần đầu dùng, tìm label khó hiểu, thiếu trạng thái trống hay báo lỗi, lỗi trên mobile. Và soát bảo mật theo các kiểu tấn công phổ biến (OWASP Top 10), mỗi lỗi sửa đều có test đi kèm.

Có vài dấu hiệu cần dừng lại ngay: AI xóa hoặc nới lỏng test cho dễ pass, nói "em đã đơn giản hóa" mà không hỏi trước, hay sửa những file chẳng liên quan gì đến feature.

Chuyện sắp tới

AI đang giỏi lên rõ rệt ở việc hiểu ý mình, chứ không chỉ hiểu đúng chữ mình gõ. Các model mới giữ được cả dự án trong đầu, nhận ra khi một yêu cầu mâu thuẫn với quyết định trước đó, và tự bắt lỗi, tự sửa ngay trong lúc build và test. Một đội AI agent, mỗi agent đóng một vai trong bảng ở trên, giờ đã có thể nhận một ticket từ backlog rồi tự đưa nó đi qua plan, code, test và review.

Càng về sau, vòng lặp này càng ngắn lại. AI sẽ ít hỏi những câu hiển nhiên, hỏi nhiều câu đáng hỏi hơn. Nó sẽ thấy bug trước mình, tự chạy browser test, rồi quay lại với câu "xong rồi, đây là những gì em đã kiểm tra".

Nhưng AI càng thông minh thì cuộc nói chuyện ban đầu càng quan trọng, chứ không phải bớt đi. AI build càng giỏi, kết quả càng phụ thuộc vào việc mình có yêu cầu đúng thứ hay không. Nó không tự biết user của mình là ai, họ sẵn sàng trả tiền cho cái gì, hay mình chấp nhận đánh đổi điều gì — nếu mình không nói. Phần cái gì và vì sao vẫn là của mình. Cái khung trong bài này — discovery trước, nền móng rõ ràng, test là hợp đồng, người duyệt cái gì được ship — chính là thứ giúp mình yên tâm giao ngày càng nhiều phần làm thế nào cho AI.

Bắt đầu ngay hôm nay

Không cần biết code. Chỉ cần chạy đúng quy trình. Toàn bộ nằm gọn trong một danh sách:

• [ ] Nói chuyện discovery thật kỹ với AI: user, vấn đề, feature, market fit, roadmap
• [ ] Chốt thành PRD có acceptance criteria dạng Given / When / Then, và duyệt nó
• [ ] Để AI đề xuất framework phù hợp, kèm lý do
• [ ] Tạo 4 file dự án: CLAUDE.md, architecture.md, memory.md, deployment.md
• [ ] Dựng design token, component, trang style guide, và duyệt giao diện
• [ ] Dựng test và browser test trước feature đầu tiên
• [ ] Build từng feature một: test trước, kiểm trên browser, mình bấm thử, commit
• [ ] Soát UX và soát bảo mật trước mỗi lần release
• [ ] Deploy lên staging trước, rồi mới lên production

Hãy nghĩ mình là trưởng một team phần mềm nhỏ nhưng làm việc cực nhanh. Việc của mình là biết cần build cái gì, vì sao, và nói có hoặc không với những gì được ship. Phần còn lại, để team lo.

Tài liệu để bắt đầu

Dài dòng quá hả phải không, bạn yên tâm, mình đã tạo file md cho bạn gắn vô Claude Code hay Cursor + Claude, bạn kèm file rồi nói Claude theo hướng của file nhen.

Prompt Playbook: Vibe Coding cho BA (file md trên google drive)

Cách nhanh nhất: tải và để AI hỏi bạn câu đầu tiên.