Công cụ AI đang tạo ra "nợ kỹ thuật" trong hệ thống IoT như thế nào và giải pháp là gì?

Vào ngày 4 tháng 6 năm 1996, chuyến phóng đầu tiên của tên lửa Ariane 5 đã diễn ra. Đây là tên lửa hạng nặng mới của châu Âu được thiết kế để đưa tải trọng vào quỹ đạo Trái đất thấp. Tuy nhiên, tên lửa đã phát nổ chưa đầy 40 giây sau khi cất cánh. Nguyên nhân là do các lỗi đặc tả và thiết kế trong phần mềm của hệ thống dẫn đường quán tính. Một module phần mềm đã được tái sử dụng từ phiên bản Ariane 4 trước đó mà không xác minh xem các ràng buộc của nó có phù hợp với môi trường mới hay không. Đây đã trở thành một trong những lỗi phần mềm đắt đỏ nhất trong lịch sử.

Tại sao tôi lại nhắc lại một sự kiện từ ba mươi năm trước trong một bài viết về nợ kỹ thuật do các công cụ AI tạo ra? Bởi vì nó giúp chúng ta nhớ một sự thật đơn giản: trong các hệ thống phức tạp, điều nguy hiểm không chỉ là "mã xấu", mà còn là những đoạn mã có vẻ chấp nhận được nhưng không phù hợp với ngữ cảnh. Các trợ lý AI đang tái hiện một vấn đề tương tự.

Là một chuyên gia trong lĩnh vực IIoT (Internet vạn vật công nghiệp), đặc biệt là về bảo trì dự đoán, tôi nhận thấy điều sau: Các công cụ AI nhanh chóng tạo ra mã nguồn có chức năng, có vẻ phù hợp cho một nhiệm vụ cục bộ, nhưng chúng không xác minh các giả định của mình ở cấp độ toàn hệ thống. Trong IIoT, điều này có nghĩa là một giải pháp có thể đúng ở cấp độ một hàm hoặc dịch vụ riêng lẻ, nhưng lại không tính đến các ràng buộc của phần cứng cụ thể, luồng dữ liệu, ranh giới kiến trúc hoặc điều kiện vận hành thực tế của thiết bị. Kết quả là, mã đúng về mặt cục bộ trở thành nguồn gốc của các lỗi hệ thống và các bản sửa lỗi tốn kém, dẫn đến sự phát triển chậm chạp của toàn bộ nền tảng.

Nợ kỹ thuật vô hình trong hệ thống IoT

Bốn loại nợ kỹ thuật từ AI

Nợ kỹ thuật là bất kỳ quyết định nào giúp tăng tốc độ hiện tại nhưng tốn kém hơn sau này. Tôi muốn làm nổi bật bốn cơ chế chính mà qua đó các công cụ AI có thể tạo ra nợ kỹ thuật.

Sao chép các mẫu mã và lỗi lỗi thời

Một trợ lý AI tạo ra các đề xuất dựa trên ngữ cảnh của mã mà nó thấy trong môi trường hiện tại và không luôn có khả năng xác định các vấn đề thiết kế hoặc kiến trúc rộng lớn hơn. GitHub lưu ý rõ rằng Copilot có phạm vi hạn chế, dựa vào ngữ cảnh của mã đang được viết và cũng có thể kế thừa các lỗi và thiên kiến từ các kho lưu trữ hiện có. Do đó, nếu một dự án đã chứa các cách tiếp cận lỗi thời, lưu trữ dữ liệu dư thừa hoặc các "biện pháp thay thế" thay vì các giải pháp kiến trúc phù hợp, AI sẽ coi đây là tiêu chuẩn và tiếp tục sao chép nó. Theo nghĩa này, nó hoạt động giống như một phòng vang: các thực hành kém không chỉ được bảo tồn mà còn được mở rộng nhanh hơn.

Đây không chỉ là rủi ro lý thuyết. Một nghiên cứu về 304.000 lượt commit do AI tạo ra đã được xác minh trên hơn 6.000 kho lưu trữ thực tế cho thấy hơn 15% các commit từ mỗi trong số năm công cụ AI được đánh giá vẫn còn ít nhất một vấn đề về chất lượng mã, và một phần tư trong số các vấn đề đó vẫn chưa được sửa trong phiên bản cuối cùng của mã.

Trong các hệ thống IoT, cơ chế này đặc biệt nguy hiểm vì một mẫu mã lỗi thời hiếm khi vẫn là một vấn đề cục bộ trong một module duy nhất. Nếu một trợ lý sao chép một giải pháp yếu trong mã phần mềm nhúng (firmware), dịch vụ cổng (gateway) hoặc xử lý遥测 (telemetry), nó sẽ nhanh chóng lan truyền trên toàn bộ chuỗi — từ lớp thiết bị đến phía đám mây của hệ thống.

Các "giải pháp nhanh" mà không có nhận thức kiến trúc

AI rất hiệu quả trong việc giải quyết các nhiệm vụ kỹ thuật cục bộ: nó có thể nhanh chóng tạo ra các bài kiểm tra, viết mã mẫu (boilerplate code) hoặc tạo các điểm cuối CRUD tiêu chuẩn. Tuy nhiên, nó không nhìn thấy kiến trúc — cơ sở dữ liệu nào được dùng cho dữ liệu nào, các giới hạn nào đang được áp đặt và các thành phần tương tác với nhau như thế nào. Một nghiên cứu của Ox Security trên 300 dự án mã nguồn mở, trong đó 50 dự án được tạo hoàn toàn hoặc một phần bởi AI, đã phát hiện ra rằng mã có chức năng nhưng lại thiếu một cách có hệ thống các phán đoán kiến trúc.

Kết quả là, AI có thể tạo ra nợ kỹ thuật ngay cả khi không sao chép các mẫu mã lỗi thời. Nếu các quy tắc kiến trúc không được quy định rõ ràng — trong tài liệu, hồ sơ quyết định hoặc thậm chí trong chính các câu lệnh (prompt) — mô hình sẽ tối ưu hóa nhiệm vụ cục bộ như một nhiệm vụ cô lập. Trong các hệ thống IIoT phức tạp, điều này trông như sau: dữ liệu chuỗi thời gian, dữ liệu tham chiếu và nhật ký được lưu trữ trong các cơ sở dữ liệu khác nhau, mỗi cái được tối ưu hóa cho khối lượng công việc của riêng nó — nhưng trợ lý, khi được yêu cầu lưu trữ dữ liệu mới, không biết về cấu trúc này và tạo ra mã dần dần vi phạm các thỏa thuận kiến trúc đã được nhóm thiết lập.

Nhân đôi logic và tăng độ phức tạp bảo trì

Một trợ lý AI không biết rằng mã nó cần đã tồn tại ở nơi khác trong hệ thống, vì vậy nó viết một phiên bản mới. Kết quả là nhiều triển khai độc lập của cùng một logic — và khi cần thay đổi, các nhà phát triển phải mất thời gian tìm kiếm tất cả các bản sao.

Phân tích 211 triệu dòng mã được sửa đổi từ năm 2020–2024 bởi GitClear cho thấy tỷ lệ mã trùng lặp đã tăng từ 8,3% lên 12,3%. Năm 2024 là năm đầu tiên lượng mã trùng lặp vượt quá lượng tái cấu trúc (refactoring). Các công cụ AI có khả năng sẽ đẩy nhanh xu hướng này hơn nữa. Chúng cho phép chèn một khối mã mới chỉ với một lần nhấn phím, nhưng ít khi đề xuất sử dụng lại một hàm tương tự từ một phần khác của dự án — một phần là do ngữ cảnh hạn chế mà chúng có.

Trong các hệ thống IoT, nếu cùng một logic — ví dụ, phân tích gói tin hoặc xác thực kết nối — được triển khai độc lập ở nhiều nơi, việc sửa lỗi trong một bản sao mà không tìm thấy các bản sao khác có thể dẫn đến việc các thiết bị hiện trường hoạt động khác nhau dưới cùng một tín hiệu đầu vào. Giải quyết các sự không nhất quán này không chỉ đòi hỏi thay đổi mã, mà còn phải đồng bộ hóa các bản cập nhật phần mềm nhúng trên hàng nghìn thiết bị cùng một lúc.

Bỏ qua các ràng buộc phần cứng

Thiết bị IoT không có tài nguyên vô hạn như các dịch vụ đám mây. Một cổng thông tin có một lượng bộ nhớ cụ thể, băng thông mạng hạn chế và ngân sách pin cố định. Một trợ lý AI có thể tính đến các ràng buộc này — nhưng chỉ khi nhà phát triển quy định rõ ràng chúng.

Nếu điều này không xảy ra, trợ lý sẽ tạo ra các giải pháp cho môi trường mà nó chủ yếu được đào tạo — các hệ thống dựa trên máy chủ và đám mây nơi bộ nhớ thực tế là vô hạn và mạng ổn định. Kết quả là có thể dự đoán trước: các vòng lặp thử lại (retry) vô tận không có thời gian chờ (timeout), các định dạng dữ liệu dựa trên văn bản "nặng nề" thay vì các giao thức nhị phân nhỏ gọn, và mã biên dịch đúng nhưng không tính đến các đặc điểm phần cứng cụ thể của một bo mạch cụ thể.

Một giải pháp hoạt động tốt trong trình giả lập có thể thất bại khi chạy trên thiết bị vật lý có tài nguyên hạn chế.

Giải pháp để AI không tạo ra nợ kỹ thuật trong dự án

AI trong các hệ thống IoT đòi hỏi kỷ luật kỹ thuật nghiêm ngặt hơn so với phát triển không có nó. Tôi sẽ mô tả bốn thực hành giúp nhóm của tôi giữ chất lượng mã dưới sự kiểm soát.

Xem xét mã nguồn bởi con người là bắt buộc

Điều này nghe có vẻ hiển nhiên, nhưng trong thực tế, khi làm việc với các trợ lý AI, có sự cám dỗ chấp nhận mã được tạo ra mà không cần phân tích sâu — đặc biệt là vì hơn một nửa số nhà phát triển nói rằng mã thường trông "đúng". Theo một nghiên cứu với hơn 1.100 nhà phát triển, chỉ có 48% luôn xem xét mã do AI tạo ra trước khi commit.

Việc xem xét nên kiểm tra không chỉ mã có biên dịch được hay không, mà còn xem nó có tính đến các ràng buộc của môi trường phần cứng cụ thể hay không, có sự trùng lặp logic nào không, và giải pháp có phù hợp với kiến trúc tổng thể của hệ thống hay không.

Tuy nhiên, xem xét mã thủ công có một vấn đề: các trợ lý AI làm tăng khối lượng và tốc độ mã mới nhanh hơn mức các nhóm có thể thích ứng. Theo LeadDev, 29% tổ chức đang dành nhiều thời gian hơn cho việc xem xét mã so với trước đây. Điều này có nghĩa là trong phát triển dựa trên AI, việc xem xét của con người nhanh chóng tạo ra nút thắt cổ chai nếu nó không được củng cố bằng các rào chắn và kiểm tra tự động.

Hạn chế AI đối với các phần quan trọng của dự án

Không phải tất cả mã đều quan trọng như nhau. Đáng lẽ nên xác định rõ các "vùng cấm" cho việc tạo tự động bởi AI: xử lý các gói tin đến từ thiết bị, logic ủy quyền, xử lý ngắt và logic bộ hẹn giờ watchdog (watchdog timer), và bất kỳ mã nào tương tác trực tiếp với phần mềm nhúng.

Một tiêu chí đơn giản để tách biệt là: nếu một lỗi trong mã này yêu cầu cập nhật phần mềm nhúng trên các thiết bị hiện trường hoặc làm hỏng tính toàn vẹn dữ liệu cho tất cả khách hàng cùng một lúc, thì AI chỉ nên đóng vai trò là trợ lý dưới sự giám sát của con người, và quyết định cuối cùng phải thuộc về nhà phát triển người hiểu ngữ cảnh hệ thống.

Tái cấu trúc và giám sát thường xuyên

Khi tốc độ sản xuất mã tăng lên, tốc độ tích lũy các vấn đề tiềm ẩn cũng tăng theo. Việc tái cấu trúc thường xuyên trở thành không chỉ là thực hành tốt, mà là một sự cần thiết. Theo kinh nghiệm của tôi, kiến trúc nên được xem xét ít nhất mỗi sáu tháng một lần — với sự chú ý riêng biệt đối với các khu vực mà mã do AI tạo ra có thể đã đưa ra các vấn đề tiềm ẩn.

Song song đó, việc giám sát là cần thiết — nhưng trong IoT, nó có phạm vi tập trung rộng hơn so với một hệ thống backend điển hình. Theo kinh nghiệm của tôi, ngoài sự suy giảm hiệu suất ở cấp độ dịch vụ mà các công cụ như Datadog hoặc AWS CloudWatch hiển thị, điều quan trọng là phải theo dõi trạng thái của chính các thiết bị: mức tiêu thụ bộ nhớ tại biên (edge), độ trễ giữa thiết bị và cổng thông tin, và các bất thường trong遥测. Đây là nơi mã do AI tạo ra với các ràng buộc phần cứng không được tính đến thường xuất hiện đầu tiên.

Kết luận

Nợ kỹ thuật đã tồn tại từ lâu trước khi việc sử dụng AI trở nên phổ biến. Tuy nhiên, AI có thể tăng tốc độ tích lũy của nó — đặc biệt là trong các môi trường nơi không có văn hóa tài liệu, quản trị kiến trúc và tái cấu trúc thường xuyên. Trong các hệ thống IoT, chi phí của sự tăng tốc này không chỉ được đo bằng thời gian của nhà phát triển, mà còn bằng độ tin cậy của hàng nghìn thiết bị vật lý.