El teu agent de codi consumeix més energia que tu escrivint a mà — però compensa?

41 Wh. Això consumeix una sessió mitjana de Claude Code — dades mesurades directament pel investigador Simon P. Couch al gener de 2026.

És el mateix que 136 consultes de text normals. O que una bombeta LED encesa durant quatre hores. O el 12% de l’energia que consumeix el teu portàtil en un dia de treball complet.

I això és la sessió mitjana. Una sessió complexa — un dia sencer amb l’agent actiu — pot arribar a 50-200 Wh.

La pregunta no és si el consum és alt. És si compensa.

Què és un agent de codi i per què consumeix tant

Hi ha una diferència fonamental entre un assistent de codi i un agent de codi.

L’autocompletat clàssic — el GitHub Copilot original, els snippets intel·ligents — fa una sola crida al model per suggeriment. El cost és petit i puntual: 0,5-2 Wh per sessió de treball.

Un agent és una altra cosa. No espera que tu escriguis: actua. Rep una tasca en llenguatge natural (“implementa l’autenticació amb OAuth”, “migra aquests tests a la nova API”, “troba i corregeix el bug de rendiment a checkout”) i procedeix de forma autònoma.

Per completar aquesta tasca, l’agent:

• Llegeix fitxers del projecte — de vegades desenes
• Planifica i descompon la tasca abans de tocar codi
• Escriu codi, l’executa en un entorn sandbox i llegeix la sortida
• Interpreta errors i decideix com corregir-los
• Torna a començar si el resultat no passa els tests

Una “tasca simple” pot desencadenar 20-50 crides al model. Una tasca complexa, centenars. I cada crida inclou el context acumulat — tots els fitxers llegits, tot l’historial — cosa que fa que els tokens per crida també creixin amb el temps.

El resultat: el consum no escala linealment amb la complexitat de la tasca. Escala de forma superlineal.

Les dades: eina per eina

Aquests són els rangs de consum documentats per als principals agents de codi, amb els seus multiplicadors respecte a una consulta de text simple (0,3 Wh de referència):

Algunes observacions sobre aquesta taula:

Aider és l’anomalia positiva. L’agent open source consumeix x4 menys tokens que Claude Code per a tasques equivalents. L’eficiència no és monopoli de les solucions comercials.

Devin 2.0 és el més impredictible. El rang de 10-60 Wh reflecteix una variància enorme: el seu mode autònom complet pot consumir tant com una sessió extensa de Claude Code amb Opus.

GPT-5.3-Codex duplica el seu predecessor. El salt de x20-x67 a x40-x133 entre versions il·lustra la tendència: els models amb raonament integrat costen més, encara que també són més capaços.

El cas Claude Code: les úniques dades amb metodologia pública

De tota la llista anterior, només existeix una anàlisi pública amb metodologia detallada: la de Simon P. Couch, publicada al gener de 2026.

Couch va analitzar les seves pròpies sessions de treball amb Claude Code durant setmanes i va documentar el següent:

• Sessió mitjana: 592.000 tokens en 24 intercanvis interactius
• Consum per sessió mitjana: 41 Wh
• Equivalència: 136 consultes de text normals
• Sessió d’ús intensiu (múltiples instàncies, dia complet): 50-200 Wh

“Un desenvolupador que utilitza agents de codi 8 hores al dia consumeix una energia equivalent a tenir una nevera encesa durant 24 hores.” — Simon P. Couch, anàlisi de consum energètic de Claude Code, gener 2026

El que fa valuosa aquesta anàlisi no és només el número: és que ningú més ha publicat dades similars. Ni Anthropic, ni OpenAI, ni GitHub, ni Cursor. Les empreses que venen aquestes eines no publiquen Wh per tasca. Només publiquen preu per token — que és una variable proxy del consum, però no equival al consum real en context.

La paradoxa de productivitat

Aquí ve la part incòmoda de l’anàlisi: el cost energètic alt pot estar justificat si el guany de productivitat és real.

Les dades internes de GitHub apunten a un +55% de velocitat en tasques acotades amb Copilot Agent. Estudis d’equips que adopten agents de codi complets reporten equivalències de 3-4 dies de treball comprimits en un per a certs tipus de tasques.

Si això és cert — i la metodologia té limitacions que discutirem — el ROI pot ser positiu fins i tot considerant el consum energètic.

Però hi ha un problema amb aquestes dades:

Els benchmarks de productivitat els produeixen les pròpies empreses. GitHub mesura l’impacte de Copilot. Anthropic mesura l’impacte de Claude Code. Cap estudi independent ha mesurat simultàniament:

1. Velocitat de desenvolupament
2. Consum energètic total
3. Qualitat del codi produït
4. Mantenibilitat a llarg termini
5. Deute tècnic generat

L’efecte rebot és real i documentat en altres tecnologies: quan alguna cosa es torna més ràpida, s’utilitza més. Un equip que adopta agents de codi no només fa el mateix més ràpid — també genera més codi, més iteracions, més revisions, més PRs. Més despesa total? Probablement sí.

La pregunta que ningú no està responent és: aquest codi addicional genera valor, o només acumula deute tècnic?

En quins casos SÍ compensa el cost?

No tots els casos d’ús són iguals. Aquestes són les situacions on el cost energètic d’un agent de codi té un retorn clar:

Migracions i refactoring amb patrons ben definits. Migrar d’una versió d’API a una altra, actualitzar dependències, convertir tests d’un framework a un altre. L’agent coneix el patró, l’aplica a centenars de fitxers amb consistència. L’humà trigaria dies; l’agent, hores. El diferencial de temps té valor de negoci real.

Prototipat ràpid on el temps de mercat importa. En fases d’exploració amb deadlines reals — una demo per a inversors, un MVP per validar una hipòtesi — el cost de velocitat pot superar amb escreix el cost energètic.

Comprensió de codebases grans. Demanar a un agent que expliqui l’arquitectura d’un projecte de 200.000 línies, traçar el flux d’una funció o identificar tots els punts d’ús d’una API. Aquí l’agent llegeix més que escriu, i el valor rau en la síntesi.

Tests de regressió i cobertura. Generar tests per a codi existent ben documentat és predictible i l’agent ho fa bé. El temps humà alliberat es pot dedicar a tasques de major valor cognitiu.

En quins casos NO compensa?

Exploració open-ended. “Fes alguna cosa interessant amb aquestes dades.” “Millora el rendiment de l’aplicació.” “Refactoritza perquè sigui més net.” Sense criteri d’èxit clar, l’agent itera sense convergir. Moltes crides al model, resultat incert, revisió manual inevitable de totes maneres.

Dominis que el model no domina bé. Si l’agent no coneix bé el domini — una llibreria molt específica, un llenguatge poc comú, lògica de negoci sense documentar — cometrà errors i necessitarà moltes iteracions per corregir-los. Consum alt, resultat mediocre.

Tasques on la velocitat no importa. Si no hi ha deadline, si el codi generat necessitarà revisió exhaustiva de totes maneres, si l’equip passarà més temps revisant el que ha fet l’agent que el que hauria trigat a escriure-ho: el ROI és negatiu.

Quan el codi generat crea més deute tècnic del que resol. Els agents són optimitzadors de completar la tasca assignada. No tenen context de negoci propi, no coneixen les convencions implícites de l’equip, no saben quines parts del codi són més crítiques. El codi que generen pot funcionar i tot i així ser un problema d’aquí a sis mesos.

El biaix de la mesura

Existeix un problema estructural en com s’està avaluant l’impacte dels agents de codi:

Els estudis de productivitat els financen els que venen productivitat. L’estudi més citat sobre l’impacte de Copilot és el de GitHub, que pertany a Microsoft, que ven Copilot. L’anàlisi més favorable sobre Claude Code ve d’Anthropic. Això no invalida les dades, però sí que requereix llegir-les amb sentit crític.

Les mètriques d’èxit estan esbiaixades cap al que és fàcil de mesurar. Velocitat de completar una tasca acotada: mesurable. Qualitat del codi a sis mesos: no mesurable en un estudi de tres setmanes. Deute tècnic acumulat: tampoc. Impacte en la capacitat del desenvolupador de mantenir i entendre el seu propi codi: gairebé impossible d’aïllar.

Cap proveïdor publica mètriques de consum energètic per tasca. Els preus per token són públics. Els Wh per tasca no. La transparència energètica que s’exigeix als electrodomèstics no s’exigeix a les eines de programari que consumeixen ordres de magnitud més energia que qualsevol rentadora.

Des d’AISHA plantegem una petició concreta: que els proveïdors d’agents de codi publiquin mètriques de Wh per tasca, de la mateixa manera que publiquen preu per token i velocitat de generació. No és informació difícil de calcular per a qui té accés als seus propis sistemes. És informació que els usuaris i els equips d’enginyeria necessiten per prendre decisions informades.

Un agent de codi no és millor que un desenvolupador humà. És diferent: més ràpid en certs tipus de tasques, més costós energèticament, sense context de negoci propi. La decisió d’usar-lo bé requereix saber exactament quin tipus de tasca tens entre mans.

Què puc fer jo?

• Si ets desenvolupador: Distingeix quin tipus de tasca tens abans d’invocar l’agent. Tasca repetitiva amb criteri clar → agent. Exploració oberta → escriu tu primer. Considera Aider per a tasques on l’autonomia màxima no és necessària: x4 menys consum per a resultats comparables.

• Si dirigeixes un equip d’enginyeria: Estableix una política d’ús, no només d’accés. Mesura el temps total del cicle — incloent-hi revisió i correcció del codi generat — no només el temps de generació. Defineix quins tipus de tasques justifiquen agent complet versus assistència simple.

• Si ets CTO o responsable tècnic: Un equip de 20 enginyers que utilitzen agents de codi 6h diàries consumeix l’equivalent energètic de diversos centenars de neveres enceses 24/7. És una dada rellevant per a ESG i per a costos operatius quan el còmput es paga per ús.

• Si treballes en sostenibilitat tecnològica: Exigeix als proveïdors d’eines de desenvolupament que incloguin mètriques de Wh per tasca als seus dashboards. El cost per token ja està publicat. El cost en Wh també hauria d’estar-ho — no és difícil tècnicament, és una decisió de transparència.