La ingeniería de contexto es el término del año en el desarrollo asistido por IA, y llegó con el misticismo de siempre: frameworks, diagramas, títulos de puesto. Los reportes de la industria en 2026 — los ensayos de Martin Fowler, la guía práctica de Sourcegraph, el reporte de tendencias de programación agéntica de Anthropic — coinciden en un hallazgo: para la mayoría de los equipos que ya corren agentes de código en producción, el techo de calidad no es el modelo, es el contexto. El diagnóstico es correcto. Pero después de meses corriendo agentes a diario en mis propios repos, creo que la disciplina merece un nombre menos glamoroso.
Es plomería.
Nada en mi configuración es ingenioso. Son cuatro tuberías que llevan hechos al agente, un drenaje que saca el lodo y una válvula de ruteo que decide qué tubería sirve cada pregunta. Se instala una vez, se mantiene poco, y todo el sistema se capitaliza en silencio. Aquí va el diagrama completo.
Por qué la ingeniería de contexto desplazó a la ingeniería de prompts
La ingeniería de prompts era decoración de interiores: acomodar palabras en la pared de una sola petición. Importaba cuando los modelos eran más débiles y cada petición vivía sola. Los agentes rompieron ese modelo. Un agente trabajando en tu repo no necesita una instrucción bellamente redactada — necesita saber cosas: cómo es el código, qué decidiste el mes pasado, qué no debe tocar jamás, dónde te quedaste ayer.
Nada de eso cabe en un prompt que escribes a mano. Tiene que llegar por tubería — automáticamente, en el momento correcto, en la cantidad correcta. Esa es toda la disciplina. La razón por la que la “ingeniería de contexto” desplazó a la de prompts como barrera de calidad es que el cuello de botella se movió de cómo preguntas a qué puede ver el agente cuando actúa.
La pregunta deja de ser “¿cuál es el prompt mágico?” y se vuelve “¿qué infraestructura alimenta a esta cosa?”. Las preguntas de infraestructura tienen respuestas aburridas. Qué bueno.
Tubería 1: un índice de archivos curado — la línea de suministro
La tubería base es un archivo markdown plano, versionado en git, que se carga al inicio de cada sesión. Claude Code lee CLAUDE.md automáticamente; cada harness de agentes tiene su equivalente. El mío es por capas: un archivo global con reglas que aplican en todas partes (“usa Bun, nunca npm a secas”) y uno por repo con los hechos de ese proyecto (comandos, arquitectura, convenciones, destinos de deploy).
La disciplina es curar sin piedad. Este archivo se carga en cada sesión, así que cada línea cuesta contexto para siempre. Diez hechos permanentes valen más que doscientos rancios:
## Gestor de paquetes
Usa **Bun** (existe `bun.lock`). Corre comandos con `bun` o `bunx`.
## i18n
El idioma principal es español (`es`). El contenido en inglés vive bajo `/en/`.De esta capa escribí con más detalle en cómo mantengo contexto entre sesiones — la versión corta: los hechos permanentes pertenecen a un archivo revisable y diffeable, no a un chat que se evapora.
Tubería 2: memoria semántica — el pozo
El índice de archivos guarda lo que siempre es cierto. Es inútil para las mil cosas que fueron ciertas una vez: el razonamiento detrás de una decisión vieja, el callejón sin salida que exploraste en mayo, por qué un valor de configuración está puesto exactamente en ese número.
Para eso corro un servidor de memoria sobre MCP — el mío indexa el código más las notas de sesión en una base Postgres en Supabase, con embeddings de un modelo afinado para código (voyage-code-3, 1024 dimensiones). Uno de mis repos tiene hoy 118 páginas embebidas. El número que me convenció: le pedí “portfolio filter isotope” — intención vaga, a medio recordar, sin nombre de símbolo — y regresó src/lib/portfolio-filter.ts con similitud de 0.88, primer resultado.
Esa es la propiedad que compra una tubería semántica: recuperar por significado. grep encuentra cadenas que ya conoces. El pozo encuentra cosas que solo sabes describir. Y como está conectado por MCP, el agente lo consulta solo, a mitad de la tarea — yo no soy el bibliotecario.
Tubería 3: un grafo del código — el plano
La búsqueda semántica responde “¿dónde se maneja X?”. No responde “¿quién llama a X?” — esa es una pregunta estructural, y los embeddings son la herramienta equivocada. La tercera tubería es un grafo de conocimiento del código: funciones, clases y rutas como nodos; llamadas e imports como aristas. El mismo repo que tiene 118 páginas embebidas carga un grafo de 1,205 nodos y 1,783 aristas.
Cuando el agente necesita análisis de impacto — “si cambio este helper, ¿qué se rompe?” — recorre el grafo en lugar de leerse veinte archivos hacia su ventana de contexto. Los reportes públicos sobre contexto basado en grafos presumen ahorros de tokens de entre 7× y 49×. No tengo un benchmark así de limpio, pero la diferencia cualitativa es obvia: el agente deja de inundar su propia memoria con volcados de archivos y empieza a preguntarle al plano.
Tubería 4: punteros de sesión — dónde quedó la llave abierta
La tubería más mundana, y la de mejor relación esfuerzo-beneficio. Un hook guarda un puntero pequeño al final de cada sesión: rama, directorio de trabajo, últimos commits, estado del árbol. La siguiente sesión arranca con ese puntero inyectado — aquí te quedaste — y se reorienta desde git en vivo antes de tocar nada.
Sin él, cada sesión abre con cinco minutos de arqueología. Con él, el agente se sienta ya sabiendo qué cajón estaba abierto. Y si corres más de un agente a la vez, esta tubería también carga la advertencia que salva tus ramas — esa la aprendí a la mala en dos agentes de IA, un repo.
El drenaje: lo que mantienes fuera de las tuberías
La mitad de la plomería es drenaje, y la mitad de la ingeniería de contexto es exclusión. Cada byte que devuelve una herramienta ocupa la memoria de trabajo del agente por el resto de la sesión. Un volcado de log de 400 líneas para responder un sí-o-no es lodo en las tuberías.
Las reglas del drenaje son simples: procesa las salidas grandes fuera de la ventana de contexto y muestra solo la respuesta derivada; resume en lugar de pegar; y mantén el índice siempre-cargado tan corto que nada importante se ahogue. Un agente alimentado con todo no recuerda nada.
La válvula de ruteo: qué tubería para qué pregunta
Las tuberías solo pagan si cada consulta baja por la correcta. Mi tabla de ruteo:
| Forma de la pregunta | Tubería |
|---|---|
| ”¿Cuáles son las reglas aquí?” | Índice de archivos (ya cargado) |
| “¿Dónde se maneja X?” / intención vaga | Memoria semántica |
| ”¿Quién llama a X?” / “¿qué se rompe si…?” | Grafo del código |
| Cadenas exactas, regex, globs | grep de toda la vida |
| ”¿Dónde me quedé?” | Puntero de sesión + git en vivo |
Nota que grep conserva su lugar en la mesa. La búsqueda semántica es para preguntas que solo sabes describir; cuando conoces el identificador exacto, la herramienta tonta es más rápida y más barata. La plomería no se trata de la tubería más elegante — se trata de rutear bien.
Cuando la plomería falla: tuberías rancias
Una advertencia desde el campo. Una tubería que sirve agua rancia en silencio es peor que no tener tubería, porque el agente le cree. Una vez dejé en cola una especificación de tarea escrita contra un índice desactualizado; hacía referencia a un componente que se había borrado del código una semana antes. El agente habría reconstruido un fantasma, con toda confianza. El arreglo es el mismo que en la plomería real: re-indexa después de cambios significativos y trata “¿cuándo se sincronizó esto por última vez?” como una pregunta de primera clase. Mi rutina hoy re-sincroniza el índice semántico después de cada ventana de merges, igual de mecánicamente que valido un post antes de publicarlo.
Para llevar
No necesitas un framework de ingeniería de contexto. Necesitas tuberías, instaladas en orden de costo: un archivo corto y versionado en git con los hechos permanentes (una tarde), punteros de sesión (una noche), y — cuando el historial rebase cualquier archivo — memoria semántica y un grafo del código sobre MCP. Suma una política de drenaje para que la basura no entre, y el hábito de ruteo para que cada pregunta baje por la tubería correcta.
Nada de esto es glamoroso. Ese es el punto. A los equipos atorados en el techo de calidad del contexto no les falta un modelo más listo — les falta plomería.
