Los agentes de IA en ingeniería necesitan un operating model

Cuando un agente de IA tiene que desarrollar un producto, lo primero que se suele mirar es el modelo y las herramientas: ¿qué LLM, qué CAD, qué simulación? Después de unas semanas de reto robótico estoy convencido: la calidad del resultado la decide el operating model en el que trabaja el agente. Es decir, la cuestión de cómo se trabaja, se decide, se verifica y se aprende.

Como recordatorio: en Next challenge me propuse dejar que un agente de IA desarrollara de forma autónoma un pequeño robot DIY. Desde los requisitos, pasando por la arquitectura, el CAD y el firmware, hasta la simulación. Yo defino el framework y los requisitos; atornillarlo todo lo tengo que hacer yo mismo. Un primer diseño del robot ya está terminado y simulado (construido, todavía no). Lo más interesante es lo que hubo que aprender por el camino.

Fiel al proceso y aun así equivocado

Mi primer borrador del framework consistía básicamente en reglas básicas y un stack tecnológico. El resultado fue bastante mediocre.

El ejemplo más claro: el agente había elegido por su cuenta un kit comercial como base, un chasis redondo de acrílico con dos cubiertas. Pero en su modelo CAD apareció un marco rectangular de aluminio. La foto del producto estuvo todo el tiempo en la carpeta del proyecto. Me di cuenta yo mismo, con solo mirarlo.

Lo llamativo: el agente había respetado todas las reglas del proceso. Requisitos derivados, decisiones documentadas, investigación con fuentes. Lo que faltaba era simplemente un criterio para reconocer un buen trabajo de ingeniería — para él, el marco de aluminio era, dicho de forma exagerada, un «ya vale así». Y yo, de alguna manera, di por hecho que era obvio que el modelo tenía que corresponder con lo que después debía construirse.

La segunda lección me afectó a mí mismo. Desde el principio tenía claro que quería separar el conjunto de reglas (¿cómo trabaja el agente?) del proyecto (¿qué construye?), para poder reutilizarlo. Tampoco había anotado eso como requisito. Me quedó claro al ver los primeros borradores del framework: no, todavía no habíamos llegado.

Mi operating model empieza a tomar forma

Después de dos o tres rondas de revisión, de ahí surgió mi operating model en su forma actual.

A la izquierda entra el Intent: objetivos, requisitos, condiciones de contorno, presupuesto. A la derecha salen paquetes de build, prototipos e informes de prueba. Abajo corre un circuito de control de vuelta, con findings, experiencias y change requests.

Dentro del propio agente hay varios niveles. La parte superior (azul) depende del dominio y de la organización (o, en mi caso, de mí): herramientas como SysML, CAD, ECAD y simulación, además de reglas de diseño, lessons learned y la pregunta de qué puede fabricar y probar realmente la organización (= yo). En mi «empresa unipersonal» eso significa: soldar sí, SMD no, sin impresora 3D, un multímetro. El agente tiene que planificar con lo que yo luego también pueda llevar a cabo.

La parte inferior (amarilla) es el núcleo fijo del operating model. Es válida más allá de cada proyecto y consta de tres capas:

Quien se mueva con soltura en PLM no descubrirá gran cosa nueva aquí. Manual de desarrollo, change management, proceso de aprobación, design guidelines: todo eso existe para equipos humanos desde hace décadas. Un agente necesita lo mismo, solo que mucho más explícito y, en muchos puntos, impuesto de forma automática.

Lo que faltaba al principio

El método, la plataforma y las reglas del juego para las decisiones estaban ahí desde el principio. Lo que faltaba era un criterio para el buen trabajo de ingeniería. El framework lo recibió en la segunda ronda, en forma de design guidelines para cada disciplina, tal como las conoce cualquier departamento de desarrollo. La lección del chasis es una de ellas.

Para mí era igual de importante que estas directrices no se quedaran en el estado del primer día. El agente registra lo que ha aprendido y a partir de ello propone nuevas reglas. Yo decido cuáles de ellas se aplican.

Cuándo confío en el agente

En mi artículo «La IA en la ingeniería necesita reglas y confianza» traté la cuestión de cuándo se puede confiar en el trabajo de una IA. El operating model debe fundamentar precisamente esa confiabilidad. Quiero poder confiar en el resultado sin tener que revisar cada línea yo mismo.

Para eso hace falta, primero, trazabilidad: cada decisión está justificada, cada requisito es trazable hasta la prueba. Después, responsabilidades claras. Las cuestiones técnicas las resuelve el agente solo; los objetivos, el presupuesto, la seguridad y las propias reglas del juego, solo conmigo. Y esos límites los impone la plataforma; una petición en el prompt sería demasiado blanda en sesiones largas. Dato curioso: una vez cambié las reglas del juego yo mismo, directamente y sin CR, y el agente lo notó al arrancar de nuevo y me lo atribuyó a mí. ¡Pillado!

Agentic Engineering no es Vibe Engineering

Andrej Karpathy describió Vibe Coding, en esencia, así: te dejas llevar por el vibe y ves qué sale. Y a menudo se confunden los términos Vibe Engineering y Agentic Engineering. Pero lo que ocurre aquí es cualquier cosa menos «vibe». Hay un framework claro que debe cumplir unos requisitos frente a un Intent, y de forma trazable.

Con esto noto algo que conozco de mi larga experiencia trabajando con IA. Para tareas puntuales y acotadas funciona de maravilla. En proyectos más grandes, donde quizá solo se conoce el Intent pero la dirección aún es muy difusa, y hasta la definition of done solo se puede expresar de forma vaga, solo funciona en diálogo entre persona e IA. Sin IA, este proyecto no habría existido. Pero sin mí, tampoco.

¿Y el robot?

Está tomando forma un robot doméstico tímido. Se asusta con la luz y el ruido y se esconde en la oscuridad, preferiblemente debajo de nuestro sofá. Se simula en una réplica digital de nuestro salón, con el mismo firmware que después correrá en el microcontrolador.

Bajo el capó de «proto-1» hay unos 50 requisitos, todos trazables hasta el caso de prueba, 14 decisiones documentadas, una arquitectura SysML v2 verificada automáticamente y una lista de materiales de casi 75 euros (con un presupuesto fijado de 100 euros). El propio agente había introducido tres bugs en su firmware. Y también los encontró él mismo, en pruebas de escenario y simulación.

Lo siguiente es construirlo. Entonces se verá si el diseño aguanta y cuánto valió la simulación. Según los requisitos, el pequeño huye de la luz y del ruido. En ninguna parte dice que tenga que perseguirme a mí. Tengo curiosidad por ver si se atiene a eso 😉

Indirecta nada sutil: a quien se esté planteando cómo podría ser un operating model para agentes de IA en su propia ingeniería, con requisitos, proceso de cambios y Digital Thread, mis colegas de BHC y PROSTEP y yo le ayudamos encantados.

Preguntas y respuestas

¿Qué es un operating model para agentes de IA en ingeniería?

El marco en el que trabaja un agente, independientemente del proyecto concreto: un método de ingeniería (en mi caso, basado en modelos, architecture first), una plataforma de ingeniería (Git, contenedores, skills, comprobaciones automáticas) y governance con convenciones (derechos de decisión, proceso de cambios, entregas a la persona, nomenclatura). A eso se suma un circuito de control que convierte las experiencias del proyecto en nuevas reglas.

¿En qué se diferencia la ingeniería agéntica del vibe coding?

En el vibe coding se describe a grandes rasgos lo que se quiere obtener y uno se deja sorprender por el resultado. La ingeniería agéntica trabaja frente a un Intent explícito: requisitos con IDs, decisiones documentadas, solicitudes de cambio y verificaciones, de modo que cada resultado se pueda rastrear hasta su requisito.