Los Créditos de IA Desperdiciados Son el Impuesto Tonto de Todo Desarrollador. Esto Es Lo Que Hago En Su Lugar.

8 min read

Algunas mañanas abro mi dashboard de Claude antes que nada y veo un 15-20% de mis créditos semanales ahí tirados, a pocas horas del reset. Créditos que ya pagué. Créditos a punto de expirar por nada.

La mayoría de desarrolladores ven ese contador llegar a cero. (Total, no ibas a hacer nada útil con ellos, ¿verdad?)

Yo uso esas horas de otra manera. Suelto un agente de refactoring autónomo en un proyecto real, le doy una condición de finalización verificable, y me voy a hacer otra cosa. Código de producción en vivo, no un proyecto de tutorial. La semana pasada: un backend de catálogo WooCommerce de 118,000 líneas de TypeScript con uptime monitoreado cada 30 minutos, y un segundo proyecto con 6 archivos de integración de proveedores ejecutando todos el mismo bucle de sincronización, unas 500 líneas de código copiadas y pegadas en los 6. Setup: Opus 4.8, /effort ultracode, /goal. Configuré ambos y me fui.

TLDR: un agente no "mejora" las cosas. Optimiza hacia la condición de finalización que le das. Una condición vaga obtiene resultados vagos. Un prompt malo encuentra el camino más corto a "terminado", que a veces es el camino equivocado. 🤓 Estas sesiones son donde esa diferencia se hizo evidente.

Trabajador de oficina en pánico frente a la computadora con créditos de IA casi agotados mientras una figura de superhéroe se mantiene confiada monitoreando el progreso de un agente autónomo
Tus créditos de IA no se están quemando solos. Tú los estás quemando.

Opus 4.8, /effort ultracode, /goal

El trío necesita explicación antes de que las sesiones tengan sentido.

Opus 4.8 es el único modelo de Claude compatible con razonamiento xhigh, y maneja una ventana de contexto de 1M tokens. Esa segunda parte importa cuando le entregas 118,000 líneas de TypeScript y le dices que encuentre su propio camino.

/effort ultracode es una configuración de sesión en Claude Code, lanzada el 28 de mayo con v2.1.154. Activarla habilita razonamiento xhigh y activa Dynamic Workflows automáticamente. Claude decide por sí mismo cuándo vale la pena distribuir una subtarea a subagentes paralelos: hasta 16 ejecutándose concurrentemente en una máquina estándar, hasta 1,000 por ejecución. Algunos subagentes atacan el problema desde ángulos independientes. Otros intentan refutar las conclusiones del primer pase, iterando hasta que los resultados convergen. Verificación adversarial, básicamente (un grupo de raid donde la mitad está ahí específicamente para hacer fallar a la otra mitad). Las salidas intermedias viven en variables de script, no en la ventana de contexto principal, así el contexto primario se mantiene limpio mientras el trabajo se distribuye. Expliqué por qué la arquitectura nativa de CLI cambia lo que es posible para agentes autónomos en por qué los CLIs superan a MCP para agentes de IA.

/goal está disponible desde v2.1.139+. Defines una condición de finalización verificable en lenguaje natural. Una instancia separada de Haiku lee la transcripción de la sesión después de cada turno y responde con sí o no más una razón de una línea. Si no, esa razón se convierte en la siguiente instrucción de Claude. Si sí, el objetivo se limpia y la sesión termina. Sin /goal: aproximadamente 40 mensajes manuales de "continúa". Con él: defines el estado final y te vas.

Junta los 3 y tienes una sesión que puede ejecutarse sola por horas. Lo que le das para que trabaje hacia eso es la parte que realmente importa.

Antes de que Cambie la Primera Línea

Lo primero que hizo el agente en ambas sesiones no fue escribir código. Fue contar.

Backend del catálogo: encontró la suite de tests del propio proyecto, ejecutó typecheck, y bloqueó la línea base. 303 tests pasando, typecheck verde. Esos números fueron al archivo de seguimiento antes de que cualquier otra cosa se moviera.

Sesión de integración de proveedores: 404 tests verdes. 701 errores de lint ya presentes en el codebase, contados y registrados antes del primer cambio.

Esto no es ceremonia opcional. El mecanismo que hace que el refactoring autónomo funcione es el mismo que lo hace seguro: el agente optimiza para la condición de finalización que defines, no para alguna noción abstracta de mejor código. Sin una línea base conocida establecida antes del primer commit, no hay condición para optimizar y no hay estado de referencia al cual regresar si algo se rompe a mitad del cambio. La línea base define qué significa verde. Es a lo que apunta cada verificación en la sesión. Omítela y el agente hace cambios que no puede verificar, continúa porque nada dice que no lo haga, y para cuando revisas el diff está horas adentro sin un camino limpio de regreso. Toma minutos establecerla antes de tocar cualquier cosa. Omitirla puede costar toda la sesión.

No atacas al jefe sin configurar tu punto de spawn. La línea base es el punto de spawn.

Primer comportamiento notable en el backend del catálogo: el agente generó subagentes paralelos para mapear el codebase antes de escribir una sola línea. Cada hallazgo regresó a través de grep para verificación cruzada. No estaba navegando el código. Estaba construyendo un caso.

Dos Momentos Sobre Verificación

Error fantasma, backend del catálogo

A mitad de la extracción de un componente, la consola arrojó un error: CategoryEditor definido dos veces. El tipo de cosa que te hace querer hacer rollback inmediatamente.

El agente ejecutó typecheck. Limpio. Buscó con grep cualquier definición de clase duplicada en el codebase. Nada encontrado. Cargó la página actual en un navegador: se renderizó correctamente.

Era un artefacto del servidor de desarrollo, un fantasma de la transición entre rutas de módulos viejas y nuevas durante la extracción. Un reinicio en el siguiente checkpoint: cero errores.

El procedimiento: typecheck, grep, render en navegador. Cada verificación independiente. Un error de consola es ruido hasta que 2 señales independientes concuerdan con él. "Compila" no es una prueba en vivo. Tampoco lo es "la terminal arrojó algo una vez."

Una pequeña tangente: mientras leía los logs de la sesión de integración de proveedores, recibí un Slack de un cliente preguntando sobre una factura de hace 3 meses. Pasé 20 minutos buscando en hilos de email para encontrar la original. Mientras tanto el agente había procesado 40 archivos y estaba ejecutando 3 subagentes paralelos. Diferente tipo de throughput.

Rechazo de deploy, integración de proveedores

En un punto la sesión golpeó una barrera que bloqueó el acceso a producción. El agente no intentó evitarla. Verificó lo que pudo a través de la suite de tests, confirmó que los cambios centrales se mantenían, y siguió trabajando en el alcance restante sin la ruta de producción. Esa es la diferencia entre una herramienta y una responsabilidad, y no es una distinción menor.

Lo que el Agente Decidió No Tocar

El backend del catálogo tenía 2 funciones slugify que se veían casi idénticas. Cualquier auditoría automatizada las marca como candidatos obvios para fusión. Leyendo el código real: 1 maneja apóstrofes diferente, la otra trunca a 80 caracteres. La diferencia entre ellas no es cosmética. Es sobre qué productos obtienen qué URLs, y esas URLs ya están indexadas en todo el catálogo. Fusionarlas habría reescrito enlaces de productos en vivo sin aviso.

La misma lógica aplicó a 5 variantes de un parser de metadata que todas reescribían registros de productos en vivo. La auditoría encontró la duplicación. Leer el código mostró por qué existía cada variante. El 10% que diverge entre ellas es exactamente el 10% que importa para datos en vivo. El agente marcó las 5, no fusionó nada, y siguió adelante.

El backend Convex fue una decisión más difícil. Ejecuta en un solo ambiente, significando que dev es prod. Una prueba en vivo requiere hacer deploy a producción. La ganancia potencial era limpieza cosmética. El riesgo era inverificable sin un deploy. El agente lo difirió, lo documentó en el archivo de seguimiento, y lo dijo. Honestamente no estoy seguro de que el refactor hubiera valido la pena incluso con un ambiente de prueba real, pero ese es un juicio que pertenece a un humano con contexto completo, no a un agente ejecutándose sin supervisión.

La sesión de integración de proveedores terminó con 334 errores de lint aún en su lugar. Esos 334 ya estaban ahí antes de que la sesión comenzara, distribuidos en cientos de archivos. Limpiarlos en lote habría significado tocar todo para cero ganancia arquitectónica. Los scripts de migración viejos se veían muertos pero resultaron ser escotillas de emergencia manuales, del tipo que solo recuerdas que existen cuando prod está en llamas y el failover automatizado está caído (pregúntame cómo lo sé). El agente dejó una nota y los omitió en lugar de decidir por mí.

"Satisfecho" no significa que todo fue tocado. Significa que los verdaderos ofensores fueron abordados y verificados, y todo lo demás es riesgoso de cambiar o de bajo valor para arreglar. Inventar trabajo adicional es falla, no diligencia.

El Prompt Con Cicatrices

El prompt original que envié para la sesión del backend del catálogo tenía huecos.

Ninguna mención de producción en ningún lado. "Hasta estar satisfecho" sin endpoint verificable. "Live-test" sin una definición de qué cuenta. Una instrucción "autoreview" que no corresponde a ningún comando real de Claude Code.

Cada hueco mapea a un momento que podría haber ido diferente. Las funciones slugify habrían sido fusionadas. El backend Convex podría haber sido tocado. El error fantasma habría disparado un rollback en una sola señal no confirmada.

Estas 2 sesiones produjeron algo que vale la pena conservar:

/goal Improve this project's architecture through safe, incremental refactoring.
First: discover the project's own check/test/build/run commands (package.json
scripts, Makefile, justfile, CI config, README) and establish a green baseline
with them — record it. Then audit the codebase for concrete debt (dead code,
duplication, oversized files/modules) with grep-level evidence BEFORE touching
anything. If the project isn't green at the start, stop and report instead of
refactoring blind.
Work in priority order of (value × safety × verifiability). For each step:
  1. one coherent change,
  2. live-test through the REAL path — exercise the change end-to-end for THIS
     project type (browser for a web app, run the CLI/binary, the test suite for
     a library, a real request for an API, a dry-run for a cron). "It compiles"
     is NOT a live-test,
  3. run /code-review on the diff and address its findings,
  4. commit (conventional message, stage by path).
Hard constraints:
  - Production code: prefer surgical, reversible changes over rewrites.
  - Never change a public contract (API paths, published URLs, output formats)
    or any externally observable behavior.
  - Never refactor anything you cannot verify green. If you can't safely
    live-test it, DEFER it and say so explicitly.
  - If reading the real code shows a duplication or variation exists for a
    reason, skip the "cleanup."
Done when the remaining debt is either risky or low-value — don't manufacture work.
Track progress in ~/tmp/refactor-<project>.md (derive <project> from the repo):
log every step, every decision, AND every item you deliberately rejected with why.
Don't push or deploy without asking.

Cada cláusula es una cicatriz de una sesión que no la tenía.

De eso se trata realmente el framework completo de contratos de prompts: no estructura por sí misma, sino restricciones que vienen de que algo salió mal.

Tus Créditos Expiran Esta Noche

Lo que las 2 sesiones realmente produjeron:

Backend del catálogo: 4 commits limpios, 2 archivos hinchados reducidos, tests de 303 a 313, neto -57 líneas. Cero roto en producción.

Integración de proveedores: +288/-711 líneas, tests de 404 a 407, un componente muerto de 504 líneas purgado, lint de 701 bajó a 334 errores.

Si quieres profundizar en el método, Vibe Coding, For Real cubre el enfoque paso a paso para enviar proyectos reales con IA. Gratis en Kindle Unlimited.

Tu reset viene en camino. Los créditos en tu dashboard ya están pagados.

Mejorar la arquitectura de tus proyectos es el mejor uso de créditos que expiran.

Fuentes

Este post puede contener enlaces de afiliado. Si los clickeas, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).