IA y experiencia de desarrollador: el agente como usuario
La IA cambia la experiencia de desarrollador porque tus herramientas tienen un usuario nuevo: el agente de IA. Una CLI o una API pensada para agentes da salida estructurada, errores que se pueden resolver y confirmación explícita en lo destructivo, con una persona al mando de lo sensible. Y lo que le sirve al agente le sirve a tu equipo.
¿Qué es la experiencia de desarrollador y por qué la cambia la IA?
La experiencia de desarrollador (DX) es cómo se vive construir sobre una herramienta: lo que tardas en tener el primer resultado, lo claro que es un error, lo fácil que es encontrar el comando que necesitas y lo que te puedes fiar de la documentación.
Hasta hace poco, al otro lado siempre había una persona. Una persona que lee entre líneas, que reconoce un aviso en rojo y que pregunta a un compañero cuando algo no cuadra.
Ahora, cada vez más a menudo, al otro lado hay un agente de IA. Lee tu documentación, llama a tu CLI, interpreta tus errores y decide el siguiente paso. No pregunta a nadie. Lo que para una persona es ambiguo, para un agente es una apuesta.
Eso no sustituye la DX para personas: la amplía. Tu herramienta tiene que servir a los dos, y con las mismas garantías.
¿Qué necesita un agente de IA para operar tu herramienta?
Partimos de un principio que aplicamos en nuestros productos: todo lo que hace la interfaz lo puede hacer un agente de IA, y al revés. La IA es usuaria de primera, no un añadido. De ahí salen siete reglas.
- Paridad entre consola, CLI y MCP. Si una acción solo existe en la consola, el agente no puede hacerla; si solo existe para el agente, tu equipo no puede revisarla. MCP (Model Context Protocol) es el estándar abierto con el que los agentes usan herramientas externas.
- Salida estructurada y predecible. Los mismos campos, con los mismos nombres, siempre. Nada de mezclar mensajes decorativos con los datos. Un cambio en el formato de salida es un cambio de contrato.
- Confirmación explícita en lo destructivo. Un «¿seguro? [s/N]» interactivo no protege de un agente que responde «s» a todo. Lo que borra algo, o lo cambia sin vuelta atrás, pide una confirmación expresa, distinta de la propia orden.
- Conjuntos de herramientas de solo lectura. Un agente que vigila no necesita poder cambiar nada. Un perfil de solo lectura te deja empezar a usar agentes sin arriesgar la operación.
- Errores que un agente pueda resolver. Qué ha fallado, por qué y qué hacer a
continuación, con un código estable. «Error interno» obliga al agente a adivinar; «falta el
parámetro
device_id; se esperaba un texto» le deja corregirse solo. - Documentación que un agente pueda leer. La descripción de cada herramienta y de cada parámetro es, a la vez, documentación y prompt. Tiene que ser precisa, llevar ejemplos y decir qué hace la herramienta y qué no.
- Operaciones idempotentes. Los agentes reintentan. Repetir una orden no puede duplicar un dispositivo, una alarma o un cobro.
¿Cómo lo aplicamos en nuestros productos?
En NovaeOps, nuestra plataforma AIoT, lo que haces desde la consola se puede hacer por línea de comandos y por MCP: más de 180 operaciones para que tu asistente de IA supervise y opere la plataforma. Las que borran algo piden confirmación expresa.
En CogniX, nuestra IA predictiva, consola, línea de comandos y MCP van en paridad. Y hay un reparto de papeles que importa para la DX: CogniX responde en milisegundos en el camino del dato, y tu asistente de IA lo consulta por MCP para explicarte qué ha pasado. Cada pieza hace lo que sabe hacer a la velocidad que le toca.
¿En qué se diferencia la DX para personas de la DX para agentes?
| Aspecto | DX para personas | DX para agentes |
|---|---|---|
| Descubrir qué se puede hacer | Menús, autocompletado y tutoriales | Una lista de herramientas con descripciones precisas de cada una y de sus parámetros |
| Salida | Tablas legibles, colores y resúmenes | Datos estructurados con campos estables |
| Errores | Un mensaje claro para quien lo lee | Un código estable, la causa y el siguiente paso |
| Operaciones destructivas | Un aviso visible antes de confirmar | Confirmación expresa, distinta de la orden, y aprobación humana si es sensible |
| Permisos | Los del rol de la persona | Un conjunto de herramientas por agente, de solo lectura por defecto |
| Reintentos | La persona ve que algo ya se hizo | Operaciones idempotentes: repetir no duplica |
| Documentación | Guías y ejemplos de uso | Descripciones que el agente lee como instrucciones, sin ambigüedad |
No son dos productos. Es el mismo producto con dos lectores, y casi todo lo que mejora la columna de la derecha mejora también la de la izquierda.
¿Quién está al mando cuando opera un agente?
Una persona. Operable por IA no significa autónomo: todo se puede automatizar y supervisar con IA, y lo sensible espera a una persona. Eso tiene dos partes.
La aprobación de lo sensible
La confirmación expresa de las operaciones destructivas es la primera barrera. La segunda es decidir qué operaciones necesitan, además, que una persona las apruebe antes de ejecutarse. El agente propone; la persona decide. Y queda constancia de quién decidió qué.
El gobierno de las herramientas
Cuando tienes varios agentes y varios servidores MCP, la pregunta deja de ser «¿puede el agente hacer esto?» y pasa a ser «¿qué agente puede usar qué herramienta, con qué identidad y con qué límites?». Hoy cada servidor MCP gestiona los permisos a su manera, o no los gestiona.
Hay un riesgo menos evidente: si la descripción de una herramienta cambia, el agente cambia lo que hace con ella. La documentación que el agente lee forma parte de su comportamiento.
Es el problema que aborda Praesidix, la puerta de control de tus agentes de IA, hoy en laboratorio: una pasarela que se sentará delante de tus servidores MCP, decidirá qué agente usa qué herramienta, con qué identidad y con qué límites, detectará cualquier cambio en la definición de una herramienta para que lo apruebes y dejará un registro de auditoría que no se pueda alterar. Lo contamos con más detalle en gobierno de agentes de IA.
¿Qué gana tu equipo de desarrollo?
Diseñar para agentes obliga a una disciplina que tu equipo agradece:
- Una sola superficie que probar y documentar, en vez de una consola por un lado y una API a medias por otro.
- Lo que hizo un agente lo puede repetir una persona con el mismo comando, y al revés: el procedimiento que hoy hace alguien de tu equipo mañana lo hace un agente sin reescribir nada.
- Errores mejores para todos. Un mensaje que un agente sabe resolver también lo entiende quien está de guardia a las tres de la mañana.
¿Por dónde empiezas?
Coge las diez operaciones que tu equipo hace más a menudo y comprueba, en cada una, si un agente podría hacerla sin ayuda: ¿existe fuera de la consola?, ¿su salida es estable?, ¿su error dice qué hacer?, ¿pide confirmación si borra algo? Lo que falle es tu lista de trabajo.
Si quieres ver una plataforma diseñada así desde el principio, mira NovaeOps, la plataforma que se opera por prompt.