Cómo optimicé el consumo de tokens en mis proyectos de programación

Durante mis primeros meses trabajando con IA en mis proyectos de código, la trataba casi como un amigo con superpoderes. Abría un chat y escribía en él durante horas: preguntas, código, correcciones, nuevas ideas, todo en la misma conversación. Al principio las respuestas eran sólidas. Pero con el tiempo, en esa misma conversación, el modelo empezaba a alucinar, mezclaba contextos que ya no tenían nada que ver entre sí, y al final del día había agotado buena parte de mi cuota de tokens sin darme cuenta en qué momento se me había ido de las manos.

Ese patrón se repitió tantas veces que dejó de sentirse como mala suerte y empezó a sentirse como un problema de diseño — mío, no del modelo. Así que tomé cartas en el asunto, y con los cambios que voy a contar aquí reduje el consumo de tokens en mis proyectos en un 70%. Pero lo más valioso no fue el ahorro en sí: fue dejar de perder tiempo corrigiendo alucinaciones y poder enfocarme únicamente en la lógica del negocio, que es en realidad el trabajo que me interesa hacer.

El primer cambio, y el más importante, fue terminar con los chats infinitos. En todo proyecto de desarrollo hay información que siempre debería estar presente — la arquitectura base, el stack, los estándares del equipo — y hay información que solo aplica a una parte específica del negocio. Mezclar las dos en un historial kilométrico es lo que termina confundiendo al modelo. La solución fue segmentar ese conocimiento en archivos `.md`: uno global con las reglas base, y uno independiente por cada dominio del negocio. En el fondo es aplicar los principios de Domain-Driven Design al prompting — dividir el contexto en vez de arrastrarlo completo en cada conversación.

Con el contexto ya separado, dejé de usar un chat tradicional. En su lugar, instancio agentes que nacen en blanco, como especialistas, y en vez de copiarles el código o el contexto a mano, les doy skills — herramientas que ellos mismos usan para ir a buscar y leer únicamente el archivo `.md` del dominio en el que van a trabajar. El agente extrae la información bajo demanda, resuelve la tarea con precisión quirúrgica, y el ahorro en tokens de entrada es enorme comparado con arrastrar todo el proyecto en cada mensaje.

El tercer cambio fue aceptar que no todas las tareas necesitan el modelo más inteligente — ni el más costoso. Para tareas mecánicas, como tipar datos o hacer cambios simples, uso un modelo ligero. Para debugging complejo, le asigno el modelo más pesado. Distribuir la carga según lo que realmente exige cada tarea resultó ser uno de los ajustes con mayor impacto directo en el presupuesto.

El resto son ajustes más pequeños, pero que suman: configurar a la IA para que responda de forma concreta, sin párrafos de relleno; escribir instrucciones en inglés y en un tono directo, sin cortesías innecesarias, porque los tokenizadores gastan menos tokens por palabra en inglés que en español; apoyarme en un skill que convierte la documentación en un grafo de navegación para que el agente encuentre lo que necesita sin leer de más; aprovechar el prompt caching manteniendo estable el inicio de mis prompts; y, sobre todo, pedir solo el fragmento de código relevante — una función, un error puntual — en vez de pegar archivos completos.