💸 Ahorro de tokens

La frase clave de Matt Pocock sobre este tema es directa: "¿Cómo optimizas el gasto de tokens? Teniendo un codebase al que sea más fácil hacerle cambios." Fíjate: su respuesta no no es «usa un prompt mágico» ni «espera a que haya un modelo mejor». Es arquitectura — la forma en que tu codebase está organizado. Cada vez que el agente necesita entender el código para cambiar algo, lee archivos (tokens de entrada) y escribe intentos (tokens de salida). Cuanto más confuso sea el terreno, más necesita leer e intentar, y el gasto de tokens sube.

¿Por qué esto es fundamental y no un detalle? Porque el precio de la IA se cobra por token — tanto lo que entra como lo que sale. Un archivo gigante de mil líneas obliga al agente a tragárselo todo solo para cambiar una función. En cambio, un codebase modular (archivos pequeños, nombres obvios, cada cosa en su lugar) permite que el agente lea solo la parte relevante. La misma tarea, el mismo modelo, una fracción de los tokens. El error común de principiante es tratar el costo de la IA como una cifra fija en la factura, cuando en realidad es consecuencia directa de cuán fácil dejaste de recorrer tu código.

Pocock usa una imagen excelente para explicar el costo: sin protección, el modelo queda "dándose de cabeza contra la pared" — intentando, fallando, intentando de nuevo, quemando tokens en cada intento. La solución no es un modelo más inteligente: son guard rails. Un guard rail es cualquier cosa en la base de código que impide el camino equivocado y señala el correcto: un tipo (type) que no compila si le pasas el valor incorrecto; un prueba que falla de inmediato; un linter que se queja; un mensaje de error claro que dice exactamente qué falta.

La razón es puro costo: cada guard rail convierte una tropiezo costoso (el agente descubre el error tarde, después de reescribir medio sistema) en una corrección barata (el error aparece de inmediato, en una línea). Pocock resume: "mejores barreras de seguridad, menos tokens chocando contra la pared." O error común aquí es lo opuesto — gente que elimina las pruebas «para ir más rápido». Sin barreras de seguridad, la IA avanza a ciegas, se desvía más y te cuesta más a cada paso.

Aquí está el corazón del módulo, en palabras de Pocock: "Ten un codebase más fácil de modificar → puedes usar un modelo más tonto/más barato para hacer el mismo trabajo." Fíjate en la lógica: la capacidad necesaria del modelo no es fija — depende de lo difícil que hayas hecho la tarea. Un buen harness baja el nivel de inteligencia necesaria. Por eso, un modelo más barato puede entregar lo que, en un codebase deficiente, solo entregaría un modelo costoso.

Y el reverso, que Pocock llama por su nombre: "Dejas tu modelo limitado desde el primer día → necesitas un modelo inteligente." Hamstringing (literalmente «cortar el tendón») es darle a la IA un terreno confuso, sin guard rails ni documentación. Entonces tropieza con todo, y tú estás gracias a pagar por el modelo más avanzado solo para que no se pierda. Conexión con el módulo 1.1: como el harness representa el 50% del resultado, es él —no el modelo— quien define el límite de costo. El error común es la carrera por el «modelo del momento»: invertir en un motor caro para compensar un chasis que tú mismo podrías haber arreglado por mucho menos.

El costo de un codebase deficiente no es un cobro único; es un impuesto recurrente sobre cada tarea futura. La IA vuelve a leer archivos que no necesitaba leer, intenta enfoques que un guard rail habría bloqueado y genera código que rompe otras partes (porque no podía saber que existían). Cada una de esas idas y vueltas es token costo. Multiplícalo por todos los cambios del proyecto y el «impuesto» se convierte en el rubro más grande de tu factura.

Hay un efecto todavía más engañoso: un codebase malo también oculta bugs, y los bugs ocultos cuestan tokens (y dinero) cada vez que la IA tropieza con ellos. Pocock observa que muchos bugs profundos no requieren un modelo genial para encontrarlos: "podrías descubrir estos errores con modelos más baratos si buscaras en los lugares correctos y dieras el prompt/harness adecuado." Es decir: lo que parecía «necesitar una IA cara» era, una vez más, un problema de harness. El error común es normalizar el grifo que gotea («es así, la IA es cara») en vez de cerrarlo.

La buena noticia: no estás atado al codebase que tienes. Refactorizar es reorganizar el código por dentro — dividir el archivo gigante en módulos, poner nombres claros, agregar tipos y pruebas — sin cambiar lo que hace el sistema por fuera. Y aquí está el giro: la propia IA refactoriza por ti. Gastas tokens una vez para poner todo en orden y, con cada cambio futuro, pagas mucho menos. Es una inversión, no un gasto.

Cómo Pocock lo plantea en DX × AX: mejorar el codebase es una de las palancas "frecuentemente olvidadas" para mejorar la experiencia del agente y, con ella, el costo. Refactorizar agrega guard rails (tema 2), hace que el terreno sea navegable (tema 1) y cierra la llave que gotea (tema 4), todo de una vez. El error común es posponer la refactorización «para cuando haya tiempo»: como el costo es recurrente, cada día que la pospones son más tokens desperdiciados. Mira en el cuadro de copia de abajo cómo cambia solo el manera de pedir la refactorización — del prompt vago al prompt con guard rails:

❌ ANTES (prompt vago → muitos tokens, resultado incerto)
"arruma esse arquivo aí, tá uma bagunça"

✅ DEPOIS (prompt com guard rails → poucos tokens, resultado seguro)
Refatore o arquivo src/pagamento.js, SEM mudar o comportamento.
Objetivo: baratear mudanças futuras.
Regras (guard rails):
1. Quebre em módulos pequenos por responsabilidade (1 arquivo = 1 tema).
2. Adicione TIPOS nas funções públicas (assinaturas explícitas).
3. NÃO toque na lógica de negócio — só na organização.
4. Rode os testes existentes ao final; todos têm que continuar passando.
5. Se faltar teste pra um caminho crítico, escreva o teste antes de mover o código.
Entregue: lista do que mudou + confirmação de testes verdes.

Lo que no se mide no se mejora. La métrica adecuada no es "cuánto gasté este mes" (eso oculta la causa), sino tokens por cambio: cuántos tokens consume una tarea típica, desde el pedido hasta la entrega. Si esta cifra es alta, es señal de hamstringing: el codebase obliga al agente a leer y probar demasiado. Si baja después de una refactorización, acabas de demostrar con números que el harness mejoró. Es el resumen práctico de todo el módulo: la arquitectura (T1) y los guard rails (T2) reducen la cifra; un codebase deficiente (T4) la aumenta; refactorizar (T5) la reduce; y una cifra baja permite usar el modelo económico (T3). Copia la lista de verificación de abajo y úsala cada vez que una tarea consuma más de lo debido:

Tarefa gastou tokens demais? Diagnostique o HARNESS, não o modelo:
[ ] ARQUITETURA — a IA teve que ler arquivos gigantes/irrelevantes?
[ ] GUARD RAILS — faltou type/teste/lint pra barrar o erro na hora?
[ ] DOCS — faltou um README/comentário apontando o lugar certo?
[ ] REPETIÇÃO — a IA tentou, errou e retentou o mesmo erro várias vezes?
Ação: refatore a área cara + adicione 1 guard rail.
Depois, reduza o modelo (ex.: do caro pro barato) e confirme que ainda passa.
Meta: o número de "tokens por mudança" cair na próxima vez.