TL;DR: "Vibe coding" đang bị hiểu sai là thả AI viết bừa rồi bấm Accept. Kitze (tác giả Sizzy) đề xuất khái niệm "Vibe Engineering" - nơi bạn vẫn để AI làm nặng, nhưng với plan rõ ràng, context đầy đủ, và kỷ luật không "đốt 4 tiếng cho cái 15 phút". Bài này tổng hợp các insight thực chiến nhất từ talk của Kitze.
Vibe Coding đang bị hiểu sai
Thuật ngữ "vibe coding" xuất phát từ Andrej Karpathy, mô tả cách làm việc: bấm Accept, thúc AI làm tiếp, không quan tâm code, miễn chạy được.
Nhưng trong thực tế, nhiều người đang dùng nó như cái cớ để:
- Thả AI viết bừa
- Không review
- Không plan
- Rồi than "AI code dở"
Kitze đề xuất thuật ngữ mới: Vibe Engineering.
Vibe Engineering là gì?
Vibe Engineering = Engineering có kỷ luật + Agent làm nặng
Bạn vẫn để AI viết phần lớn code, nhưng:
- Có plan trước khi bắt đầu
- Có context (rules, docs, conventions)
- Có kỷ luật (biết dừng khi prompt không hiệu quả)
- Có steer (điều hướng kiến trúc, không chỉ nhận code)
So sánh nhanh:
| Vibe Coding | Vibe Engineering |
|---|---|
| "Làm app đặt phòng cho tôi, xịn, không lỗi" | "Tạo module booking theo Next.js App Router, tách domain availability/reservation, validation server-side, test luồng overbooking" |
| Cầu nguyện | Engineering |
| Accept mù | Review có mục tiêu |
Insight 1: Đừng cố viết code giỏi hơn AI - Hãy điều khiển AI tốt hơn
Vibe coding không phải là bỏ nghề. Nó là đổi giao diện điều khiển.
Dev không còn "gõ từng dòng", mà ra lệnh, đánh giá, chỉnh hướng.
Đừng hỏi:
"AI có viết React tốt bằng mình không?"
Hãy hỏi:
"Mình có đang điều khiển được hướng kiến trúc của code AI sinh ra không?"
Cách đọc code AI hiệu quả
Khi AI sinh code, đừng đọc từng dòng từ trên xuống. Đọc theo câu hỏi:
- Data đi đâu?
- State nằm ở đâu?
- Boundary giữa frontend/backend ở đâu?
- Có thứ gì sẽ đau đầu sau 3 tháng không?
Bạn chuyển từ coder sang technical director.
Insight 2: Code AI "khác style" không có nghĩa là code dở
React ecosystem vốn mơ hồ - ai cũng "tự phát minh quy ước". AI viết "không giống bạn" là chuyện bình thường.
Ngừng phản xạ:
"Code này khác style mình → code dở"
Thay bằng checklist:
- Có chạy đúng không?
- Có dễ đọc cho người khác không?
- Có test/guardrail không?
- Có phụ thuộc lib kỳ quặc không?
Nếu CÓ → cho qua chuyện style.
Style để lint + rules file xử lý, không phải não bạn.
Insight 3: AI không sợ code lặp - Và đó là lợi thế
LLM không "ngứa tay refactor" như dev. Điều này giúp tránh abstract quá sớm.
Kitze mô tả "abstraction addiction" của developer:
- Nhìn code lặp là muốn refactor ngay
- AI làm bạn đến abstraction nhanh hơn
- Nhanh đến "đúng abstraction" ✅
- Nhưng cũng nhanh đến "sai abstraction" ❌
Thực hành: Trì hoãn abstraction
Trong giai đoạn MVP/landing/admin tool:
- Cho phép code lặp
- Trì hoãn abstraction cho tới khi:
- Lặp 3-4 lần
- Và hiểu rõ pattern thật
Ví dụ:
- 2 form giống nhau 80%
- ❌ Vội tạo
SuperFormComponent(props...) - ✅ Copy form → ship nhanh → refactor sau khi có pattern rõ
Đây là anti-overengineering, rất hợp AI.
Insight 4: Context > Prompt
AI dở không phải vì nó ngu, mà vì bạn chưa "huấn luyện tại chỗ".
Bạn không cần prompt hay, bạn cần context ổn định.
Tối thiểu nên có trong repo
docs/
├── stack.md # Bạn dùng gì
├── ai-rules.md # Bạn ghét gì, cấm gì
└── patterns.md # Cách bạn tổ chức code
Sau đó mọi prompt đều ngắn lại, AI ít bịa.
Ví dụ ai-rules.md:
## Stack
- Next.js App Router
- Tailwind CSS
- react-hook-form + zod
## Cấm
- Không dùng inline style
- Không fetch trong component
- Không global state client
## Pattern
- Form: react-hook-form + zod
- Fetch: Server Actions
- Error: toast từ sonner
Insight 5: Prompt như giao task cho senior dev
Prompt tệ thường là:
"Refactor toàn bộ sang TypeScript và đừng lỗi"
Prompt tốt = constraint + phạm vi + tiêu chí
So sánh:
| ❌ Vibe Coding Prompt | ✅ Vibe Engineering Prompt |
|---|---|
| "Make it scalable and clean" | "Tách logic form validation sang server action, giữ UI không đổi, thêm test cho case dữ liệu rỗng" |
| "Fix all bugs" | "Sửa bug khi user refresh page, state booking bị mất. Dùng server-driven approach" |
| "Make me million-dollar app" | "Tạo MVP booking với 3 màn: list, detail, confirm. Không thanh toán. Data mock" |
Bạn đang làm engineering, không phải casting spell.
Insight 6: Vibe coding giống casino - Cần kỷ luật
Kitze ví AI như slot machine: có jackpot, có mất trắng.
Và tệ nhất:
"Mình vừa prompt 4 tiếng cho cái đáng lẽ 15 phút tự làm"
Rule sống còn
⏱ Nếu 15-20 phút prompt mà chưa tiến triển:
- Dừng
- Quay lại viết plan
- Hoặc tự làm tay 30% trước
AI là đòn bẩy, không phải nơi trú ẩn khi bí.
Insight 7: Viết PLAN.md trước khi code
Trước khi cho AI viết code, luôn làm 1 trong 2:
Cách A: Viết PLAN.md (khuyên dùng)
## Mục tiêu
- Trang booking phòng
## Phạm vi
- Frontend only
- Không thanh toán
## Ràng buộc
- Next.js App Router
- Server Actions
- No client state global
## Edge cases
- Overbooking
- Refresh page giữ state
- Validation date range
Cách B: Voice/text như PM
"Luồng này sai, user sẽ quay lại trang trước, state bị mất. Sửa lại theo hướng server-driven."
Không plan = vibe coding Có plan = vibe engineering
Insight 8: Nghề mới - "Vibe Code Fixer"
AI làm 70-80% đầu. Người giỏi làm 20% cuối.
Định vị bản thân không phải "AI viết code nhanh", mà là:
- Người sửa code AI
- Người dọn slop
- Người đảm bảo production không sập
Skill cần tập trung
| Skill | Tại sao quan trọng |
|---|---|
| Code review | Bắt lỗi AI, đảm bảo quality |
| Boundary & data flow | Kiến trúc đúng từ đầu |
| Debug production | AI không debug được prod |
| Refactor có kiểm soát | Dọn dẹp code AI an toàn |
Đây là lý do bạn không bị thay thế.
Insight 9: Đừng làm "PA Dev"
PA Dev = Pain-in-the-ass Developer
Người quá nitpick, ám ảnh "code phải đúng gu mình" sẽ khó sống với AI.
Học phân biệt:
- ❌ "Code này không giống mình viết" → bỏ qua
- ✅ "Code này có gây rủi ro không?" → sửa ngay
Nếu chỉ là gu cá nhân → cho qua. Nếu là rủi ro hệ thống → fix immediately.
Checklist Vibe Engineering
Dán lên Notion, dùng hàng ngày:
Trước khi code
- Có PLAN.md hoặc spec rõ ràng?
- Có context file (rules, patterns)?
- Prompt có constraint + phạm vi?
Trong khi code
- Review theo câu hỏi (data flow, state, boundary)?
- Không stuck quá 15-20 phút?
- Cho phép code lặp, trì hoãn abstraction?
Sau khi code
- Chạy đúng?
- Dễ đọc cho người khác?
- Có test cho edge case?
- Không có lib/pattern kỳ quặc?
Kết luận
AI không giết dev. AI giết dev không chịu nâng vai trò.
Vai trò mới của bạn:
- Ít gõ - nhiều nghĩ
- Nhiều review - ít accept mù
- Nhiều quyết định hệ thống - ít chi tiết syntax
Vibe Engineering là cách để AI thật sự trở thành đòn bẩy, không phải cái bẫy đốt thời gian.
Bài viết hữu ích? Hãy kết nối với Diginno!
Chúng tôi giúp doanh nghiệp SME ứng dụng AI và automation vào quy trình làm việc - từ tư vấn chiến lược đến triển khai thực tế.
👉 Đặt lịch tư vấn miễn phí để thảo luận về cách AI có thể tăng tốc công việc của bạn.
Tham khảo: Bài viết tổng hợp từ talk "From Vibe Coding to Vibe Engineering" của Kitze (Sizzy) tại hội nghị frontend 2025.
Bài viết hữu ích?
Chia sẻ để nhiều người biết đến!
>_ LLM-Friendly Copy
Copy as Markdown to use with ChatGPT, Claude, or other AI tools
