Cómo manejar el contexto cuando programás con IA

Al principio de la sesión le dijiste al agente “en este proyecto usamos pnpm, no npm”. Te contestó que perfecto. Dos horas y varios arreglos después, corre npm install como si nunca se lo hubieras dicho.

No se distrajo ni te ignoró: se le llenó la mesa. Este artículo explica qué es esa mesa, que se llama contexto, y cuatro hábitos para que no se te desborde. No hay nada que instalar ni configurar: se aplican desde la próxima conversación y funcionan con cualquier herramienta.

Qué es el contexto

El contexto es todo lo que el modelo de IA tiene delante en el momento de responder. No es solo tu último mensaje. Es la conversación entera: lo que le pediste, lo que te contestó, cada archivo que abrió y cada resultado de cada comando que corrió.

La forma más fácil de pensarlo es como una mesa de trabajo. El modelo no tiene memoria aparte, ni un cajón donde guarde cosas para después: lo que no está sobre la mesa, no existe. Y la mesa tiene un tamaño fijo.

Esto vale tanto para el modelo como para el agente de código, el programa que lo rodea (Claude Code, Cursor, Copilot) y que le deja leer archivos y correr comandos. El agente es el que va poniendo cosas sobre la mesa. El modelo solo ve lo que hay.

Por qué se llena sin que te des cuenta

Vos ves la conversación como una charla: unos cuantos mensajes cortos. Pero sobre la mesa hay mucho más de lo que ves en pantalla.

Un ejemplo. Le pedís que arregle un test que falla. Para hacerlo, el agente:

• abre el archivo del test (200 líneas),
• abre el archivo que se está probando (600 líneas),
• corre toda la batería de pruebas, que imprime otras 300 líneas,
• y como algo no cierra, abre dos archivos más para entender de dónde viene un dato.

Tu pedido fue una línea. Lo que quedó sobre la mesa son más de mil. Y todo eso sigue ahí cuando le pedís lo siguiente.

Una mesa llena no rompe nada de golpe. Lo que pasa es más sutil: lo que pusiste al principio pierde peso. Tu aclaración sobre pnpm sigue estando, pero ahora compite con miles de líneas de código y resultados de pruebas. En algún momento pierde.

Cuatro hábitos que alcanzan

Cada hábito termina con los pasos concretos en Claude Code. En otros agentes los comandos se llaman distinto, pero la idea es la misma.

1. Una tarea, una conversación

Es el hábito que más diferencia hace. Cuando terminás algo y vas a empezar otra cosa, abrí una conversación nueva.

Si arreglaste un error en el login y ahora vas a escribir un reporte de ventas, nada de lo que quedó sobre la mesa te sirve: los archivos del login, los intentos fallidos, los resultados de pruebas. Pero ahí siguen, ocupando lugar y distrayendo. Una conversación nueva arranca con la mesa limpia.

La tentación es seguir en la misma “porque ya sabe cómo es el proyecto”. Lo que sabe del proyecto está en el código, y lo puede volver a leer. Lo que arrastrás es sobre todo ruido.

Paso a paso:

1. Terminás el arreglo del login y comprobás que las pruebas pasan.
2. Hacés el commit.
3. Escribís /clear. La conversación queda vacía; el proyecto y el CLAUDE.md siguen ahí.
4. Pedís la tarea nueva: “Armá el reporte de ventas mensual”.
5. Si después necesitás volver a la conversación del login, /resume te muestra las anteriores para retomarla.

2. Dale lo justo, no todo

Cuando le pedís algo, decile dónde mirar. Compará estos dos pedidos:

• “Fijate por qué falla el cálculo de descuentos.”
• “El test calcula_descuento_por_volumen falla con este error: esperaba 90, recibió 100. La función está en src/precios.ts.”

Con el primero, el agente va a explorar: abrir carpetas, leer archivos que no tienen nada que ver, correr cosas para orientarse. Todo eso termina sobre la mesa. Con el segundo, va directo. Tarda menos, gasta menos y deja más lugar para lo que importa.

Lo mismo vale al revés: no le pegues el proyecto entero “por las dudas”. Tres archivos correctos rinden más que veinte donde están esos tres.

Paso a paso:

1. Corrés vos la prueba que falla y copiás el error.
2. En el pedido, nombrás el archivo con @: al escribir @src/precios.ts, Claude Code lo suma al pedido sin tener que buscarlo.
3. Pegás el error tal cual, sin resumirlo: El test calcula_descuento_por_volumen falla: esperaba 90, recibió 100. Mirá @src/precios.ts
4. Si igual empieza a abrir archivos que no tienen nada que ver, apretás Esc para frenarlo y le decís dónde mirar.

3. Lo que vale siempre, escribilo una vez

Hay cosas que son verdad en cada conversación: que usás pnpm, que las pruebas se corren con tal comando, que la carpeta de migraciones no se toca. Si se las decís en el chat, se pierden cuando la mesa se llena, y en la próxima conversación hay que repetirlas.

La solución es un archivo de instrucciones en la raíz del proyecto, que el agente lee al empezar cada conversación. Según la herramienta se llama AGENTS.md o CLAUDE.md, y alcanza con unas pocas líneas:

- Usamos pnpm, no npm.
- Las pruebas se corren con `pnpm test`.
- No modificar nada dentro de `db/migrations/`.

Así esas reglas están sobre la mesa desde el principio, en cada conversación, sin que tengas que acordarte. En el artículo sobre preparar el repositorio hay más sobre qué conviene poner ahí.

Paso a paso:

1. La primera vez que trabajás en el proyecto con el agente, corrés /init. Lee el repositorio y arma un CLAUDE.md con lo que encontró.
2. Lo abrís y borrás lo que se deduce leyendo el código, como la lista de carpetas. Cada línea se carga en todas las conversaciones.
3. Agregás lo que no se deduce: “usamos pnpm”, “no tocar db/migrations/”.
4. Lo commiteás, así lo tiene todo el equipo.
5. Cada vez que te descubrís repitiéndole algo en el chat, lo sumás al archivo.

4. Si lo corregiste dos veces, empezá de nuevo

Le pedís algo, lo hace mal, lo corregís. Lo vuelve a hacer mal, lo volvés a corregir. A esta altura, la mesa tiene tres versiones equivocadas y dos correcciones, y el modelo tiene que adivinar cuál de todo eso es lo que vale.

En vez de una tercera corrección, abrí una conversación nueva con un pedido mejor, que ya incluya lo que aprendiste:

Agregá validación al formulario de registro. El mail tiene que validarse con la función que ya existe en src/validaciones.ts, no con una nueva. Los mensajes de error van debajo de cada campo, no en un cartel arriba.

Esas dos aclaraciones son las que antes te costaron dos rondas de corrección. Escritas desde el principio, la primera respuesta suele salir bien.

Paso a paso:

1. A la segunda corrección que no funciona, apretás Esc y no seguís corrigiendo.
2. Si tocó archivos que no querías, apretás Esc dos veces (o escribís /rewind), elegís el mensaje donde empezó el problema y restaurás el código y la conversación.
3. Anotás en una línea qué fue lo que malinterpretó.
4. Escribís /clear.
5. Hacés el pedido de nuevo con esa aclaración incluida, como el ejemplo de arriba.

Si tu herramienta te deja ver la mesa

Muchos agentes muestran cuánto contexto llevás usado. En Claude Code, por ejemplo, el comando /context lo dibuja por partes, y hay comandos para limpiar o resumir la conversación sin salir. Están explicados en el artículo sobre los comandos de Claude Code.

No hace falta mirarlo todo el tiempo. Sirve para lo mismo que la barra de batería del celular: saber cuándo conviene cortar antes de que empiece a fallar.

La mesa limpia rinde más

Casi todos los problemas de “el agente se olvidó” o “empezó a hacer cualquier cosa” son una mesa desbordada. La solución no es un modelo más caro ni un pedido más largo, sino tener menos cosas encima: una tarea por conversación, lo justo para cada pedido, las reglas fijas en un archivo y empezar de cero en vez de corregir por tercera vez.