- Vibe coding nợ kỹ thuật là vấn đề thật: tốc độ tăng nhanh, nhưng chi phí hiểu và sửa code cũng tăng theo.
- Các báo cáo bảo mật về AI-generated code đều nhấn mạnh rủi ro review nông, dependency sai và validation thiếu [1][4].
- Context Engineering là kỹ năng thay thế prompt engineering: thiết kế “ngữ cảnh” cho AI thay vì chỉ gõ lệnh.
- File
CLAUDE.md(hoặc tương đương) là “hợp đồng hành vi” giúp agent không phá vỡ kiến trúc. - Quy trình “Vibe & Verify” đang thay thế “vibe coding thuần” trong môi trường production.
Bạn vừa dùng Claude Code hoặc Cursor để build xong một tính năng trong 20 phút. Nó chạy được. Bạn commit, push, và chuyển sang task tiếp theo.
Hai tuần sau, bạn quay lại sửa một bug nhỏ trong module đó. Mất 3 tiếng. Không phải vì bug phức tạp — mà vì bạn không thực sự hiểu cái codebase AI vừa tạo ra cho bạn.
Đây chính là vibe coding nợ kỹ thuật: nó không tạo ra lỗi ngay lập tức, nhưng tích lũy đủ để làm chậm toàn bộ team về sau. Nếu bạn mới tìm hiểu khái niệm này, bài vibe coding là gì sẽ giúp bạn nắm nền trước khi đi sâu vào phần kiểm soát.
Vibe coding nợ kỹ thuật trông như thế nào?
Nợ kỹ thuật không phải là code xấu. Đó là cognitive debt — khi codebase trở nên quá phức tạp để bất kỳ ai (kể cả AI) có thể hiểu được mục đích ban đầu.
Với vibe coding, nợ tích lũy theo 4 dạng phổ biến nhất:
- Kiến trúc không nhất quán: AI thường kết hợp functional programming và OOP trong cùng một module, hoặc dùng 3 cách khác nhau để xử lý cùng một loại dữ liệu. Mỗi lần bạn prompt mới, agent không nhớ convention từ lần trước.
- Thiếu ownership thực sự: Bạn “sở hữu” code nhưng không thực sự hiểu nó. Khi có bug, bạn lại phải nhờ AI debug code AI vừa viết — vòng lặp phụ thuộc không có điểm thoát.
- Dependency rủi ro: AI hay đề xuất package không cần thiết hoặc đôi khi là package không tồn tại (package hallucination). Đây là một hướng rủi ro supply chain thường được nhắc tới trong bảo mật AI-assisted development [1][6].
- Bảo mật bị bỏ qua: AI tối ưu cho “chạy được”, không tối ưu cho “an toàn”. Thiếu server-side validation, missing rate limiting, hardcoded credentials là những pattern xuất hiện cực kỳ thường xuyên trong AI-generated code.
Các phân tích về AI-generated code đều đi đến cùng một điểm: review cẩn thận không phải tùy chọn, nó là bắt buộc [1][4]. Vibe coding nợ kỹ thuật thường bắt đầu từ những đoạn code “trông có vẻ ổn” nhưng thiếu validation, test hoặc convention.
Tại sao AI liên tục tạo ra nợ kỹ thuật
Không phải AI “cố tình” tạo ra code tệ. Vấn đề nằm ở cách LLM được thiết kế để hoạt động.
AI tối ưu cho “đầu ra hoàn chỉnh”, không tối ưu cho “kiến trúc dài hạn”. Khi bạn prompt “tạo API endpoint xác thực user”, model sẽ tạo code chạy được — nhưng nó không biết rằng bạn đã có một auth service riêng ở chỗ khác, hoặc team bạn quy định không dùng JWT mà dùng session cookie.
AI không nhớ convention từ session trước. Mỗi lần mở chat mới, context cũ biến mất. Nếu bạn không cung cấp lại các quy tắc kiến trúc, agent sẽ tự suy luận — và suy luận đó không phải lúc nào cũng đúng với codebase của bạn.
Bạn review nông hơn vì tin tưởng AI. Đây là điểm nguy hiểm nhất. Các khảo sát developer về AI tools đều cho thấy AI vừa tăng tốc vừa tạo thêm áp lực review [2]. Output trông “chuyên nghiệp” không đồng nghĩa permission logic, null check hay validation đã đúng.
Context Engineering là gì — và khác gì prompt engineering
Prompt engineering là kỹ năng viết câu lệnh tốt hơn. Context engineering là kỹ năng thiết kế toàn bộ “môi trường thông tin” mà AI agent nhìn thấy trước khi nó thực thi.
Sự khác biệt thực tế:
| Prompt Engineering | Context Engineering |
|---|---|
| Viết câu lệnh tốt hơn | Thiết kế ngữ cảnh AI nhận được |
| Tối ưu cho từng request | Tối ưu cho toàn bộ workflow |
| Không persistent giữa sessions | Persistent qua files như CLAUDE.md |
| Phụ thuộc vào “prompt hay” | Phụ thuộc vào “kiến trúc thông tin” |
| “Vibe-and-pray” | Structured, reproducible |
Nói đơn giản hơn: thay vì mỗi lần nói với AI “nhớ nhé, dự án này dùng TypeScript và không dùng any”, bạn viết điều đó vào một file cấu hình mà agent tự đọc mỗi lần khởi động.
Context engineering gồm 3 thành phần cốt lõi:
- Retrieval — cung cấp đúng thông tin codebase, API schema, và quy tắc kiến trúc cho agent trước khi nó làm việc.
- Structure — tổ chức thông tin sao cho machine-readable, persistent, và dễ cập nhật.
- Compaction — curate những gì agent thấy, loại bỏ noise để không làm tràn context window với thông tin vô nghĩa.
Nếu bạn đang dùng AI agent trong dự án thật, bài AI viết code nhanh hơn review là phần đọc thêm phù hợp để đặt lại quy trình kiểm soát.
Thiết lập CLAUDE.md: hợp đồng hành vi cho AI agent
Nếu bạn dùng Claude Code, CLAUDE.md là điểm bắt đầu quan trọng nhất. Nếu bạn dùng tool khác (Cursor, Copilot Workspace, Windsurf), cơ chế tương tự tồn tại với tên khác — nhưng nguyên tắc giống nhau.
Cách đơn giản nhất để nghĩ về CLAUDE.md: đây là bản onboarding bạn viết cho một senior engineer mới vào team. Nó trả lời các câu hỏi:
- Dự án này dùng stack gì?
- Quy tắc nào là không được vi phạm?
- Khi gặp tình huống X, làm Y hay Z?
- Phải test trước khi commit không?
Một CLAUDE.md thực tế tốt cần có:
# Project Context
## Stack
- Next.js 15, TypeScript (strict mode)
- PostgreSQL + Prisma ORM
- Tailwind CSS — không dùng inline styles
- pnpm (không dùng npm hay yarn)
## Quy tắc bắt buộc
- Không bao giờ dùng `any` trong TypeScript
- Auth luôn xử lý server-side, không check permission ở frontend
- Mọi API route phải có input validation bằng Zod
- Không hardcode secret — dùng biến môi trường
## Workflow
- Viết test trước khi implement feature mới
- Chạy `pnpm lint` và `pnpm test` trước khi hoàn thành task
- Nếu không chắc về approach, hỏi và document assumption
## Khi bị block
- Ghi lại vào `PENDING.md` và chuyển sang task khác
- Không tự đoán credential hay config quan trọng
Điểm quan trọng: CLAUDE.md không phải là prompt dài. Nó là tập hợp các rule có tác dụng “chốt chặn” — chỉ ghi những gì ngăn được lỗi thực tế, không phải mọi preference của bạn.
Quy trình “Vibe & Verify” — làm nhanh mà không mắc nợ
Xu hướng 2026 đang hình thành rõ: developer giỏi không “vibe coding” thuần — họ “Vibe & Verify”. Tức là dùng AI để tăng tốc, nhưng có checkpoint kiểm soát chặt tại đúng thời điểm.
Quy trình thực tế, 5 bước:
Bước 1: Viết spec trước khi prompt. Không mở AI agent khi bạn chưa rõ mình muốn gì. Dành 5-10 phút viết spec ngắn: input là gì, output là gì, constraints là gì. Spec này cũng chính là nội dung bạn đưa cho agent — thay vì nói “build tính năng login”, nói “build login flow: nhận email + password, validate bằng Zod, check user trong DB qua Prisma, trả JWT có TTL 24h, lưu vào httpOnly cookie”.
Bước 2: Cấp quyền truy cập tối thiểu cho agent. Đừng để agent đọc toàn bộ codebase khi nó chỉ cần 3 file. Chỉ định rõ file và folder nào liên quan. Điều này vừa giảm context noise, vừa giảm nguy cơ agent “học” pattern sai từ phần code cũ.
Bước 3: Review bằng checklist, không bằng cảm tính. Sau khi AI generate, kiểm tra theo 4 điểm cụ thể:
- ✅ Logic có đúng với spec không?
- ✅ Có bất kỳ hardcoded value nào không?
- ✅ Server-side validation có đầy đủ không?
- ✅ Có import/dependency mới nào không cần thiết không?
Bước 4: Chạy test tự động. Nếu bạn đã có test suite, đây là checkpoint quan trọng nhất. AI-generated code thường break test vì nó không hiểu toàn bộ contract của hệ thống. Test fail = signal để refactor, không phải signal để “bỏ qua test”.
Bước 5: Document assumption. Khi AI đưa ra một quyết định kiến trúc mà bạn chấp nhận, ghi chú lại lý do. Sau 2 tháng, bạn (hoặc teammate) sẽ cần biết tại sao code trông như vậy — và “AI viết vậy” không phải câu trả lời đủ.
Kiểm tra sức khỏe codebase vibe coding hiện tại
Nếu bạn đã vibe coding một thời gian mà chưa có CLAUDE.md hay spec nào, đây là checklist nhanh để đánh giá mức độ “nợ” hiện tại:
| Câu hỏi | Dấu hiệu nợ thấp | Dấu hiệu nợ cao |
|---|---|---|
| Bạn có thể giải thích logic của bất kỳ function nào mà không cần đọc lại? | Phần lớn là có | Thường phải đọc lại mới nhớ |
| Cùng một loại dữ liệu được xử lý theo mấy cách trong project? | 1–2 cách nhất quán | 3+ cách khác nhau ở các file |
| Bạn có CLAUDE.md hoặc tài liệu kiến trúc tương đương không? | Có, cập nhật | Không có, hoặc có nhưng cũ |
| Khi AI tạo code mới, nó có follow convention cũ không? | Thường có | Mỗi lần một kiểu |
| Test coverage của AI-generated code là bao nhiêu? | >60% | Dưới 30% hoặc không rõ |
Nếu bạn trả lời “dấu hiệu nợ cao” ở 3/5 câu trở lên, đây là thời điểm dừng vibe coding thêm và dành một sprint để trả nợ trước.
Cách trả nợ không phải là refactor toàn bộ ngay lập tức. Bắt đầu từ việc tạo CLAUDE.md ghi lại những quy tắc đang tồn tại ngầm trong đầu bạn. Sau đó, mỗi lần làm việc với một module, bổ sung test cho module đó. Nợ trả từng phần thực tế hơn là kế hoạch “refactor toàn diện” không bao giờ xong.
Nguồn tham khảo
- [1] Cloud Security Alliance — Vibe Coding Security Risks Report 2026
- [2] Stack Overflow Blog — Developer Survey: AI Tools & Review Fatigue 2026
- [3] Medium — The Technical Debt Flywheel in AI-Assisted Development
- [4] SonarSource — The Great Toil Shift: AI Code Quality in 2026
- [5] Appwrite Blog — From Vibe Coding to Spec-Driven Development
- [6] BeeSoul — CVE-2025-48757: Vibe Coding RLS Bypass Case Study
Câu hỏi thường gặp
Context engineering khác gì với prompt engineering?
Prompt engineering là tối ưu từng câu lệnh bạn gõ vào AI. Context engineering là thiết kế toàn bộ “môi trường thông tin” mà AI nhận được — bao gồm file cấu hình, quy tắc kiến trúc, và tài liệu dự án. Context engineering có tính persistent (tồn tại qua nhiều sessions), trong khi prompt engineering chỉ có hiệu lực trong một conversation.
CLAUDE.md cần viết bao nhiêu dòng là đủ?
Không có con số cố định, nhưng nguyên tắc là: chỉ ghi những rule thực sự ngăn được lỗi. Một CLAUDE.md 50-100 dòng hiệu quả hơn một CLAUDE.md 500 dòng đầy thông tin không cần thiết. Nếu agent đọc hết nhưng vẫn mắc lỗi X, mới cần thêm rule về X — không viết trước cho mọi trường hợp tưởng tượng.
Vibe coding có phù hợp cho production không?
Vibe coding với quy trình “Vibe & Verify” phù hợp cho production. Vibe coding thuần (không có review, không có test, không có spec) thì không. Sự phân biệt quan trọng là: AI làm công việc thực thi, nhưng bạn giữ trách nhiệm kiến trúc và chất lượng.
Nếu codebase đã có nhiều nợ kỹ thuật, bắt đầu từ đâu?
Bắt đầu bằng 3 bước nhỏ: (1) Tạo CLAUDE.md ghi lại quy tắc đang tồn tại ngầm trong đầu bạn. (2) Chọn 1 module quan trọng nhất, bổ sung test coverage cho module đó. (3) Trong sprint tiếp theo, áp dụng “Vibe & Verify” cho mọi thay đổi mới — không cần refactor cũ, chỉ cần dừng tạo nợ mới.
Dùng Cursor hoặc Windsurf thì cũng cần CLAUDE.md không?
Có, nhưng tên file khác. Cursor dùng .cursorrules, Windsurf dùng .windsurfrules, GitHub Copilot Workspace dùng .github/copilot-instructions.md. Nguyên tắc và nội dung cần có giống nhau — chỉ khác tên file tùy tool.
Spec-driven development mất nhiều thời gian hơn vibe coding không?
Spec ngắn (5-10 phút) tiết kiệm 2-3 giờ debug sau này. Nghiên cứu 2026 cho thấy developer dùng AI có thể chậm hơn 19% trên task phức tạp nếu không có spec, vì thời gian debug và refactor vượt qua thời gian tiết kiệm từ AI generation. Spec không cần dài — cần đủ để AI hiểu constraint.
Tổng kết
Vibe coding không sai. Cách dùng nó mà không có guardrail mới là vấn đề.
Context engineering — cụ thể là thiết lập CLAUDE.md, viết spec trước khi prompt, và áp dụng quy trình “Vibe & Verify” — là bộ công cụ giúp bạn giữ tốc độ của vibe coding mà không trả giá bằng codebase khó bảo trì. Đây là cách giảm vibe coding nợ kỹ thuật mà không phải quay lại làm mọi thứ thủ công.
Trong series tiếp theo, mình sẽ đi sâu hơn vào cách viết test cho AI-generated code — vì test là “lưới an toàn” thực sự khi bạn không đọc hết từng dòng code AI tạo ra. Bạn cũng có thể đọc thêm bài rủi ro vibe coding để rà lại những lỗi thường gặp.
Nếu website của bạn đang dùng codebase vibe coding trong production và cần đánh giá rủi ro bảo mật, team VietnamTutor có thể hỗ trợ audit và thiết lập guardrail phù hợp.
