Nội dung chính
1. Nợ kỹ thuật là gì — giải thích không dùng thuật ngữ
Hãy hình dung bạn đang xây nhà. Để tiết kiệm thời gian, thợ xây dùng vật liệu tạm, che kín bên ngoài cho đẹp. Nhà vẫn đứng, vẫn dùng được. Nhưng 2 năm sau, muốn sửa bếp thì phải đập tường, muốn thêm tầng thì móng không chịu được, muốn mở cửa sổ thì trúng dầm ẩn.
Nợ kỹ thuật trong phần mềm cũng vậy:
- Code viết tắt, thiếu chú thích, cấu trúc rối
- Tính năng mới thêm vào ngày càng khó và tốn thời gian hơn
- Developer mới vào không hiểu gì, không dám sửa
- Cuối cùng phải viết lại từ đầu — tốn kém hơn gấp nhiều lần làm đúng ban đầu
2. Tại sao AI đặc biệt giỏi tạo ra nợ kỹ thuật
AI rất giỏi tạo ra code trông đúng. Đây chính là vấn đề.
Code người viết tệ: Thường bị phát hiện sớm — reviewer thấy, lập trình viên khác thấy, test thất bại.
Code AI viết tệ: Trông sạch sẽ, có comment đầy đủ, chạy được khi test — nhưng ẩn chứa vấn đề kiến trúc mà chỉ lộ ra khi hệ thống lớn hơn hoặc bị tải nặng.
Theo báo cáo của CodeRabbit (tháng 12/2025) dựa trên hàng triệu pull request thực tế:
- Code AI có nhiều hơn 75% lỗi cấu hình sai so với code người
- 1,7 lần nhiều hơn các lỗi kiến trúc nghiêm trọng
- Vấn đề thường ẩn dưới bề mặt code "sạch"
Ví dụ thực tế: AI tạo ra một hàm xử lý đơn hàng. Code chạy tốt khi test với 10 đơn. Khi hệ thống có 10.000 đơn đồng thời, hàm đó làm database bị chậm 50 lần — vì AI không tối ưu truy vấn cho tải cao. Không ai phát hiện cho đến khi sập.
3. Vòng xoáy nợ kỹ thuật — diễn ra theo từng giai đoạn
Tháng 1–2: Cảm giác siêu năng suất
Với vibe coding, team ra tính năng nhanh gấp 3 lần bình thường. Mọi người phấn khích. Sếp hài lòng. Đây là giai đoạn nguy hiểm nhất — mọi thứ trông ổn trong khi nợ đang âm thầm tích lũy.
Tháng 3–4: Tốc độ bắt đầu chậm lại
Thêm tính năng mới vào code cũ ngày càng phức tạp. Dev phải dành nhiều thời gian đọc hiểu code AI đã sinh ra trước đó — code trông sạch nhưng logic không rõ ràng. Estimate bắt đầu sai so với thực tế.
Tháng 5–6: Onboarding trở thành ác mộng
Developer mới join team, đọc code AI và... không hiểu tại sao code lại làm vậy. Không có người giải thích được vì người viết prompt cũng không hoàn toàn hiểu code AI sinh ra. Senior dev mất thời gian hướng dẫn thay vì build tính năng.
Tháng 9–12: Quyết định đau đớn
Team họp và thống nhất: phải viết lại. Chi phí viết lại thường gấp 2–3 lần chi phí làm đúng từ đầu — chưa tính thời gian mất đi và cơ hội bỏ lỡ trong thời gian chuyển đổi.
4. Dấu hiệu nhận biết sớm
Đây là những cảnh báo đỏ bạn có thể quan sát từ góc độ quản lý, không cần biết kỹ thuật:
Dấu hiệu 1: Estimate ngày càng sai
Dev nói "sửa cái này 2 ngày" rồi thực tế mất 1 tuần. Lý do: phải đọc hiểu và vá code cũ trước khi thêm gì mới.
Dấu hiệu 2: Ngại thêm tính năng vào chỗ cũ
Team có xu hướng "thêm ở chỗ khác" thay vì mở rộng code hiện tại. Dấu hiệu của code quá rối để sửa.
Dấu hiệu 3: Bug lặp đi lặp lại ở cùng một chỗ
Sửa xong xuất hiện lại sau 2 tuần, dạng khác. Đây là triệu chứng của code thiếu cấu trúc vững.
Dấu hiệu 4: Developer mới mất quá lâu để productive
Nếu developer mới cần hơn 2 tháng để tự làm việc độc lập, codebase có vấn đề về tài liệu và cấu trúc.
Dấu hiệu 5: Không ai dám sửa module X
"Cái đó đừng đụng vào" là câu quen thuộc trong team. Module đó là nợ kỹ thuật đang đợi nổ.
5. Cách phòng tránh — không cần bỏ AI
Nợ kỹ thuật không phải lý do để không dùng AI. Nó là lý do để dùng AI có ý thức hơn.
Nguyên tắc 1: AI drafts, human understands
Mọi code AI tạo ra, lập trình viên phải đọc và hiểu trước khi commit. Nếu không giải thích được code làm gì, đừng ship.
Nguyên tắc 2: Đặt giới hạn tối đa cho file code
File code không quá 200 dòng. Nếu AI tạo ra file 500 dòng, yêu cầu nó chia nhỏ. Code nhỏ dễ hiểu, dễ test, dễ sửa.
Nguyên tắc 3: Test trước khi merge
Mỗi tính năng mới phải có test đi kèm. Test không chỉ để kiểm tra tính năng — còn là tài liệu sống giải thích code làm gì.
Nguyên tắc 4: Dành 20% thời gian để "trả nợ"
Mỗi sprint (chu kỳ làm việc), dành 20% thời gian refactor — tức làm sạch và cải thiện code cũ, không thêm tính năng mới. Tích lũy nhỏ tránh khủng hoảng lớn.
Điều này ảnh hưởng gì đến bạn?
Nếu bạn đang điều hành doanh nghiệp có đội dev và đang dùng AI coding:
Một câu hỏi đơn giản để đánh giá mức độ nợ kỹ thuật hiện tại:
"Nếu cả team bị bệnh 2 tuần và một người mới phải tiếp quản, mất bao lâu để họ hiểu hệ thống và tự làm được?"
- Dưới 1 tháng: hệ thống tốt
- 1–3 tháng: nợ trung bình, cần chú ý
- Hơn 3 tháng: nợ cao, cần ưu tiên xử lý
Điều bạn có thể làm ngay:
Yêu cầu team hàng tháng trả lời: "Phần nào trong hệ thống khiến mình lo nhất?" Những câu trả lời đó chính là nợ kỹ thuật đang chờ xử lý.
Số liệu & thống kê
| Chỉ số | Con số | Nguồn |
|---|---|---|
| Lỗi cấu hình sai trong code AI vs người | Nhiều hơn 75% | CodeRabbit, 2025 |
| Lỗi kiến trúc nghiêm trọng | 1,7 lần nhiều hơn | CodeRabbit, 2025 |
| Chi phí viết lại hệ thống vibe-coded | Gấp 2–3 lần | Ước tính từ case study |
| Nợ kỹ thuật toàn cầu dự báo 2027 | 1,5 nghìn tỷ USD | Ước tính ngành |
| Thời gian trước khi nợ kỹ thuật lộ ra | 6–12 tháng | Quan sát thực tế |
| Năng suất giảm do nợ kỹ thuật (giai đoạn 6 tháng) | Chậm hơn 2–4 lần | Ước tính team thực tế |
Sources
| # | Tên bài | URL | Ghi chú |
|---|---|---|---|
| 1 | State of AI vs human code | https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report | EN - CodeRabbit |
| 2 | Vibe coding: phát nhanh hôm nay, nợ kỹ thuật ngày mai | https://vndigitech.com/vibe-coding-tu-phat-nhanh-hom-nay-no-ky-thuat-ngay-mai/ | VI - Digitech VN |
| 3 | Cursor CEO warning | https://fortune.com/2025/12/25/cursor-ceo-michael-truell-vibe-coding-warning-generative-ai-assistant/ | EN - Fortune |
| 4 | Vibe coding vs AI-assisted engineering | https://medium.com/@addyosmani/vibe-coding-is-not-the-same-as-ai-assisted-engineering-3f81088d5b98 | EN - Google engineer, Medium |
| 5 | The real risk of vibecoding | https://www.trendmicro.com/en_us/research/26/c/the-real-risk-of-vibecoding.html | EN - Trend Micro |
