- La realidad de que el costo de escribir código ha caído drásticamente está sacudiendo los hábitos de ingeniería en general
- En el pasado, como producir código era costoso, se formó una cultura de desarrollo eficiente centrada en diseño, estimación y planificación
- Con la aparición de los agentes de codificación, un solo desarrollador puede realizar al mismo tiempo múltiples tareas (implementación, refactorización, pruebas y documentación)
- Sin embargo, crear “buen código” sigue exigiendo altos estándares de calidad y el criterio del desarrollador
- En consecuencia, está surgiendo el desafío de construir nuevos hábitos de desarrollo, tanto personales como organizacionales
Cambios en el costo de escribir código
- Antes, escribir cientos de líneas de código limpio y probado tomaba más de un día
- Por eso, los desarrolladores evaluaban el valor y la prioridad de las funciones en función del tiempo y costo limitados
- El diseño del proyecto, la estimación del calendario y la planificación de funcionalidades se hacían en torno al “uso eficiente del tiempo de codificación”
- Con la introducción de los agentes de codificación, el costo de introducir código cayó de forma abrupta y los criterios de decisión tradicionales empezaron a tambalearse
- Un solo ingeniero puede ejecutar varios agentes en paralelo para realizar trabajo de desarrollo simultáneo en múltiples frentes
- Este cambio obliga a reconsiderar la estructura tradicional de evaluación del valor frente al tiempo
El “buen código” sigue siendo caro
- La producción de código nuevo se ha vuelto casi gratuita, pero crear “buen código” sigue siendo costoso
- Las condiciones del buen código son las siguientes
- Funciona correctamente y cumple su objetivo sin errores
- Pasa por procesos de verificación que demuestran que el código es confiable
- Se enfoca en resolver el problema adecuado y maneja las situaciones de error de forma predecible
- Mantiene una estructura simple y mínima para mejorar la mantenibilidad y la comprensión
- Las pruebas y la documentación deben mantenerse actualizadas
- Considera la posibilidad de cambios futuros sin añadir complejidad innecesaria
- Cumple atributos de calidad no funcionales como accesibilidad, seguridad, escalabilidad y mantenibilidad
- Los agentes de codificación pueden apoyar parte de este proceso, pero la responsabilidad final de garantizar la calidad sigue recayendo en el desarrollador
La necesidad de nuevos hábitos de desarrollo
- En un entorno de ingeniería basada en agentes (agentic engineering), los hábitos de desarrollo tradicionales ya no son válidos
- Tanto las personas como las organizaciones deben formar nuevas formas de trabajo y nuevos criterios de decisión
- En toda la industria, estas mejores prácticas (best practices) aún se están definiendo
- El enfoque propuesto es que, incluso cuando parezca que “es una pérdida de tiempo”, se experimente ejecutando sesiones asíncronas con agentes
- En el peor de los casos, solo se revisa 10 minutos después y termina siendo un desperdicio de tokens
Ubicación dentro de la guía Agentic Engineering Patterns
- Este texto forma parte del primer capítulo, “Principles”, de la guía Agentic Engineering Patterns
- El siguiente capítulo continúa con el tema de comprensión de código (Understanding code), con Linear walkthroughs
- Más adelante, en la sección Testing and QA, se abordan temas como Red/green TDD y First run the tests
- Está previsto añadir 1 o 2 capítulos por semana, con una estructura parecida a la de un libro, aunque en formato de “guía”
1 comentarios
Comentarios en Hacker News
No estoy seguro de que sea correcto decir que “el código siempre fue caro”.
En realidad, lo caro nunca fue el código en sí, sino todo lo que lo rodea: asegurar la corrección, darle mantenimiento, coordinar equipos, soporte a largo plazo, etc.
Si se exagera con las pruebas o los procesos de aprobación, el proceso mismo termina representando la mayor parte del costo.
Los LLM sí redujeron mucho a corto plazo el costo de generar código que funciona, pero a largo plazo podrían aumentar la carga de mantenimiento, seguridad y pruebas.
Al final, solo con datos de largo plazo sabremos si de verdad hubo un cambio.
Antes, incluso escribir unos pocos cientos de líneas ya costaba bastante.
Probé meter 256 líneas de JavaScript en la herramienta estilo SLOCount de los 2000 (versión WebAssembly) y estimó un costo de unos $6,461 según los criterios de esa época.
Claro, esa cifra hay que tomarla solo como curiosidad.
Ahora me siento menos como alguien que hace el trabajo y más como un autogerente que administra su propio trabajo.
Siento que mi productividad subió unas 2.5 veces frente a antes.
Sigue haciendo falta levantar requisitos, diseñar, probar, desplegar y mantener, y la mayor parte del costo sigue estando en la etapa de mantenimiento.
Como en la ley de Amdahl, aunque el costo de programar se acerque a cero, el costo de las demás etapas se vuelve el límite.
El problema es que, por naturaleza humana, eso es difícil.
Factores de calidad como corrección, mantenibilidad y rendimiento son costos ocultos que solo se aprenden con experiencia.
No estoy de acuerdo con la idea de que “el código siempre fue caro”.
En realidad, era caro porque intentábamos escribir ‘buen código’.
Si bajas el estándar, el código generado puede ser rápido y barato, pero el esfuerzo para convertirlo en buen código sigue siendo el mismo.
Si quieres defender la programación con agentes, hay que hacerlo con otra lógica.
Cuando escribo yo, entiendo por qué está cada línea, pero con código hecho por IA tengo que validar cada construcción.
En el último mes hice la mayor parte del trabajo con agentes, y siguen apareciendo bugs en casos límite que una persona normalmente no habría introducido.
Al final, el costo de revisión crece tanto que la ganancia de corto plazo desaparece.
Aun así, gracias a los agentes de programación ese costo sí baja muchísimo.
Como el agente se encarga de ajustes finos, puedes producir código de mejor calidad más rápido.
La complejidad se acumula, así que tratarla con cuidado desde el inicio es lo más barato.
Ahora la ganancia de corto plazo es grande, pero a largo plazo el ruido podría multiplicarse por diez.
Los LLM están especializados en programación táctica, o sea, en implementar funciones rápido.
Por eso se vuelve aún más importante gestionar la complejidad a nivel sistema.
Generar código es tan barato como dicen, pero la habilidad real está en convertirlo en un resultado valioso.
La ingeniería agéntica consiste justamente en transformar insumos baratos en salidas valiosas.
La ingeniería agéntica no es solo escribir software, sino crear herramientas para resolver rápido un problema específico.
Pero una vez resuelto el problema, la IA en sí deja de ser interesante.
Mucha gente convierte la IA en el objetivo, cuando el verdadero valor está en resolver el problema.
Como decía Alan Watts, si ya recibiste el mensaje, cuelga el teléfono.
Que la herramienta sea más barata no hace que el valor aparezca automáticamente.
La verdadera fuente de valor es la capacidad de diseñar y estructurar.
Al final, lo importante es la calidad de las decisiones.
Financiarse no es prueba de valor.
Me genera dudas la afirmación de que “el código siempre fue caro”.
Incluso la definición de código limpio y probado es ambigua.
Si exageras con las pruebas, el costo se dispara, y los procesos organizacionales de aprobación también son una fuente importante de costo.
Los LLM reducen el costo a corto plazo, pero podrían aumentar el costo de mantenimiento a largo plazo.
Cuando era practicante trabajé barato en una startup, pero se acumularon incidentes, corrupción de datos y deuda técnica.
Por fuera parecía barato, pero el costo oculto era alto.
Gracias a los LLM hoy parece posible conseguir código de buena calidad por poco dinero, pero seguimos adaptándonos.
Hoy hacer una v1 es barato, pero las decisiones complejas de un producto maduro siguen siendo caras.
El valor económico del software está en la información contenida en el código.
Escribir código es solo el proceso de mapear esa información, y la calidad de la información es lo que determina el verdadero valor.
Escribir código más rápido no mejora la calidad de esa información.
Es como en consultoría: hacer diapositivas más rápido no crea valor por sí solo.
Si la velocidad de implementación se vuelve demasiado alta, el modelo mental del desarrollador se desalineará del código.
Artículo relacionado: Cognitive Debt by Simon Willison
Fue porque pude iterar refactorizaciones rápidamente.
La IA cada vez entenderá más contexto, pero eso implicará renunciar en la misma medida al juicio humano.
El día que la máquina entienda completamente la intención, el ser humano quedará fuera del loop.
El núcleo de todas las metodologías de desarrollo es que los requisitos siempre cambian.
Por eso el buen código es “código fácil de cambiar”.
No está claro que los agentes LLM actuales estén produciendo ese tipo de código.
Hasta que no sean totalmente confiables, probablemente se queden en nivel de prototipo.
Si la especificación es ambigua, se vuelve difícil tanto probar como validar el valor.
Incluso con pruebas, uno solo tiene como un 70% de confianza.
Es más rápido que programar yo mismo, y el resultado sale como código mantenible.
Si especificas código limpio y buenas prácticas, sí se puede obtener un resultado suficientemente mantenible.
Al final es Garbage in, garbage out.
Como dije en mi texto (The Final Bottleneck),
la velocidad de escritura de código aumentó, pero las etapas posteriores no han seguido el ritmo.
No es solo una cuestión de hábitos; hay que cambiar la estructura de responsabilidades, el diseño de los lenguajes y la arquitectura general del sistema.
Si de verdad la productividad hubiera subido 10 veces, las startups ya habrían dado vuelta el mercado.
Que algo sea posible no significa que necesariamente haya que hacerlo.
Enfoques como AI evals (measure-first-optimize-last, ai-evals.io) apuntan en esa dirección.
Nadie quiere una explosión descontrolada de funcionalidades.
Cada línea de código es una responsabilidad (liability).
En una era donde los LLM producen código en masa, esa responsabilidad se dispara.
La herramienta en sí no es mala, pero es riesgoso un esquema donde programas sin responsabilidad reescriben la base de código.
Que “el código sea barato” solo significa que generar código se abarató; el costo de aprobar el despliegue sigue siendo alto.
Si te saltas la etapa de juicio, no obtienes más productividad sino un vacío de control (control gap).
Dar una llave maestra solo porque algo es rápido es peligroso.
Ninguna de las dos cosas se ha vuelto barata.
Yo también estoy casi totalmente de acuerdo con esta opinión.
Escribir código se abarató, pero el costo de revisión y validación sigue siendo alto.
Sobre todo en monorepos de millones de líneas, la clave es mejorar la capacidad de prueba.
Agradezco que este tipo de discusión aporte equilibrio en medio del ambiente sobrecalentado de Twitter.
El churn de código se volvió fácil, pero la verificación de calidad se está convirtiendo en el nuevo reto.
Los cambios masivos generados por LLM producen fallas sutiles, y ese flujo no se detiene.
El código no es barato.
También están los costos de tokens, y la estructura real de costos todavía es incierta.
Como startups sin ingresos están acaparando la cadena de suministro de GPU, faltan datos claros.
A medida que aumenta el LOC, también aumenta la deuda.
La distancia entre pensar y ejecutar se acortó, pero el código sigue siendo una responsabilidad.
Ahora es barato por los subsidios, pero podría abaratarse todavía más si bajan los costos de hardware, energía y personal.