Hacia una arquitectura de intenciones para prompts y sistemas de IA
La conversación desarrolló una idea que podría convertirse en una disciplina propia:
la Ingeniería / Arquitectura de Intenciones aplicada a prompts y sistemas de IA.
La premisa central es sencilla:
Un prompt no debe entenderse únicamente como una instrucción textual. Es la fachada visible de una arquitectura de intenciones mucho más profunda.
1. La intención no es única
Una solicitud puede contener varias intenciones simultáneas:
La intención explícita del usuario.
Intenciones implícitas dentro de su discurso.
Intenciones de otras personas o entidades involucradas.
Restricciones del negocio, del proyecto o del contexto.
Intenciones que pueden entrar en conflicto.
Por ejemplo, un CEO puede imponer una intención superior:
“El sistema debe ser seguro.”
Otras intenciones deben coexistir con ella, pero no pueden violarla.
Esto genera el concepto de colisión de intenciones.
2. Dominios
Las intenciones pueden organizarse en dominios.
Cada dominio representa una región conceptual o funcional del problema y puede contener múltiples intenciones.
Cuando dos dominios se interfieren, no necesariamente hay que eliminar uno. Se puede diseñar una arquitectura que permita que ambos coexistan.
La metáfora utilizada fue arquitectónica:
Si dos funciones de un edificio chocan, se puede crear un pasillo, una puerta o una zona de transición para impedir que los dominios se atraviesen indebidamente.
Así aparecen:
Dominios · Fronteras · Puertas · Pasillos · Transiciones · Escapes
3. Transiciones entre dominios
No basta con definir los dominios.
Hay que definir cómo se pasa de uno al otro.
En un prompt complejo, la IA debe poder recorrer una secuencia conceptual sin que una intención destruya o contamine la anterior.
Esto introduce una dimensión topológica del prompt.
No solamente importa qué conceptos están presentes, sino:
cómo están conectados y cómo circula la intención entre ellos.
4. Base, Sustento, Estructura y Fachada
La conversación llegó a una arquitectura de cuatro niveles.
BASE
Define qué se está construyendo y para qué existe.
Ejemplo:
“Genera un dibujo de un bodegón realizado por un alumno.”
La base no dice simplemente:
“Haz una obra bonita.”
Define una intención superior:
queremos ver el trabajo de un estudiante, no una obra maestra.
SUSTENTO
Representa el terreno y el contexto sobre el cual esa intención tiene que funcionar.
Por ejemplo:
El alumno es inexperto, se distrae, está sentado cerca de la puerta y tiene determinadas limitaciones.
El sustento condiciona naturalmente lo que puede ocurrir.
ESTRUCTURA / DOMINIOS
Aquí el problema se divide en dominios concretos.
En el bodegón:
Mesa.
Primera manzana.
Segunda manzana.
Florero.
Fondo.
Tratamiento de cada elemento.
Cada dominio tiene sus propias intenciones y características.
FACHADA
La fachada es el mismo prompt, no un elemento separado.
Son los pequeños detalles que hacen que el resultado tenga huella, identidad y valor.
Por ejemplo:
Una firma escondida.
Una pequeña corrección.
Una gota de pintura seca.
Una diferencia entre las dos manzanas.
Una señal de cansancio del alumno.
Un detalle relacionado con la persona que le gusta.
La fachada es aquello que hace que el resultado deje de parecer una simple ejecución técnica y parezca tener una historia detrás.
5. El “prompt del millón de dólares”
El prompt extraordinario no necesariamente es extraordinario por ser largo.
Su valor está en contener una arquitectura de intención extremadamente precisa, incluyendo pequeños detalles capaces de producir autenticidad.
Es una especie de alquimia:
gramática + matemática + contexto + intención + estructura + detalle
El objetivo es permitir que la máquina alcance una solución latente mucho más cercana a la intención real del autor.
6. Ingeniería inversa de intenciones
El arquitecto no solamente puede construir prompts.
También puede tomar un prompt existente y preguntarse:
¿Qué intención produjo realmente este prompt?
Por ejemplo:
“Genera un florero con dos manzanas, fotorrealista.”
Si el contexto es una clase de arte, el arquitecto puede descubrir que “fotorrealista” contradice la intención real.
El profesor quizá no quería que el alumno simplemente reprodujera fotográficamente el bodegón.
Quería evaluar su capacidad artística.
La ingeniería inversa detecta entonces una discrepancia entre:
intención declarada → estructura del prompt → resultado esperado
7. El arquitecto de intenciones como auditor
El arquitecto no desaparece después de escribir el prompt.
Como un arquitecto que vuelve a visitar un edificio después del invierno, una tormenta o un terremoto, debe observar:
Qué funcionó.
Qué falló.
Qué intención se perdió.
Qué dominios colisionaron.
Qué transición produjo el problema.
Qué intención inesperada apareció.
Esto propone una especie de auditoría continua de intenciones.
8. La IA como detector de problemas humanos
Una idea especialmente interesante aparece en el ejemplo de ingeniería de software.
Un ingeniero puede pensar que el problema está en las pruebas:
“Las pruebas están fallando y necesito comunicarme mejor con el sistema.”
Pero al analizar el proceso completo, la IA puede descubrir que el verdadero problema está en la arquitectura de las intenciones del equipo.
Incluso un error de la IA puede revelar algo que los humanos no habían visto:
dos procesos estaban conectados o ejecutándose de una manera que generaba una concurrencia que nadie había detectado.
Por tanto:
El error de la IA puede convertirse en una herramienta de auditoría de los procesos humanos.
La IA no solamente resuelve el problema.
Puede revelar que el problema que creíamos tener no era el problema real.
9. El prompt de debugging
El resultado buscado no era un prompt lleno de explicaciones sobre la teoría, sino un “hechizo” sencillo que escondiera toda esa arquitectura.
La intención profunda sería aproximadamente:
Toma este Pull Request, genera y ejecuta las pruebas correspondientes, muestra todos los logs y advertencias aunque las pruebas pasen, explica los procesos relevantes y, al final, reconstruye el flujo de datos completo de la aplicación en lenguaje comprensible para el ingeniero. Explica qué está ocurriendo realmente, dónde se transforman los datos, qué componentes intervienen y si existe alguna discrepancia entre la intención del sistema y su comportamiento real.
La arquitectura está detrás.
La fachada es simplemente:
“Por favor, haz esto.”
La máquina recibe un prompt aparentemente sencillo, pero diseñado para explotar todo su potencial.
10. La conversación como sistema de pasos
Existe una diferencia fundamental entre un buscador y un sistema conversacional.
Un buscador responde a una consulta.
Un sistema conversacional tiene historia y pasos.
Por eso el arquitecto puede observar la conversación completa y preguntarse:
¿Qué pasó en el paso anterior?
¿La intención se conservó?
¿Dónde se desvió?
¿Qué debo modificar en el siguiente paso?
Esto convierte la arquitectura en un sistema dinámico, no en un prompt estático.
11. Rúbrica y realimentación
El ingeniero puede generar una rúbrica para evaluar el resultado.
El cliente o usuario califica la respuesta.
Después comienza un ciclo:
Prompt → Respuesta → Evaluación → Auditoría → Ajuste → Nueva respuesta
Esto crea un ciclo de aprendizaje.
La intención se va afinando mediante la interacción.
12. Aplicación educativa
Al final aparece otro caso particularmente revelador.
Un profesor no quiere simplemente:
“Hazme un examen sobre enlaces covalentes.”
Su intención real puede ser:
“Quiero que mis alumnos se despierten, piensen, se sorprendan y se enamoren de la materia.”
Esa es una intención superior completamente diferente de la instrucción superficial.
Por ejemplo:
“Diseña una experiencia de química para estudiantes de noveno que sea segura, intelectualmente retadora y sorprendente, que conecte conceptos aparentemente extraños y despierte curiosidad, sin sacrificar el aprendizaje de los conceptos fundamentales.”
El arquitecto de intenciones transforma:
“hacer un examen”
en:
“diseñar una experiencia que produzca pensamiento y curiosidad”.
13. La arquitectura
La ciencia que comenzó a emerger en la conversación podría resumirse así:
La Ingeniería de Intenciones es el proceso de descubrir, estructurar, conectar, expresar y auditar las múltiples intenciones que existen detrás de una instrucción, para construir prompts y sistemas capaces de producir resultados alineados con la intención real y no solamente con la literalidad del texto.
Su arquitectura básica podría representarse como:
Intención
↓
Base
↓
Sustento
↓
Dominios
↓
Fronteras
↓
Transiciones
↓
Fachada
↓
Ejecución
↓
Observación
↓
Auditoría
↓
Retroalimentación
↓
Reestructuración
La idea central
Quizá la idea más potente sea esta:
No se trata de enseñarle a la máquina qué hacer.
Se trata de construir el espacio de intenciones en el que la máquina pueda descubrir correctamente qué debe hacer.