Nhờ các AI co-pilot và coding agents, vận tốc phát triển của nhiều đội ngũ kỹ thuật đã tăng mạnh hơn bao giờ hết. Một feature từng mất vài ngày giờ có thể được dựng xong trong vài giờ. Jira đẹp hơn. Demo dày hơn. Cảm giác tiến độ tốt hơn.
Nhưng trong kỹ thuật phần mềm, không có bữa ăn nào miễn phí.
Trong tài chính, vay tiền giúp bạn có thanh khoản ngay nhưng sẽ phải trả lãi sau đó. Trong phần mềm, copy-paste code từ AI mà không hiểu bản chất cũng là một hình thức vay nợ. Bạn mượn tốc độ ở hiện tại và cam kết trả giá ở tương lai.
AI đang giúp chúng ta sinh code với vận tốc ánh sáng. Điều đó cũng có nghĩa là technical debt đang có khả năng tích lũy với vận tốc ánh sáng.
Vấn đề không nằm ở AI.
Vấn đề nằm ở việc team có nhận ra mình đang vay nợ hay không.
Nợ Kỹ Thuật Thời AI Khác Gì Nợ Kỹ Thuật Truyền Thống?
Technical debt truyền thống thường đến từ một quyết định có ý thức. Team biết rõ mình đang viết giải pháp tạm thời để kịp deadline và chấp nhận refactor sau.
Nợ kỹ thuật thời AI nguy hiểm hơn ở chỗ nó thường là khoản nợ thụ động:
- được tạo ra rất nhanh
- trông có vẻ sạch sẽ
- lan rộng qua nhiều module
- nhưng không ai thực sự sở hữu toàn bộ ngữ cảnh
Đó là lý do nó khó nhìn thấy hơn và khó kiểm soát hơn.
Ba Dạng "Lãi Ẩn" Của AI-Generated Tech Debt
1. Phình To Âm Thầm
Code do AI sinh ra thường có bề ngoài rất đẹp:
- format chuẩn
- tên biến gọn gàng
- comment nghe hợp lý
- cấu trúc file nhìn có vẻ có tổ chức
Nhưng đằng sau vẻ ngoài đó có thể là:
- logic trùng lặp ở nhiều nơi
- vòng lặp lồng nhau làm độ phức tạp tăng không cần thiết
- abstraction thừa
- dead code không ai dùng
Hệ thống phình ra mà bề mặt vẫn có vẻ "clean".
Đây là loại nợ rất nguy hiểm vì nó dễ qua mắt những cuộc review hời hợt.
2. Kiến Trúc Frankenstein
AI tối ưu cục bộ rất giỏi.
Nếu bạn đưa cho nó một file và yêu cầu sửa một lỗi, nó có thể tạo ra lời giải khá ổn cho đúng file đó. Nhưng một hệ thống thật không phải là tập hợp của những file tối ưu cục bộ. Nó là một tổng thể cần chung triết lý thiết kế.
Khi mỗi thành viên prompt AI theo một kiểu khác nhau, kết quả thường là:
- module A mang tư duy service-oriented
- module B lại trộn business logic vào UI
- module C dùng naming conventions khác
- module D có error handling hoàn toàn lệch pha
Ghép lại, hệ thống trở thành một con quái vật Frankenstein: chạy được, nhưng thiếu tính nhất quán kiến trúc.
3. Mất Ngữ Cảnh Và Mất Ownership
Khi kỹ sư tự tay xử lý một bài toán khó, họ buộc phải hiểu vì sao đoạn code đó tồn tại.
Khi AI viết phần lớn lời giải và con người chỉ đóng vai trò merge, hệ thống bắt đầu xuất hiện những vùng code mà không ai thật sự sở hữu.
Đó là lúc những câu hỏi nguy hiểm xuất hiện:
- Vì sao chỗ này phải cache?
- Tại sao ở đây dùng queue thay vì xử lý đồng bộ?
- Tại sao validation được đặt ở tầng này?
- Nếu production lỗi lúc 2 giờ sáng, ai là người thật sự debug nổi?
Một codebase mà không ai nắm context đủ sâu là một codebase đang vay nợ với lãi suất rất cao.
"Lãi Suất" Của Khoản Nợ Này Được Trả Bằng Gì?
AI-generated technical debt không thu tiền ngay. Nó tính lãi bằng những thứ làm đội ngũ chậm đi theo thời gian.
[Lạm dụng AI sinh code]
↓
[Nợ kỹ thuật tăng nhanh]
↓
[Regression nhiều hơn]
[Onboarding khó hơn]
[Cloud cost cao hơn]
[Velocity giảm dần]Velocity Sụt Giảm
Ba tháng đầu mọi thứ trông rất tuyệt. Team ship nhanh, backlog chạy tốt, stakeholders hài lòng.
Nhưng đến tháng thứ sáu, mỗi lần chạm vào module cũ để thêm tính năng là một lần hồi hộp. Một sửa đổi nhỏ có thể kéo theo regression ở ba nơi khác. Lúc đó, thời gian sửa hậu quả bắt đầu nhiều hơn thời gian tạo giá trị mới.
Onboarding Nặng Hơn
Một senior mới vào team có thể đọc code rất nhanh, nhưng họ vẫn cần một hệ thống có logic đủ nhất quán để hình thành mental model.
Nếu codebase là sản phẩm của hàng trăm prompt rời rạc, chi phí onboarding sẽ tăng mạnh. Người mới không chỉ học business domain. Họ còn phải giải mã những quyết định thiết kế không ai nhớ nguồn gốc.
Chi Phí Hạ Tầng Tăng
Code AI viết có thể chạy rất ổn ở local hoặc dữ liệu test nhỏ.
Nhưng khi lên production, những lỗi tối ưu kinh điển như:
- N+1 query
- blocking I/O
- memory bloat
- truy vấn không tận dụng index
sẽ được quy đổi trực tiếp thành tiền cloud, chi phí vận hành và sự mất ổn định của sản phẩm.
Làm Gì Để Không Biến AI Thành Máy Tạo Nợ?
Không cần tẩy chay AI.
Điều cần làm là quản lý nó như một nguồn rủi ro kỹ thuật có thật.
1. Siết Chặt Ownership Trong Code Review
Code review là tường phòng thủ cuối cùng trước khi nợ xấu chui vào main.
Một nguyên tắc nên rất rõ:
Nếu tác giả không giải thích được đoạn code vận hành như thế nào, đoạn code đó chưa sẵn sàng để merge.
Bạn có thể cho phép AI-assisted, nhưng không thể cho phép AI-owned.
Nếu cần, team có thể:
- gắn tag
AI-assistedcho PR - lưu lại prompt quan trọng trong mô tả PR
- yêu cầu tác giả nêu rõ trade-off của giải pháp
Mục tiêu không phải là truy vết "ai viết". Mục tiêu là xác định "ai chịu trách nhiệm".
2. Dùng Automation Để Đặt Trần Nợ
Không thể chỉ dựa vào cảm giác để kiểm soát technical debt.
Team cần các rào chắn cứng trong CI/CD:
- test coverage tối thiểu
- static analysis
- complexity thresholds
- security checks
- performance guardrails cho các luồng quan trọng
Và tốt hơn nữa, hãy chuẩn hóa càng nhiều bước sinh mã càng tốt.
Trong hệ sinh thái của tôi, một ví dụ cho hướng đi này là Finvoras_Gen. Đây là internal CLI tôi xây để tự động hóa scaffold, code generation và các pipeline lặp lại, nhằm ép những phần boilerplate phải đi theo cùng một chuẩn ngay từ đầu thay vì để mỗi lần AI sinh ra một phiên bản cấu trúc khác nhau.
Automation đúng cách không chỉ giúp đi nhanh hơn. Nó còn giúp giới hạn biên độ hỗn loạn mà tốc độ có thể tạo ra.
3. Dành Một Phần Sprint Để Trả Nợ Có Chủ Đích
AI rất giỏi tạo code nhanh. Hãy dùng chính lợi thế đó để trả nợ thay vì chỉ tạo nợ mới.
Một nguyên tắc thực dụng là dành một phần thời gian cố định trong mỗi sprint để:
- viết test cho module cũ
- bổ sung documentation kỹ thuật
- refactor các điểm nóng
- hợp nhất những đoạn logic bị AI nhân bản ở nhiều nơi
Không cần phải thần thánh hóa con số 20%.
Điều quan trọng là khoản thời gian này phải có thật, được bảo vệ thật, và được xem là đầu tư kỹ thuật chứ không phải phần việc "nếu rảnh thì làm".
Kết
AI là một động cơ tăng tốc cực mạnh cho kỹ sư phần mềm.
Nhưng tốc độ không tự động tạo ra chất lượng. Nếu thiếu tư duy kiến trúc, kỷ luật review và cơ chế kiểm soát nợ, team càng nhanh bao nhiêu thì càng có thể lao vào tường sớm bấy nhiêu.
Thước đo của một software engineer giỏi trong kỷ nguyên AI không phải là mỗi ngày sinh được bao nhiêu nghìn dòng code.
Thước đo thật sự là sau một năm, hai năm, hệ thống đó còn đứng vững hay không.
Ship nhanh là tốt.
Nhưng ship nhanh mà không kiểm soát được lãi suất của technical debt thì chỉ là hoãn ngày phải trả giá.