Bạn có tin một người không phải lập trình viên có thể build được một sản phẩm internal tool hoàn chỉnh trong 30 ngày, với hơn 200 giờ làm việc và ~70k dòng code không? Đó chính xác là những gì odessaconnections đã làm và chia sẻ trên r/vibecoding. Xuất thân từ background PM, chỉ có hiểu biết cơ bản về kiến trúc và code, sau 30 ngày anh ấy đã ship được một tool nội bộ với đầy đủ chat, vector embeddings, LLM screenshot reading, text & image generation qua 2 model khác nhau, login, settings, cùng với Sentry và PostHog. Codebase khoảng 70k dòng, 30% là test.
Bài viết này tổng hợp lại 13 bài học mà odessaconnections ước gì mình biết từ ngày đầu — cực kỳ thực chiến cho anh em đang làm vibe coding.
1. Luôn bắt đầu với PRD
Viết product requirements document trước khi code. Phác thảo roadmap tổng quát, chia nhỏ thành từng bước, quyết định làm gì trước. Build theo từng micro-feature. Đừng kỳ vọng AI one-shot được thứ gì phức tạp — nó sẽ thất bại.
2. Đừng build mọi thứ trong một session
Làm vậy đốt token cực nhanh. Mỗi session mới cho mỗi tính năng mới, dùng /compact focus on <X> để giữ context gọn. Lên kế hoạch với model mạnh nhất, code với model rẻ hơn. Tiết kiệm token thấy rõ.
3. Build UI trước cho mọi tính năng mới
Đây là cách rẻ nhất để kiểm tra xem AI có thực sự hiểu ý mình không. Dùng mock data để spec-check, lên kế hoạch data cần thiết, tinh chỉnh bề mặt cho đúng ý tưởng, rồi mới xuống backend khi đã hài lòng.
4. Dạy AI viết test — cả unit và e2e
Cực kỳ hữu ích. Test tự động bắt regression mỗi khi AI chạm vào thứ gì đó. Vẫn nên test tay những chỗ quan trọng, nhưng test tự động trả ơn rất nhanh.
5. Dùng git ngay từ đầu
Rollback về bản đã chạy tốt đôi khi là cách fix nhanh nhất. odessaconnections bắt đầu dùng git ở mốc 16k dòng và tiếc vì không làm sớm hơn.
6. Viết một file CLAUDE.md (hoặc AGENTS.md) tử tế
Đây là file hướng dẫn cho AI: plan, conventions, những cái bẫy cần tránh. Component của anh ấy cứ phình mãi cho đến khi thêm rule như "split components aggressively" và "no business logic in components". File này là investment cực rẻ mà lợi ích dài hạn.
7. Dành ngày refactor định kỳ
1-2 ngày chỉ để dọn dẹp, refactor và viết docs thay vì ship tính năng mới. Khó dừng lại khi đang có đà, nhưng nếu không làm, codebase sẽ phình không kiểm soát và chất lượng giảm dần.
8. Chạy /review và /security-review cho mọi PR
odessaconnections đã build subagent riêng cho cả hai tác vụ này, tiết kiệm thời gian và được tune theo pattern mà anh ấy (và LLM) hay bỏ sót.
9. Siêng năng với security
Không cần là chuyên gia, nhưng phải biết căn bản: token nên được xử lý thế nào, database authorization hoạt động ra sao (Firestore security rules, Postgres RLS…), cái gì lộ ra client vs server. Hỏi AI giải thích các cái bẫy trước khi implement, không phải sau khi đã xong. Spot-check những chỗ critical định kỳ.
10. Dùng nhiều model, chơi đúng thế mạnh
Claude giỏi UI/UX. Codex làm tốt hơn với task phức tạp và đốt token chậm hơn khi refactor nặng. Cross-check PR với model khác sẽ bắt được lỗi mà model gốc bỏ qua. Gemini dùng để đánh giá phần lớn codebase vì tốc độ nhanh, nhưng không để nó build — feedback của nó luôn được kiểm tra lại bởi Claude hoặc Codex.
11. Dùng preview channel, đừng chỉ có main
Deploy lên preview trước khi lên production. Script deploy từ chối promote nếu commit hiện tại không khớp với SHA đã preview. Preview có thể vỡ, production thì không được.
12. Nhiều agent chỉ cho các tính năng không liên quan đến nhau
Chạy Claude và Codex trong các git worktree riêng, mỗi bên một branch, kèm script theo dõi file nào bị cả hai cùng chạm vào. Tuyệt đối không để chúng cùng làm một thứ — lần nào cũng thành mớ hỗn độn.
13. Dùng TypeScript sớm hơn mình nghĩ
Lợi ích của TypeScript chỉ thực sự rõ khi đã muộn. odessaconnections bắt đầu ở ranh giới nhưng refactor mất thời gian, phần lớn codebase vẫn là JS. Nếu làm lại, anh ấy sẽ dùng TS sớm hơn nhiều.
Mình thấy điểm đáng chú ý nhất trong bài chia sẻ này không phải là kỹ thuật, mà là mindset: một người không phải dev vẫn có thể ship sản phẩm thực tế nếu có quy trình làm việc với AI đúng đắn. PRD → UI trước → test → refactor định kỳ → preview → production. Nghe quen không? Đấy chính là quy trình software engineering truyền thống, nhưng được thực thi bởi một người và AI.
Anh em nào đang vibe coding mà chưa có quy trình rõ ràng thì 13 điểm trên là một template cực tốt để bắt đầu.
Top comments (0)