IA y machine learning
El asistente de IA escribe en segundos la estructura de un add-in de AutoCAD. Parece convincente, y llama a un método que no existe en la API. O compila sin errores y utiliza una clase que, en .NET 10, lanza una excepción en tiempo de ejecución. La IA acelera notablemente la programación. Pero si el resultado sirve lo sigue decidiendo alguien que entiende la materia.
Qué se desplaza
Ebi F. Eilber, director general de Cadida y con más de 25 años en el desarrollo de CAD, lo resume así: la programación la asume cada vez más la IA. Tanto más importantes se vuelven la creatividad, el conocimiento técnico, la comprensión del producto, la innovación y el aseguramiento de la calidad.
- Creatividad: ¿qué solución es la correcta? La IA responde a la pregunta que se le hace, no a la que se le debería haber hecho.
- Conocimiento técnico: ¿cómo se comporta una referencia de bloque, qué exige una norma, qué ruido tiene un sensor? Sin este conocimiento, un error plausible pasa desapercibido.
- Comprensión del producto: ¿qué necesita realmente el usuario y qué no debe ocurrir en ningún caso?
- Innovación: lo nuevo surge de la experiencia y de las ideas, no de la media de ejemplos conocidos.
- Aseguramiento de la calidad: si el código se crea más rápido, también debe revisarse más rápido y a fondo.
Dónde ayuda hoy la IA
La IA es muy adecuada para estructuras y código repetitivo, para transformar programas existentes, por ejemplo en una portabilidad, para casos de prueba que de otro modo se omiten por falta de tiempo y para explicar código ajeno. Cuanto más extendida está una técnica, mejor la conoce la IA. Con API especializadas como AutoCAD, Revit o FeatureCAM, con controladores de dispositivos y con cambios de versión se vuelve más insegura, y aun así suena igual de convencida.
Dónde se equivoca
Un ejemplo bien estudiado son los paquetes inventados. Para un estudio presentado en USENIX Security 2025, 16 modelos de lenguaje generaron 576.000 ejemplos de código. Por término medio, al menos el 5,2 % de los paquetes recomendados por los modelos comerciales y el 21,7 % de los recomendados por los modelos de libre acceso eran inventados. Es más que una molestia: los atacantes pueden registrar esos nombres y publicar código malicioso con ellos.
Un segundo ejemplo es la propia percepción. En un estudio aleatorizado de METR de 2025, 16 desarrolladores experimentados de código abierto necesitaron con herramientas de IA, por término medio, un 19 % más de tiempo para sus tareas, y después estimaron que habían sido un 20 % más rápidos. La propia METR señala que las herramientas han evolucionado desde entonces y que el resultado no debe generalizarse. La lección sigue siendo válida: medir en lugar de estimar.
Aseguramiento de la calidad para el código de IA
- Revisión como con un compañero nuevo: cada cambio lo lee alguien que es responsable del código.
- Primero las pruebas: los criterios de aceptación y los casos de prueba determinan qué es correcto, no el asistente.
- Comprobar automáticamente: las pruebas unitarias y de interfaz, el análisis estático y las comprobaciones de seguridad se ejecutan en cada compilación.
- Confidencialidad: el código de los clientes y los secretos comerciales solo deben ir a servicios de IA cuyo contrato y tratamiento de datos estén aclarados.
- Autorizar las dependencias: los paquetes nuevos solo entran en el proyecto tras ser revisados. Un pequeño script en la compilación detiene todo lo que no está autorizado:
import re
import sys
def paketnamen(pfad):
"""Lee los nombres de paquete de un archivo requirements, normalizados según PEP 503."""
namen = set()
with open(pfad, encoding="utf-8") as datei:
for zeile in datei:
zeile = zeile.split("#")[0].strip()
if zeile and not zeile.startswith("-"):
name = re.split(r"[\s\[<>=!~;@]", zeile, maxsplit=1)[0]
namen.add(re.sub(r"[-_.]+", "-", name).lower())
return namen
neu = paketnamen("requirements.txt") - paketnamen("freigegeben.txt")
for name in sorted(neu):
print("Nicht freigegeben:", name)
sys.exit(1 if neu else 0)
Lo decisivo es la autorización, no la mera existencia de un paquete. Un nombre inventado puede haberlo registrado ya hace tiempo un atacante. Y la responsabilidad sigue donde estaba: el Cyber Resilience Act no pregunta si el código lo ha escrito una persona o una IA. Quien responde de la seguridad del producto es el fabricante.
Errores típicos
- Adoptar código de IA porque compila.
- No contrastar las propuestas para API especializadas con la documentación de la versión utilizada.
- Instalar paquetes que propone el asistente sin revisarlos.
- Dejar que la IA escriba también las pruebas y fijarse solo en que estén en verde.
- Estimar el ahorro de tiempo en lugar de medirlo.
- Dejar que los recién incorporados solo formulen instrucciones. Sin conocimiento técnico, no reconocen los errores.
Cómo le ayudamos
- Revisión de código: revisamos su código en busca de errores y vulnerabilidades, también si se ha creado con IA: control de calidad y revisión de código.
- Automatización de pruebas: con nuestro producto TesteriX prueba automáticamente aplicaciones de escritorio en cada compilación: automatización de pruebas.
- Desarrollar conocimiento técnico: quien modela bien los requisitos obtiene también mejores resultados de la IA, por ejemplo tras la formación en UML o la formación «AutoCAD .NET API con C#».
- Su proyecto: Concierte una primera conversación.
Fuentes: J. Spracklen et al., «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», USENIX Security 2025; METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», julio de 2025; valoración: Ebi F. Eilber, director general de Cadida Software GmbH.
