Tu agente de código consume más energía que tú escribiendo a mano — pero ¿compensa?

41 Wh. Eso consume una sesión mediana de Claude Code — datos medidos directamente por el investigador Simon P. Couch en enero de 2026.

Es lo mismo que 136 consultas de texto normales. O que una bombilla LED encendida durante cuatro horas. O el 12% de la energía que consume tu portátil en un día de trabajo completo.

Y eso es la sesión mediana. Una sesión compleja — un día entero con el agente activo — puede llegar a 50-200 Wh.

La pregunta no es si el consumo es alto. Es si compensa.

Qué es un agente de código y por qué consume tanto

Hay una diferencia fundamental entre un asistente de código y un agente de código.

El autocompletado clásico — el GitHub Copilot original, los snippets inteligentes — hace una sola llamada al modelo por sugerencia. El coste es pequeño y puntual: 0,5-2 Wh por sesión de trabajo.

Un agente es otra cosa. No espera a que tú escribas: actúa. Recibe una tarea en lenguaje natural (“implementa la autenticación con OAuth”, “migra estos tests a la nueva API”, “encuentra y corrige el bug de rendimiento en checkout”) y procede de forma autónoma.

Para completar esa tarea, el agente:

• Lee archivos del proyecto — a veces decenas
• Planifica y descompone la tarea antes de tocar código
• Escribe código, lo ejecuta en un entorno sandbox y lee la salida
• Interpreta errores y decide cómo corregirlos
• Vuelve a empezar si el resultado no pasa los tests

Una “tarea simple” puede desencadenar 20-50 llamadas al modelo. Una tarea compleja, cientos. Y cada llamada incluye el contexto acumulado — todos los archivos leídos, todo el historial — lo que hace que los tokens por llamada también crezcan con el tiempo.

El resultado: el consumo no escala linealmente con la complejidad de la tarea. Escala de forma superlineal.

Los datos: herramienta por herramienta

Estos son los rangos de consumo documentados para los principales agentes de código, con sus multiplicadores respecto a una consulta de texto simple (0,3 Wh de referencia):

Algunas observaciones sobre esta tabla:

Aider es la anomalía positiva. El agente open source consume x4 menos tokens que Claude Code para tareas equivalentes. La eficiencia no es monopolio de las soluciones comerciales.

Devin 2.0 es el más impredecible. El rango de 10-60 Wh refleja una varianza enorme: su modo autónomo completo puede consumir tanto como una sesión extensa de Claude Code con Opus.

GPT-5.3-Codex duplica a su predecesor. El salto de x20-x67 a x40-x133 entre versiones ilustra la tendencia: los modelos con razonamiento integrado cuestan más, aunque también son más capaces.

El caso Claude Code: los únicos datos con metodología pública

De toda la lista anterior, solo existe un análisis público con metodología detallada: el de Simon P. Couch, publicado en enero de 2026.

Couch analizó sus propias sesiones de trabajo con Claude Code durante semanas y documentó lo siguiente:

• Sesión mediana: 592.000 tokens en 24 intercambios interactivos
• Consumo por sesión mediana: 41 Wh
• Equivalencia: 136 consultas de texto normales
• Sesión de uso intensivo (múltiples instancias, día completo): 50-200 Wh

“Un desarrollador usando agentes de código 8 horas al día consume una energía equivalente a tener una nevera encendida durante 24 horas.” — Simon P. Couch, análisis de consumo energético de Claude Code, enero 2026

Lo que hace valioso este análisis no es solo el número: es que nadie más ha publicado datos similares. Ni Anthropic, ni OpenAI, ni GitHub, ni Cursor. Las empresas que venden estas herramientas no publican Wh por tarea. Solo publican precio por token — que es una variable proxy del consumo, pero no equivale al consumo real en contexto.

La paradoja de productividad

Aquí viene la parte incómoda del análisis: el coste energético alto puede estar justificado si la ganancia de productividad es real.

Los datos internos de GitHub apuntan a un +55% de velocidad en tareas acotadas con Copilot Agent. Estudios de equipos que adoptan agentes de código completos reportan equivalencias de 3-4 días de trabajo comprimidos en uno para ciertos tipos de tareas.

Si eso es cierto — y la metodología tiene limitaciones que discutiremos — el ROI puede ser positivo incluso considerando el consumo energético.

Pero hay un problema con estos datos:

Los benchmarks de productividad los producen las propias empresas. GitHub mide el impacto de Copilot. Anthropic mide el impacto de Claude Code. Ningún estudio independiente ha medido simultáneamente:

1. Velocidad de desarrollo
2. Consumo energético total
3. Calidad del código producido
4. Mantenibilidad a largo plazo
5. Deuda técnica generada

El efecto rebote es real y documentado en otras tecnologías: cuando algo se vuelve más rápido, se usa más. Un equipo que adopta agentes de código no solo hace lo mismo más rápido — también genera más código, más iteraciones, más revisiones, más PRs. ¿Más gasto total? Probablemente sí.

La pregunta que nadie está respondiendo es: ¿ese código adicional genera valor, o solo acumula deuda técnica?

¿En qué casos SÍ compensa el coste?

No todos los casos de uso son iguales. Estas son las situaciones donde el coste energético de un agente de código tiene un retorno claro:

Migraciones y refactoring con patrones bien definidos. Migrar de una versión de API a otra, actualizar dependencias, convertir tests de un framework a otro. El agente conoce el patrón, lo aplica a cientos de archivos con consistencia. El humano tardaría días; el agente, horas. El diferencial de tiempo tiene valor de negocio real.

Prototipado rápido donde el tiempo de mercado importa. En fases de exploración con deadlines reales — una demo para inversores, un MVP para validar una hipótesis — el coste de velocidad puede superar con creces el coste energético.

Comprensión de codebases grandes. Pedir a un agente que explique la arquitectura de un proyecto de 200.000 líneas, trace el flujo de una función o identifique todos los puntos de uso de una API. Aquí el agente lee más que escribe, y el valor está en la síntesis.

Tests de regresión y cobertura. Generar tests para código existente bien documentado es predecible y el agente lo hace bien. El tiempo humano liberado puede dedicarse a tareas de mayor valor cognitivo.

¿En qué casos NO compensa?

Exploración open-ended. “Haz algo interesante con estos datos.” “Mejora el rendimiento de la aplicación.” “Refactoriza para que sea más limpio.” Sin criterio de éxito claro, el agente itera sin converger. Muchas llamadas al modelo, resultado incierto, revisión manual inevitable de todos modos.

Dominios que el modelo no domina bien. Si el agente no conoce bien el dominio — una librería muy específica, un lenguaje poco común, lógica de negocio sin documentar — cometerá errores y necesitará muchas iteraciones para corregirlos. Consumo alto, resultado mediocre.

Tareas donde la velocidad no importa. Si no hay deadline, si el código generado va a necesitar revisión exhaustiva de todos modos, si el equipo va a pasar más tiempo revisando lo que hizo el agente que lo que habría tardado en escribirlo: el ROI es negativo.

Cuando el código generado crea más deuda técnica que la que resuelve. Los agentes son optimizadores de completar la tarea asignada. No tienen contexto de negocio propio, no conocen las convenciones implícitas del equipo, no saben qué partes del código son más críticas. El código que generan puede funcionar y aun así ser un problema a seis meses vista.

El sesgo de la medición

Existe un problema estructural en cómo se está evaluando el impacto de los agentes de código:

Los estudios de productividad los financian los que venden productividad. El estudio más citado sobre el impacto de Copilot es el de GitHub, que pertenece a Microsoft, que vende Copilot. El análisis más favorable sobre Claude Code viene de Anthropic. Esto no invalida los datos, pero sí requiere leerlos con sentido crítico.

Las métricas de éxito están sesgadas hacia lo que es fácil de medir. Velocidad de completar una tarea acotada: medible. Calidad del código a seis meses: no medible en un estudio de tres semanas. Deuda técnica acumulada: tampoco. Impacto en la capacidad del desarrollador de mantener y entender su propio código: casi imposible de aislar.

Ningún proveedor publica métricas de consumo energético por tarea. Los precios por token son públicos. Los Wh por tarea no. La transparencia energética que se exige a los electrodomésticos no se exige a las herramientas de software que consumen órdenes de magnitud más energía que cualquier lavadora.

Desde AISHA planteamos una petición concreta: que los proveedores de agentes de código publiquen métricas de Wh por tarea, del mismo modo que publican precio por token y velocidad de generación. No es información difícil de calcular para quien tiene acceso a sus propios sistemas. Es información que los usuarios y los equipos de ingeniería necesitan para tomar decisiones informadas.

Un agente de código no es mejor que un desarrollador humano. Es diferente: más rápido en ciertos tipos de tareas, más costoso energéticamente, sin contexto de negocio propio. La decisión de usarlo bien requiere saber exactamente qué tipo de tarea tiene entre manos.

¿Qué puedo hacer yo?

• Si eres desarrollador: Distingue qué tipo de tarea tienes antes de invocar el agente. Tarea repetitiva con criterio claro → agente. Exploración abierta → escribe tú primero. Considera Aider para tareas donde la autonomía máxima no es necesaria: x4 menos consumo para resultados comparables.

• Si diriges un equipo de ingeniería: Establece una política de uso, no solo de acceso. Mide el tiempo total del ciclo — incluyendo revisión y corrección del código generado — no solo el tiempo de generación. Define qué tipos de tareas justifican agente completo versus asistencia simple.

• Si eres CTO o responsable técnico: Un equipo de 20 ingenieros usando agentes de código 6h diarias consume el equivalente energético de varios cientos de neveras encendidas 24/7. Es un dato relevante para ESG y para costes operativos cuando el cómputo se paga por uso.

• Si trabajas en sostenibilidad tecnológica: Exige a los proveedores de herramientas de desarrollo que incluyan métricas de Wh por tarea en sus dashboards. El coste por token ya está publicado. El coste en Wh debería estarlo también — no es difícil técnicamente, es una decisión de transparencia.