La IA generativa cambia parte del desarrollo embebido — pero no la parte decisiva. Lo que se ha desplazado, lo que se ha intensificado, y lo que usted obtiene como cliente.
La IA generativa puede producir hoy controladores estándar, máquinas de estado simples y código repetitivo en SystemVerilog, VHDL, C o Python. Es real, es útil y ha reducido el esfuerzo para tareas rutinarias.
De ahí surge una pregunta legítima: ¿qué aporta aún un desarrollador experimentado de embebido y FPGA en este entorno?
La respuesta es concreta.
Una IA es un ejecutor rápido. Produce lo que se le pide — no lo que es necesario. Pedir a una IA «escríbeme un controlador UART» da un controlador UART. Pero no el que realmente funciona con este dominio de reloj, esta asignación de pines, este comportamiento temporal y este manejo de errores en el entorno de destino.
La verdadera labor de ingeniería no es generar código. Es escribir una especificación precisa: qué debe pasar exactamente, bajo qué condiciones, con qué tolerancias, con qué comportamiento en caso de fallo, en qué rango de temperatura, durante qué vida útil.
Una IA mejor no cambia esto. Al contrario: cuanto más capaces se vuelven las herramientas, más decisivo es instruirlas correctamente.
Una IA no añade requisitos en los que el cliente no haya pensado. No inventa casos especiales. Entrega exactamente lo que está en la especificación — y nada más. Lo que no está especificado falta en el resultado.
Esto desplaza el riesgo por completo a la propia especificación. Una especificación inexperta describe correctamente lo que el cliente ha pedido y pasa por alto todo lo que el redactor nunca ha vivido: el raro fallo de sensor con ciertos gradientes de temperatura, el comportamiento durante un brown-out simultáneo y un bloqueo del bus I²C, un reset de watchdog durante una secuencia de escritura en flash, el acoplamiento electromagnético en cables de sensor largos, el comportamiento al rearranque tras un reset involuntario durante una operación de escritura crítica.
Estos puntos no son requisitos del cliente. Son requisitos que un desarrollador experimentado añade porque sabe que de otro modo no aparecerían en ninguna parte. Una especificación es por ello también siempre un catálogo de riesgos — y la profundidad de ese catálogo es proporcional a la experiencia de quien la redacta.
En una investigación de seguridad sobre una bomba de infusión, en la que fui llamado por un fabricante de productos sanitarios, se manifestó un fallo relevante para la seguridad surgido de la aparición simultánea de dos fallos individuales: el fallo de hardware de un chip de memoria y una rutina de verificación errónea para ese mismo chip. Cada fallo por separado era manejable. Solo la combinación produjo el estado de fallo no detectado.
Es precisamente este análisis combinatorio lo que debe añadirse activamente a una especificación. A partir del requisito «verificar la memoria», una herramienta genera una rutina de verificación. La experiencia añade el requisito adicional de que el fallo de la propia rutina de verificación no debe llevar a un estado de fallo silencioso. Ninguna herramienta formula este segundo requisito por sí misma.
A esto se suman los escollos cercanos al hardware que no aparecen en las hojas de datos sino en las cabezas de los desarrolladores que ya los han perseguido alguna vez:
Para la mayoría de las tareas hay varias soluciones que fundamentalmente funcionan. Pero solo unas pocas cumplen los requisitos de seguridad, fiabilidad y vida útil que el producto concreto exige.
Un sistema de IA elige lo que aparecía con frecuencia en sus datos de entrenamiento. Un desarrollador experimentado elige lo que no lleva a la catástrofe en un sistema relevante para la seguridad. Esta decisión de selección no es un detalle de implementación. Es la verdadera ingeniería.
En caso de daño, el legislador exige la prueba de que el producto, en el momento de su puesta en el mercado, se correspondía con el estado del arte. Es la condición central para que un fabricante pueda salir de la responsabilidad por producto. Con la nueva Directiva europea sobre responsabilidad por productos defectuosos y la ley nacional de transposición que la sigue, esta carga de la prueba se refuerza explícitamente para el software y los productos con software integrado.
El estado del arte no es un estado estático. Es lo que se considera habitual entre los profesionales — y actualmente cambia de forma acelerada porque nuevas herramientas y métodos elevan el estándar del mercado en ciclos cortos.
De ahí se sigue: quien desarrolla hoy un sistema embebido debe conocer y usar los métodos más capaces actualmente disponibles. Quien no lo hace genera para su mandante un riesgo de responsabilidad concreto. Esto presupone justamente un desarrollador que domina tanto las herramientas establecidas como las nuevas y que puede tomar la decisión correcta.
Uso herramientas de IA donde ahorran tiempo medible sin crear riesgo: primer borrador de código repetitivo, generación de bancos de prueba, documentación, comprobación de legibilidad.
No las uso como sustituto de:
El resultado: menos esfuerzo en trabajo rutinario, calidad sostenidamente alta en las tareas que realmente sustentan el proyecto, y un proceso de desarrollo documentado que cumple el estado del arte actual.
Encarga a un desarrollador con más de 35 años de experiencia en FPGA y embebido, que conoce las herramientas actuales y puede juzgar sus límites. No obtiene ni un «proyecto generado por IA» ni un «proyecto sin IA». Obtiene un sistema funcional del que una persona concreta asume la responsabilidad — y que, en caso de daño, puede demostrarse que ha sido desarrollado conforme al estado del arte.
Si tiene un proyecto embebido que exige exactamente esta profundidad, hablémoslo directamente. Conversación inicial y evaluación aproximada son gratuitas y sin compromiso.