Durante cuarenta años dimos por sentado que escribir una línea de código era invertir. Costaba tiempo de alguien caro, así que la línea valía lo que había costado producirla, y la contábamos como patrimonio: cuanto más código, más empresa. Sobre esa creencia se construyeron las métricas de líneas por desarrollador, la mística del programador diez veces más productivo y la idea de que un repositorio grande es un foso defensivo.
Esa creencia se sostenía en un supuesto que acaba de romperse: que escribir código es caro. Con un agente como Kiro generando funciones a partir de una especificación, el costo marginal de producir la línea número mil no es el de la primera; tiende a cero. Y cuando el costo de producir algo tiende a cero, ese algo deja de comportarse como un activo. Empieza a comportarse como inventario.
El código nunca fue un activo: era inventario mal contabilizado
Un activo produce valor mientras lo tienes. Un edificio, una patente, una marca: los guardas y trabajan para ti. El inventario es lo contrario. Es mercancía en una estantería que todavía no ha producido nada, y que mientras espera te cuesta dinero: ocupa espacio, hay que asegurarlo, se deteriora, se queda obsoleto y, si no lo vendes, un día hay que pagar para deshacerte de él.
El código en producción tiene las dos caras. La parte que sirve a un cliente es activo. Pero todo lo demás (la función que quizás uses el trimestre que viene, el flag que dejaste por si acaso, el microservicio que copió el patrón del anterior) es inventario. Se almacena en un repositorio, se asegura con pruebas, se deteriora en cuanto cambia una dependencia y hay que entenderlo cada vez que alguien lo toca. La diferencia es que hasta ahora el inventario era tan caro de fabricar que lo confundíamos con inversión. Cuando algo duele producirlo, uno supone que vale.
Esta no es una metáfora nueva disfrazada. Es la misma intuición que Ward Cunningham y Martin Fowler llevan años defendiendo cuando hablan de deuda técnica: el código no es solo lo que hace, es un pasivo que arrastras. El propio Fowler advierte que la metáfora de la deuda no encaja del todo, porque un préstamo tiene intereses predecibles y el código no. El inventario encaja mejor precisamente ahí: nadie sabe cuánto te va a costar el stock que no rota hasta que intentas moverlo.
¿Por qué la metáfora del almacén aguanta y la del activo no?
Gregor Hohpe tiene una regla para saber si una metáfora sirve para pensar o solo para decorar, y la explica en Mighty Metaphor: no basta con que la imagen se parezca, tienen que coincidir las dinámicas. Su ejemplo es el indicador de gasolina, que descartó porque el depósito se llena rápido y se vacía despacio, justo al revés que la cosa que quería explicar.
Apliquemos su prueba al inventario. ¿Coinciden las dinámicas?
En un almacén, el costo de producir una unidad puede desplomarse sin que baje un centavo el costo de sostenerla. Una fábrica más eficiente no reduce el alquiler del almacén, ni el seguro, ni lo que pierdes cuando el modelo pasa de moda. Es más: cuando producir sale casi gratis, la tentación es sobreproducir, llenar la estantería «por si acaso», y entonces el costo de sostener el stock se dispara mientras el de fabricarlo desaparece. Ese es exactamente el efecto de un agente de codificación. El costo de escribir cae a cero; el de leer, entender, probar y retirar ese código no se mueve, porque lo sigue pagando un humano con la misma cabeza de siempre.
Las dinámicas coinciden. Y como coinciden, el lector puede deducir cosas que no he escrito: si el código es inventario, entonces querrás generación just-in-time en lugar de producir stock especulativo, lotes pequeños que se revisen enteros en vez de volcados de mil líneas, y un límite de trabajo en curso sobre lo que el agente produce antes de que un humano lo haya digerido. No lo he argumentado y ya lo estás viendo. Eso es lo que distingue un modelo de un adorno.
El costo de producir se desploma; el de sostener no. La restricción se muda de la fábrica al almacén.
La cuenta de la servilleta
Pongamos números, con los supuestos a la vista para que rehagas la cuenta con los tuyos. Nada de esto es una medición de un cliente real; es aritmética para pensar.
Un desarrollador escribe, siendo generosos, unas 100 líneas netas de código que sobreviven al día. Un agente supervisado por esa misma persona produce, digamos, 2.000 líneas al día que pasan la revisión superficial. La producción se multiplica por veinte. Ese es el titular que se vende.
Ahora el otro lado del balance. Leer y entender código de verdad, el suficiente para modificarlo sin miedo, va a unas 400 líneas por hora en un lenguaje conocido. La capacidad de comprensión de esa persona no cambió: sigue siendo un cerebro humano, unas 3.000 líneas al día si no hace nada más, cosa que nunca pasa. Producíamos 100 y podíamos digerir 3.000: sobraba almacén. Ahora producimos 2.000 y seguimos pudiendo digerir 3.000, y encima hay que digerir lo que ya había.
- Antes: producción 100/día, comprensión 3.000/día. El cuello de botella era escribir.
- Ahora: producción 2.000/día, comprensión 3.000/día. El cuello de botella es el almacén, y se estrecha cada día que el agente trabaja.
La restricción se mudó. Durante cuarenta años optimizamos la fábrica porque ahí estaba el límite. El límite ya no está ahí.
Sé lo que estás a punto de decir
¡Pero si el código generado es mejor y más consistente que el mío! El agente no se cansa, sigue el estándar, escribe pruebas.
Es verdad, y no cambia nada. Un almacén lleno de mercancía impecable sigue siendo un almacén que hay que pagar. La calidad de la unidad reduce el costo de sostenerla, no lo elimina: sigues teniendo que entenderla para cambiarla, sigue caducando cuando cambia la dependencia, y ahora tienes veinte veces más unidades impecables que digerir. Un inventario perfecto sobredimensionado no es un activo; es un problema de almacén con mejor acabado.
Y hay una trampa peor. Cuando producir cuesta esfuerzo, ese esfuerzo actúa de freno natural: nadie escribe mil líneas por capricho. Cuando producir es gratis, el freno desaparece justo cuando más falta hace, porque cada línea que el agente añade «gratis» tiene el mismo costo de sostenimiento que si la hubieras sudado. La factura no llega en la generación. Llega seis meses después, cuando alguien tiene que entender por qué eso está ahí.
El costo de escribir código era lo único que nos impedía ahogarnos en él. Quitarlo no nos hizo más rápidos: nos quitó el único límite que teníamos.
¿Dónde está entonces la palanca del arquitecto?
Si el cuello de botella era la fábrica, tenía sentido que el arquitecto se preocupara por cómo se escribe: patrones, revisiones, estándares aplicados línea a línea. Pero el arquitecto nunca escribió a la velocidad del cuello de botella nuevo, y no va a empezar ahora. Revisar a mano dos mil líneas al día por agente es tan realista como pedirle a tus desarrolladores que escriban código sin errores.
La palanca se traslada, y ya escribí sobre hacia dónde. En arquitectos arquitectando arquitectura defendí que un framework de arquitectura se construye adelantando decisiones («shift left»), no revisando al final. Con agentes eso deja de ser una preferencia de estilo y se vuelve la única opción física, porque revisar al final ya no cabe en el día. Lo que el arquitecto controla no es cada línea: son las restricciones que el agente lee antes de escribirla.
Ahí es donde una plataforma como Amazon Bedrock AgentCore deja de ser un detalle de infraestructura y se vuelve el sitio donde se ponen esos límites: identidad, permisos y guardrails que acotan lo que el agente puede tocar. Y es donde el flujo dirigido por especificaciones de Kiro, con sus specs y sus hooks que comprueban lo generado contra una regla, se convierte en el equivalente moderno de la línea de ensamblaje: no controlas cada pieza, controlas la plantilla que las produce. La decisión de arquitectura ya no vive en el código; vive en el ADR, en la especificación y en la regla de gobierno, que es lo mismo que Yagni llevaba diciendo desde antes de los agentes, solo que ahora el costo de ignorarlo se multiplica por veinte.
Como argumenté en Multinube, la peor práctica, la indecisión disfrazada de flexibilidad se paga en trabajo de mantenimiento. Con agentes es igual, pero más rápido: cada opción que dejas abierta «por si acaso» ahora la materializa el agente en código real, y ese código va derecho a la estantería.
Mi sugerencia
El lunes, lleva una sola pregunta a tu próxima revisión de arquitectura: ¿cuál es nuestro costo de sostenimiento por cada mil líneas generadas, y quién lo está pagando? No la respondas con una sensación; ponle una cuenta como la de arriba, con sus números de cuánto código sale por semana y cuánto puede digerir de verdad el equipo.
Y si quieres algo más concreto todavía, prueba esto durante un sprint: pon un límite de trabajo en curso a lo que el agente genera antes de que un humano lo haya entendido y aprobado, igual que limitarías el stock en un almacén con espacio finito. Trata cada spec y cada guardrail como la plantilla que decide qué se fabrica, no como papeleo. Si al final del sprint el equipo entiende todo lo que hay en producción, felicidades: estás gestionando inventario en lugar de acumularlo. Si no, ya sabes dónde está tu cuello de botella, y no es escribir. ;)