Chúng ta thường gọi nợ kỹ thuật là những đoạn mã xấu, lặp lại, thiếu test hoặc khó bảo trì. Nhưng trong thời AI coding, một loại nợ mới đang lớn lên nhanh hơn: ý định bị lệch. Code có thể chạy, test cục bộ có thể xanh, pull request có thể trông hợp lý, nhưng thứ được tạo ra lại không còn đúng với bài toán kinh doanh, ràng buộc hệ thống hay cách đội ngũ muốn sản phẩm vận hành.
Đây mới là nỗi đau thật trong nhiều đội kỹ thuật hiện nay. Công cụ sinh mã giúp tăng tốc rất mạnh, nhưng đồng thời cũng tạo ra một lớp nợ kiểm soát mới: ai đã quyết định thay đổi này, thay đổi đó bám theo yêu cầu nào, nó tác động tới workflow nào, và vì sao hệ thống lại chuyển từ trạng thái A sang trạng thái B? Khi không trả lời được những câu hỏi đó, đội ngũ đang tích lũy nợ dù code nhìn qua vẫn có vẻ ổn.
Tốc độ sinh mã tăng, nợ kiểm soát cũng tăng
Các AI coding tools ngày nay rất giỏi ở việc tạo ra code nhanh, gợi ý cấu trúc hợp lý và lấp đầy những phần việc lặp lại. Điều đó đặc biệt hấp dẫn trong bối cảnh startup cần ra tính năng nhanh, đội kỹ thuật thiếu người, hoặc mô hình contract coding phải giao hàng liên tục. Tuy nhiên, tốc độ không tự động tạo ra kiểm soát.
Khi một thay đổi được sinh ra quá nhanh, phần khó nhất không còn là viết code mà là xác minh xem code đó có thực sự phản ánh đúng intent hay không. Nói cách khác, AI đang giảm chi phí tạo mã nhưng làm tăng chi phí kiểm chứng đầu ra. Nếu đội ngũ vẫn giữ nguyên cách làm cũ, nợ kỹ thuật sẽ không biến mất mà chỉ chuyển dạng: từ nợ ở cấp dòng lệnh sang nợ ở cấp quyết định.
Vì sao review theo từng dòng không còn đủ
Trong thế giới trước đây, senior engineer có thể đọc từng diff, hiểu logic, đối chiếu với ticket và phát hiện lỗi sớm. Nhưng khi AI có thể tạo hàng trăm dòng thay đổi trong vài phút, cách review theo từng dòng bắt đầu hụt hơi. Reviewer không chỉ phải đọc code nhiều hơn mà còn phải đoán xem ý định ban đầu là gì, giả định nào đang bị AI tự thêm vào, và thay đổi nào có thể gây tác động dây chuyền ở nơi khác.
Đó là lý do nhiều đội có cảm giác rằng họ vẫn review rất chăm nhưng bug và regression vẫn lọt. Vấn đề không hẳn là reviewer yếu đi. Vấn đề là phương pháp review không còn tương xứng với tốc độ sinh mã mới. Human review không scale nếu chỉ tập trung ở lớp line diff.
Bốn kiểu rủi ro phổ biến khi dùng AI coding
- Lệch ý định: AI hiểu sai yêu cầu hoặc tối ưu theo cách hợp lý về mặt kỹ thuật nhưng sai về mặt nghiệp vụ.
- Lệch kiến trúc: Một thay đổi nhỏ được sinh ra theo hướng tiện tay, nhưng phá vỡ boundary, convention hoặc nguyên tắc thiết kế của hệ thống.
- Lệch quy trình: Code được thêm vào nhưng không đi qua đầy đủ contract, acceptance criteria, traceability hoặc tiêu chuẩn bàn giao.
- Hồi quy: Một phần sửa lỗi cục bộ làm thay đổi hành vi ở khu vực khác mà reviewer không nhìn thấy hết tác động.
Điểm nguy hiểm là cả bốn loại rủi ro này đều có thể xuất hiện ngay cả khi code trông sạch, có comment, thậm chí có test. Vì thế, nếu chỉ đồng nhất nợ kỹ thuật với code xấu thì đội ngũ sẽ nhìn sai bản chất của vấn đề.
Phải nhìn ở cấp workflow thay vì chỉ cấp code
Khi AI tham gia mạnh vào quy trình phát triển, cách kiểm soát hiệu quả hơn là chuyển từ câu hỏi “đoạn code này viết có đẹp không?” sang “thay đổi này đi theo workflow nào, dựa trên contract nào, truy vết được đến đâu, và được xác minh bằng tiêu chí gì?”. Đây là khác biệt rất lớn giữa vibe coding và một cách làm có kiểm soát.
Một workflow tốt cần có ít nhất bốn lớp:
- Contract-first: mô tả rõ đầu vào, đầu ra, ràng buộc và tiêu chí chấp nhận trước khi sinh mã.
- Traceability: mỗi thay đổi phải lần ngược được về yêu cầu, quyết định và phạm vi tác động.
- Regression control: không chỉ test phần mới mà phải xác định những workflow cũ nào có nguy cơ bị ảnh hưởng.
- Human review ở đúng tầng: con người tập trung vào intent, boundary, risk và output thay vì cố đọc thủ công toàn bộ chi tiết sinh ra.
Trong tư duy software factory hoặc contract coding hiện đại, giá trị không nằm ở việc tạo code nhanh nhất mà ở việc tạo thay đổi có thể kiểm soát được. Đây cũng là lý do các mô hình như Midi Coder nhấn mạnh contract-first, traceability và kiểm soát đầu ra thay vì chỉ chạy theo tốc độ sinh mã.
Một thay đổi nhỏ vẫn có thể gây ảnh hưởng dây chuyền
Hãy tưởng tượng AI được giao sửa một hàm tính chiết khấu để hỗ trợ thêm điều kiện ưu đãi mới. Thay đổi nhìn qua rất nhỏ: thêm vài nhánh logic, cập nhật một service, test đơn vị vẫn pass. Nhưng nếu hệ thống còn có báo cáo doanh thu, đồng bộ dữ liệu sang CRM, giới hạn hoàn tiền và logic hiển thị giá ở frontend, thì thay đổi đó không còn là một diff nhỏ nữa. Nó là một thay đổi workflow.
Nếu reviewer chỉ đọc phần code mới được sinh ra, họ có thể bỏ sót câu hỏi quan trọng hơn: điều kiện mới này có làm sai báo cáo cuối tháng không, có mâu thuẫn với rule cũ không, có làm lệch trải nghiệm ở kênh bán khác không, và ai xác nhận rằng diễn giải nghiệp vụ của AI là đúng? Regression thường bắt đầu từ những chỗ như vậy.
Từ code generation sang output control
Điều các đội kỹ thuật cần hiện nay không chỉ là thêm công cụ AI coding, mà là nâng cấp cơ chế kiểm soát. Nếu không, tốc độ càng cao thì chi phí sửa sai càng lớn. Nợ kỹ thuật mới của thời AI không còn đơn thuần là code xấu, mà là khoảng cách ngày càng rộng giữa thứ hệ thống đang làm và thứ doanh nghiệp thực sự muốn nó làm.
Vì vậy, trọng tâm nên dịch chuyển từ sinh mã sang kiểm soát đầu ra. Khi intent được khóa bằng contract, thay đổi được truy vết rõ ràng, regression được nhìn ở cấp workflow và human review được đặt đúng chỗ, AI mới thực sự tạo ra đòn bẩy. Còn nếu chỉ tăng tốc viết code mà không tăng tốc kiểm soát, đội ngũ chỉ đang tích lũy một loại nợ kỹ thuật mới, âm thầm hơn và nguy hiểm hơn.
