Ingeniería del Propósito: programar con LLMs sin caer en la tiranía del contexto

La llegada de los LLMs al desarrollo de software prometía una liberación: menos fricción, más velocidad, más capacidad de iterar. Y, en parte, esa promesa se ha cumplido. Hoy podemos generar borradores, explorar alternativas, refactorizar bloques enteros y producir documentación en una fracción del tiempo que antes costaba.

Pero esa misma revolución ha traído una carga inesperada. En lugar de sentirnos más libres, muchos desarrolladores se han convertido en operadores de contexto. Pasan buena parte de su tiempo copiando archivos, resumiendo tickets, pegando fragmentos de código, explicando reglas de negocio y reconstruyendo el pasado del sistema para que el modelo pueda producir algo razonable.

La paradoja es evidente: cuanto más poderosa parece la IA, más tiempo dedica el programador a actuar como asistente de la propia IA.

Ahí es donde conviene introducir una idea distinta: quizá el problema no sea que a los modelos les falte contexto, sino que nosotros hemos colocado el contexto en el centro de una tarea cuyo núcleo real sigue siendo otro. Ese núcleo es el propósito.

El error de fondo: confundir más información con mejor dirección

Una parte importante de la práctica actual con LLMs descansa sobre una intuición muy extendida: si el modelo tiene suficiente información, responderá mejor. La intuición no es absurda. Con algo de contexto, el modelo suele rendir mejor que en vacío. El problema aparece cuando esa intuición se convierte en dogma y se traduce en una estrategia de exhaustividad.

Entonces empieza la carrera por darle al modelo todo:

• el archivo actual,
• los archivos relacionados,
• el histórico del módulo,
• el esquema de base de datos,
• las convenciones del equipo,
• los errores previos,
• y cualquier detalle que parezca vagamente relevante.

Sin darnos cuenta, pasamos de colaborar con una herramienta a mantenerla constantemente abastecida. El desarrollador deja de pensar primero en la forma deseable del sistema y empieza a pensar en cómo empaquetar el pasado para que el modelo no se pierda.

Ese desplazamiento tiene un coste alto. Aumenta la fatiga cognitiva, diluye la señal importante y convierte la interacción con la IA en una forma sofisticada de secretariado técnico. El problema no es solo operativo. Es también profesional. Cuando el valor del programador se reduce a transportar contexto, su papel se degrada.

La paradoja del bibliotecario agotado

Podemos describir este fenómeno de forma simple: hemos empezado a tratar al programador como un bibliotecario de prompts.

Su trabajo ya no parece consistir en definir qué sistema merece ser construido, bajo qué criterios y con qué límites, sino en acercar a la máquina los libros correctos con la esperanza de que esta produzca una respuesta útil. Es una inversión extraña del reparto de capacidades: el humano, que debería aportar criterio, se dedica a mover contexto; la máquina, que debería ejecutar a gran velocidad, marca el ritmo del proceso.

Esta dinámica genera ansiedad por una razón muy concreta. El contexto nunca parece suficiente. Siempre puede faltar un archivo, una convención, una excepción de negocio o un detalle histórico. Y como nunca hay garantía de completitud, el trabajo se vuelve defensivo: meter más contexto por si acaso.

Pero programar no es solo reconstruir por qué el sistema llegó hasta aquí. Programar es decidir hacia dónde debe ir. Cuando ese eje se pierde, la colaboración con IA se vuelve reactiva, errática y, a menudo, decepcionante.

Del "¿por qué?" al "¿para qué?"

La propuesta de la Ingeniería del Propósito consiste en un "cambio de contexto". En vez de empezar por el "¿qué contexto le doy al modelo?", propone empezar por otra pregunta: "¿para qué existe este cambio?"

Ese giro obliga a formular primero la dirección, luego los principios y finalmente los límites. Solo después entra el contexto, y entra además en una posición subordinada: como material de ejecución, no como criterio rector.

Dicho de forma breve:

• el contexto explica de dónde venimos,
• el propósito decide hacia dónde vamos.

La Ingeniería del Propósito no niega que el contexto sea útil. Lo que niega es que pueda gobernar por sí solo la calidad de una solución. Un modelo puede conocer mucho y seguir produciendo algo equivocado, frágil o arquitectónicamente pobre. Lo que le falta entonces no es volumen de información, sino una dirección clara.

Qué es la Ingeniería del Propósito

La Ingeniería del Propósito es un modelo de interacción con LLMs en el que el programador declara explícitamente el fin que debe orientar una solución antes de aportar el contexto mínimo necesario para construirla.

Su tesis central es sencilla:

• el contexto sin propósito tiende al ruido,
• el propósito sin contexto puede quedarse en abstracción,
• la combinación correcta es propósito primero, contexto después.

Lo importante aquí no es solo el orden. Es el criterio que ese orden introduce. Si el propósito está bien formulado, el desarrollador puede evaluar una respuesta de la IA sin depender únicamente de si "funciona". Puede preguntarse si cumple el fin buscado, si respeta la arquitectura, si preserva restricciones críticas y si deja un código comprensible para otros humanos.

En ese sentido, la Ingeniería del Propósito no es solo una técnica de prompting. Es una manera de devolverle al programador la soberanía intelectual sobre el proceso.

Los cuatro horizontes del propósito

Para que esta idea no quede en una consigna vaga, conviene traducirla a un marco operativo. La propuesta se articula en cuatro horizontes.

1. Horizonte funcional

No pregunta simplemente qué debe hacer el código, sino qué problema desaparece cuando la solución existe. Obliga a pensar en términos de capacidad real, no de implementación superficial.

Un mal encargo sería: "Añade persistencia asíncrona".
Un mejor encargo sería: "El usuario debe poder guardar sin percibir latencia".

2. Horizonte arquitectónico

Define cómo debe sobrevivir la solución en el tiempo. Aquí entra el criterio profesional del desarrollador: desacoplamiento, extensibilidad, simplicidad, observabilidad o facilidad de sustitución.

No se trata solo de resolver el caso actual, sino de evitar que el arreglo de hoy se convierta en la deuda de mañana.

3. Horizonte de restricción

Marca aquello que no debe suceder aunque la solución parezca correcta desde el punto de vista funcional. En este horizonte entran la seguridad, la compatibilidad, la privacidad, la complejidad o los límites operativos.

Es el lugar donde se enuncia lo innegociable.

4. Horizonte de autoría

Introduce una dimensión que muchas veces se omite y, sin embargo, importa mucho: cómo debe leerse el código resultante. La claridad, la declaratividad, la capacidad de transmitir intención o incluso una preferencia deliberada por la simplicidad frente a la brevedad también forman parte del diseño.

Cuando este horizonte se explicita, el código deja de ser solo una salida válida y empieza a ser una pieza mantenible.

Un ejemplo simple

Imaginemos un cambio aparentemente normal: añadir preferencias de usuario a una aplicación.

La forma habitual de pedírselo a un LLM sería algo así:

"Aquí tienes UserService, UserController y el esquema de base de datos. Añade un campo de preferencias y hazlo igual que el resto de campos."

Esa petición está guiada por contexto. Lo más probable es que el modelo replique la forma ya existente del sistema, incluidos sus aciertos y sus errores. Si el diseño actual es pobre, el modelo tenderá a perpetuarlo.

La misma petición, formulada desde la Ingeniería del Propósito, cambiaría así:

• Funcional: el usuario debe poder personalizar la interfaz sin recargar la página.
• Arquitectónico: las preferencias deben poder ampliarse sin tocar el esquema principal cada vez.
• Restricción: una preferencia corrupta no puede bloquear el inicio de sesión; debe haber degradación segura a valores por defecto.
• Autoría: el servicio debe exponer con claridad qué preferencias existen y cómo se resuelven.

Solo después se aporta el contexto mínimo imprescindible.

El efecto de este cambio de enfoque es profundo. Ahora el modelo no recibe solo material. Recibe un criterio de legitimidad. Si devuelve algo que "funciona" pero acopla la UI al almacenamiento, o convierte las preferencias en una maraña opaca, la respuesta puede rechazarse con base objetiva.

Qué se gana con este enfoque

La primera ganancia es cognitiva. El desarrollador deja de abrir archivos por inercia y empieza por aclarar el sentido del cambio. Eso reduce ruido y mejora la calidad de la conversación con la IA.

La segunda es metodológica. Las soluciones dejan de evaluarse solo por su corrección local y pasan a medirse contra un marco más completo: utilidad, permanencia, límites y legibilidad.

La tercera es profesional. El programador recupera su papel como arquitecto. La IA deja de ser una caja negra a la que hay que satisfacer con contexto y pasa a ser una herramienta de ejecución al servicio de una voluntad técnica explícita.

Y hay una cuarta ganancia, menos visible pero decisiva: la continuidad. El contexto cambia con cada commit. El propósito, en cambio, suele ser más estable. Por eso funciona mejor como hilo conductor entre iteraciones.

Lo que esta idea no dice

Sería un error vender la Ingeniería del Propósito como una negación del contexto. No lo es. Hay tareas donde el contexto masivo es legítimamente necesario: auditorías, análisis forense, depuración compleja, sistemas legacy poco conocidos. En esos casos, el propósito no elimina la necesidad de explorar mucho material.

Tampoco conviene olvidar que un propósito mal formulado produce resultados igual de malos. Si el fin es ambiguo, contradictorio o banal, la interacción con la IA seguirá siendo mediocre.

La tesis es más modesta y más útil: el contexto sigue siendo necesario, pero no debe mandar. Debe estar filtrado, priorizado y ordenado por una intención técnica explícita.

Una disciplina más exigente, no más cómoda

La Ingeniería del Propósito no simplifica el trabajo en el sentido banal de hacerlo trivial. De hecho, exige más del programador. Exige claridad conceptual. Exige juicio. Exige saber qué se quiere proteger y qué se está dispuesto a sacrificar.

Pero precisamente por eso mejora la colaboración con LLMs. No porque convierta a la IA en infalible, sino porque convierte al humano en un director más competente de la interacción.

En el fondo, la propuesta es esta: si los modelos ya pueden leer una gran parte del pasado por nosotros, nuestro valor diferencial ya no está en repetirles ese pasado una y otra vez. Está en decidir con precisión qué futuro merece construirse.

Cierre

La pregunta decisiva del trabajo con IA no es "¿qué más contexto debo añadir?".

La pregunta decisiva es: "¿para qué existe este cambio, bajo qué principios y con qué límites?"

Mientras no recuperemos esa pregunta, seguiremos usando modelos poderosos de una forma intelectualmente pobre. Cuando la recuperamos, algo cambia de lugar: la IA deja de dirigir la conversación por hambre de contexto y el programador vuelve a dirigirla por claridad de propósito.

Estamos, posiblemente, ante el comienzo de una práctica más madura de programar con LLMs.

Si te interesa utilizar este patrón, hemos creado un plugin para Claude así como Agent Skills / Slash Commands con la intención de facilitar el proceso. Puedes encontrarlos en el repositorio de Github ingenieria-del-proposito.

Para saber más

• Liu, N. F., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arxiv.org/abs/2307.03172
• Aristóteles (1995). Física (G. R. de Echandía, Trad.). Editorial Gredos.
• Anthropic. Effective context engineering for AI agents. anthropic.com
• Mei, L., et al. A Survey of Context Engineering for Large Language Models. arxiv.org/abs/2507.13334
• Muness, C. Intent Engineering: From Vibe Coding to Productive Outcomes. muness.com