La deuda técnica ahora también se paga en tokens
En el artículo anterior, con el que se estrenaba éste espacio de reflexión, se apuntaba una consecuencia lateral: si el contexto empieza a costar dinero de forma visible, la claridad deja de ser solo una virtud técnica. Pasa a ser una forma de ahorro.
Durante años nos acostumbramos a hablar de la deuda técnica como si fuera una molestia interna: algo que ralentiza equipos, complica entregas y convierte tareas pequeñas en expediciones por capas antiguas del sistema. Costaba tiempo de onboarding, bugs raros, discusiones en Slack, miedo a tocar módulos heredados, tests lentos, releases tensas y esa sensación tan familiar de que una tarea de una hora necesita tres días de arqueología.
Nunca fue gratis, pero siempre pareció que se podía posponer indefinidamente.
La diferencia es que ahora una parte de ese coste empieza a aparecer en otro lugar. Con agentes de IA, la deuda técnica no solo se paga en tiempo humano, retrasos, fatiga o riesgo operativo. También puede pagarse en consumo medible de computación.
Si a las personas ya les costaba entender o modificar estos sistemas, resulta inquietante comprobar que a este tipo de máquinas les ocurre lo mismo.
El contexto también factura
Los agentes no llegan a un repositorio neutral. Llegan a un entorno hecho de documentación, convenciones, herramientas, nombres, abstracciones y decisiones acumuladas. Si ese entorno es claro, necesitan menos vueltas. Si es confuso, necesitan más contexto, más lectura, más intentos y más correcciones.
Antes de los agentes, un módulo mal organizado costaba sobre todo tiempo humano. Con agentes, también puede costar tokens. Una documentación desactualizada no solo confunde a una persona: empuja al modelo a explorar caminos falsos.
El desorden se convierte en gasto computacional recurrente. Los humanos al menos podemos compensarlo recurriendo a la memoria o la intuición. Los agentes tropiezan una y otra vez, durante todas sus interacciones, aumentando el coste cada vez.
Esto cambia algunos incentivos. Durante años, muchas buenas prácticas se defendieron con argumentos de mantenibilidad, calidad o profesionalidad. Eran argumentos correctos, pero a menudo perdían contra la urgencia. Documentar bien, modularizar, limpiar APIs, escribir tests útiles o mejorar mensajes de error importaba, pero no siempre parecía urgente.
Parte del problema era contable. La deuda técnica tenía coste, pero rara vez tenía una métrica directa. Aparecía como una tarea que tardaba más de lo esperado, una estimación que se rompía, una persona bloqueada durante dos días o un despliegue que exigía más coordinación de la razonable. Era una factura real, repartida en demasiadas partidas.
Cuando el contexto cuesta, la claridad empieza a tener retorno financiero directo.
La buena ingeniería reduce consumo
Un repositorio con límites claros permite dar menos contexto al agente. Una arquitectura comprensible reduce exploración. La buena ingeniería deja de ser una virtud interna o romántica y pasa a ser también una forma de optimización de coste de inferencia.
Esta puede ser una de las consecuencias más positivas de los cambios en los modelos de pago de los agentes. No solo evita hacer obsoletas las buenas prácticas, quizá las vuelva más importantes. Lo que antes se justificaba como disciplina profesional puede empezar a justificarse también como eficiencia económica.
La eficiencia no cae sobre una superficie plana
Esto puede abrir una brecha dentro de las propias organizaciones. Los equipos con repositorios sanos obtendrán mejores resultados y menor coste. Los equipos con sistemas críticos, antiguos y confusos pagarán más por cada intento. La IA no distribuye eficiencia de manera uniforme. Se apoya en la calidad previa del sistema.
Por eso las métricas importan. No basta con mirar el consumo total de tokens. Habrá que observar qué repositorios son más caros para agentes, qué tipos de tareas consumen más, qué herramientas devuelven más ruido, qué módulos requieren más intentos y qué partes del sistema provocan bucles. Esas señales pueden convertirse en una nueva forma de mapa de deuda técnica.
Hasta ahora sabíamos que ciertas zonas del código eran dolorosas porque la gente las evitaba. Pronto quizá sepamos también que son caras porque los agentes gastan demasiado en entenderlas.
La pregunta no será solo dónde tenemos deuda técnica, sino dónde estamos pagando intereses en tokens.
Diseñar para lectores humanos y máquinas
Dejemos atrás ese breve periodo en el que parecía que el caos no importaba, porque ya lo resolvería el agente uno o dos millones de tokens más adelante. Recuperemos el noble objetivo de construir software comprensible, útil y mantenible para personas, pero también para máquinas.
Diseñar para esa convivencia será de nuevo parte de la ingeniería.