Los agentes de IA para programar deben reducir necesariamente los costos de mantenimiento
(jamesshore.com)- Aunque los agentes de IA para programar aumenten la velocidad de escritura de código, si no logran reducir los costos de mantenimiento en la misma proporción, una mejora temporal de productividad termina convirtiéndose en una caída permanente de la productividad
- Todo código, después de escribirse, exige mantenimiento continuo como corrección de bugs, limpieza y actualización de dependencias; con el tiempo, ese mantenimiento ocupa la mayor parte del tiempo de trabajo
- Si se duplica la cantidad de código generado y también se duplican los costos de mantenimiento, el costo real de mantenimiento aumenta 4 veces, por lo que la ventaja de productividad desaparece en pocos meses
- Incluso si se elimina la IA, la carga de mantenimiento del código ya generado permanece, dejando una productividad más baja que si nunca se hubiera usado IA
- Para duplicar la productividad, se necesita una IA que reduzca los costos de mantenimiento exactamente a la mitad, y hay que invertir el mismo nivel de esfuerzo en reducir costos de mantenimiento que en aumentar la velocidad de programación
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 actualización de dependencias
- El análisis se enfoca no en nuevas funciones o mejoras, sino únicamente en el mantenimiento que se repite cada año 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 en el primer año y luego 5 días por año
- Se considera que, usando el enfoque de Wisdom of the Crowd, preguntar por el costo de mantenimiento a unas 50 personas desarrolladoras puede dar 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 a desarrollar funcionalidades, pero con el paso del tiempo crece la proporción dedicada al mantenimiento del código pasado
- En esa estimación, después de dos años y medio el tiempo dedicado a mantenimiento supera la mitad del total, y después de 10 años se vuelve casi imposible 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 los costos de mantenimiento que en la velocidad para escribir código nuevo
El modelo puede estar equivocado, pero la dirección es correcta
- En startups en etapas avanzadas, después de 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 se vean tan mal como la gráfica puede deberse a que sus costos de mantenimiento eran más bajos o a que tapaban el problema de otras maneras
- Entre las respuestas posibles están no corregir todos los bugs ni actualizar todas las dependencias, sumar gente cuando el equipo se vuelve lento y seguir sumando más, o abandonar todo y reescribirlo
- Se puede discutir la cifra exacta, pero el patrón general de que la productividad disminuye con el tiempo parece correcto por experiencia
El efecto multiplicador que crean los agentes de programación con IA
- Como ejemplo, se asume que el framework moderno de programación con agentes 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 se siente abrumado por los pull requests y que no lee realmente el código antes de aprobarlo
- 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 la productividad vuelve a su nivel original en unos 5 meses, y unos meses después incluso queda peor que si nunca se hubiera usado
- Esto no significa que la IA realmente duplique la productividad o los costos de mantenimiento, sino que subraya 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 de usar el agente, el costo de mantenimiento permanece
- Los agentes de programación cuestan dinero, y si su utilidad se vuelve menor que su costo, puede surgir la intención de 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 el agente sigue ahí mientras ese código exista
- En ese caso, se puede quedar atrapado en una productividad más baja que la que se tendría si nunca se hubiera usado el agente
La única matemática que funciona es reducir el costo de mantenimiento
- El costo de mantenimiento debe bajar 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 cierre
- Si la producción se duplica y el costo de mantenimiento de ese resultado también se duplica, el costo total de mantenimiento se vuelve 4 veces mayor
- Si la producción se duplica pero el costo de mantenimiento por cada 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 ser la mitad; si la producción se triplica, el costo de mantenimiento debe ser un tercio
- Solo cumpliendo esa condición se puede obtener la ganancia de velocidad sin caer en una dependencia perjudicial a largo plazo
Preocupaciones actuales sobre los agentes de programación y otras posibles palancas
- En fuentes como Hacker News parecen abundar las 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 se observa la gran reducción de costos de mantenimiento que haría falta; más bien parece lo contrario
- Aunque el modelo no represente perfectamente la realidad, el mensaje de que la IA debe reducir los costos de mantenimiento en proporción a la velocidad con la que escribe código nuevo sigue siendo válido
- Incluso si se busca mejorar la velocidad de programación, hay que dedicar la misma cantidad de tiempo a mejorar los costos de mantenimiento
- No es un argumento anti-IA; también hay otras palancas posibles, como una IA que vuelva más productivo el trabajo de mantenimiento en sí, aunque no mejore la mantenibilidad del código como tal
- Si se quieren ajustar las suposiciones al contexto real, se puede copiar la hoja de cálculo y modificar las distintas variables del modelo
2 comentarios
La razón más fundamental por la que surge la desconfianza hacia la IA
actualmente es que la mayoría de los supuestos expertos afirman a gritos que ellos no están experimentando las desventajas de la IA de las que otros hablan, y que tampoco existe ningún trade-off, comportándose como promotores.
Como ya han aumentado los estafadores, se ha acumulado desconfianza hacia todo el sector.
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