AI Coding và Technical Debt: Khi code nhanh quá cũng trở thành vấn đề

AI coding mang lại một cảm giác rất dễ gây nghiện. Bạn viết prompt. AI viết code. Feature xuất hiện gần như ngay lập tức. Một ticket vốn cần nửa ngày bỗng có vẻ hoàn thành trong ba mươi phút. Dashboard năng suất nhìn như vừa được bơm steroid. Không khí trong team trở nên lạc quan theo kiểu “chúng ta sắp code nhanh hơn cả roadmap rồi”.

Nhưng rồi sau một thời gian, nhiều team bắt đầu nhận ra một điều hơi khó nói nhưng rất thật:

Code được viết nhanh hơn, nhưng technical debt cũng tăng nhanh hơn.

Điều này không nhất thiết xảy ra vì AI viết code tệ. Phần lớn nó xảy ra vì tốc độ thay đổi tăng mạnh hơn tốc độ kiểm soát cấu trúc. Nếu kiến trúc, quy ước và workflow không đủ chặt, AI sẽ giúp đội ngũ xây rất nhanh một căn nhà mà phần dọn dây điện sau tường sẽ khiến ai cũng muốn đổi nghề.

AI không phát minh ra technical debt. Nó chỉ làm nghề ngân hàng rất giỏi: giải ngân nhanh, lãi cộng dồn mạnh, đến kỳ thì đội kỹ thuật trả.

Technical Debt thực sự là gì?

Technical debt, hay nợ kỹ thuật, là chi phí phải trả trong tương lai khi code hiện tại được tổ chức, thiết kế hoặc triển khai chưa đủ tốt. Nó giống như vay tiền để đi nhanh hơn hôm nay. Bạn có thể ra feature sớm hơn, nhưng sau đó sẽ phải “trả lãi” bằng thời gian sửa bug, refactor, onboarding chậm, estimation lệch và những buổi họp rất nhiều câu “sao chỗ này lại viết kiểu này?”.

Điểm nguy hiểm là technical debt không phải lúc nào cũng hiện ra dưới dạng lỗi đỏ chói. Nhiều khi nó xuất hiện dưới dạng hệ thống ngày càng khó đọc, sửa gì cũng chạm nhiều nơi, feature nhỏ mà PR dài như một bài văn nghị luận, hoặc team ngày càng ngại đụng vào code cũ. Đó chính là lý do nhiều đội đang dùng AI coding rất mạnh nhưng vẫn có cảm giác cả team không thật sự “nhẹ người” hơn.

Nợ kỹ thuật thường xuất hiện dưới nhiều dạng:

• logic lặp lại ở nhiều nơi
• kiến trúc bắt đầu lệch nhưng chưa vỡ hẳn
• naming và convention trôi dần
• test không theo kịp thay đổi
• module phụ thuộc lẫn nhau khó gỡ
• diff ngày càng lớn và khó review

Vì sao AI Coding có thể làm technical debt tăng nhanh?

1. Tốc độ viết code tăng mạnh hơn tốc độ hấp thụ của hệ thống

Trước đây một developer viết vài trăm dòng code mỗi ngày đã là chuyện bình thường. Với AI coding, lượng mã và số thay đổi có thể tăng lên nhiều lần. Điều này tự nó không xấu. Vấn đề là kiến trúc, review, convention và khả năng đồng bộ của team không tự động tăng theo đúng nhịp đó.

Nói đơn giản, bạn đang đổ thêm bê tông nhanh hơn, nhưng không chắc đội giám sát đã kịp kiểm tra cốt thép. Khi khối lượng thay đổi tăng nhanh, mọi lệch chuẩn nhỏ sẽ tích lũy nhanh hơn rất nhiều. Đó là môi trường lý tưởng để technical debt nhân lên.

2. Code được tạo ra từ nhiều prompt, nhiều ngữ cảnh, nhiều “tâm trạng” khác nhau

Mỗi prompt có thể dẫn đến một cách viết code khác nhau. Hôm nay AI thích đặt tên theo kiểu A, mai lại theo kiểu B. Hôm nay chia nhỏ hàm, mai gom lớp. Hôm nay validate ở entry point, mai validate sâu trong service. Nếu team không có workflow đủ rõ để buộc mọi thứ đi vào một khuôn, codebase sẽ rất dễ mất tính nhất quán.

Kết quả thường là:

• naming convention không đồng nhất
• logic phân tán
• structure không nhất quán
• pattern cùng loại nhưng mỗi nơi mỗi kiểu

Những thứ này nhìn riêng lẻ có vẻ nhỏ. Nhưng technical debt thường lớn lên từ chính những cái nhỏ như vậy, chứ không phải lúc nào cũng từ một quyết định quá tệ ai cũng nhìn ra ngay.

3. Boilerplate code xuất hiện nhiều hơn chứ không hẳn ít đi

Nghe hơi ngược đời, nhưng đúng. AI có thể viết boilerplate cực nhanh. Vấn đề là nếu không có compiler hoặc contract giữ vai trò chuẩn hóa, AI sẽ viết boilerplate theo nhiều biến thể khác nhau. Vậy là thay vì bớt boilerplate, team có thể vô tình tạo ra một bộ sưu tập boilerplate đa phong cách.

Đến lúc maintain, mỗi biến thể lại đòi hỏi một ít công sức hiểu và một ít công sức sửa. Tổng lại thành rất nhiều công sức. Đây là kiểu nợ kỹ thuật rất “êm”: không ồn ào nhưng dai như nợ thẻ tín dụng quên thanh toán.

4. Tăng tốc độ tạo code nhưng không tăng tương ứng tốc độ ra quyết định kiến trúc

AI coding giúp lời giải xuất hiện nhanh hơn. Nhưng việc quyết định lời giải nào phù hợp với hệ thống, lời giải nào nên trở thành pattern, lời giải nào chỉ là tạm thời, vẫn là công việc của con người. Nếu tốc độ generate code vượt xa tốc độ ra quyết định kiến trúc, hệ thống sẽ bắt đầu tích lũy những đoạn mã “chạy được nhưng chưa thật sự có chỗ đứng rõ ràng”. Đó là technical debt ở dạng rất phổ biến.

5. Review không tăng chất lượng kịp với tốc độ sinh code

AI có thể tạo ra thay đổi rất nhanh, nhưng reviewer vẫn là con người. Khi review trở thành thao tác “lướt cho xong”, design issue, duplicate logic, boundary sai và edge case dễ lọt vào codebase. Đây là nợ kỹ thuật tích lũy theo kiểu rất yên lặng. Merge xong nhìn vẫn đẹp. Chỉ là ba tháng sau ai cũng mệt hơn.

Dấu hiệu technical debt đang tăng

Một vài dấu hiệu khá quen thuộc nhưng rất đáng để lưu ý:

• codebase khó đọc hơn sau mỗi đợt tăng tốc với AI
• logic bị lặp lại ở nhiều nơi nhưng mỗi nơi hơi khác nhau
• refactor ngày càng khó và ngày càng bị trì hoãn
• feature mới nghe nhỏ nhưng estimate lại ngày càng cao
• review tốn sức hơn vì diff lớn và nhiều side-effect
• người mới vào team mất nhiều thời gian hơn để hiểu pattern chung
• developer bắt đầu thiếu tự tin khi sửa code cũ

Khi những dấu hiệu này xuất hiện, technical debt không còn là nguy cơ nữa. Nó đang sống khỏe trong hệ thống rồi.

AI không phải là nguyên nhân chính

Giống như nhiều vấn đề khác trong software engineering, AI chỉ là công cụ. Búa không tạo ra căn nhà lệch. Người dùng búa trong một quy trình lỏng lẻo mới tạo ra căn nhà lệch. Nếu workflow được thiết kế tốt, AI có thể giúp giảm technical debt bằng cách chuẩn hóa mô tả, tăng tốc sinh boilerplate theo quy tắc và giải phóng developer khỏi phần việc lặp lại.

Nếu workflow không rõ ràng, AI sẽ giúp debt tăng nhanh hơn đơn giản vì nó giúp bạn viết ra nhiều thứ hơn trong cùng một đơn vị thời gian. Nói không quá lời, AI là công cụ khuếch đại. Nó khuếch đại cả điểm mạnh lẫn điểm yếu của quy trình hiện tại.

Nếu workflow tốt, AI là đòn bẩy. Nếu workflow lỏng, AI là máy in nợ kỹ thuật tốc độ cao.

Một hướng tiếp cận khác

Một hướng tiếp cận hiệu quả là tách quá trình phát triển thành hai tầng rõ ràng:

• tầng mô tả hệ thống
• tầng sinh code

Ở tầng mô tả, AI được dùng để giúp team mô hình hóa hệ thống: viết contract, gợi ý schema, mô tả workflow, phân tích API shape. Ở tầng sinh code, compiler hoặc generator đảm bảo code được tạo ra theo cấu trúc ổn định. Điều này đặc biệt quan trọng với những phần lặp lại như DTO, validation, routing, controller skeleton.

Khi làm như vậy, team giảm đáng kể khả năng để mỗi prompt sinh ra một biến thể cấu trúc mới. Và đó là một bước rất mạnh để chặn technical debt ngay từ đầu nguồn. Tức là thay vì đợi repository bệnh rồi mới chữa, ta giảm luôn khả năng nó nhiễm bệnh ở phần khung.

Một vài nguyên tắc thực tế để giảm nợ kỹ thuật khi dùng AI

• Giữ pull request nhỏ và tách biệt feature với refactor
• Định nghĩa convention kiến trúc đủ rõ để AI có thể bám theo
• Không để AI tự do chỉnh trực tiếp mọi lớp code production
• Dùng contract hoặc document làm nguồn chân lý cho phần lặp của hệ thống
• Review thay đổi ở mức ý nghĩa hệ thống, không chỉ ở mức code chạy được
• Đo lại duplicate logic, kích thước diff và thời gian review theo thời gian
• Tách generated code với custom logic thật rõ để tránh nhiễu

Đây không phải là bộ luật để làm chậm AI. Đây là cách để AI giúp tăng tốc mà không để lại hóa đơn quá đắt cho tương lai.

Một checklist ngắn cho team backend

• PR do AI hỗ trợ có nằm trong phạm vi reviewer đọc kỹ được không
• Task có được chia nhỏ đủ để semantic change rõ ràng không
• Contract, docs hoặc brief có được cập nhật cùng code không
• Logic lặp lại có được gom về generator hoặc shared abstraction không
• Reviewer có kiểm tra impact lên kiến trúc chứ không chỉ syntax không

Nếu các câu này liên tục được trả lời bằng “để sau”, rất tiếc phải thông báo là khoản vay kỹ thuật của bạn đang phát triển khá khỏe mạnh.

Debt tốt và debt xấu khác nhau ở chỗ nào?

Không phải mọi technical debt đều xấu. Có những khoản nợ là quyết định chiến lược: chấp nhận làm bản tạm để kiểm chứng thị trường rồi lên kế hoạch dọn sau. Khoản nợ xấu là khoản nợ không ai nhìn thấy, không ai sở hữu và cứ tăng lên do tốc độ vượt khỏi kiểm soát. AI coding rất dễ làm loại nợ thứ hai lớn nhanh nếu team không đủ tỉnh táo.

Kết luận

AI coding mang lại tốc độ phát triển rất lớn, nhưng chính tốc độ đó có thể làm technical debt tăng nhanh nếu hệ thống không có cấu trúc và workflow đủ rõ. Vấn đề không nằm ở chuyện dùng hay không dùng AI. Vấn đề nằm ở việc đội ngũ có kiểm soát được nơi AI tác động, cách code được sinh ra và mức độ nhất quán của toàn hệ thống hay không.

Nói ngắn gọn, tốc độ bản thân nó không xấu. Nhưng tốc độ đi kèm với thiếu kỷ luật thường rất đắt. Dân kỹ thuật có thể thích cảm giác xong việc nhanh, nhưng production thì thường bắt chúng ta thanh toán bằng những tháng ngày refactor âm thầm sau đó. Muốn AI giúp team khỏe hơn, đừng chỉ hỏi “viết nhanh cỡ nào”. Hãy hỏi thêm “đã có cơ chế nào để nợ kỹ thuật không tăng cùng tốc độ đó chưa?”.

Một câu hỏi lãnh đạo kỹ thuật nên hỏi thường xuyên

Mỗi khi team khoe tốc độ mới nhờ AI coding, CTO hoặc tech lead nên hỏi thêm một câu khá lạnh lùng nhưng rất hữu ích:

Tốc độ đó đang được mua bằng gì?

Nếu câu trả lời là diff to hơn, review mệt hơn và pattern rối hơn, thì đó không phải năng suất bền vững. Đó là chuyển chi phí từ hiện tại sang tương lai. Mà tương lai trong phần mềm thường đến rất nhanh.

Một cách nhìn rất thực tế về tốc độ

Tốc độ thật sự không phải số lượng code xuất hiện trong tuần này. Tốc độ thật sự là khả năng hệ thống tiếp tục thay đổi được trong nhiều tháng tới mà không làm cả team kiệt sức. Nếu AI coding làm code ra nhanh nhưng khiến repo khó sửa, khó review và khó tin hơn, thì đó chỉ là tốc độ bề mặt. Còn nếu AI giúp tăng tốc mà team vẫn giữ được cấu trúc, đó mới là productivity đúng nghĩa.

Một nguyên tắc nhớ rất lâu

AI coding không làm nợ kỹ thuật biến mất, cũng không tự làm nó xuất hiện. Nó chỉ khuếch đại cách team đang làm việc. Quy trình tốt sẽ được khuếch đại thành năng suất. Quy trình lỏng sẽ được khuếch đại thành gánh nặng. Nhớ được nguyên tắc này, team sẽ bớt bị mê hoặc bởi tốc độ ngắn hạn và tỉnh táo hơn với chi phí dài hạn.

Và một khi team đã nhìn thấy mối liên hệ giữa tốc độ, review và technical debt, họ sẽ dùng AI bình tĩnh hơn rất nhiều. Đó là dấu hiệu rất tốt của một tổ chức kỹ thuật trưởng thành.