Tómate tu tiempo, esa es la clave en la era del agente

Título original: Reflexiones sobre la necesidad de bajar el ritmo de una vez por todas
Autor original: Mario Zechner
Traducción: Peggy, BlockBeats

Nota del editor: A medida que la IA generativa se va imponiendo en la ingeniería de software, la percepción del sector está pasando del «asombro ante sus capacidades» a la «preocupación por la eficiencia». No escribir lo suficientemente rápido, no utilizarlo lo suficiente, no automatizarlo lo bastante: todo ello parece generar una sensación de obsolescencia. Sin embargo, a medida que los agentes de programación se incorporan de verdad al entorno de producción, empiezan a surgir algunos problemas más prácticos: los errores se magnifican, la complejidad se dispara sin control, los sistemas se vuelven cada vez más opacos y las mejoras en la eficiencia no se traducen proporcionalmente en mejoras de calidad.

Basándose en la experiencia práctica sobre el terreno, este artículo ofrece una reflexión serena sobre la tendencia actual de la «codificación agencial». El autor señala que los agentes no aprenden de los errores como lo hacen los seres humanos; al no existir cuellos de botella ni mecanismos de retroalimentación, los pequeños problemas se amplifican rápidamente. En los códigos fuente complejos, su perspectiva local y su capacidad de memoria limitada agravan aún más el desorden de la estructura del sistema. La esencia de estos problemas no radica en la tecnología en sí misma, sino en que las personas renuncian prematuramente a su capacidad de juicio y control, impulsadas por la ansiedad.

Por lo tanto, en lugar de caer en la inquietud de «si debemos adoptar plenamente la IA», es mejor replantearnos la relación entre los seres humanos y las herramientas: dejar que los agentes se encarguen de tareas puntuales y controlables, mientras mantenemos el diseño del sistema, el control de calidad y las decisiones clave firmemente en nuestras manos. En este proceso, «tomarme las cosas con calma» se convierte en una habilidad; significa que sigues entendiendo el sistema, puedes hacer concesiones y mantienes el control sobre tu trabajo.

En una época en la que las herramientas están en constante evolución, lo que realmente escasea quizá no sean unas capacidades generativas más rápidas, sino la capacidad de evaluar la complejidad y la firmeza necesaria para elegir entre eficiencia y calidad.

A continuación se muestra el texto original:

La expresión de la cara de la tortuga refleja mi visión de este sector

Hace aproximadamente un año, empezaron a aparecer auténticos «agentes de programación» capaces de ayudarte a «llevar a cabo un proyecto completo de principio a fin». Ya existían herramientas anteriores, como Aider y las primeras versiones de Cursor, pero se parecían más a «asistentes» que a «agentes». La nueva generación de herramientas resulta muy atractiva, y mucha gente ha dedicado gran parte de su tiempo libre a llevar a cabo todos esos proyectos que siempre había querido hacer pero para los que nunca había tenido tiempo.

No creo que eso sea un problema en sí mismo. Hacer algo en tu tiempo libre es, por naturaleza, algo que da alegría y, la mayoría de las veces, no hace falta preocuparse por la calidad del código ni por su facilidad de mantenimiento. Esto también te ofrece la oportunidad de aprender un nuevo conjunto de tecnologías.

Durante las fiestas navideñas, Anthropic y OpenAI también lanzaron unos «créditos gratuitos», que atrajeron a la gente como si se tratara de una máquina tragaperras. Para muchos, esta fue su primera experiencia real con la magia de la «programación de agentes». La participación va en aumento.

Hoy en día, la programación con un agente también está empezando a introducirse en los códigos de producción. Han pasado doce meses y estamos empezando a ver las consecuencias de este «progreso». Estas son mis reflexiones actuales.

Todo se está desmoronando

Aunque en su mayor parte se trata de casos aislados, es cierto que el software actual da la sensación de que «está a punto de fallar» en cualquier momento. Un tiempo de actividad del 98 % está pasando de ser una excepción a convertirse en la norma, incluso en el caso de los grandes servicios. La interfaz de usuario está plagada de todo tipo de errores absurdos que el equipo de control de calidad debería haber detectado a simple vista.

Reconozco que esta situación ya existía antes de que apareciera el agente. Pero ahora, el problema se está agravando claramente.

No podemos ver la situación real dentro de las empresas, pero de vez en cuando se producen filtraciones de información, como el supuesto «corte de servicio de AWS provocado por la IA». Amazon Web Services «corrigió» rápidamente la declaración, pero a continuación puso en marcha de inmediato un plan de reorganización interno de 90 días.

Satya Nadella (director ejecutivo de Microsoft) también ha destacado recientemente que cada vez es mayor la parte del código de la empresa que se escribe mediante IA. Aunque no hay pruebas directas, sí que existe la sensación de que la calidad de Windows está decayendo. Incluso en algunos blogs publicados por la propia Microsoft, parece que lo han reconocido tácitamente.

Las empresas que afirman que «el 100 % del producto ha sido creado por IA» casi siempre acaban ofreciendo los peores productos que uno pueda imaginar. No es por señalar a nadie, pero cosas como las fugas de memoria por gigabytes, el caos en la interfaz de usuario, las funciones que faltan, los fallos frecuentes... nada de eso es lo que ellos consideraban un «sello de calidad», y mucho menos una demostración positiva de «deja que el Agente lo haga todo por ti».

En privado, cada vez se oye más, tanto de grandes empresas como de equipos pequeños, que dicen lo mismo: se han visto acorralados por la «programación de agentes». Sin revisiones del código, dejando las decisiones de diseño en manos del agente y añadiendo luego un montón de funciones innecesarias... está claro que eso no va a acabar bien.

Por qué no deberíamos utilizar el agente de esta manera

Hemos abandonado casi por completo toda disciplina de ingeniería y todo criterio subjetivo, cayendo en cambio en una forma de trabajar «adictiva»: solo hay un objetivo: generar la mayor cantidad de código en el menor tiempo posible, sin tener en cuenta en absoluto las consecuencias.

Estás creando una estructura básica para dirigir un ejército de agentes automatizados. Has instalado Beads, pero no tienes ni idea de que, en realidad, se trata de un «malware» imposible de desinstalar. Solo lo haces porque en Internet dicen que «todo el mundo lo hace». Si no lo haces así, estás «ngmi» (no lo vas a conseguir).

Te estás consumiendo a ti mismo sin cesar en un «bucle al estilo de las muñecas rusas».

Mira, Anthropic ha creado un compilador C utilizando un grupo de agentes; aunque ahora todavía tiene algunos problemas, el modelo de próxima generación seguro que podrá solucionarlos, ¿no?

Mira, Cursor creó un navegador utilizando un gran grupo de agentes; aunque ahora es prácticamente inutilizable y todavía requiere alguna intervención manual de vez en cuando, el modelo de próxima generación seguro que podrá gestionarlo, ¿no?

«Distribuido», «Divide y vencerás», «Sistemas autónomos», «Black Light Factory», «Seis meses para resolver un problema de software», «El SaaS ha muerto, mi abuela acaba de crear una tienda en Shopify usando Claw»...

Estas historias parecen apasionantes.

Por supuesto, es posible que este enfoque «siga funcionando» para tu proyecto paralelo, que casi nadie utiliza (ni siquiera tú mismo). Quizás haya realmente algún genio capaz de utilizar este método para crear un producto de software que no sea basura y que sea realmente útil. Si eres esa persona, te admiro de verdad.

Sin embargo, al menos en mi círculo de desarrolladores, todavía no he visto ningún caso en el que este método haya resultado realmente eficaz. Claro, quizá es que todos somos demasiado inexpertos.

La acumulación de errores en la ausencia de aprendizaje, la ausencia de cuellos de botella y las explosiones retardadas

El problema con los agentes es que cometen errores. En sí mismo, no es para tanto; los humanos también cometemos errores. Podrían ser solo algunos errores de sintaxis, fáciles de detectar y corregir, y añadir una prueba de regresión lo hace aún más estable. También podrían ser algunos indicios de código defectuoso que los linters no detectan: un método sin usar por aquí, un tipo poco adecuado por allá, algo de código duplicado, etcétera. Por sí solos, no son gran cosa, y los desarrolladores humanos también cometen este tipo de pequeños errores.

Pero las «máquinas» no son seres humanos. Después de cometer el mismo error varias veces, los seres humanos suelen aprender a no repetirlo, ya sea porque alguien les regaña o porque cambian a raíz de un proceso de aprendizaje genuino.

Los agentes no tienen esta capacidad de aprendizaje, al menos no de forma predeterminada. Repetirán el mismo error una y otra vez, y es posible que incluso «creen» combinaciones maravillosas de diferentes errores basadas en los datos de entrenamiento.

Por supuesto, puedes intentar «entrenarlos»: escribe reglas en AGENTS.md para que no repitan esos errores; diseña un sistema de memoria complejo para que puedan consultar los errores históricos y las mejores prácticas. Esto resulta realmente eficaz para ciertos tipos de problemas. Pero la premisa es que primero debes darte cuenta de que ha cometido ese error.

La diferencia fundamental es la siguiente: El cuello de botella lo constituyen las personas; los agentes, no.

Un ser humano no puede escribir veinte mil líneas de código en unas pocas horas. Aunque la tasa de errores no sea precisamente baja, solo se pueden producir un número limitado de errores al día, y su acumulación es lenta. Por lo general, cuando el «dolor causado por los errores» alcanza un cierto nivel, las personas (por su instinto de evitar el dolor) se detienen para arreglar las cosas. O bien se sustituyen, y otra persona se encarga de arreglarlas. En cualquier caso, el asunto se aborda.

Sin embargo, cuando se despliega todo un ejército de agentes perfectamente coordinados, no hay cuellos de botella ni «sensación de dolor». Estos pequeños errores, que al principio parecen insignificantes, se acumulan a un ritmo insostenible. Te has quedado al margen, sin darte cuenta de que esos fallos aparentemente inofensivos se han convertido en un gigante. Para cuando realmente sientes el dolor, suele ser demasiado tarde.

Solo cuando un día intentas añadir una nueva función y te das cuenta de que la arquitectura actual del sistema (que, en esencia, es un montón de errores) no puede adaptarse al cambio, o los usuarios empiezan a quejarse furiosamente porque la última versión tiene fallos o, lo que es peor, se han perdido datos.

Es en este momento cuando te das cuenta de que: Ya no puedes confiar en este código.

Y lo que es peor, los miles y miles de pruebas unitarias, pruebas de instantáneas y pruebas de extremo a extremo generadas por los agentes son igualmente poco fiables. La única forma de comprobar si «el sistema funciona correctamente» es mediante pruebas manuales.

Enhorabuena, te has metido (y has metido a tu empresa) en un buen lío.

El mercader de la complejidad

Has perdido por completo la perspectiva de lo que está sucediendo en el sistema porque has cedido el control a los Agentes. Y, en esencia, el negocio de los agentes consiste en «vender complejidad». Han detectado numerosas decisiones arquitectónicas erróneas en sus datos de entrenamiento y han reforzado continuamente estos patrones durante el proceso de aprendizaje por refuerzo. Si les dejas diseñar el sistema, el resultado es el que cabría esperar.

El resultado es un sistema tremendamente enrevesado, que combina diversas imitaciones deficientes de las «mejores prácticas del sector», y no impusiste ninguna restricción antes de que los problemas se descontrolaran.

Pero los problemas no terminan ahí. Tus agentes no comparten entre sí los procesos de ejecución, no pueden ver el código completo y desconocen las decisiones que tú u otros agentes hayan tomado anteriormente. Por lo tanto, sus decisiones son siempre «locales».

Esto conduce directamente a los problemas mencionados anteriormente: una gran cantidad de código duplicado, estructuras excesivamente abstractas por el mero hecho de ser abstractas y todo tipo de incoherencias. Estos problemas se acumulan, lo que acaba dando lugar a un sistema irremediablemente complejo.

En realidad, esto se parece bastante a un código fuente de nivel empresarial escrito por personas. La única diferencia es que este tipo de complejidad suele ser el resultado de años de acumulación: el problema se distribuye entre un gran número de personas, ninguna de las cuales ha alcanzado el umbral de «hay que solucionarlo», y la propia organización tiene una gran capacidad de tolerancia, por lo que la complejidad y la organización «coevolucionan».

Sin embargo, en el caso de una combinación de persona y agente, este proceso se acelerará considerablemente. Dos personas, además de un grupo de agentes, pueden alcanzar este nivel de complejidad en cuestión de semanas.

La tasa de recuperación de la búsqueda agentiva es baja

Quizá esperes que los agentes «arreglen el desastre» por ti, te ayuden a refactorizar, optimizar y hacer que el sistema sea más limpio. Pero el problema es que ya no pueden hacerlo.

Porque el código es demasiado extenso y su complejidad es muy elevada, y solo pueden ver una parte del mismo. No se trata solo de que la ventana de contexto no sea lo suficientemente grande, o de que el mecanismo de contexto largo falle ante millones de líneas de código. El problema es más insidioso.

Antes de que un agente intente reparar el sistema, debe localizar primero todo el código que hay que modificar, así como las implementaciones existentes que se puedan reutilizar. A este paso lo llamamos «búsqueda agencial».

La forma en que un agente lleva esto a cabo depende de las herramientas que se le proporcionen: puede ser Bash + ripgrep, un índice de código con función de búsqueda, un servicio LSP, una base de datos vectorial...

Pero independientemente de las herramientas que se utilicen, la esencia es la misma: cuanto mayor es el código fuente, menor es la tasa de recuperación. Y una tasa de recuperación baja significa que el agente no puede encontrar todo el código relevante y, por supuesto, no puede realizar las modificaciones correctas.

Por eso también es por lo que al principio aparecen esos pequeños errores que delatan un «code smell»: al no encontrar una implementación existente, acaba reinventando la rueda e introduce incoherencias. Con el tiempo, estos problemas seguirán extendiéndose, solapándose y convirtiéndose en una «flor marchita» extremadamente compleja.

Entonces, ¿cómo podemos evitar todo esto?

¿Cómo deberíamos colaborar con los agentes (al menos por ahora)?

Programar con Agents es como lidiar con un monstruo marino, con su altísima velocidad de generación de código y ese tipo de inteligencia «intermitente, pero a veces impresionante» que te atrapa. A menudo son capaces de realizar tareas sencillas con una rapidez asombrosa y con gran calidad. El verdadero problema empieza cuando se te ocurre la idea: «Esto es demasiado potente, ordenador, ¡haz tú el trabajo por mí!».

Por supuesto, delegar tareas al propio agente no supone ningún problema. Las tareas adecuadas para un agente suelen tener varias características: el alcance puede definirse con claridad, no es necesario comprender todo el sistema; la tarea es de ciclo cerrado, lo que significa que el agente puede evaluar los resultados por sí mismo; el resultado no se encuentra en la ruta crítica, sino que se trata simplemente de algunas herramientas o software temporales para uso interno, que no afectarán a los usuarios reales ni a los ingresos; o simplemente necesitas un «pato de goma» que te ayude a pensar —básicamente, tomar tus ideas y confrontarlas con el conocimiento condensado de Internet y los datos sintéticos—.

Si se cumplen estas condiciones, se trata de una tarea que puede delegarse al agente, siempre y cuando tú, como persona, sigas siendo el responsable último del control de calidad.

¿Por ejemplo, utilizando el método de autoinvestigación de Andrej Karpathy para optimizar el tiempo de inicio de la aplicación? Genial. Pero es fundamental que comprendas que el código que genera no está, en absoluto, listo para su uso en producción. La investigación automática es eficaz porque le has asignado una función de aptitud para optimizar una métrica concreta (como el tiempo de arranque o la pérdida). Sin embargo, esta función de aptitud abarca solo una dimensión muy limitada. El agente ignorará sin reparos todos los parámetros que no estén incluidos en la función de aptitud, como la calidad del código, la complejidad del sistema y, en algunos casos, incluso la corrección —si la propia función de aptitud es defectuosa—.

La idea fundamental es, en realidad, bastante sencilla: deja que el agente se encargue de las tareas aburridas y poco formativas, o del trabajo de exploración que nunca has tenido tiempo de hacer. A continuación, evalúa los resultados, selecciona las partes que sean realmente razonables y correctas, y lleva a cabo la implementación definitiva. Por supuesto, también puedes utilizar el Agente para que te ayude con este último paso.

Pero lo que realmente quiero destacar es: de verdad, tómatelo con más calma.

Tómate tu tiempo para pensar en lo que estás haciendo y por qué lo haces. Date la oportunidad de decir «no, no necesitamos esto». Establece un límite claro para el agente: cuánta cantidad de código puede generar al día, una cantidad que debe ajustarse a tu capacidad real de revisión. Todas las partes que determinan la «estructura general» del sistema, como la arquitectura y las API, deben ser creadas por ti. Puedes usar la función de autocompletado para hacerte una idea de lo que es «escribir código a mano», o practicar la programación en pareja con el Agente, pero lo importante es que estés metido en el código.

Porque escribir el código uno mismo, o ver cómo se va creando paso a paso, genera una especie de «fricción». Es precisamente esta fricción la que te ayuda a tener más claro lo que quieres hacer, cómo funciona el sistema y cuál es la «sensación» general. Aquí es donde entran en juego la experiencia y el «gusto», y eso es precisamente lo que los modelos más avanzados aún no pueden sustituir. Tómate las cosas con calma, aguanta las dificultades: así es precisamente como se aprende y se crece.

Al final, lo que tendrás seguirá siendo un sistema fácil de mantener; al menos, no peor que antes de que apareciera el agente. Sí, los sistemas anteriores tampoco eran perfectos. Pero tus usuarios te lo agradecerán porque tu producto es «fácil de usar», y no un montón de chatarra ensamblada a toda prisa.

Tendrás menos funciones, pero serán más precisas. Aprender a decir «no» es, en sí mismo, una habilidad. Además, puedes dormir tranquilo porque sigues estando al tanto de lo que ocurre en el sistema y sigues teniendo el control. Es precisamente esta comprensión la que te permite abordar el problema de la recuperación de la búsqueda agencial, lo que hace que los resultados del agente sean más fiables y requieran menos correcciones.

Cuando el sistema falla, puedes arremangarte y arreglarlo; cuando el diseño era defectuoso desde el principio, puedes comprender el problema y refactorizarlo para mejorar su estructura. En realidad, que haya un agente o no no tiene tanta importancia.

Todo esto requiere disciplina. Todo esto es inseparable del ser humano.

[Artículo original]