Más despacio, esa es la respuesta a la era del agente

Título original: Pensamientos sobre la ralentización de la mierda
Autor original: Mario Zechner
Traducción: Peggy, BlockBeats

Nota del editor: A medida que la IA generativa se acelera hacia la ingeniería de software, el sentimiento de la industria está cambiando de "asombro por la capacidad" a "ansiedad por la eficiencia". No escribir lo suficientemente rápido, no usar lo suficiente, no automatizar lo suficiente, todo parece crear una presión de obsolescencia. Sin embargo, a medida que los agentes de codificación entran realmente en el entorno de producción, comienzan a surgir algunos problemas prácticos más: los errores se magnifican, la complejidad se descontrola, los sistemas se vuelven cada vez más opacos y las ganancias de eficiencia no se traducen proporcionalmente en mejoras de calidad.

Basado en la práctica de primera línea, este artículo ofrece una reflexión sobria sobre la tendencia actual de "codificación genética". El autor señala que los agentes no aprenden de los errores como lo hacen los humanos; en ausencia de cuellos de botella y mecanismos de retroalimentación, los pequeños problemas se amplifican rápidamente. Dentro de las bases de código complejas, su perspectiva local y su limitada capacidad de recuperación exacerban aún más el desorden de la estructura del sistema. La esencia de estos problemas no radica en la tecnología en sí, sino en que los seres humanos renuncian al juicio y al control prematuramente bajo el impulso de la ansiedad.

Por lo tanto, en lugar de caer en la ansiedad de "si debemos adoptar completamente la IA", es mejor recalibrar la relación entre los seres humanos y las herramientas: dejar que los agentes asuman tareas locales y controlables, manteniendo firmemente en nuestras manos el diseño del sistema, la garantía de calidad y las decisiones clave. En este proceso, "ralentizar" se convierte en una capacidad; significa que aún entiendes el sistema, puedes hacer concesiones y mantener un sentido de control sobre tu trabajo.

En una era de evolución de las herramientas, lo verdaderamente escaso puede no ser una capacidad generativa más rápida, sino el juicio de la complejidad y la firmeza para elegir entre eficiencia y calidad.

A continuación el texto original:

La expresión en la cara de la tortuga es cómo veo esta industria

Hace aproximadamente un año, comenzó a surgir un verdadero agente de codificación que podría ayudarte a "completar todo un proyecto de principio a fin". Había herramientas anteriores como Aider y Cursor temprano, pero eran más como asistentes que "agentes". La nueva generación de herramientas es muy atractiva, y muchas personas han pasado mucho de su tiempo libre haciendo todos los proyectos que siempre han querido hacer, pero nunca tuvieron tiempo para hacerlo.

No creo que esto sea un problema en sí mismo. Es inherentemente alegre hacer algo en su tiempo libre, y la mayoría de las veces, realmente no necesita preocuparse por la calidad y la mantenibilidad del código. Esto también le da un camino para aprender una pila de nueva tecnología.

Durante la temporada navideña, Anthropic y OpenAI también lanzaron algunos "créditos gratis", atrayendo a la gente como una máquina tragaperras. Para muchos, este fue su primer sabor real de la magia de la "codificación de agentes". La participación está creciendo.

Hoy en día, la codificación con un agente también está empezando a abrirse paso en las bases de código de producción. Han pasado doce meses, y estamos empezando a ver las consecuencias de este "progreso". Aquí están mis pensamientos actuales.

Todo se está desmoronando

Si bien la mayoría de esto es anecdótico, el software actual da la sensación de estar "a punto de romperse" en cualquier momento. El 98% del tiempo de actividad está pasando de una excepción a la norma, incluso para servicios grandes. La interfaz de usuario está llena de todo tipo de errores absurdos que deberían haber sido capturados de un vistazo por el equipo de control de calidad.

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

No podemos ver el verdadero estado dentro de las empresas, pero hay filtraciones ocasionales de información, como el rumoreado "corte de AWS inducido por IA". Amazon Web Services "corrigió" rápidamente la declaración, pero luego lanzó inmediatamente un plan de reorganización de 90 días internamente.

Satya Nadella (Director General de Microsoft) también ha estado enfatizando recientemente que cada vez más el código en la compañía es escrito por IA. Aunque no hay evidencia directa, sí hay una sensación: la calidad de Windows está disminuyendo. Incluso desde algunos blogs publicados por los propios Microsoft, parecen haberlo reconocido tácitamente.

Las empresas que afirman que "el 100% del producto es generado por la IA" casi siempre terminan produciendo los peores productos que puedas imaginar. No es por señalar con el dedo, pero cosas como fugas de memoria por el gigabyte, caos en la interfaz de usuario, características perdidas, bloqueos frecuentes... ninguno de estos son lo que pensaban como un "avance de calidad", y mucho menos una demostración positiva de "deja que el Agente haga todo por ti".

En privado, escucharás cada vez más, tanto de grandes empresas como de pequeños equipos, decir una cosa: han sido empujados a una esquina por la "codificación de agentes". Sin revisiones de código, entregando las decisiones de diseño al agente y luego acumulando un montón de características innecesarias, obviamente, no va a terminar bien.

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

Casi hemos abandonado toda disciplina de ingeniería y juicio subjetivo, cayendo en una forma de trabajo "adictiva": solo hay un objetivo: generar la mayor cantidad de código en el menor tiempo posible, sin tener absolutamente en cuenta las consecuencias.

Estás construyendo una capa de andamiaje para comandar un ejército automatizado de agentes. Usted ha instalado Beads, sin embargo, no es completamente consciente de que es esencialmente un "malware" desinstalable. Solo lo estás haciendo porque fuentes en línea dicen "todo el mundo lo está haciendo". Si no lo haces de esta manera, eres "ngmi" (no lo lograrás).

Continuamente te autoconsumes en un "bucle estilo muñeca de anidamiento".

Mira: Anthropic creó un compilador C usando un grupo de Agentes, aunque todavía tiene problemas ahora, el modelo de próxima generación seguramente podrá solucionarlo, ¿verdad?

Ahora miren: Curror construyó un navegador usando un gran grupo de Agentes, aunque básicamente es inutilizable ahora y aún necesita una intervención manual ocasional, el modelo de próxima generación seguramente podrá manejarlo, ¿verdad?

"Distribuido", "Dividir y conquistar", "Sistemas autónomos", "Fábrica de luz negra", "Seis meses para resolver un problema de software", "SaaS está muerto, mi abuela acaba de montar una tienda Shopify usando Garra"...

Estas narrativas suenan emocionantes.

Por supuesto, este enfoque puede "todavía funcionar" para su proyecto paralelo casi no utilizado (incluido usted mismo). Tal vez, realmente hay un genio que puede usar este método para crear un producto de software verdaderamente utilizable y sin basura. Si eres esa persona, entonces realmente te admiro.

Sin embargo, al menos en mis círculos de desarrolladores, todavía no he visto un caso realmente efectivo de este método. Por supuesto, tal vez todos somos demasiado inexpertos.

La acumulación de errores sin aprendizaje, sin cuellos de botella y explosiones retardadas

El problema con los Agentes es: cometen errores. Esto no es gran cosa en sí mismo; los humanos también cometen errores. Podrían ser solo algunos errores de corrección, fáciles de identificar y corregir, y agregar una prueba de regresión lo hace aún más estable. También podría haber olores de código que los borrachos no pueden captar: un método no utilizado aquí, un tipo irrazonable allí, algún código duplicado, etc. Individualmente, estos no son un gran problema, y los desarrolladores humanos también cometen este tipo de pequeños errores.

Pero las "máquinas" no son humanas. Después de repetir el mismo error varias veces, los seres humanos generalmente aprenden a no repetirlo, o son regañados por alguien o cambian en un proceso de aprendizaje genuino.

Los agentes no tienen esta capacidad de aprendizaje, al menos no por defecto. Repetirán el mismo error una y otra vez, e incluso pueden "crear" maravillosas combinaciones de diferentes errores basados en datos de entrenamiento.

Por supuesto, puedes intentar "entrenarlos": escribir reglas en AGENTS.md para que no repitan tales errores; diseñar un sistema de memoria complejo para que consulten errores históricos y mejores prácticas. Esto es realmente efectivo en ciertos tipos de problemas. Pero la premisa es: primero debes observar que ha cometido este error.

La diferencia clave es esta: Los humanos son el cuello de botella; los agentes no.

Un humano no puede vomitar veinte mil líneas de código en unas horas. Incluso con una tasa de error no tan baja, solo se puede introducir un número finito de errores en un día, siendo lenta su acumulación. Típicamente, cuando el "dolor por errores" alcanza cierto nivel, los humanos (por aversión instintiva al dolor) harán una pausa para arreglar las cosas. O son reemplazados, y alguien más los arregla. En cualquier caso, el problema se aborda.

Sin embargo, cuando despliegas todo un ejército de agentes bien orquestados, no hay cuello de botella ni "sensación de dolor". Estos pequeños errores inicialmente intrascendentes se acumulan a un ritmo insostenible. Has sido sacado del circuito, sin saber que estos problemas aparentemente inofensivos se han convertido en un gigante. Para cuando realmente siente el dolor, generalmente es demasiado tarde.

Es solo cuando un día intenta agregar una nueva característica y descubre que la arquitectura actual del sistema (esencialmente una pila de errores) no puede adaptarse al cambio, o los usuarios comienzan a quejarse furiosamente porque la última versión tiene problemas, o peor aún, pérdida de datos.

Es en este punto que te das cuenta: Ya no puedes confiar en este código base.

Peor aún, las miles y miles de pruebas unitarias, pruebas instantáneas, pruebas de extremo a extremo generadas por los Agentes son igualmente poco confiables. La única manera de medir si el "sistema está funcionando correctamente" es a través de pruebas manuales.

Felicitaciones, te has cavado a ti mismo (y a tu empresa) en un agujero.

El mercader de la complejidad

Has perdido completamente de vista lo que está sucediendo en el sistema porque has entregado el control a los agentes. Y fundamentalmente, los agentes están en el negocio de "vender complejidad". Han visto un montón de decisiones arquitectónicas terribles en sus datos de formación y han reforzado continuamente estos patrones en el proceso de aprendizaje de refuerzo. Dejas que diseñen el sistema, y el resultado es el esperado.

Lo que terminas con un sistema altamente enrevesado, mezclando varias imitaciones pobres de las "mejores prácticas de la industria", y no impusiste ninguna restricción antes de que los problemas se salieran de control.

Pero los problemas no terminan ahí. Sus Agentes no comparten procesos de ejecución entre sí, no pueden ver el código base completo y no tienen conocimiento de las decisiones que usted u otros Agentes tomaron anteriormente. Por lo tanto, sus decisiones son siempre "locales".

Esto conduce directamente a los problemas antes mencionados: código duplicado copioso, estructuras demasiado abstraídas en aras de la abstracción, todo tipo de inconsistencias. Estos problemas se agravan, dando lugar en última instancia a un sistema irredimiblemente complejo.

Esto es en realidad bastante similar a una base de código de nivel empresarial escrita por humanos. La única diferencia es que este tipo de complejidad suele ser el resultado de años de acumulación: el dolor se extiende a un gran número de personas, cada una de las cuales no ha alcanzado el umbral de "debe arreglar", la organización en sí tiene una alta tolerancia, por lo que la complejidad y la organización "coevolucionan".

Sin embargo, en el caso de una combinación humano + agente, este proceso se acelerará en gran medida. Dos personas, más un montón de agentes, pueden alcanzar este nivel de complejidad en cuestión de semanas.

La Tasa de Retirada de Búsqueda Agente es Baja

Puede esperar que los agentes "limpien el desastre" por usted, lo ayuden a refactorizar, optimizar y limpiar el sistema. Pero el problema es que ya no pueden hacerlo.

Porque la base de código es demasiado grande y la complejidad es demasiado alta, y solo pueden ver una parte de ella. 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 arreglar el sistema, primero debe encontrar todo el código que necesita ser modificado, así como las implementaciones existentes que pueden ser reutilizadas. Este paso, lo llamamos búsqueda agente.

Cómo lo hace un Agente depende de las herramientas que le des: puede ser Bash + ripgrep, puede ser un índice de código de búsqueda, servicio LSP, base de datos vectorial...

Pero no importa qué herramientas se utilicen, la esencia es la misma: cuanto más grande sea la base de código, menor será la tasa de recuperación. Y una baja tasa de recuperación significa: el Agente no puede encontrar todo el código relevante y, naturalmente, no puede hacer las modificaciones correctas.

También es por esto que inicialmente aparecen esos errores menores de "olor a código", no encontró una implementación existente, por lo que reinventa la rueda, introduce inconsistencia. Eventualmente, estos problemas continuarán extendiéndose, superponiéndose y creciendo hasta convertirse en una "flor podrida" extremadamente compleja.

Entonces, ¿cómo podemos evitar todo esto?

Cómo debemos colaborar con los agentes (al menos por ahora)

Codificar con Agentes es como lidiar con un monstruo marino, con su velocidad de generación de código extremadamente rápida y ese tipo de inteligencia "intermitente pero ocasionalmente impresionante" que te atrae. A menudo pueden completar tareas simples a una velocidad asombrosa y de alta calidad. El verdadero problema comienza cuando se tiene la idea - "Esta cosa es demasiado poderosa, computadora, hacer el trabajo para mí!"

Entregar las tareas al propio Agente no es un problema. Las tareas de Good Agent generalmente tienen varias características: el alcance puede estar bien definido, no hay necesidad de entender todo el sistema; la tarea es de circuito cerrado, lo que significa que el agente puede evaluar los resultados por su cuenta; la salida no está en el camino crítico, solo algunas herramientas temporales o software para uso interno, no afectará a los usuarios reales o ingresos; o solo necesita un "pato de goma" para ayudarlo a pensar, esencialmente tomando sus ideas y teniendo una colisión con el conocimiento comprimido de Internet y los datos sintéticos.

Si se cumplen estas condiciones, entonces esta es una tarea adecuada para entregar al Agente, siempre que usted, como humano, siga siendo el último control de calidad.

Por ejemplo, ¿utilizando el método de investigación automática de Andrej Karpathy para optimizar el tiempo de inicio de la aplicación? Genial. Pero es esencial que entiendas que el código que escupe no está listo para la producción. La investigación automática es efectiva porque le has dado una función de aptitud para optimizar alrededor de una métrica específica (como el tiempo de inicio o la pérdida). Sin embargo, esta función de fitness solo cubre una dimensión muy estrecha. El Agente ignorará audazmente todas las métricas no incluidas en la función de fitness, como la calidad del código, la complejidad del sistema y, en algunos casos, incluso la corrección, si su función de fitness en sí misma es defectuosa.

La idea central es en realidad bastante simple: dejar que el agente haga las tareas aburridas y no educativas, o el trabajo exploratorio que nunca tuvo tiempo de probar. Luego, evalúe los resultados, elija las partes verdaderamente razonables y correctas y complete la implementación final. Por supuesto, también puede utilizar el agente para ayudar con este paso final.

Pero lo que realmente quiero enfatizar es: realmente, baje la velocidad un poco.

Date tiempo para pensar en lo que estás haciendo y por qué lo estás haciendo. Date la oportunidad de decir "no, no necesitamos esto". Establezca un límite claro para el agente: cuánto código puede generar por día, una cantidad que debe coincidir con su capacidad de revisión real. Todas las partes que determinan la "forma general" del sistema, como la arquitectura, las API, deben ser escritas por usted. Puedes usar el autocompletado para tener una idea de "escribir código a mano" o emparejar la programación con el agente, pero la clave es: debes estar en el código.

Porque escribir código tú mismo, o verlo construirse paso a paso, trae una especie de "fricción". Es esta fricción la que te hace 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 esto es precisamente lo que los modelos más avanzados aún no pueden reemplazar. Más despacio, aguanta algo de fricción – así es precisamente como aprendes y creces.

Al final, lo que tendrás sigue siendo un sistema mantenible, al menos no peor que antes de que apareciera el Agente. Sí, los sistemas pasados tampoco eran perfectos. Pero tus usuarios te lo agradecerán porque tu producto es “utilizable”, no una pila de chatarra tirada apresuradamente.

Tendrás menos características, pero serán más correctas. Aprender a decir "no" es en sí mismo una habilidad. También puedes dormir profundamente porque todavía sabes lo que está sucediendo en el sistema, todavía tienes el control. Es este entendimiento el que le permite abordar el problema de la búsqueda de agentes, haciendo que la salida del agente sea más confiable y requiera menos parches.

Cuando el sistema sale mal, puede ensuciarse las manos para arreglarlo; cuando el diseño estaba defectuoso desde el principio, puede entender el problema y refactorizarlo en una mejor forma. Que haya o no un agente no es tan importante, en realidad.

Todo esto requiere disciplina. Todo esto es inseparable de los humanos.

[Artículo original]