Một Backend Developer nhận yêu cầu bổ sung chức năng rút tiền cho ứng dụng. Thay vì tự viết từng dòng code, anh mở AI coding assistant, mô tả yêu cầu và chỉ sau vài phút đã có API, database migration cùng một bộ unit test. Code nhìn gọn gàng, các bài kiểm tra đều chạy thành công và tính năng nhanh chóng được đưa vào bản release tiếp theo.
Nhưng vài ngày sau, hệ thống bắt đầu xuất hiện những giao dịch rút tiền bất thường. Có yêu cầu bị xử lý hai lần, một số giao dịch thành công ở hệ thống đối tác nhưng lại được ghi nhận thất bại ở ứng dụng. Cả đội phải kiểm tra log, đối soát dữ liệu, bổ sung cơ chế xử lý trùng lặp và sửa lại luồng nghiệp vụ mà ban đầu tưởng chừng đã hoàn chỉnh.
Đây là một tình huống giả định, nhưng phản ánh một vấn đề đáng quan tâm khi sử dụng AI để phát triển phần mềm: chúng ta có thể tạo ra code nhanh hơn rất nhiều, nhưng chi phí để hiểu, kiểm chứng và bảo trì code không nhất thiết giảm theo cùng tốc độ. Nếu không có quy trình kiểm soát phù hợp, lợi ích tiết kiệm vài giờ phát triển ban đầu có thể bị bù trừ bởi nhiều ngày xử lý sự cố về sau.
- Technical Debt là gì và vì sao AI khiến vấn đề đáng quan tâm hơn?
Technical Debt, hay nợ kỹ thuật, là cách mô tả những chi phí hoặc khó khăn phát sinh trong tương lai từ các quyết định kỹ thuật hiện tại. Chẳng hạn, một nhóm lựa chọn triển khai nhanh bằng cách viết logic trực tiếp vào API handler thay vì tổ chức thành các thành phần có trách nhiệm rõ ràng. Quyết định ấy có thể phù hợp với một prototype nhỏ, nhưng khi tính năng phát triển, việc sửa đổi và kiểm thử có thể trở nên khó khăn hơn.
Nợ kỹ thuật không phải lúc nào cũng là kết quả của code kém chất lượng. Đôi khi, đó là sự đánh đổi có chủ đích để đáp ứng thời hạn kinh doanh, miễn là đội ngũ hiểu rõ hệ quả và có kế hoạch xử lý khi cần. Vấn đề đáng lo hơn là những khoản nợ xuất hiện mà không ai nhận ra, đặc biệt khi code vẫn chạy tốt trong các tình huống đơn giản.
AI coding assistants giúp developer triển khai tính năng nhanh hơn, nhưng cũng có thể làm tăng lượng code được đưa vào hệ thống trong thời gian ngắn. Nếu tốc độ review, testing và kiểm soát kiến trúc không theo kịp, đội ngũ dễ tích lũy những đoạn code trùng lặp, các giả định nghiệp vụ chưa được kiểm chứng hoặc những thành phần khó thay đổi về sau.
Nghiên cứu công bố tại hội nghị MSR 2026 về việc ứng dụng coding agents trong các repository mã nguồn mở ghi nhận một số chỉ báo chất lượng như cảnh báo phân tích tĩnh và độ phức tạp nhận thức gia tăng sau khi áp dụng agents. Tuy nhiên, đây là kết quả trong phạm vi dữ liệu và phương pháp nghiên cứu cụ thể, không có nghĩa mọi dự án sử dụng AI đều sẽ gặp vấn đề tương tự.
Điều đáng quan tâm không phải AI viết được bao nhiêu dòng code, mà là sau khi code được merge, đội ngũ có còn đủ khả năng hiểu, thay đổi và vận hành nó một cách an toàn hay không.
- Khi code chạy đúng nhưng thiết kế vẫn chưa giải quyết hết vấn đề
Hãy quay lại tình huống API rút tiền. Một yêu cầu nghiệp vụ ban đầu có thể được mô tả khá đơn giản: kiểm tra số dư, tạo giao dịch rút tiền, gọi đối tác thanh toán và cập nhật trạng thái.
Với yêu cầu ấy, AI hoàn toàn có thể tạo ra một implementation hợp lý, nhưng câu hỏi quan trọng là điều gì xảy ra khi hệ thống không vận hành theo kịch bản lý tưởng.
Giả sử một khách hàng gửi yêu cầu rút 500.000 đồng. Backend gọi API đối tác và đối tác đã xử lý thành công, nhưng kết nối bị gián đoạn trước khi phản hồi quay về. Backend nhận timeout và đánh dấu giao dịch thất bại; khách hàng nhìn thấy thông báo lỗi nên bấm rút tiền lần nữa.
Nếu không có cơ chế nhận diện yêu cầu trùng lặp và đối soát kết quả với đối tác, hệ thống có nguy cơ tạo thêm một giao dịch rút tiền, dù yêu cầu ban đầu thực tế đã được xử lý.
Trong trường hợp này, một API trả về đúng HTTP status, sử dụng transaction ở database và vượt qua unit test vẫn chưa đủ để bảo đảm tính chính xác của toàn bộ quy trình. Database transaction có thể bảo vệ những thay đổi trong một cơ sở dữ liệu, nhưng không tự động khiến việc cập nhật database và gọi API bên ngoài trở thành một thao tác nguyên tử.
Để xử lý đúng, đội ngũ cần làm rõ nhiều vấn đề hơn: mỗi yêu cầu có được gắn idempotency key hay không, timeout được xem là thất bại hay trạng thái chưa xác định, đối tác có hỗ trợ truy vấn trạng thái giao dịch không và hệ thống sẽ phục hồi thế nào nếu tiến trình bị dừng giữa chừng.
Một thiết kế phù hợp có thể sử dụng trạng thái PENDING để ghi nhận kết quả chưa xác định, kết hợp idempotency, đối soát và quy trình retry có kiểm soát. Cách triển khai cụ thể phụ thuộc vào hợp đồng API, hệ thống lưu trữ và yêu cầu nghiệp vụ, nhưng nguyên tắc chung là không được biến một kết quả chưa biết thành kết luận chắc chắn rằng giao dịch đã thất bại.
Technical Debt trong trường hợp này không chỉ nằm ở vài dòng code thiếu kiểm tra, mà còn ở một quyết định thiết kế chưa làm rõ cách hệ thống xử lý những trạng thái bất thường. Khi phát hiện sau khi triển khai, việc sửa lỗi có thể ảnh hưởng đến database schema, API contract, quy trình đối soát và cả cách ứng dụng hiển thị thông tin cho khách hàng.
Đó là lý do một thay đổi nhỏ về mặt chức năng đôi khi trở thành một công việc lớn về mặt hệ thống.
- Vì sao AI có thể làm nợ kỹ thuật khó nhận ra hơn?
Một đoạn code do AI tạo ra thường có hình thức khá thuyết phục: tên hàm rõ ràng, cấu trúc dễ đọc, comment đầy đủ và đôi khi có cả unit test đi kèm. Những yếu tố này giúp developer tiết kiệm thời gian, nhưng cũng có thể khiến người review tập trung vào việc code có chạy hay không mà bỏ qua câu hỏi thiết kế đã phù hợp với hệ thống hiện tại chưa.
Chẳng hạn, một codebase đã có PaymentService chịu trách nhiệm kiểm soát trạng thái giao dịch, nhưng AI lại tạo thêm logic xử lý thanh toán trực tiếp trong controller vì chưa được cung cấp đủ ngữ cảnh kiến trúc. Tính năng mới vẫn hoạt động, song hệ thống bắt đầu tồn tại hai nơi cùng xử lý một nghiệp vụ; khi quy tắc thay đổi, developer phải sửa cả hai và có nguy cơ bỏ sót một nơi.
Một dạng vấn đề khác là code được tạo quá nhiều so với nhu cầu. AI có thể đề xuất thêm abstraction, interface, configuration hoặc cơ chế retry mà hệ thống thực tế chưa cần, khiến một yêu cầu đơn giản trở nên khó đọc và khó bảo trì hơn. Ngược lại, nếu chỉ cung cấp một yêu cầu ngắn, công cụ cũng có thể chọn giải pháp quá đơn giản và bỏ qua những ràng buộc quan trọng.
Những rủi ro này không hoàn toàn mới. Developer vẫn có thể tạo ra code trùng lặp hoặc thiết kế không phù hợp khi làm việc mà không sử dụng AI. Điểm khác biệt là công cụ sinh code có thể giúp những quyết định ấy được triển khai nhanh hơn, trên phạm vi lớn hơn, trước khi đội ngũ kịp đánh giá đầy đủ.
Báo cáo DORA 2025 của Google nhấn mạnh rằng AI chủ yếu đóng vai trò khuếch đại năng lực hiện có của tổ chức. Một nhóm có quy trình phát triển tốt có thể tận dụng AI để tạo ra nhiều giá trị hơn; ngược lại, những điểm yếu trong quy trình, nền tảng kỹ thuật hoặc phối hợp đội ngũ vẫn có thể làm hạn chế lợi ích đạt được.
Vì vậy, thay vì chỉ hỏi “AI đã giúp team viết code nhanh hơn bao nhiêu?”, chúng ta cũng cần hỏi “Những thay đổi ấy có khiến hệ thống dễ hiểu, dễ kiểm thử và dễ phát triển hơn không?”.
- Làm thế nào để tận dụng AI mà không tích lũy nợ kỹ thuật ngoài ý muốn?
Giải pháp không phải quay lại viết mọi thứ thủ công, bởi AI vẫn mang lại giá trị lớn trong việc tạo bản nháp, giải thích code, hỗ trợ refactor và xây dựng test. Điều quan trọng là thay đổi cách giao việc cho AI và cách đánh giá kết quả.
Trước khi sinh code, hãy làm rõ yêu cầu và những ràng buộc quan trọng. Thay vì chỉ yêu cầu “Viết API rút tiền bằng Go”, developer nên mô tả luồng nghiệp vụ, trạng thái giao dịch, các trường hợp timeout, yêu cầu idempotency và những thành phần hiện có cần được tái sử dụng. Nếu chưa chắc phương án nào phù hợp, có thể yêu cầu AI phân tích các lựa chọn thiết kế trước khi triển khai.
Trong quá trình phát triển, ưu tiên những thay đổi nhỏ và dễ kiểm chứng. Một pull request chỉ tập trung vào một trách nhiệm thường dễ review hơn một thay đổi lớn tác động đến nhiều service cùng lúc. Khi AI đề xuất tạo thêm abstraction hoặc dependency, hãy kiểm tra chúng có thực sự giải quyết vấn đề hiện tại hay chỉ làm tăng độ phức tạp không cần thiết.
Trước khi merge, kiểm thử các trường hợp có khả năng gây thiệt hại thực tế. Ngoài happy path, đội ngũ cần chú ý đến duplicate requests, concurrency, timeout, partial failure và khả năng phục hồi. Với những thay đổi liên quan đến tiền, phân quyền hoặc dữ liệu nhạy cảm, việc kiểm chứng nên dựa trên các yêu cầu nghiệp vụ rõ ràng, không chỉ dựa vào những unit test do cùng một công cụ AI tạo ra.
Sau khi triển khai, tiếp tục đo lường và quan sát hệ thống. Một API có thể vượt qua tất cả bài test nhưng vẫn bộc lộ vấn đề khi gặp dữ liệu hoặc tải thực tế. Metrics, logs, distributed tracing và cảnh báo bất thường giúp developer phát hiện những dấu hiệu cần điều tra, đồng thời tạo dữ liệu để đánh giá hiệu quả của thay đổi.
Một cách bắt đầu thực tế là chọn một tính năng đang được phát triển với AI và yêu cầu người phụ trách giải thích ba điều trước khi merge: thay đổi này phục vụ yêu cầu nghiệp vụ nào, những tình huống nào có thể khiến nó thất bại và nhóm sẽ phát hiện sự cố bằng cách nào sau khi triển khai. Nếu không trả lời được, có thể chúng ta đang đưa vào production một phần hệ thống mà chính mình chưa hiểu đầy đủ.
- Đừng chỉ đo tốc độ viết code, hãy đo chi phí tạo ra giá trị
Một team sử dụng AI có thể hoàn thành nhiều pull request hơn, nhưng số lượng PR không phản ánh đầy đủ hiệu quả phát triển phần mềm. Nếu những thay đổi mới liên tục tạo ra regression, khiến developer phải sửa lại hoặc làm tăng thời gian xử lý sự cố, năng suất đo bằng số lượng code có thể đang che giấu chi phí phát sinh ở các giai đoạn sau.
Để đánh giá AI có thực sự giúp đội ngũ làm việc hiệu quả hơn, chúng ta nên xem xét kết hợp nhiều chỉ số thay vì chỉ đo tốc độ hoàn thành task.
Chỉ số Điều cần quan sát Lead time for changes Từ lúc bắt đầu thay đổi đến khi được triển khai mất bao lâu? Change failure rate Bao nhiêu thay đổi triển khai gây sự cố hoặc cần khắc phục? Failed deployment recovery time Khi triển khai gây lỗi, đội ngũ mất bao lâu để phục hồi? Rework và regression Bao nhiêu công việc phải làm lại do lỗi hoặc thiết kế chưa phù hợp? Maintainability Việc sửa đổi, kiểm thử và mở rộng tính năng có trở nên khó khăn hơn không?
Những chỉ số này không nên được sử dụng riêng lẻ để đánh giá năng suất cá nhân, bởi kết quả còn phụ thuộc độ phức tạp của công việc, đặc điểm hệ thống và nhiều yếu tố ngoài khả năng kiểm soát của một developer.
Điểm quan trọng là nhìn vào toàn bộ quá trình đưa một thay đổi đến tay người dùng. Nếu AI giúp viết code nhanh hơn nhưng thời gian review, sửa lỗi và phục hồi sự cố tăng lên, đội ngũ cần xem xét lại cách sử dụng công cụ và quy trình kiểm soát chất lượng.
Ngược lại, nếu AI giúp giảm công việc lặp lại, cải thiện khả năng kiểm thử và đưa thay đổi vào production an toàn hơn, đó mới là lợi ích đáng đầu tư lâu dài.
Kết luận: Code được tạo ra nhanh, nhưng trách nhiệm không thể được rút ngắn
Hãy quay lại tình huống API rút tiền ở đầu bài. Việc tạo ra một endpoint có thể chỉ mất vài phút, nhưng để bảo đảm giao dịch không bị xử lý trùng, dữ liệu luôn nhất quán và hệ thống có thể phục hồi sau timeout, đội ngũ cần nhiều hơn một bản implementation chạy thành công.
Điều này không có nghĩa AI là nguyên nhân của mọi khoản nợ kỹ thuật, bởi những quyết định thiết kế thiếu cân nhắc đã tồn tại từ lâu trước khi coding assistants xuất hiện. Tuy nhiên, khi tốc độ tạo code tăng lên, chúng ta càng cần bảo đảm năng lực thiết kế, review, testing và vận hành theo kịp.
Một developer giỏi không nhất thiết phải tự viết tất cả code, nhưng cần hiểu điều gì đang được đưa vào hệ thống và những rủi ro mà thay đổi ấy có thể tạo ra. Tương tự, một đội ngũ kỹ thuật hiệu quả không chỉ hoàn thành nhiều tính năng hơn mà còn phải duy trì được khả năng phát triển sản phẩm một cách bền vững.
AI có thể giúp chúng ta giảm thời gian viết code, nhưng giá trị thực sự chỉ xuất hiện khi phần thời gian tiết kiệm được không biến thành chi phí sửa lỗi và bảo trì trong tương lai.
⸻
Nguồn tham khảo
- DORA / Google — 2025 State of AI-assisted Software Development Report: https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
- Agarwal và cộng sự — AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development (MSR 2026): https://doi.org/10.1145/3793302.3793589
- JetBrains Research — Evolving with AI: A Longitudinal Analysis of Developer Logs (2026): https://kairos.jetbrains.com/research/publications/evolving-with-ai
Bài viết sử dụng tình huống giả định về hệ thống rút tiền để giải thích rủi ro kỹ thuật, không mô tả một sự cố có thật tại doanh nghiệp cụ thể. Những nhận định về quy trình phát triển phần mềm là phân tích thực hành, không phải kết luận rằng mọi dự án sử dụng AI đều tích lũy nợ kỹ thuật.
Tân Mít — Technology, AI & Software Engineering
https://thanhtanmit.com