Si un prompt puede provocar un fallo en producción, necesita ingeniería
Prompts, instrucciones, skills, agentes, hooks, herramientas y MCP condicionan el comportamiento del sistema. Todo artefacto persistente cuyo cambio pueda afectar de forma material al comportamiento necesita un ciclo de ingeniería proporcional al riesgo.
Es razonable pensar que escribiremos menos código directamente, pero no que programar dejará de ser una parte relevante del desarrollo de software. Mientras delegamos una parte creciente de la implementación en agentes, construimos a su alrededor instrucciones, herramientas, permisos, skills, hooks, servidores MCP, esquemas, evaluaciones, memoria y mecanismos de orquestación. Esa capa necesita diseño, límites y mantenimiento. Automatizar la escritura de código no elimina la ingeniería: desplaza parte de su superficie.
Este texto formula una tesis profesional sobre esa superficie de software. No afirma que todos los equipos o herramientas evolucionen del mismo modo.
No, un prompt no es código
Un prompt no es código fuente en el sentido habitual: no expresa una lógica ejecutable con la semántica de un lenguaje de programación. Tampoco lo son un archivo AGENTS.md, un CLAUDE.md o una regla escrita en lenguaje natural. Un servidor MCP sí contiene software y un script ejecutado desde un hook también. Cuando uso la palabra harness, me refiero al entorno de orquestación y control que rodea al modelo; puede incluir una cantidad considerable de código convencional. Una política de permisos, una definición YAML o un conjunto de instrucciones pertenecen a categorías distintas.
La clasificación formal no resuelve la responsabilidad de ingeniería. Si un artefacto puede cambiar de forma relevante el comportamiento del sistema, su revisión debe ser proporcional a las consecuencias que pueda producir.
Un archivo Markdown puede dejar de ser simple documentación
Pensemos en una instrucción como esta:
Antes de modificar una API, localiza sus consumidores, ejecuta las pruebas de contrato, conserva la compatibilidad hacia atrás y actualiza su especificación OpenAPI. No des por terminada la tarea si falla alguna prueba.
Aunque está escrita en lenguaje natural, puede vivir en el repositorio, cargarse automáticamente y condicionar todas las modificaciones que los agentes realizan sobre las API del producto. Cambiarla puede mejorar o empeorar su comportamiento, hacer que omitan una comprobación importante, entrar en conflicto con otra regla o quedar obsoleta después de un cambio de arquitectura. Si puede romper el producto, necesita revisión, versionado y una forma de recuperar el estado anterior; discutir si ese Markdown «es código» resulta secundario.
La diferencia entre orientar y garantizar también importa. Una instrucción puede decirle al agente que no modifique determinados archivos, pero una restricción crítica debería apoyarse además en permisos, entornos aislados, políticas, hooks deterministas o controles del entorno de ejecución.
El lenguaje natural expresa muy bien intención, contexto, criterios y procedimientos. No se convierte en un control determinista porque lo escribamos en mayúsculas y añadamos «IMPORTANTE».
El repositorio ya no termina en /src
Un proyecto preparado para trabajar seriamente con agentes puede contener artefactos de naturaleza muy distinta.
| Capa | Ejemplos | Qué aporta |
|---|---|---|
| Código ejecutable | Aplicación, scripts, servidores MCP, plugins | Lógica y operaciones ejecutables |
| Instrucciones persistentes | AGENTS.md, CLAUDE.md, reglas | Convenciones, restricciones y contexto |
| Capacidades reutilizables | Skills, herramientas y comandos | Procedimientos y acciones disponibles |
| Agentes | Subagentes y agentes especializados | Delegación con contexto y capacidades propias |
| Automatización | Hooks, flujos de trabajo e integración continua | Reacción ante eventos y ejecución automática |
| Configuración | Modelos, enrutamiento, permisos y listas de permitidos | Parámetros y límites de funcionamiento |
| Contratos | JSON Schema, OpenAPI y esquemas de herramientas | Interfaces y estructuras verificables |
| Contexto | Documentación, memoria, RAG y recursos | Conocimiento disponible durante la ejecución |
| Validación | Pruebas, evaluaciones, evaluadores y conjuntos de referencia | Comprobación del comportamiento |
| Entorno de ejecución | Espacio aislado, sistema de archivos, red y credenciales | Entorno y límites de ejecución |
| Orquestación | Entorno de control, bucles y transferencias entre agentes | Coordinación del proceso completo |
No todos esos elementos son código ni simples adornos alrededor de él: forman parte del sistema que determina cómo trabaja el agente.
Una skill puede ser un SKILL.md, pero también incluir documentación, plantillas, ejemplos y scripts ejecutables. Un subagente puede tener su propio prompt, conjunto de herramientas y permisos. Una definición de permisos puede limitar las operaciones disponibles si el entorno de ejecución la aplica. Un esquema puede validar entradas y salidas cuando forma parte de una ruta de validación exigida. Un hook puede bloquear una llamada a una herramienta.
Cada pieza tiene una naturaleza distinta, pero todas pueden participar en el comportamiento del sistema.
Hemos trasladado parte de la lógica a otra capa
La representación popular de la programación con IA suele ser muy sencilla:
Si el agente escribe el código, parece razonable concluir que el código irá perdiendo importancia.
El problema es que falta casi todo lo que hace que ese agente pueda trabajar de manera fiable.
Cada una de esas piezas contiene decisiones:
- ¿Qué herramientas puede utilizar el agente?
- ¿Qué directorios puede modificar?
- ¿Qué información debe consultar antes de actuar?
- ¿Qué instrucciones tienen prioridad?
- ¿Qué operaciones requieren aprobación?
- ¿Qué datos pueden salir del entorno?
- ¿Qué comprobaciones son obligatorias?
- ¿Cómo sabe que una tarea está terminada?
- ¿Qué ocurre cuando una prueba falla?
- ¿Qué debe derivarse a una persona?
- ¿Qué debe quedar registrado?
Estas preguntas no han desaparecido con la IA. Son la aplicación de la arquitectura, la seguridad, el control de acceso, los contratos, la observabilidad, la gestión de errores y las pruebas a una nueva capa del sistema: la ingeniería sigue ahí.
El impacto determina el rigor necesario
Un prompt escrito una vez en una conversación y descartado cinco minutos después no necesita un repositorio Git, un flujo de integración continua ni una estrategia de reversión. Sería absurdo defenderlo, pero tampoco deberíamos utilizar ese caso para razonar sobre prompts que forman parte de un producto. Un prompt que interviene miles de veces al día en decisiones de producción, una skill compartida por todo un equipo y una regla cargada automáticamente en todos los trabajos de un agente son artefactos distintos por su impacto y permanencia.
El impacto potencial del artefacto sobre el comportamiento del sistema debería determinar el rigor, con independencia de la extensión del archivo.
Que un artefacto no sea código fuente no lo exime del ciclo de ingeniería. Si un artefacto persistente puede afectar de forma material al comportamiento del sistema, necesita una disciplina proporcional al riesgo, el alcance y la reversibilidad de sus cambios.
No todos los cambios necesitan el mismo proceso. Una modificación de documentación destinada solo a personas no exige el mismo rigor que una regla que controla operaciones de producción.
Pero el formato no debería servir como excusa para ignorar el riesgo.
Gobernar también tiene un coste
La disciplina no sale gratis. Versionar una skill, mantener un conjunto de evaluaciones, revisar permisos y preparar una reversión añade tiempo y fricción. En un prototipo que cambia cada hora, imponer el mismo circuito que a un agente que toca producción solo ralentiza el aprendizaje.
El rigor debe graduarse según el impacto:
- una conversación descartable puede resolverse con instrucciones locales y sin un flujo de entrega específico;
- un artefacto compartido necesita versión, revisión y algunos casos de regresión;
- un artefacto que opera sobre datos, permisos o producción necesita evaluaciones comparables, mínimo privilegio, despliegue gradual, observabilidad y reversión.
Al graduar ese rigor no solo cuentan los datos, los permisos o la producción. También importan el alcance del cambio, la frecuencia con la que se ejecuta, la exposición a terceros, la facilidad para detectar el daño y la posibilidad de deshacerlo.
Así el coste de gobernar se decide junto con el coste de no hacerlo. En un equipo pequeño una misma persona puede asumir varias responsabilidades; lo importante es que la decisión quede explícita y que alguien pueda recuperar el estado anterior.
Un prompt de producción también necesita trazabilidad
Imaginemos que el lunes cambiamos el prompt de un agente encargado de clasificar incidencias. El miércoles alguien detecta que ha aumentado el número de clasificaciones incorrectas.
¿Qué necesitamos saber?
- qué versión estaba funcionando antes;
- qué cambió exactamente;
- quién realizó el cambio y por qué;
- con qué modelo se validó;
- qué conjunto de casos se utilizó;
- qué resultados producía la versión anterior;
- qué resultados produce la nueva;
- si las métricas han cambiado en producción;
- cómo recuperar rápidamente la versión anterior.
Eso se parece sospechosamente a gestionar software.
En un sistema serio deberíamos poder reconstruir una traza suficiente y minimizada del comportamiento:
versión de la aplicación
+ versión de instrucciones y skills
+ configuración, identidad y permisos
+ modelo, versión identificable y parámetros relevantes
+ herramientas invocadas y sus resultados o referencias
+ versión o referencia del contexto recuperado
+ entorno, hora y resultadoNo siempre hace falta conservar el contenido completo. Las referencias resolubles a artefactos versionados y retenidos, junto con hashes para comprobar su integridad, pueden bastar para investigar una regresión. El contenido sensible requiere controles de acceso, retención limitada y una política explícita de exclusión de secretos. Tampoco toda ejecución es reproducible de forma exacta: el modelo puede ser no determinista y las herramientas pueden tener efectos o estados externos.
Sin una traza de ese tipo, investigar una regresión puede convertirse rápidamente en arqueología.
Si puede introducir una regresión, necesita un ciclo de vida
En el código convencional damos por sentado que los cambios relevantes recorren un ciclo de diseño, revisión, pruebas, despliegue y mantenimiento.
Los artefactos agénticos no deberían vivir al margen de él.
Versionado y revisión
Las instrucciones persistentes, las skills, las configuraciones de agentes, los hooks y las políticas relevantes deberían estar bajo control de versiones.
No porque Git convierta mágicamente un prompt en software, sino porque necesitamos saber qué cambió, cuándo y respecto a qué versión.
Los cambios necesitan revisión proporcional a su impacto. Una modificación aparentemente pequeña en una instrucción global puede afectar a cientos de tareas posteriores. Una configuración que amplía permisos necesita todavía más atención.
El hecho de que el archivo termine en .md no reduce el alcance de lo que puede provocar.
Pruebas y evaluaciones
Un script puede tener pruebas unitarias. Un servidor MCP puede tener pruebas de integración. Un esquema puede validarse automáticamente. Un hook puede comprobarse de forma determinista. Una política de permisos puede someterse a pruebas.
Pero una modificación de las instrucciones de un modelo puede necesitar otro tipo de comprobación.
Necesitamos evaluaciones: casos representativos, casos límite, pruebas adversariales cuando corresponda, resultados esperados, criterios de aceptación, comparación entre versiones y medición de regresiones.
Un cambio importante no debería aprobarse simplemente porque alguien haya conversado cinco minutos con el agente y diga que «parece funcionar mejor».
La pregunta debería ser:
¿En qué conjunto de casos es mejor, cuánto mejora y qué hemos empeorado a cambio?
Por ejemplo, antes de promover un cambio podemos fijar una línea base, combinar casos representativos y adversariales, elegir una métrica principal y definir qué indicadores no pueden empeorar. El criterio de promoción o reversión debe estar decidido antes de mirar el resultado.
En algunos equipos, estos controles adoptan la forma de registros versionados de prompts, catálogos de herramientas, evaluaciones previas y posteriores al despliegue, líneas base comparables, despliegues piloto y trazas de ejecución. No hace falta adoptar una plataforma concreta para aplicar la idea; hace falta poder comparar el cambio y observar sus resultados.
Seguridad, despliegue y reversión
Cada nueva capacidad modifica la superficie de ataque. Dar acceso a una herramienta no equivale a añadir información pasiva. Conectar un MCP puede proporcionar nuevas fuentes de datos o nuevas acciones. Cambiar un permiso puede permitir operaciones antes imposibles. Un hook puede ejecutar lógica automáticamente en puntos determinados del ciclo.
Los permisos no sustituyen los límites de confianza. El contexto recuperado, los documentos y las respuestas de herramientas pueden contener datos que no son de confianza; no deberían poder cambiar por sí mismos las instrucciones, los permisos ni los objetivos del agente. Las acciones sensibles necesitan una autorización independiente del texto que las propone.
El principio de mínimo privilegio no ha perdido vigencia porque quien consuma esas capacidades sea un modelo. Probablemente importa más.
Un cambio de prompt puede necesitar promoción entre entornos. Una skill nueva puede probarse primero sobre un conjunto limitado de trabajos. Una nueva versión de un agente puede convivir temporalmente con la anterior.
Y si algo empeora, necesitamos poder volver atrás.
Un artefacto que puede desplegarse también debería poder retirarse. Uno que puede modificarse debería poder compararse con la versión anterior. Uno que puede producir una regresión debería tener algún mecanismo de recuperación.
Revertir una versión no deshace por sí solo los efectos externos. Si un agente puede borrar, enviar, comprar o divulgar información, hacen falta límites previos, operaciones idempotentes cuando sea posible, registros de compensación y un procedimiento de corrección. Algunas acciones sencillamente son irreversibles.
Las skills también tienen arquitectura
Una skill parece pequeña al principio:
SKILL.md
unas instrucciones
algunos recursos
tal vez un scriptEso invita a tratarla como un elemento aislado: la encontramos, la instalamos, vemos que parece funcionar y continuamos.
El problema aparece cuando el sistema crece.
Dos skills empiezan a cubrir parcialmente la misma responsabilidad. Otra contiene conocimiento que debería estar centralizado. Una depende de una herramienta sin declararlo adecuadamente. Varias repiten instrucciones casi idénticas. Una contradice las convenciones actuales del proyecto. Otra dejó de tener sentido después de una migración.
Los problemas resultan familiares:
- responsabilidades mal definidas;
- acoplamiento;
- duplicación;
- dependencias implícitas;
- obsolescencia;
- deuda técnica.
En cuanto algo se reutiliza, evoluciona, interactúa con otros elementos y empieza a tener dependencias, necesitamos gestionar su complejidad.
Más autonomía exige mejores límites
Un agente más capaz puede completar más pasos sin intervención humana. Eso aumenta su utilidad, pero también la distancia que puede recorrer antes de que detectemos una decisión equivocada.
La respuesta no debería consistir necesariamente en poner a una persona a aprobar cada operación. Eso destruiría buena parte del valor de la autonomía. En operaciones irreversibles, de alto impacto o sin recuperación suficiente, esa aprobación humana puede seguir siendo el control apropiado.
La respuesta está en diseñar mejores límites: un entorno mejor diseñado, pruebas útiles, información suficiente, herramientas adecuadas, contratos claros, observabilidad y mecanismos de recuperación.
Ese entorno de control —el harness— no es una montaña de prompts ni una colección arbitraria de instrucciones. Hace posible que un agente actúe de manera útil sobre un problema real: herramientas, contexto, permisos, scripts, pruebas, evaluaciones, documentación, entornos aislados, observabilidad, mecanismos de recuperación y coordinación entre agentes.
La calidad del modelo importa. La calidad de ese entorno también.
Un modelo excelente con herramientas deficientes puede producir malos resultados. Un agente sin acceso directo o indirecto a evidencia de validación adecuada no puede demostrar de forma fiable que su trabajo cumple los criterios. Un agente al que proporcionamos permisos excesivos puede realizar operaciones innecesarias. Un agente que no recibe información sobre sus errores tiene pocas posibilidades de corregir el proceso que los genera.
La responsabilidad se reparte, no se diluye
Esta capa no pertenece automáticamente a un equipo nuevo. El equipo de producto responde por el comportamiento que necesita y por sus criterios de aceptación. El equipo de plataforma o de IA mantiene el entorno de control compartido, el enrutamiento, las herramientas comunes y la infraestructura de evaluación. Seguridad y fiabilidad revisan los límites, los permisos, los datos y la recuperación. Quien cambia una instrucción o una skill debe aportar la evidencia proporcional al riesgo del cambio.
En un equipo pequeño, una misma persona puede cubrir varios de esos papeles. Lo que no conviene es que todos queden implícitos: cuando una regresión aparece, debe estar claro quién puede explicar la decisión, comparar versiones y detener o revertir el despliegue.
El cambio de modelo es un cambio del sistema
Podemos conservar exactamente los mismos prompts, herramientas, skills y reglas y obtener un comportamiento diferente después de cambiar el modelo.
Puede cambiar hasta qué punto el modelo sigue las instrucciones, el uso que hace de las herramientas, la interpretación del contexto, la generación de salidas estructuradas, la latencia, el coste o la frecuencia de determinados errores.
El modelo forma parte de la arquitectura: es una dependencia crítica y, como cualquier dependencia crítica, necesita validación. Un resultado general favorable en una prueba comparativa no decide si el nuevo modelo sirve aquí; necesitamos saber qué ocurre en nuestros casos y si el comportamiento que necesitamos se mantiene o mejora.
Un ciclo posible para artefactos de agentes
Un cambio relevante en una skill, un prompt, una regla, un agente o su configuración podría recorrer algo parecido a esto:
No se trata de crear un proceso burocrático para cada línea de Markdown. Eso sería tan absurdo como exigir el mismo procedimiento de cambio para un README que para el algoritmo de autorización de pagos.
La disciplina debe ser proporcional al impacto. El ciclo no es una liturgia: es una forma de hacer explícito qué riesgo asumimos y qué recuperación tenemos si la decisión sale mal.
Programar nunca fue solo escribir código
Es posible que dentro de poco muchos desarrolladores escriban manualmente una fracción del código que escribían hace unos años. La ingeniería de software, sin embargo, nunca consistió solo en teclear instrucciones en un lenguaje: también exige entender el problema, definir límites, diseñar interfaces, modelar datos, gestionar dependencias, controlar privilegios, probar, investigar fallos, observar producción, reducir complejidad y retirar lo que ya no sirve.
Una parte de ese trabajo seguirá expresándose en TypeScript, Java, Python, PHP u otros lenguajes; otra aparecerá en esquemas, políticas, configuración, evaluaciones, documentación operativa e instrucciones, y otra podrá ser ejecutada por agentes. La automatización amplía el sistema sobre el que tenemos que ejercer la ingeniería.
La responsabilidad cuando cambia el comportamiento
Probablemente seguiremos discutiendo si los prompts deberían considerarse una nueva forma de código. No hace falta resolver esa clasificación para trabajar con rigor.
La cuestión operativa es quién responde por el artefacto cuando modifica el resultado: quién lo versiona, quién define la evidencia, quién revisa sus permisos y quién puede recuperar el estado anterior. Una skill no necesita compilar para necesitar revisión. Una regla no necesita tener funciones y clases para poder introducir una regresión.
Cuando el impacto lo justifica, la respuesta incluye versionado, revisión, pruebas o evaluaciones, seguridad, trazabilidad, despliegue controlado, observabilidad, mantenimiento, reversión y retirada.
El artefacto puede ser una función, un esquema, una política, una skill, un hook, un AGENTS.md, la configuración de un agente o un prompt. El formato importa menos que sus consecuencias.
Para automatizar una parte cada vez mayor de la producción de código estamos construyendo una nueva capa de software con arquitectura, interfaces, permisos, dependencias, fallos, versiones, pruebas y deuda técnica. Que parte de la implementación se automatice no reduce la necesidad de ingeniería: cambian los artefactos, los riesgos y las decisiones que debemos gobernar. Ahora también tenemos que gobernar el sistema que interpreta nuestras instrucciones, selecciona capacidades, utiliza herramientas y modifica el propio software.
Fuentes primarias
Referencias para comprobar el argumento
- Secure Software Development Framework de NIST
Marco de prácticas para preparar, proteger, producir y responder durante el ciclo de vida del software.
- Publicaciones oficiales del SSDF
Incluye el perfil de desarrollo seguro para IA generativa y modelos de doble uso.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Seguir leyendo
- ¿Está tu LMS preparado para agentes? Ocho pruebas de arquitectura
Ocho pruebas para saber si un LMS permite que agentes de IA consulten y actúen con delegación, límites, trazabilidad y responsabilidad educativa.
- MCP y Moodle: arquitectura segura para agentes
Cómo situar una pasarela MCP delante de Moodle sin compartir tokens, exponer toda la API ni permitir que el contenido del curso gobierne las acciones del agente.
- Tu proveedor de servicios gestionados va a ser un agente (y es una buena noticia)
Cómo evolucionan las altas, las matriculaciones y el resto de la administración de Moodle desde el CSV hasta agentes con permisos, confirmación y trazabilidad.