, 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.
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?.
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.
Four types of technical debt from 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.
Reproducing legacy patterns and errors
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.
And this is not just a theoretical risk. A study of 304,000 verified AI-generated commits across more than 6,000 real-world repositories showed that more than 15% of commits from each of the five evaluated AI tools remained at least one code quality issue, and a quarter of those issues remain unfixed in the final version of the code.
In IoT systems, this mechanism is particularly dangerous because a legacy pattern rarely remains a local issue within a single module. If an assistant reproduces a weak solution in firmware code, gateway services, or telemetry processing, it quickly propagates across the entire chain — from the device layer to the cloud side of the system.
“Quick fixes” without architectural awareness
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. If architectural rules are not explicitly laid out — in documentation, decision records, or even in the prompts themselves — the model optimizes the local task as an isolated one. In complex IIoT systems, this looks like the following: time series, reference data, and logs are stored in different databases, each optimized for its own workload — but the assistant, when asked to store new data, is unaware of this topology and generates code that gradually violates the architectural agreements established by the team.
Duplication of logic and increased maintenance complexity
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. They make it possible to insert a new block of code with a single keystroke, but are unlikely to suggest reusing a similar function from another part of the project — partly due to the limited context available to them.
In IoT systems, if the same logic — for example, packet parsing or connection validation — is implemented in multiple places independently, fixing a bug in one copy without finding the others can lead to devices in the field behaving differently under the same input signal. Resolving such inconsistencies requires not just changing code, but synchronizing firmware updates across thousands of devices simultaneously.
Ignoring hardware constraints
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 can take these constraints into account — but only if the developer explicitly specifies them.
If this does not happen, the assistant generates solutions for the environment it was mostly trained on — cloud and server-based systems where memory is effectively unlimited and the network is stable. The result is predictable: endless retry loops without timeouts, “heavy” text-based data formats instead of compact binary protocols, and code that compiles correctly but does not account for the hardware specifics of a particular board.
A solution that works well in an emulator may fail when running on a physical device with limited resources.
What to do so that AI does not create technical debt in a project
AI in IoT systems requires stricter engineering discipline than development without it. I will describe four practices that help my team keep code quality under control.
Mandatory human code review
This sounds obvious, but in practice, when working with AI assistants, there is a temptation to accept generated code without deep analysis — especially since more than half of developers say the code usually looks “correct.” According to a study of more than 1,100 developers, only 48% always review AI-generated code before committing it.
The review should check not only whether the code compiles, but also whether it accounts for the constraints of the specific hardware environment, whether there is any duplication of logic, and whether the solution aligns with the system’s overall architecture.
However, manual code review has a problem: AI assistants increase the volume and speed of new code faster than teams can adapt. According to LeadDev, 29% of organizations are already spending more time on code review than before. This means that in AI-driven development, human review quickly creates a bottleneck if it is not reinforced with guardrails and automated checks.
Restricting AI for critical parts of the project
Not all code is equally critical. It is worth explicitly defining “no-go zones” for autonomous AI generation: processing incoming device packets, authorization logic, interrupt handling and watchdog timer logic, and any code that directly interacts with firmware.
A simple criterion for separation is this: if a mistake in this code requires a firmware update on field devices or breaks data integrity for all clients simultaneously, then AI should only act as an assistant under human supervision, and the final decision must remain with the developer who understands the system context.
Regular refactoring and monitoring
As the speed of code production increases, the speed at which hidden problems accumulate also increases. Regular refactoring becomes not just good practice, but a necessity. From my experience, the architecture should be reviewed at least once every six months — with separate attention paid to areas where AI-generated code may have introduced hidden issues.
In parallel, monitoring is required — but in IoT it has a broader focus than in a typical backend system. From my experience, beyond service-level performance degradation shown by tools like Datadog or AWS CloudWatch, it is critical to track the state of the devices themselves: edge memory consumption, latency between device and gateway, and anomalies in telemetry. This is where AI-generated code with unaccounted hardware constraints tends to surface first.
Conclusion
Technical debt existed long before the use of AI became mainstream. However, AI can accelerate its accumulation — especially in environments where there is no culture of documentation, architectural governance, and regular refactoring. In IoT systems, the cost of this acceleration is measured not only in developer time, but also in the reliability of thousands of physical devices.