El agente de código que duplica tu deuda técnica

Hay una frase de James Shore que merece más atención de la que suele recibir en los debates sobre productividad con IA: "Estás intercambiando un impulso temporal de velocidad por servidumbre permanente". No es retórica. Es aritmética.

El 11 de mayo, Simon Willison destacó en su blog un fragmento del artículo de Shore You Need AI That Reduces Maintenance Costs, y la lógica expuesta ahí es tan sencilla como demoledora para cualquier equipo que haya adoptado agentes de código sin pensarlo demasiado.

La matemática que nadie quiere hacer

El argumento de Shore parte de una premisa básica: el coste total de un sistema de software no es solo el coste de escribirlo, sino el de mantenerlo durante toda su vida útil. Cuando introduces un agente que te hace tres veces más productivo en la generación de código, también estás generando tres veces más superficie que alguien —o tú mismo, dentro de seis meses— tendrá que leer, depurar, refactorizar y actualizar.

Si tu tasa de producción se multiplica por dos y el coste de mantenimiento por unidad de código se mantiene igual, el resultado no es neutro: has doblado tu carga de mantenimiento total. Si la tasa de producción se triplica y el coste de mantenimiento también se triplica, el resultado es nueve veces más deuda. El único escenario donde la ecuación funciona a tu favor es aquel en que el agente produce código que es proporcionalmente más fácil de mantener que el que escribirías sin él. Y eso, en la práctica, no es el comportamiento por defecto.

Por qué esto importa ahora

En mayo de 2026, con herramientas como Claude Code madurando rápidamente —soporte para subagentes, hooks en el ciclo de vida, skills reutilizables— la tentación de delegar volúmenes crecientes de código a agentes es completamente comprensible. Las métricas de velocidad son visibles e inmediatas; los costes de mantenimiento son diferidos e invisibles hasta que no lo son.

El problema no es la herramienta en sí. Es el marco de evaluación que los equipos aplican. Si el único indicador de éxito es "líneas de código generadas" o "tickets cerrados por sprint", el agente siempre parecerá una ganancia. El deterioro del código base tardará trimestres en hacerse evidente, y para entonces será difícil trazar la causalidad.

Shore no pide que dejes de usar agentes. Pide que midas lo correcto. La pregunta no es ¿cuánto código generó el agente esta semana? sino ¿el código que generó es más o menos costoso de mantener que el que habría escrito un desarrollador sin asistencia?

Para quién es especialmente relevante

Este argumento afecta de forma distinta según el perfil:

• Equipos pequeños con código base longevo: son los más expuestos. Cada decisión de arquitectura tomada por un agente sin suficiente contexto del dominio es un problema futuro que recaerá sobre dos o tres personas.
• Startups en fase de crecimiento rápido: el "moverme rápido ahora, limpiar después" es tentador y a veces racional, pero el "después" llega antes cuando el volumen de código generado se ha multiplicado por tres.
• Equipos que evalúan ROI de herramientas IA: si la métrica de éxito no incluye coste de mantenimiento proyectado, la evaluación está incompleta por diseño.

Los proyectos donde el agente podría salir bien parado en esta ecuación son aquellos donde se le da contexto suficiente para respetar las convenciones existentes, se limita su autonomía a tareas bien acotadas y hay revisión humana real —no ceremonial— del output.

Lo que dice esto del estado del sector

Que en 2026 sigamos necesitando que alguien escriba este artículo dice algo sobre cómo se están vendiendo y adoptando estas herramientas. La narrativa dominante sigue girando alrededor de la velocidad de generación, y la conversación sobre calidad estructural del código generado ocupa mucho menos espacio del que debería.

Desde EP, llevamos meses observando que los equipos con mejores resultados a largo plazo con Claude Code no son los que más delegan, sino los que han invertido tiempo en definir qué delegan y cómo evalúan el resultado. La aritmética de Shore no es pesimista; es un recordatorio de que "productividad" sin denominador no es una métrica útil.