Tokens, Agentes y Copilot: La Economía Real del Desarrollo Asistido por IA

Imagina que necesitas un taxista que te ayude a recorrer la ciudad. Cada vez que le das una dirección, pagas por cada kilómetro recorrido. Algunos viajes son eficientes: sales directo al destino. Otros son un desastre: das indicaciones vagas, el taxista se pierde, regresa para preguntar, exploras calles innecesarias.

Eso es GitHub Copilot con agentes.

Cada pregunta que haces, cada archivo que el agente lee, cada herramienta que ejecuta, cada iteración que necesita para entender más — todo es kilómetros recorridos. Y en Copilot, los kilómetros se llaman tokens. Cada token es dinero. Cada token es contexto que le quitas a la respuesta.

La diferencia entre un desarrollador que usa Copilot y quema su cuota de premium al tercer día de la semana, y uno que pasa meses con la misma cuota, no es el modelo. No es suerte. Es entender exactamente cómo funcionan los tokens, cómo piensan los modelos de lenguaje, y cómo diseñar tus solicitudes para que el agente tenga exactamente lo que necesita, ni una línea de más.

Esta guía cubre eso. Y es larga porque hay mucho que desaprender primero.

---

¿Qué Son Realmente los Tokens?

Comienza aquí: los modelos de lenguaje no ven texto. Ven números.

Cuando escribes “GitHub Copilot es una IA que ayuda a programar”, el modelo no procesa esa oración. La convierte en tokens, que son números que representan pequeños fragmentos de texto. La oración se convierte en aproximadamente 15-20 tokens. En español, el promedio es 2-3 caracteres por token (el tokenizador es diferente al inglés, donde son 3-4).

Un token es la unidad mínima de significado que el modelo entiende. No equivale exactamente a una palabra. Puede ser una palabra completa, parte de una palabra, o incluso un carácter especial. “GitHub” podría ser un token. “Copilot” otro. Un espacio después de un punto podría ser un tercer token de por sí.

La Ventana de Contexto: el espacio de trabajo del modelo

Todo lo que el modelo procesa en una sola conversación vive dentro de una ventana de contexto. Piensa en ella como la memoria de trabajo de una persona: es finita, tiene límites, y cuando se llena, los recuerdos antiguos empiezan a desaparecer.

En Claude Haiku, la ventana es de 200,000 tokens. En GPT-4o, es de 128,000. En Copilot (que usa varios modelos, principalmente Claude y GPT-4o mini), depende del modelo que hayas seleccionado en VS Code.

Esa ventana contiene todo:

• Las instrucciones del sistema (quién eres, qué reglas sigues)
• Tu solicitud actual
• Todo el historial de la conversación
• Los archivos que referenciaste
• Los resultados de cada herramienta que ejecutó
• Tus instrucciones personalizadas y CLAUDE.md

Cuando la ventana se llena, un proceso automático comprime las partes más antiguas. Generalmente, los primeros turnos de la conversación se resumen o descartan. Los detalles técnicos se pierden. Esto significa: cada token que pones en contexto es espacio que le quitas a la respuesta del agente.

Costo y Cuota: la economia del consumo

Si usas GitHub Copilot con un plan Pro o Enterprise, tienes una cuota de solicitudes premium. Los modelos de menor costo (GPT-4o mini, Claude 3.5 Haiku) no consumen cuota. Los de mayor costo (GPT-4 Turbo, Claude 3.5 Sonnet) consumen cuota rápidamente.

No es solo sobre dinero de tu bolsillo. Es sobre límites de velocidad. Si quemas toda tu cuota en una sola semana, el sistema te ralentiza. Tus solicitudes pagan dinero adicional o se colan en una cola. Tu productividad cae.

Un desarrollador que no entiende tokens es como un taxista que no ve el precio del combustible: cada viaje se ve barato hasta el momento en que miras la factura del mes.

---

Cómo Piensan Realmente los Modelos de Lenguaje

Aquí es donde muchos desarrolladores se equivocan. Los LLM no ejecutan lógica como el código que escribes. No tienen variables que persisten entre solicitudes. No “recuerdan” conversaciones anteriores sin que se las incluyas en el contexto.

Son probabilísticos, no determinísticos

Si le das el mismo prompt a un LLM cien veces, obtendrás noventa respuestas ligeramente diferentes. Esto no es un bug. Es la naturaleza del tipo de modelo.

Un LLM funciona como un predictor masivo de probabilidades. Dado un contexto (los tokens anteriores), predice cuál es el token más probable que debería venir después. Luego predice el siguiente. Y el siguiente. Cada predicción se basa en una distribución de probabilidad estatística, no en reglas deterministas.

La pequeña aleatoriedad en tu configuración (parameters como “temperature”, que controla cuánta variación hay) hace que a veces elija la opción más probable, y a veces otra viable. Esto es útil porque el token “más probable” no siempre es la mejor respuesta creativa. Pero también significa: si necesitas exactitud garantizada, no uses un LLM. Usa un algoritmo.

Lo que sí puedes controlar: la calidad del contexto. Un prompt vago (“ayúdame con mi código”) con contexto pobre produce respuestas caóticas e inconsistentes. Un prompt preciso (“Refactoriza esta función para extraer la validación a un método separado, sin cambiar la firma pública”) con contexto relevante produce respuestas consistentemente buenas.

El contexto es pensamiento

Para un LLM, incluir información relevante en tu solicitud no es un “extra”. Es el equivalente a darle instrucciones más claras a una persona. Un desarrollador senior con referencia a la documentación es más preciso que uno senior sin referencia.

Aquí viene la trampa: más contexto no siempre significa mejor respuesta. Un archivo de 10,000 líneas cuando tu pregunta solo necesita 50 líneas de ese archivo es ruido. Es tokens desperdiciados. El modelo tiene que leer todo, extraer lo relevante, y luego razonar. Es como pedirle a alguien que responda una pregunta mientras le pones diez libros en la mesa.

La habilidad no es poner más contexto. Es poner exactamente el contexto correcto.

Multiturno: cómo itera el razonamiento

Un “turno” es una sola solicitud y respuesta. En modo agente, una tarea típica involucra muchos turnos:

1. Turno 1: Pregunta sobre un problema
2. El agente lee archivos, ejecuta herramientas
3. Turno 2: El agente propone una solución en código
4. Ejecuta esas herramientas (escribir archivos, ejecutar tests)
5. Ve si funcionó
6. Turno 3: Ajusta basándose en lo que aprendió

Cada turno quema tokens de entrada y salida. Un agente que itera sin dirección clara puede terminar quemando 3x o 5x los tokens que necesita una solicitud bien estructurada.

---

GitHub Copilot: Más Allá de “Autocompletado para Código”

GitHub Copilot es más que el VS Code inline suggestion que muchos conocen. Es un stack de componentes: un modelo de lenguaje, un sistema de instrucciones especializadas, integración con herramientas (MCP), y three interaction modes.

¿Qué modelo hay debajo?

Cuando abres Copilot en VS Code, no siempre sabes qué modelo está corriendo. GitHub usa principalmente Claude 3.5 Sonnet y GPT-4o mini, variando según la tarea, tu suscripción y la carga del sistema. El usuario puede elegir, dependiendo de su versión de Copilot.

• Claude 3.5 Sonnet: Mejor razonamiento, mejor para tareas complejas. Consume más tokens, más lento.
• GPT-4o mini: Rápido, suficiente contexto, bueno para tareas simples. Más barato en tokens.

No hay un modelo perfecto. Hay un modelo apropiado para cada tarea. Un refactor simple de una función de 30 líneas en GPT-4o mini toma 2-3 segundos. En Sonnet toma 8-10 segundos. El contexto que necesita es el mismo. La velocidad es diferente.

Los tres modos: Ask, Plan, Agent

GitHub Copilot expone tres formas de interactuar:

Ask — Haces una pregunta, Copilot responde. No modifica archivos. Es útil para preguntas conceptuales, explicaciones, debugging exploratorio. Un turno. A veces dos o tres de ida y vuelta. Bajo costo en tokens.

Plan — Copilot analiza tu solicitud, propone un plan de qué hacer, y espera tu aprobación antes de ejecutar cambios. Útil para trabajo de mediano alcance donde quieres validar la estrategia antes del cambio. Tres a cinco turnos típicamente.

Agent — Es donde ocurre la magia y también donde quemas tokens rapidísimo si no sabes qué estás haciendo. El agente puede leer múltiples archivos, ejecutar herramientas, ver salidas, iterar. Para una tarea compleja, puede tomar 20-30 turnos. Cada turno es contexto: todos los archivos leídos se mantienen en el historial. Todas las salidas de herramientas acumulan tokens.

Elegir el modo incorrecto para una tarea es como elegir un camión para un viaje de 2 km. Funciona, pero es innecesariamente caro.

---

La Anatomía del Consumo de Tokens en Agentes

Cuando activas Agent en VS Code y dices “Refactoriza toda la carpeta src/ para usar principios SOLID”, esto ocurre internamente:

1. El agente lee tu solicitud (digamos, 50 tokens)
2. Incluye su contexto del proyecto (CLAUDE.md, si existe: 500-2000 tokens)
3. Comienza a explorar: lee archivos. Cada archivo es más tokens. Un archivo Go de 300 líneas son 500-1000 tokens. Si lee 10 archivos, son 5000-10000 tokens en solo lectura.
4. Propone cambios. La respuesta son más tokens.
5. Ejecuta herramientas o cambios. Sus salidas vuelven al contexto. Más tokens.
6. Ve que falló un test, lee el output del test (100-500 tokens).
7. Ajusta. Más tokens.
8. Itera hasta éxito.

Una solicitud que podría ser resuelta en 3 turnos bien estructurados al agente le tomas 15 turnos sin estructura. Es 5x el costo en tokens.

MCP: Dándole Herramientas al Agente

MCP (Model Context Protocol) es la forma en que Copilot agrega nuevas herramientas al agente más allá de leer/escribir archivos. Un agente puede conectar a:

• Bases de datos
• APIs externas
• Herramientas CLI personalizadas
• Sistemas de gestión de paquetes

Cada herramienta que ejecuta agrega contexto: su solicitud, su respuesta. Un agente que llama a una API 5 veces acumula 5 conjuntos de request/response en la ventana. Eso es tokens.

---

Estrategias de Optimización Real

Ahora, cómo no quemar tokens sin razón.

1. CLAUDE.md Como Puente de Contexto

El problema: cada vez que iniciabas una conversación con Copilot, tenías que explicar tu proyecto. Estructura, convenciones, stack. Eso es contexto que el agente aprendía desde cero cada sesión, quemando tokens en educación básica.

La solución: un archivo CLAUDE.md en la raíz que Copilot lee automáticamente. Este archivo contiene:

• Qué es el proyecto
• Su estructura (directorios importantes)
• Cómo ejecutar comandos
• Reglas duras (nunca hagas esto)
• Punteros a más documentación

El beneficio: el agente empieza cada sesión con contexto. No precisa explorar. No precisa preguntar. Comienza a trabajar.

# Proyecto: Blog Técnico SazarDev

**Estructura:**

- src/content/blog/es/ — Posts en español
- src/content/blog/en/ — Posts en inglés
- src/layouts/ — Componentes de estructura

**Comandos:**

- bun dev — servidor de desarrollo
- bun build — build para producción

**Reglas:**

- Sin emojis en código ni en prosa
- Tamaño máximo de imagen: 200KB
- Siempre traduce cambios en ambos idiomas

Eso podría ser 500 tokens guardados por sesión.

2. Especificidad Incremental

En lugar de:

Ayúdame a optimizar este código

Escribe:

El archivo src/utils/parser.ts tiene una función parseHeavyXML que está siendo llamada 10,000 veces por segundo en trafico pico.
Actualmente toma 50ms por llamada y estamos viendo bottlenecks.
Necesito optimizarlo para que no exceda 5ms sin cambiar su firma pública.
Usa memoización o caché si es aplicable. Muestra solo el cambio de código, no toda la refactorización.

La primera solicitud es vaga. Copilot dirá “OK, pero necesito ver tu código primero” y querrá leer 20 archivos. Eso es 10-15 turnos innecesarios.

La segunda es específica. El agente sabe dónde mirar, qué problema resolver, y qué No cambiar. Lee una función, propone una solución. Un turno.

3. Fragmentación Inteligente de Tareas

Dividir una tarea grande en tareas pequeñas no siempre ahorra tokens, pero a menudo sí.

Mal:

Migra el proyecto de PostgreSQL a DynamoDB

La ventana del agente se llena de schemas SQL, configuración, migrations. Es un proyecto entero. Puede tomar 30+ turnos.

Bien:

Paso 1: Migra la tabla users a DynamoDB. Muestra solo modelo de datos, no toda la aplicación.

Paso 2: Migra la tabla transactions. Reutiliza lo que aprendiste del paso 1.

Cada paso es 5-8 turnos. El contexto es nuevo pero más pequeño y enfocado. El agente necesita menos exploración. Es consistentemente más rápido.

4. Excluir Ruido

Cuando hagas una solicitud, excluye explícitamente lo que el agente No debería leer:

Refactoriza src/api/handlers.ts para usar inyección de dependencias.
Ignora: tests, migrations, documentación externa.

Sin eso, el agente dirá “déjame revisar archivos relacionados” y leerá tests, migrations, docs. Eso es contexto que no necesita.

5. Compresión de Contexto Manual

Para contexto que el agente va a usar pero que es muy grande:

En lugar de apuntar al archivo completo, extrae la sección relevante:

Mal:

Revisa src/domain/user/entity.ts

(El archivo tiene 500 líneas de código relacionado con múltiples entidades)

Bien:

Revisa esta función de validación en src/domain/user/entity.ts:

[copias las 40 líneas de la función específica aquí]

¿Cómo extraería esto a un validador reutilizable?

Es más trabajo para ti, pero ahorra al agente exploración. Y en tiempo real significativo.

---

Patrones de Consumo en la Práctica

Patrón 1: La Pregunta Exploratoria (Ask)

Token profile: 50 entrada + 200 salida = 250 tokens

¿Cuál es la diferencia entre usar Context en Go
y pasar un parámetro timeout a cada función?

El agente da una respuesta directa. Un turno. No lee archivos. Bajo costo.

Patrón 2: El Refactor Localizado (Plan)

Token profile: 200 entrada + 1000 exploración + 500 salida = 1700 tokens

Refactoriza la función calculateTotal en src/service/order.go
para que sea más testeable. Extrae la lógica de descuentos
a un validador separado.

El Plan mode:

1. Lee tu solicitud
2. Lee el archivo específico
3. Propone cambios
4. Espera validación
5. Ejecuta

3-4 turnos, contexto controlado.

Patrón 3: La Migración Compleja (Agent)

Token profile: 5000+ entrada + 10000-50000 exploración = consumo alto

Migra el sistema de caché de Redis a Memcached.
Actualiza toda la capa de persistencia.
Reemplaza las llamadas en aplicación.
Ejecuta tests.

El agente va a:

1. Explorar arquitectura
2. Leer implementación actual
3. Proponer cambios
4. Ejecutar
5. Ver qué rompe
6. Iterar

15-25 turnos. Alto consumo.

Cómo reducirlo:

**Paso 1:** Migra la capa de caché (src/cache/redis.go) a Memcached.
Solo modelo, no aplicación. No ejecutes tests aún.

Después:

**Paso 2:** Ahora actualiza src/application/service.ts para usar el nuevo caché.

Mismo trabajo. 10 turnos de 15 cada uno. Contexto más pequeño por turno. Costo similar o mejor. Mejor control.

---

El Error Más Caro que Cometen los Equipos

Abrir Copilot agente sin contexto y decir: “Hazme un backend completo”.

Lo que ocurre:

1. El agente pregunta: “¿Qué base de datos? ¿Qué framework? ¿Qué regiones?”
2. Le explicas. Eso es tokens.
3. Dice: “Déjame revisar archivos relacionados”. Lee 20 archivos. Más tokens.
4. Propone una solución que no se alinea con tu stack. Más iteraciones.
5. Al final resulta en 5x tokens utilizados de lo que hubieras utilizado con una solicitud bien estructurada.

El costo de no preparar contexto es siempre mayor que el costo de construirlo. Siempre.

---

Cierre: La Mentalidad del Desarrollo Asistido por IA

Muchos desarrolladores tratan los modelos de lenguaje como si fueran Google Bard: hazle una pregunta, obtén una respuesta, listo.

Copilot es diferente. Es un compañero de trabajo que tiene límites de atención y presupuesto. Cuando lo usas como un taxista sin dirección, quemas dinero. Cuando lo usas como un taxista con mapa, ruta clara y destino conocido, llegas en línea recta.

La economía es brutal: contexto mal usado es dinero desperdiciado. Pero la oportunidad es clara: contexto bien preparado te ahorra horas de trabajo manual.

La pregunta ya no es “¿Qué me cuesta usar IA?” sino “¿Qué me cuesta No usarla bien?”

La IA no es más rápida si es más cara. Es más rápida cuando es más eficiente.