- La carga de mantenimiento determina la productividad a largo plazo más que la velocidad para escribir código nuevo
- En el modelo de ejemplo, después de dos años y medio el mantenimiento supera la mitad del tiempo total
- Si un agente de IA aumenta tanto la producción como el costo de mantenimiento, su efecto desaparece rápidamente
- Incluso si se deja de usar el agente, el costo adicional de mantenimiento del código ya creado sigue ahí
- Si la producción se duplica, el costo de mantenimiento por unidad de código también debe bajar a la mitad
El costo de mantenimiento determina la productividad
- Todo el tiempo dedicado a escribir código sigue generando después tiempo de mantenimiento, como corrección de bugs, limpieza y actualizaciones de dependencias
- No se consideran nuevas funciones ni mejoras, sino únicamente el mantenimiento recurrente anual mientras el código exista
- La estimación de ejemplo asume que por cada mes de escritura de código se requieren 10 días de mantenimiento durante el primer año y 5 días por año a partir de entonces
- Se plantea que, usando el enfoque de Wisdom of the Crowd y preguntando a unas 50 personas desarrolladoras por el costo de mantenimiento, se podría obtener una respuesta bastante precisa
- Según este modelo en hoja de cálculo basado en esa suposición, al inicio de un proyecto nuevo la mayor parte del tiempo se dedica al desarrollo de funciones, pero con el paso del tiempo crece el peso del mantenimiento del código pasado
- En esa estimación, después de dos años y medio el tiempo dedicado al mantenimiento supera la mitad del total, y tras 10 años llega a un punto en el que casi no queda margen para hacer otra cosa
- Si la estimación de mantenimiento se reduce a la mitad, se ganan 3 años más antes de llegar al punto del 50%; si se duplica, la productividad cae por debajo del 50% en menos de un año
- Si se quiere un equipo productivo, hay que enfocarse más en el costo de mantenimiento que en la velocidad de escribir código nuevo
El modelo puede estar equivocado, pero la dirección es correcta
- En startups en etapa avanzada, después de unos 5 a 9 años aparecía el problema de que el equipo ya no lograba terminar bien el trabajo, algo similar al patrón que muestra la gráfica
- Que los equipos reales no parezcan tan mal como en la gráfica puede deberse a que sus costos de mantenimiento eran menores o a que el problema se estaba cubriendo de otras maneras
- Algunas respuestas posibles son no arreglar todos los bugs ni actualizar todas las dependencias, sumar más gente cuando el equipo se vuelve lento y seguir agregando más, o tirar todo y reescribirlo
- Se puede debatir la cifra exacta, pero el patrón general de pérdida de productividad con el tiempo sí parece coincidir con la experiencia
El efecto multiplicador que crean los agentes de programación con IA
- Como ejemplo, se asume que el framework moderno de agentes de programación Rock Lobster duplica la producción de código
- Al mismo tiempo, se asume que el código se vuelve un poco más difícil de entender, que el equipo queda abrumado por los pull requests y que el código no se lee con cuidado antes de aprobarse
- Si en un mes se produce el equivalente a dos meses de código, y el costo de mantenimiento de ese resultado también se duplica, entonces el costo de mantenimiento del mes siguiente se vuelve 4 veces mayor
- En este ejemplo extremo, tras usar Rock Lobster durante unos 5 meses, la productividad vuelve a su nivel original, y unos meses después pasa a ser peor que si nunca se hubiera usado
- Esto no significa que la IA realmente duplique la productividad o el costo de mantenimiento, sino que incluso si la mantenibilidad fuera igual a la del código escrito por humanos, la ganancia de productividad no duraría mucho
Aunque se deje el agente, el costo de mantenimiento permanece
- Los agentes de programación cuestan dinero, y si su utilidad queda por debajo de su costo, es posible que se quiera volver al método anterior
- Si se deja de usar el agente, la ganancia de productividad desaparece, pero el costo adicional de mantenimiento del código creado con él sigue existiendo mientras ese código permanezca
- En ese caso, se puede quedar atrapado en una productividad menor que la de no haber usado nunca el agente
La matemática solo cierra si baja el costo de mantenimiento
- El costo de mantenimiento debe reducirse exactamente en la proporción inversa al aumento de producción de código que aporte el LLM para que el cálculo total de productividad funcione
- Si la producción se duplica y el costo de mantenimiento de ese resultado también se duplica, entonces el costo total de mantenimiento se vuelve 4 veces mayor
- Si la producción se duplica pero el costo de mantenimiento por unidad producida se mantiene igual, el costo total de mantenimiento sigue siendo 2 veces mayor
- Si la producción se duplica, el costo de mantenimiento debe reducirse a la mitad; si la producción se triplica, el costo de mantenimiento debe bajar a un tercio
- Solo cumpliendo esa condición se puede obtener una ganancia de velocidad sin quedar atrapado en una dependencia de largo plazo
Preocupaciones actuales sobre los agentes de programación y otras posibles palancas
- En fuentes como Hacker News parece haber muchas señales de que los agentes de programación aumentan los costos de mantenimiento
- Algunas personas dicen que ayudan a entender sistemas grandes, pero no parece verse la reducción sustancial del costo de mantenimiento que haría falta; más bien parece lo contrario
- El modelo no representa perfectamente la realidad, pero sigue siendo válido el mensaje de que la IA debe reducir los costos de mantenimiento en proporción a la velocidad con la que acelera la escritura de código nuevo
- Incluso si se busca mejorar la velocidad de programación, habría que dedicar la misma atención a mejorar los costos de mantenimiento
- No es un argumento anti-IA: también existen otras palancas, como una IA que vuelva más productivas las tareas de mantenimiento en sí, aunque no aumente la mantenibilidad del código como tal
- Si se quieren ajustar las suposiciones a una situación real, se puede copiar la hoja de cálculo y modificar varias variables del modelo
1 comentarios
Comentarios en Hacker News
En la charla de Dconf'24 Software as investment se propuso un framework base sustentado en funciones de valor componibles para cada pieza de software
El framework en sí no necesita cambiar particularmente por la IA; por separado, solo habría que actualizar el modelo de costos según qué tan bien le vaya a la IA en mantenimiento
Dicen que la IA introduce 1.7 veces más bugs, pero quizá también pueda corregirlos más rápido, así que no está tan claro
Si vemos el software como una inversión, entonces se habla de “valor” en vez de “deuda técnica”, y la deuda no sería más que un activo con valor menor que 0
A medida que el software sale del viejo mundo de márgenes altos, hay que definir con precisión qué software vale la pena que exista en términos económicos
En el software siempre hay partes que podrían haberse escrito mejor, y eso es la deuda
Es una perspectiva muy perspicaz y estoy de acuerdo
Lamentablemente, la mantenibilidad normalmente cae en la canasta de los “requisitos no funcionales”
Pero los requisitos no funcionales como la mantenibilidad deberían verse como algo que preserva y hace posible entregar futuros requisitos funcionales
No debería plantearse simplemente como el “cómo debe hacerse”, en contraste con lo que el software debe hacer
Si es un proyecto donde importa agregar y mejorar funcionalidades de manera constante, salvo por un periodo muy corto la mantenibilidad en la práctica se parece mucho a un requisito funcional
En cuanto les das un nombre aparte, le das a alguien que no entiende bien el tema una excusa para cercarlos y bajarles la prioridad
La calidad importa, y si no se mantiene, golpea el estado de resultados muy rápido y con mucha fuerza
Por eso es tan importante como cualquier otro factor
Se puede usar la expresión de Kevlin Henney: características operativas y características de desarrollo
La mantenibilidad es, en esencia, una característica de desarrollo
Puede que tengan hojas de ruta de producto de 1 o 2 años, pero siendo sinceros, muchas veces esas hojas de ruta sirven más para ventas que como planificación de ingeniería
Si caen los ingresos, producto e ingeniería cambian de dirección, y mientras más joven es la empresa, más seguido pasa esto
Al salir del modo startup eso debería estabilizarse, pero muchas empresas no lo hacen y siguen repitiendo el patrón de planificación de corto plazo
Como resultado, la estabilidad del producto sigue siendo de baja prioridad
Al final, muchas empresas parecen no tener los recursos para construir buen software, o simplemente no les importa de verdad
Construyendo nuestro proyecto lo vimos: la IA es rápida, pero los bugs que mete la IA son extrañamente difíciles de detectar
No son bugs obvios, sino lógica que rompe algo en producción tres semanas después, y cuando haces el rastreo resulta que la IA entendió mal alguna sutileza
Sinceramente, la IA no reduce tanto el costo de mantenimiento como cambia de lugar el costo
Baja el tiempo de escritura y sube el tiempo de revisión
El código de IA, incluso cuando está mal, suena fluido y seguro, así que es más difícil de revisar que el código humano
Que deje una ganancia neta depende por completo de qué tan bueno sea el equipo para leer código más que para escribirlo
En mi experiencia, la IA sí reduce el costo de mantenimiento
Pero el contexto puede importar. Yo trabajo con varios proyectos de décadas de antigüedad; también hay mucho desarrollo de nuevas funcionalidades, pero el código viejo y los proyectos viejos de pronto se volvieron mucho más fáciles de manejar, modernizar y, en varios casos, incluso eliminar
Las dependencias viejas de librerías y herramientas de build en algunos casos se actualizaron y en otros simplemente se quitaron; los builds ahora son más rápidos y más sencillos para los desarrolladores
También fue mucho más fácil configurar y automatizar pruebas end-to-end, DevOps mejoró bastante, y el diagnóstico de incidentes operativos mejoró muchísimo
Hay muchísimos logs e información, además de dashboards integrados y monitoreo para atrapar lo importante, pero ahora puedo hacer mucho más análisis sobre unos 50 proyectos desplegados
La tesis central del artículo es cuántas horas de mantenimiento hacen falta por cada hora de desarrollo de funcionalidades que “agregan valor”
Entonces, primero, no hay que medir solo el costo de mantenimiento sino la proporción; y segundo, ese código viejo originalmente no fue escrito por IA
Pero creo que el punto del autor es que, si pierdes acceso a las herramientas de IA, todo se vuelve mucho más cuesta arriba
Sería como mover montañas cómodamente con maquinaria pesada y luego volver a herramientas manuales
Aumentaron las caídas junto con la cantidad de líneas de código que se despliegan, y además las caídas son cada vez más graves
Claro, mejoramos mucho código viejo, borramos más código, podemos automatizar la modernización y diagnosticar mejor los problemas, y también hay más opciones de mitigación
Pero nada de eso logró compensar la escala abrumadora del código que se despliega sin que nadie lo entienda de verdad
Nuestro equipo usa IA para agregar código, pero también para eliminar de manera agresiva código viejo y abandonado
Preguntas como “¿todavía hay alguien usando esto?” o “¿cómo se llama esto?” se vuelven fáciles de responder si le lanzas al agente el frontend, el backend y toda la base de código para que arme un mapa del proyecto de software
Los IDE también ayudan algo cuando estás dentro de un solo lenguaje y normalmente un solo proyecto, pero fronteras como RPC o REST rompen muchas herramientas de IDE
Me gusta mucho esta pregunta: si pudieras elegir, ¿qué base de código querrías?
Pensándolo un momento, probablemente no querrías una base de código con una cantidad enorme de funciones
Querrías una base de código bastante parecida a la que tienes ahora, pero más fácil de entender y de mantener y expandir según los retos futuros del negocio
Una base de código que “trabaja”, es decir, una base de código que se mantiene, está resolviendo problemas del mundo real, y resolver esos problemas siempre debe estar por encima de la limpieza
Una base de código limpia muchas veces termina siendo un ejemplo de exhibición puesto en un estante para admirarlo
Quiero agregar dos cosas
Primero, el software no solo tiene mantenimiento técnico; también está el soporte a usuarios, y eso también crece conforme crece el software
Segundo, no estoy seguro de que el costo de mantenimiento aumente de forma lineal
Incluso si aumentara linealmente, al final llegas a un punto donde todo tu tiempo se va en mantenimiento
Podría ser, si no solo hay que mantener cada parte sino también cómo interactúan entre sí
La señal más fuerte que he visto sobre si la IA realmente baja el costo de mantenimiento es si el desarrollador trata la salida de la IA como un borrador o como el resultado final
Cuando usas herramientas de IA sobre una base de código existente, por ejemplo para entender un módulo desconocido, generar un refactor puntual o escribir scripts de migración, la carga de mantenimiento sí baja de verdad
Eso es porque la IA está trabajando sobre código cuya arquitectura yo ya entiendo, así que puedo evaluar rápido su salida
El problema aparece cuando la IA genera código nuevo que nadie entiende a fondo
Ese código lo tiene que mantener alguien que ni lo escribió ni lo diseñó
Si fuera código escrito por otra persona, al menos podrías inferir su intención por los nombres, la estructura y el historial de commits
El código generado por IA muchas veces carece de esa intención legible, porque su “autor” no tiene una intención sostenida a lo largo de todo el archivo
En lo que el artículo acierta es en que no solo hay que medir la velocidad, sino también el costo de mantenimiento
En la práctica, habría que seguir durante meses, no días, el tiempo necesario para entender código asistido por IA frente a código escrito por humanos, así como la tasa de cambios fallidos
Con la revisión de código pasa lo mismo
Me pregunto si la IA podría hacer que los code reviews se vean mejor
En revisiones humanas, los desarrolladores aprenden rápido a evitar cambios visuales innecesarios, como reflujo de código o comentarios, cambiar sangrías que la herramienta no puede ocultar, mover funciones o borrar líneas
Tampoco deberían hacerse refactors innecesarios
Quizá podría dividirse la revisión en dos: cambio funcional y cambio de forma
Eso hace la revisión mucho más fácil
La revisión empieza desde “no debería cambiar nada”, y quien revisa puede hacer pattern matching
De lo contrario, el revisor tiene que reevaluar cada línea para comprobar que de verdad no cambió nada, y hacerlo bien es realmente difícil
Los sistemas de control de versiones que he usado permitían colas de cambios que se revisan de forma independiente
Si hace falta refactorizar durante el desarrollo, subes un commit, haces el refactor, lo mandas a revisión, luego rebaseas el trabajo en curso y sigues
Si vas dejando pasar cambios como “CLEANUP:” o “REFACTOR_ONLY:”, el cambio final queda mucho más pequeño que una modificación monstruosa
Los revisores te lo van a agradecer
En una organización así, incluso se puede jugar con métricas sin que se vuelva algo perverso
El autor parece partir del supuesto de que una persona debe revisar en detalle todo el código de IA y ser capaz de entenderlo y mantenerlo sin ayuda de IA
En mi experiencia, la gente no usa la IA de esa manera
Así empiezan. Antes de confiar en ella y antes de aprender a escribir prompts que den el resultado que quieren, la usan para automatizar las partes tediosas, pero la implementación inicial o los patrones los hace una persona y la IA rellena los huecos
Se parece más a un autocompletado mejorado que a un cambio total en la forma de programar
Mientras más trabaja la gente con IA, menos se preocupa por el código que realmente genera
Eso no significa que esté bien. Puede introducir bugs, problemas de rendimiento o huecos de seguridad
Pero esa es la realidad. ¿El código de IA metió un bug? Le pides a la IA que lo arregle
¿El código de IA quedó inflado y difícil de leer? Si te molesta, le pides a la IA que lo arregle. A mucha gente no le molesta
Si la persona sale por completo del ciclo de mantenimiento del código, también desaparece la necesidad de tener código mantenible
Todavía no estamos 100% ahí, pero vamos en esa dirección
En muchas empresas ya es suficientemente bueno como para que valga la pena asumir el riesgo e irse en modo YOLO
Personalmente, no confío tanto en el código generado por IA como para no leerlo, pero tampoco leo cada línea
Reviso con más cuidado las pruebas que el código bajo prueba, pongo más atención en las partes sensibles al rendimiento, y guío la estructura general
Aun así, si no cumple el estándar, en vez de mantenerlo yo le pido a la IA que lo corrija
Si el mantenimiento es tan barato, entonces el costo de mantenimiento deja de estar en mi lista de preocupaciones
Este artículo resalta bien la necesidad de que los agentes o asistentes de IA ayuden no solo con la parte inicial de “créame un widget nuevo”, sino con muchas partes del desarrollo de software
El autor considera que, si alguien usa agentes o asistentes de IA solo en la etapa de crear un widget nuevo, entonces por producir más código con IA también terminará con mucho más código que mantener
Incluso si la calidad del código es alta, con el tiempo aparece un costo de mantenimiento
Aun así, el problema que plantea el autor se parece en gran medida a un problema que uno mismo se fabrica, más que a algo que necesariamente todos vayan a sufrir
La situación de startup que señala el autor —“primero hagamos que esto funcione como sea para validar el encaje con el mercado y conseguir clientes”— siempre ha traído después mayores costos de mantenimiento
Porque hasta cierto punto sí es razonable sacrificar calidad a cambio de velocidad para comprobar si hay negocio y, si lo hay, escalarlo rápido
Además, me dio la impresión de que el autor evita hablar de cómo la IA realmente puede ayudar en la parte de mantenimiento
La IA puede ser muy útil, con guía humana, para arreglar dependencias antiguas o resolver bugs fastidiosos
Ese tipo de tareas puede sentirse como trabajo ingrato para un ingeniero de software, y son justamente el tipo de cosas en las que uno quiere ayuda de la IA