tuvo lugar el primer lanzamiento del Ariane 5, un nuevo vehículo de lanzamiento europeo de carga pesada diseñado para llevar cargas útiles a la órbita terrestre baja. El cohete explotó menos de 40 segundos después del despegue. Esto se debió a errores de especificación y diseño en el software del sistema de navegación inercial. Se reutilizó un módulo de software de la versión anterior de Ariane 4 sin verificar si sus limitaciones eran adecuadas al nuevo entorno. Se convirtió en uno de los errores de software más caros de la historia.
¿Por qué recuerdo un hecho de hace treinta años en un texto sobre la deuda técnica generada por herramientas de IA? Porque nos ayuda a recordar una verdad simple: en sistemas complejos, lo peligroso no es sólo el “código incorrecto”, sino también el código que parece aceptable pero que no coincide con el contexto. ¿Los asistentes de IA reproducen un problema similar?
Como especialista en el campo IIoT, particularmente en mantenimiento predictivo, veo lo siguiente: las herramientas de IA generan rápidamente código funcional que parece apropiado para una tarea local, pero no verifican sus propias suposiciones a nivel de todo el sistema. En IIoT, esto significa que una solución puede ser correcta a nivel de una función o servicio individual, pero no tener en cuenta las limitaciones de hardware específico, flujo de datos, límites arquitectónicos o condiciones operativas de dispositivos del mundo real. Como resultado, el código correcto localmente se convierte en una fuente de fallas sistémicas y reparaciones costosas, lo que lleva a un desarrollo más lento de toda la plataforma.
Cuatro tipos de deuda técnica de la IA
La deuda técnica es cualquier decisión que acelera las cosas ahora pero cuesta más después. Destacaría cuatro mecanismos principales a través de los cuales las herramientas de IA pueden generar deuda técnica.
Reproducir patrones y errores heredados
Un asistente de IA genera sugerencias basadas en el contexto del código que ve en el entorno actual y no siempre es capaz de identificar problemas arquitectónicos o de diseño más amplios. GitHub señala explícitamente que Copilot tiene un alcance limitado, depende del contexto del código que se escribe y también puede heredar errores y sesgos de los repositorios existentes. Por lo tanto, si un proyecto ya contiene enfoques obsoletos, almacenamiento de datos redundante o “soluciones alternativas” en lugar de soluciones arquitectónicas adecuadas, la IA lo trata como la norma y continúa replicándolo. En este sentido, funciona como una cámara de resonancia: las malas prácticas no sólo se preservan, sino que se escalan más rápidamente.
Y este no es sólo un riesgo teórico. Un estudio de 304.000 confirmaciones verificadas generadas por IA en más de 6.000 repositorios del mundo real mostró que más del 15% de las confirmaciones de cada una de las cinco herramientas de IA evaluadas seguían teniendo al menos un problema de calidad del código, y una cuarta parte de esos problemas permanecen sin solucionar en la versión final del código.
En los sistemas de IoT, este mecanismo es particularmente peligroso porque un patrón heredado rara vez sigue siendo un problema local dentro de un solo módulo. Si un asistente reproduce una solución débil en el código de firmware, los servicios de puerta de enlace o el procesamiento de telemetría, se propaga rápidamente por toda la cadena, desde la capa del dispositivo hasta el lado de la nube del sistema.
“Soluciones rápidas” sin conciencia arquitectónica
La IA es muy eficaz para resolver tareas de ingeniería local: puede generar pruebas rápidamente, escribir código repetitivo o crear puntos finales CRUD estándar. Sin embargo, no ve la arquitectura: qué bases de datos se utilizan para qué datos, qué límites existen y cómo interactúan los componentes entre sí. Un estudio realizado por Ox Security de 300 proyectos de código abierto, 50 de los cuales fueron total o parcialmente generados por IA, encontró que el código era funcional pero carecía sistemáticamente de criterio arquitectónico.
Como resultado, la IA puede crear deuda técnica incluso sin reproducir patrones heredados. Si las reglas arquitectónicas no se establecen explícitamente (en la documentación, los registros de decisiones o incluso en las indicaciones mismas), el modelo optimiza la tarea local como si fuera una tarea aislada. En sistemas IIoT complejos, esto se parece a lo siguiente: las series temporales, los datos de referencia y los registros se almacenan en diferentes bases de datos, cada una optimizada para su propia carga de trabajo, pero el asistente, cuando se le pide que almacene nuevos datos, desconoce esta topología y genera código que viola gradualmente los acuerdos arquitectónicos establecidos por el equipo.
Duplicación de lógica y mayor complejidad de mantenimiento.
Un asistente de IA no sabe que el código que necesita ya existe en otra parte del sistema, por lo que escribe una nueva versión. El resultado son múltiples implementaciones independientes de la misma lógica y, cuando se necesita un cambio, los desarrolladores dedican tiempo a buscar todos los duplicados.
Un análisis de 211 millones de líneas de código modificadas entre 2020 y 2024 realizado por GitClear mostró que la proporción de código duplicado aumentó del 8,3% al 12,3%. 2024 se convirtió en el primer año en el que la cantidad de código duplicado superó la cantidad de refactorización. Es probable que las herramientas de inteligencia artificial aceleren aún más esta tendencia. Permiten insertar un nuevo bloque de código con una sola pulsación de tecla, pero es poco probable que sugieran reutilizar una función similar de otra parte del proyecto, en parte debido al contexto limitado disponible para ellos.
En los sistemas de IoT, si la misma lógica (por ejemplo, análisis de paquetes o validación de conexiones) se implementa en varios lugares de forma independiente, corregir un error en una copia sin encontrar las demás puede hacer que los dispositivos en el campo se comporten de manera diferente bajo la misma señal de entrada. Resolver tales inconsistencias requiere no solo cambiar el código, sino también sincronizar las actualizaciones de firmware en miles de dispositivos simultáneamente.
Ignorar las restricciones de hardware
Los dispositivos IoT no tienen los recursos ilimitados de los servicios en la nube. Una puerta de enlace tiene una cantidad específica de memoria, un ancho de banda de red limitado y un presupuesto de batería fijo. Un asistente de IA puede tener en cuenta estas limitaciones, pero sólo si el desarrollador las especifica explícitamente.
Si esto no sucede, el asistente genera soluciones para el entorno en el que se capacitó principalmente: sistemas basados en la nube y en servidores donde la memoria es efectivamente ilimitada y la red es estable. El resultado es predecible: bucles de reintento interminables sin tiempos de espera, formatos de datos “pesados” basados en texto en lugar de protocolos binarios compactos y código que se compila correctamente pero que no tiene en cuenta las características específicas del hardware de una placa en particular.
Una solución que funciona bien en un emulador puede fallar cuando se ejecuta en un dispositivo físico con recursos limitados.
Qué hacer para que la IA no cree deuda técnica en un proyecto
La IA en los sistemas de IoT requiere una disciplina de ingeniería más estricta que el desarrollo sin ella. Describiré cuatro prácticas que ayudan a mi equipo a mantener bajo control la calidad del código.
Revisión obligatoria del código humano
Esto suena obvio, pero en la práctica, cuando se trabaja con asistentes de IA, existe la tentación de aceptar el código generado sin un análisis profundo, especialmente porque más de la mitad de los desarrolladores dicen que el código generalmente parece “correcto”. Según un estudio de más de 1100 desarrolladores, solo el 48% siempre revisa el código generado por IA antes de enviarlo.
La revisión debe comprobar no sólo si el código se compila, sino también si tiene en cuenta las limitaciones del entorno de hardware específico, si existe alguna duplicación de lógica y si la solución se alinea con la arquitectura general del sistema.
Sin embargo, la revisión manual del código tiene un problema: los asistentes de IA aumentan el volumen y la velocidad del código nuevo más rápido de lo que los equipos pueden adaptarse. Según LeadDev, el 29% de las organizaciones ya dedican más tiempo que antes a la revisión de código. Esto significa que en el desarrollo impulsado por la IA, la revisión humana crea rápidamente un cuello de botella si no se refuerza con barreras de seguridad y controles automatizados.
Restringir la IA para partes críticas del proyecto
No todo el código es igualmente crítico. Vale la pena definir explícitamente “zonas prohibidas” para la generación autónoma de IA: procesamiento de paquetes de dispositivos entrantes, lógica de autorización, manejo de interrupciones y lógica del temporizador de vigilancia, y cualquier código que interactúe directamente con el firmware.
Un criterio simple para la separación es el siguiente: si un error en este código requiere una actualización del firmware en los dispositivos de campo o rompe la integridad de los datos de todos los clientes simultáneamente, entonces la IA solo debe actuar como asistente bajo supervisión humana, y la decisión final debe quedar en manos del desarrollador que comprende el contexto del sistema.
Refactorización y seguimiento periódicos
A medida que aumenta la velocidad de producción de código, también aumenta la velocidad a la que se acumulan los problemas ocultos. La refactorización periódica se convierte no sólo en una buena práctica, sino en una necesidad. Según mi experiencia, la arquitectura debe revisarse al menos una vez cada seis meses, prestando especial atención a las áreas donde el código generado por IA puede haber introducido problemas ocultos.
Paralelamente, se requiere monitoreo, pero en IoT tiene un enfoque más amplio que en un sistema backend típico. Según mi experiencia, más allá de la degradación del rendimiento a nivel de servicio que muestran herramientas como Datadog o AWS CloudWatch, es fundamental realizar un seguimiento del estado de los propios dispositivos: consumo de memoria perimetral, latencia entre el dispositivo y la puerta de enlace y anomalías en la telemetría. Aquí es donde el código generado por IA con restricciones de hardware no contabilizadas tiende a aparecer primero.
Conclusión
La deuda técnica existía mucho antes de que el uso de la IA se generalizara. Sin embargo, la IA puede acelerar su acumulación, especialmente en entornos donde no existe una cultura de documentación, gobernanza arquitectónica y refactorización regular. En los sistemas IoT, el coste de esta aceleración se mide no sólo en el tiempo del desarrollador, sino también en la confiabilidad de miles de dispositivos físicos.