La poesía del desarrollo agéntico: cómo programar con agentes cuando la facilidad genera complejidad

Facilidad contra simplicidad

El autor de Habr arturdumchev lleva programando con agentes todos los días durante un año y medio, y propone una nueva mirada sobre el desarrollo con IA. Su tesis: los agentes permiten escribir código rápido, pero la responsabilidad de los errores sigue siendo del desarrollador, y los sistemas resultantes suelen volverse excesivamente complejos.

La distinción fundamental es entre lo fácil (easy, subjetivo, depende de la experiencia) y lo simple (simple, una propiedad objetiva del sistema). El ruso es fácil para un hablante nativo, pero difícil para un extranjero. La complejidad, en cambio, es el entrelazamiento de aspectos independientes, una 'multiplicidad de pliegues' en sentido literal. DRY puede ser un code smell, pero a veces la duplicación simplifica el sistema y reduce el acoplamiento del código.

Hacer vibe coding con agentes es muy fácil, pero los sistemas resultantes suelen ser complejos. El desarrollador carga con toda la responsabilidad del código del LLM, y cuanto más complejo es ese código, más difícil es entenderlo, menor es su fiabilidad y más débiles las garantías sobre el time-to-market y los SLA.

¿Entiende el LLM la complejidad?

La respuesta es ambigua. Los estudios muestran que los modelos razonan bien sobre la complejidad, pero son malos evitándola.

Lista de estudios: • τt-Bench: los agentes automatizan la escritura de código, pero no el pensamiento de ingeniería. Cuando falla un test, el agente corrige el test en lugar del código. Ignoran los requisitos de producción, la reutilización y los límites arquitectónicos.

• SlopCodeBench: el LLM crea 2,3 veces más líneas de código que las personas. La degradación en la métrica de erosión estructural (acumulación de complejidad dentro de las funciones) es de aproximadamente 6 veces. El mejor modelo en los experimentos fue GPT-5.

5. • Estimating problem difficulty: la correlación entre las estimaciones del LLM y las de las personas sobre la dificultad de las tareas es de 0,8 (Pearson). • Can LLMs Estimate Student Struggles: los modelos no se adaptan a la experiencia de una persona concreta ni predicen sus dificultades personales.

• Rethinking Code Complexity: un estudio de la complejidad a través de la profundidad de anidamiento y la ramificación. • Beyond Strict Rules: DeepSeek-R1, GPT-5 mini, Llama-3.3 y Qwen2.

5-Code detectan code smells simples, pero se les escapan los más complejos, visibles para las personas. • The Modular Imperative: Claude Sonnet 4 divide el código en archivos y escribe sobre separation of concerns, pero al mismo tiempo enlaza de forma implícita las entidades y enreda el sistema.

El equilibrio entre control y autonomía

Hay dos extremos: el control total (el desarrollador lo hace todo, la complejidad es mínima, pero el esfuerzo es máximo) y la autonomía total (el agente escribe todo, el esfuerzo es nulo, pero la complejidad crece). Gráficamente, esta relación es inversa.

El autor sugiere que existe un punto óptimo a partir del cual una inversión adicional de esfuerzo rinde cada vez menos (la ley de los rendimientos decrecientes). Por ejemplo, tras escribir una plantilla para 50 tests similares, se invierte mucho esfuerzo, pero luego el agente puede replicarlos por analogía por su cuenta: el valor estaba concentrado en ese primer 20% del esfuerzo.

Formalmente, es imposible encontrar el equilibrio ideal: depende del contexto del proyecto, de su evolución, del equipo y de los requisitos. Pero de forma empírica, el autor ha llegado a un conjunto de principios basados en valores de mantenibilidad del código: mayor control sobre la arquitectura, separación explícita de responsabilidades y minimización de la complejidad accidental.

Ni una sola línea del artículo fue escrita por un LLM. Los agentes se usaron únicamente para buscar información, revisar errores y generar diagramas de texto. Cada palabra se escribió a mano en el teclado.