- Con la reciente expansión de los agentes de codificación con IA, la velocidad de desarrollo se ha acelerado, pero también se están agravando la caída en la calidad del software y la inestabilidad
- Los agentes acumulan los mismos errores sin capacidad de aprendizaje iterativo, y en bases de código grandes se produce una caída en el recall de búsqueda y una explosión de la complejidad
- Si se les deja a cargo de todo el sistema sin control humano, esto lleva a código duplicado, patrones de diseño incorrectos y bases de código imposibles de mantener
- Por ahora, los agentes deben usarse de forma limitada en tareas no esenciales o áreas experimentales, y los humanos deben seguir siendo la puerta final de control de calidad
- Bajar la velocidad y recuperar la agencia humana es clave para el aprendizaje, el crecimiento y un ecosistema de software sostenible
Todo está roto
- En el último año, los agentes de codificación han evolucionado hasta un nivel capaz de completar proyectos reales, pero como resultado se está haciendo evidente una disminución en la calidad del software
- Incluso en servicios grandes, un 98% de disponibilidad se está volviendo algo común, y los bugs de UI ocurren con frecuencia
- Se mencionan casos como incidentes relacionados con IA en AWS o declaraciones de Microsoft sobre el aumento en la proporción de código generado por IA
- Algunas empresas afirman que el 100% del código del producto lo escribe la IA, pero el resultado muestra baja calidad, con fugas de memoria, errores de UI e inestabilidad funcional
- Varios desarrolladores reportan que, debido al desarrollo centrado en agentes, han terminado en bases de código imposibles de mantener por falta de code review, ausencia de diseño y exceso innecesario de funcionalidades
Cómo no trabajar con agentes
- Los desarrolladores se han vuelto adictos a la velocidad y al volumen de código, al punto de renunciar a la calidad y al control
- Bajo lemas como “distribuido, autónomo y automatizado”, intentan orquestaciones masivas de agentes, pero en la práctica solo producen resultados inestables
- Algunos proyectos ni siquiera son fáciles de poner en marcha y no pueden mantenerse sin intervención humana
- Puede funcionar a nivel de proyectos personales, pero en productos con usuarios reales la mayoría de los casos terminan en fracaso
-
Acumulación de errores y ausencia de aprendizaje, sin cuello de botella, dolor diferido
- Los agentes no tienen capacidad de aprendizaje iterativo, por lo que siguen cometiendo los mismos errores
- Los humanos aprenden de los errores, pero los agentes repiten infinitamente las mismas equivocaciones
- Los humanos tienen una velocidad de escritura de código limitada, así que la acumulación de errores es más lenta, pero un ejército de agentes no tiene cuellos de botella y los errores se acumulan de forma explosiva
- Como resultado, la base de código deja de ser confiable, e incluso las pruebas automatizadas dejan de inspirar confianza
- Al final, las pruebas manuales se vuelven el único medio de validación, y el equipo de desarrollo cae en su propia trampa
-
Mercaderes que aprendieron la complejidad
- Los agentes toman solo decisiones locales sin ver el contexto completo del sistema
- Como consecuencia, se acumulan rápidamente código duplicado, abstracciones innecesarias y desorden estructural
- En organizaciones humanas, esta complejidad se acumula lentamente a lo largo de años, pero en equipos basados en agentes se llega al mismo nivel de caos en pocas semanas
- Los agentes reproducen tal cual patrones de diseño incorrectos aprendidos de sus datos de entrenamiento y, sin control humano, crean una complejidad imposible de recuperar
-
Bajo recall en la búsqueda de los agentes
- Cuando un agente intenta modificar o refactorizar código, no logra encontrar todo el código necesario
- A medida que la base de código crece, el recall de búsqueda baja drásticamente, lo que genera duplicación e inconsistencias
- Aunque se usen herramientas como Bash, LSP o bases de datos vectoriales, en bases de código grandes sigue habiendo límites
- Esto agrava aún más los code smells y la complejidad innecesaria
Cómo sí trabajar con agentes (por ahora)
- Los agentes son atractivos por su rápida generación de código y alta calidad inicial, pero si se les deja a cargo de todo el sistema, todo colapsa
- Los casos de uso adecuados son tareas no esenciales de alcance pequeño, trabajos con bucles de autoevaluación posibles y tareas donde fallar no sea crítico
- Por ejemplo, son apropiados para crear herramientas internas, experimentar ideas o hacer investigación automatizada basada en medición de rendimiento (auto-research)
- Los humanos deben seguir siendo siempre la puerta final de control de calidad, y tienen que revisar, corregir e integrar los resultados de los agentes
- Si la función de evaluación refleja solo métricas limitadas, el agente puede ignorar la calidad del código, la complejidad y la precisión
- Bajar la velocidad es lo clave
- Hay que asegurar tiempo para pensar qué se está construyendo y por qué, y rechazar con firmeza funcionalidades innecesarias
- Limitar la cantidad de código que un agente puede generar al día a un nivel que sea posible revisar
- Las formas esenciales del sistema, como la arquitectura o las API, deben ser escritas directamente por personas
- Hacer pair programming con el agente para conservar la fricción y la oportunidad de comprensión durante el proceso de escritura del código
- Este enfoque permite crear una base de código mantenible, aumentar la satisfacción del usuario y enfocarse en las funciones esenciales en lugar de las innecesarias
- Si la comprensión humana sigue presente, también se mitiga el problema del recall en la búsqueda de los agentes, y si surge un problema, se puede corregir directamente
- Incluso si el diseño inicial fue erróneo, se conserva la capacidad de entender por qué y mejorarlo
- Al final, lo que se necesita es disciplina y agencia humana
- La calidad y sostenibilidad del sistema dependen de la intervención y el juicio humanos
- Ir más despacio es, en última instancia, el único camino para preservar el aprendizaje y el crecimiento, así como un ecosistema de software saludable
2 comentarios
Pi – arnés de codificación de terminal conciso
Así que esta es la persona que hizo esto.
Opiniones de Hacker News
Cada vez que leo este tipo de textos reflexivos últimamente, siento que yo también ya llegué a un punto de cansancio
Al final, lo importante es “qué estamos construyendo” y “si esa herramienta realmente ayuda”
Ya repetimos los mismos errores en la era de Ruby, PHP, Lotus Notes y Visual BASIC
Hay que usar las herramientas con criterio y trabajar a una velocidad que permita entender la compleja realidad de lo que el equipo realmente está construyendo
No se trata de Agile o Waterfall, ni de Docker o Podman
Ahora vivimos en una época en la que un LLM borra una DB de producción y encima hasta ilustra el postmortem en un blog, pero no sé si eso sea realmente ingeniería
Tal vez el desarrollo de software nunca fue, en primer lugar, una disciplina de ingeniería
En los últimos 10 años, la industria del software ha estado llena de metatrabajo — nuevos frameworks, herramientas, capas de virtualización, estructuras organizacionales, etc.
Pero al final ni siquiera queda claro “para qué” se construye todo eso
Se siente como una estructura piramidal, como si se inventaran nuevos trabajos para sostener a la propia industria
Aun así, la ingeniería real sí existe: cuando se plantean preguntas de forma científica y se toman decisiones con base en esas respuestas
En cambio, trabajar por pura intuición y seguir solamente lo que dice el CEO no es ingeniería
Antes había muchos equipos sin siquiera control de versiones, y cuando lo tenían, era bastante malo
Si ves el Joel Test de Joel Spolsky, la mayoría de las empresas de esa época respondía “no” a casi todo
En un puente se calculan con precisión las cargas, los materiales y la vida útil, pero en un sitio web es difícil incluso predecir el tráfico
No existe un criterio claro para tratar cuantitativamente los límites de un servidor o un framework
Tal vez algún día el software llegue a ser ingeniería de verdad, pero todavía falta mucho
Da la impresión de que le pusieron la palabra “ingeniero” solo para pagar mejor
Los ingenieros de verdad valoran la prueba y la verificación, mientras que nosotros disfrutamos probar patrones nuevos e intentar cosas distintas
Por eso, la palabra “ingeniero” a veces hasta incomoda
La criticaba como “una metodología para que programen personas que no saben programar”, y todavía hoy parece una observación acertada
Últimamente el proceso de desarrollo basado en AI se está consolidando alrededor de las grandes empresas y la dependencia del proveedor se está volviendo más fuerte
Si el codebase pasa a estar centrado en agentes, al final solo esos agentes van a entender el código
Cuando eso pase, los precios van a subir y podría convertirse en una transición de una sola vía de la que sería difícil volver a desarrolladores humanos
Los optimistas dicen que “la tecnología siempre se vuelve más barata y mejor”, pero también podría terminar pareciéndose al mercado del petróleo
Como cuando pasamos de DVD a streaming, es como si estuviéramos comprando la misma película dos veces
Modelos como Claude Opus 4.6 ya están costando alrededor de 1 dólar por minuto, y el prompt engineering ya no alcanza para compensarlo
Al final, los servicios de AI también se están dividiendo en una estructura de niveles: económico–medio–premium
El prompt engineering ya casi se trata como una especie de jailbreaking sofisticado
Es riesgoso “arrendar” la capacidad de trabajo intelectual a empresas de AI
Decir “los costos ya no van a subir más” es básicamente el final de la conversación — ya tiraron los dados
Las grandes empresas de AI van por el mismo camino
Puede que al final terminemos atrapados en un mercado de adictos al token
La mano invisible del open source eventualmente va a volver todo gratis
A medida que mejoran el hardware y el software, el costo unitario del cómputo sigue cayendo
Las tecnologías sin uso real desaparecen, como pasó con el boom del blockchain, pero la AI sí tiene usuarios reales
Servicios como Uber, que al principio recibieron muchas críticas, al final encontraron su lugar como negocios sostenibles
A diferencia del petróleo, la computación cada año se vuelve más barata y más rápida
El autor de este texto es la persona que creó Pi, un framework open source de agentes de código
También se usa en OpenClaw
También vale la pena leer su post del blog sobre Pi
Es alguien que ha trabajado con LLM y agentes más a fondo que casi cualquiera
Cuanto más afirma una empresa que “la AI escribe el 100% del código”, más probable es que entregue un producto desastroso
En la época de DOS o MacOS, ese tipo de código tumbaba todo el sistema, así que la calidad importaba más
Hoy el OS es más tolerante, y por eso el código improvisado sobrevive
Gracias a las actualizaciones OTA, es fácil sacar productos incompletos y tratar de salir antes que la competencia
Lo que pasa es que solo recordamos la pequeña parte de productos bien hechos
Hoy, con solo tener conexión de red, hasta el OS se actualiza tan fácil como un juego
Los agentes de código son como “sirenas seductoras”
Al principio parecen rápidos e inteligentes, pero en el momento en que piensas “computadora, haz mi trabajo por mí”, todo se viene abajo
Pero esto es temporal — la AI ya supera a los humanos en áreas medibles
El problema real es la HCI (interacción humano-computadora)
Diseñar interfaces alineadas con los valores humanos será la tarea clave hacia adelante
Ahora estamos en la cima del sobrecalentamiento de la AI
Igual que cuando MongoDB o NoSQL proclamaban que “SQL ha muerto”, al final la gente va a volver a un punto de equilibrio más realista
NoSQL no desapareció, pero ahora se usa solo donde realmente hace falta
Coincido con la idea de que “el software actual es un desastre frágil”, pero en realidad el software en sí no ha cambiado
Antes había menos confianza, así que la gente verificaba las cosas manualmente, y esa lentitud reducía los problemas
La esencia de DevOps es moverse rápido sobre una base de confianza sin sacrificar la calidad
Como con el código Andon de Toyota, cuando aparece un problema hay que detenerse de inmediato y resolver la causa raíz
Esto no es un problema técnico, sino un problema de cultura y procesos
También hay que detectar temprano interfaces equivocadas o desajustes con el contexto del negocio
Como todos usan GitHub, AWS y Cloudflare, si uno se cae, se detiene el mundo entero
Si se descubre un bug justo antes del tape-out, se evalúa con cuidado sin culpar al mensajero
El producto de la programación no es solo el código, sino también el propio programador
Los modelos mentales y la memoria muscular que se acumulan al escribir código son el verdadero activo
Si la AI reemplaza ese proceso, al final desaparece el crecimiento del programador
El mismo problema aparece en “Preventing the Collapse of Civilization” de Jonathan Blow
Ver “Programming as Theory Building”
Ayer hablé de algo parecido con un colega
Vi una demo en la que la AI leía logs, corregía un bug y hasta redactaba el postmortem,
pero el problema es que los humanos no tienen tiempo para interiorizar ese proceso
Como dice la frase “un auto puede ir rápido porque tiene frenos”,
hace falta mantener una fricción de aprendizaje a una velocidad que los humanos puedan comprender
Si un agente pudiera detectarlo y recuperarse por sí solo, ¿haría falta que el humano aprendiera algo?
Claro, podría pasarse por alto la causa raíz, pero si un sistema de autorrecuperación fuera lo bastante robusto, ¿realmente sería un problema?
Desde la perspectiva del diseño de producto también se siente un problema parecido
La velocidad de desarrollo es tan alta que no hay tiempo para probar y validar directamente
Si sigues apilando funciones sobre un diseño equivocado, luego es difícil dar marcha atrás
Al final, lo importante no es la velocidad, sino el equilibrio entre calidad y aprendizaje
Y ese proceso necesariamente requiere tiempo