How AI Tools Generate Technical Debt in IoT Systems — and What to Do About It
How AI Tools Generate Technical Debt in IoT Systems — and What to Do About It
AI 工具如何在物联网系统中产生技术债——以及如何应对
AI tools speed up IoT development — but closer to the hardware, the same code that looks correct can silently break thousands of devices at once. AI 工具加快了物联网（IoT）的开发速度，但在靠近硬件的层面，那些看起来正确的代码可能会在瞬间悄无声息地导致数千台设备瘫痪。
On June 4, 1996, the first launch of Ariane 5 took place — a new European heavy-lift launch vehicle designed to deliver payloads into low Earth orbit. The rocket exploded less than 40 seconds after liftoff. This was caused by specification and design errors in the software of the inertial navigation system. A software module had been reused from the previous Ariane 4 version without verifying whether its constraints were suitable for the new environment. It became one of the most expensive software errors in history. 1996 年 6 月 4 日，欧洲新型重型运载火箭“阿丽亚娜 5 号”（Ariane 5）进行了首次发射，旨在将有效载荷送入近地轨道。火箭在升空不到 40 秒后便发生爆炸。事故原因是惯性导航系统的软件存在规格和设计错误。开发人员直接复用了“阿丽亚娜 4 号”的软件模块，却未验证其约束条件是否适用于新环境。这成为了历史上代价最昂贵的软件错误之一。
Why am I recalling an event from thirty years ago in a text about technical debt generated by AI tools? Because it helps us remember a simple truth: in complex systems, what is dangerous is not only “bad code,” but also code that looks acceptable yet does not match the context. AI assistants reproduce a similar issue. 为什么我要在一篇关于 AI 工具产生技术债的文章中回顾三十年前的事件？因为它提醒了我们一个简单的真理：在复杂系统中，危险的不仅是“烂代码”，还有那些看起来没问题、却与上下文环境不匹配的代码。AI 助手正在重演类似的问题。
As a specialist in the IIoT field, particularly in predictive maintenance, I see the following: AI tools quickly generate functional code that appears appropriate for a local task, but they do not verify their own assumptions at the level of the entire system. In IIoT, this means a solution may be correct at the level of an individual function or service, but fail to account for constraints of specific hardware, data flow, architectural boundaries, or real-world device operating conditions. As a result, locally correct code becomes a source of systemic failures and costly fixes, leading to the slower development of the entire platform. 作为一名工业物联网（IIoT）领域的专家，特别是在预测性维护方面，我观察到：AI 工具能快速生成看似适用于局部任务的功能性代码，但它们无法在整个系统层面验证自身的假设。在 IIoT 中，这意味着一个解决方案在单个函数或服务层面可能是正确的，却忽略了特定硬件、数据流、架构边界或现实设备运行条件的约束。结果，局部正确的代码反而成了系统性故障和高昂修复成本的源头，导致整个平台的开发进度变慢。
Four types of technical debt from AI
AI 带来的四种技术债
Technical debt is any decision that speeds things up now but costs more later. I would highlight four main mechanisms through which AI tools can generate technical debt. 技术债是指任何为了眼前的速度而牺牲未来成本的决策。我认为 AI 工具产生技术债主要通过以下四种机制：
1. Reproducing legacy patterns and errors
1. 复刻遗留模式与错误
An AI assistant generates suggestions based on the context of the code it sees in the current environment and is not always able to identify broader design or architectural issues. GitHub explicitly notes that Copilot has a limited scope, relies on the context of the code being written, and can also inherit mistakes and biases from existing repositories. Therefore, if a project already contains outdated approaches, redundant data storage, or “workarounds” instead of proper architectural solutions, the AI treats this as the norm and continues to replicate it. In this sense, it works like an echo chamber: poor practices are not just preserved, but scaled faster. AI 助手根据当前环境中的代码上下文生成建议，但并不总能识别出更广泛的设计或架构问题。GitHub 明确指出，Copilot 的作用范围有限，依赖于正在编写的代码上下文，并且可能会继承现有存储库中的错误和偏见。因此，如果一个项目已经包含了过时的方法、冗余的数据存储或“权宜之计”而非合理的架构方案，AI 会将其视为常态并继续复制。从这个意义上说，它就像一个回声室：糟糕的做法不仅被保留了下来，反而被更快地规模化了。
2. “Quick fixes” without architectural awareness
2. 缺乏架构意识的“快速修复”
AI is very effective at solving local engineering tasks: it can quickly generate tests, write boilerplate code, or create standard CRUD endpoints. However, it does not see the architecture — which databases are used for which data, what limits are in place, and how components interact with each other. A study by Ox Security of 300 open-source projects, 50 of which were fully or partially AI-generated, found that the code was functional but systematically lacked architectural judgment. As a result, AI can create technical debt even without reproducing legacy patterns. AI 在解决局部工程任务方面非常有效：它可以快速生成测试、编写样板代码或创建标准的 CRUD 接口。然而，它看不见架构——不知道哪些数据库用于存储哪些数据、存在哪些限制，以及组件之间是如何交互的。Ox Security 对 300 个开源项目（其中 50 个完全或部分由 AI 生成）的研究发现，这些代码虽然功能正常，但在架构判断上存在系统性缺失。因此，即使不复刻遗留模式，AI 也会产生技术债。
3. Duplication of logic and increased maintenance complexity
3. 逻辑重复与维护复杂度的增加
An AI assistant does not know that the code it needs already exists elsewhere in the system, so it writes a new version. The result is multiple independent implementations of the same logic — and when a change is needed, developers spend time searching for all duplicates. An analysis of 211 million modified lines of code from 2020–2024 by GitClear showed that the share of duplicated code increased from 8.3% to 12.3%. 2024 became the first year in which the amount of duplicated code exceeded the amount of refactoring. AI tools are likely to further accelerate this trend. AI 助手不知道它需要的代码在系统中是否已经存在，因此它会编写一个新版本。结果就是同一逻辑出现了多个独立的实现——当需要修改时，开发人员必须花费时间去寻找所有的重复代码。GitClear 对 2020 年至 2024 年间 2.11 亿行修改代码的分析显示，重复代码的比例从 8.3% 上升到了 12.3%。2024 年成为重复代码量首次超过重构代码量的一年。AI 工具很可能会进一步加速这一趋势。
4. Ignoring hardware constraints
4. 忽视硬件约束
IoT devices do not have the limitless resources of cloud services. A gateway has a specific amount of memory, limited network bandwidth, and a fixed battery budget. An AI assistant… 物联网设备不像云服务那样拥有无限的资源。网关拥有特定的内存容量、有限的网络带宽以及固定的电池预算。AI 助手……