Los prompts son útiles, no constitucionales
Una instrucción puede orientar tono, formato o tarea. Pero permisos, secretos, acciones irreversibles, datos regulados y criterios de promoción no deberían vivir sólo en lenguaje natural enviado al mismo modelo que deben limitar.
Convertir reglas en mecanismos
Contratos estructurados, máquinas de estado, validadores, fronteras de datos y gates convierten decisiones críticas en propiedades verificables. El prompt pasa a ser una pieza, no la última línea de defensa.
La demo puede fallar sin consecuencias
Un sistema real necesita sobrevivir inputs raros, caídas de proveedor, cambios de versión, usuarios apurados y errores humanos. Ahí empieza la ingeniería que la demo nunca tuvo que demostrar.
El prompt orienta; el mecanismo obliga
Una instrucción puede decir “no envíes datos sensibles”, pero la misma capa que interpreta la instrucción puede equivocarse. Una frontera técnica puede impedir físicamente que determinados valores crucen una interfaz. Las dos cosas pueden convivir, pero sólo una constituye una garantía mecánica.
Invariantes fuera del lenguaje natural
Permisos, tipos aceptados, límites de recursos, estados válidos y criterios de promoción pueden representarse en código o configuración validada. Eso reduce ambigüedad y hace que las pruebas verifiquen propiedades en vez de confiar en que el modelo entendió una frase.
Los prompts siguen siendo valiosos
No se trata de eliminar instrucciones. Son excelentes para objetivos, contexto, estilo y heurísticas que cambian con frecuencia. La arquitectura madura decide qué pertenece al espacio flexible del modelo y qué debe permanecer como contrato externo.
La prueba de cambiar el modelo
Si sustituir el proveedor obliga a reescribir todas las reglas críticas dentro de prompts nuevos, parte del control estaba acoplado al modelo. Cuando las invariantes sobreviven al cambio y sólo se adapta la capa de interacción, existe una separación más fuerte.
De demo a sistema
Una demo puede depender de un prompt cuidadosamente afinado y un operador atento. Producción necesita saber qué ocurre con entradas inesperadas, fallos de red, permisos incorrectos y acciones parciales. Esas preguntas casi siempre se responden con arquitectura, no con un prompt más largo.
Una prueba útil
Una forma concreta de someter esta idea a presión es mover una regla crítica fuera del prompt a un mecanismo verificable y comprobar si sigue aplicándose aunque cambie el modelo, el idioma de entrada o la formulación de la tarea. La prueba no debería evaluar sólo si aparece una respuesta, sino qué estado queda, qué evidencia se conserva y si otro operador puede entender por qué el sistema actuó así. Ese tipo de ensayo transforma un principio editorial en una propiedad observable y permite descubrir dónde la arquitectura todavía depende de supuestos invisibles.
Lo que esta nota no afirma
Los prompts no son inútiles ni inseguros por definición; son la capa equivocada para ser la única barrera de una propiedad que debe mantenerse aun cuando el modelo interprete mal. Esta distinción importa porque una buena práctica deja de ser útil cuando se convierte en promesa universal. El objetivo es hacer explícita una frontera de diseño que pueda discutirse, probarse y adaptarse al dominio, manteniendo separados hechos, inferencias, permisos y decisiones.