Este Informe USERS aborda un problema que muchos desarrolladores subestiman: el consumo de tokens en sesiones de trabajo con asistentes de IA. La tesis central es que el desperdicio de contexto no nace de un error puntual, sino de hábitos acumulados que reducen la calidad de las respuestas.
Auto: Elisa Belmar
El costo invisible de cada consulta
Los modelos de lenguaje trabajan con tokens, porciones de texto que incluyen desde palabras sueltas hasta fragmentos de código. Cada sesión de trabajo ocupa una “ventana de contexto”: el volumen máximo de información que el modelo puede procesar al mismo tiempo.
Cuando esa ventana se llena con material irrelevante —logs sin filtrar, archivos completos, conversaciones que mezclan tareas distintas— el asistente debe igualmente procesarlo todo. A diferencia de una persona, no puede ignorar lo que no le sirve.
El resultado es previsible: más tokens consumidos, análisis más disperso y respuestas menos útiles.
Cuando se trabaja con Codex, Claude Code, Antigravity u otros asistentes similares, no solo importa la calidad de una consulta. También importa la cantidad y la pertinencia de la información que la rodea.
Dónde se acumula el ruido
El Informe identifica tres fuentes principales de desperdicio. La primera es compartir registros de errores sin filtrar que pueden contener decenas de líneas sin relación con el problema real.
La segunda es mantener conversaciones demasiado largas donde conviven tareas distintas: lo que empezó como una corrección termina siendo un registro del proyecto entero.
La tercera —quizás la más frecuente— es entregar archivos o repositorios completos ante un error puntual, cuando la falla suele estar concentrada en unas pocas funciones.
En todos los casos, el patrón es el mismo: el contexto crece de forma gradual con material que en algún momento parecía útil.
El mismo problema puede consumir cantidades muy distintas de contexto según la forma en que se presenta. Compartir el proyecto completo, conversaciones extensas y registros sin filtrar obliga al asistente a analizar una gran cantidad de información irrelevante. En cambio, entregar únicamente el código involucrado, el error observado y el contexto necesario permite concentrar el análisis donde realmente importa.
Cómo consultar mejor
El Informe propone tres ajustes concretos. El primero es delimitar cada consulta a una tarea con un objetivo claro y un formato de respuesta definido. Un prompt como “Revisá este módulo” obliga al modelo a adivinar qué aspecto importa, en cambio, uno como “Identificá posibles vulnerabilidades de autenticación sin reescribir el código” recorta el espacio de búsqueda y mejora el resultado.
El segundo ajuste es dividir las tareas complejas en etapas. Pedir diagnóstico, corrección y documentación en una sola consulta dispersa la atención del modelo. Trabajar por pasos permite validar cada cambio antes de avanzar.
El tercero es preparar contexto mínimo y preciso. Una breve descripción de la arquitectura del proyecto —tecnologías usadas, módulos principales, flujo de datos— suele aportar más que cientos de líneas de código aisladas. El objetivo no es ocultar información, sino evitar que el modelo procese lo que no participa en la tarea.
El objetivo no es ocultar detalles importantes, sino permitir que la atención del modelo se concentre en aquello que realmente participa en la tarea.
Encuentra la versión completa de la publicación en la que se basa este resumen, con todos los detalles técnicos en RedUSERS PREMIUM
También te puede interesar:
OLLAMA TRABAJA CON IA LOCAL
Este Informe USERS recorre el uso de Ollama, una herramienta de código abierto que permite ejecutar modelos de lenguaje directamente en la propia computadora. La idea central es procesar documentos privados sin enviarlos a servidores externos, manteniendo el control total sobre la información.
Lee todo lo que quieras, donde vayas, contenidos exclusivos por una mínima cuota mensual. Solo en RedUSERS PREMIUM: SUSCRIBETE!
