Título original: Thoughts on slowing the fuck down
Autor original: Mario Zechner
Traducción: Peggy，BlockBeats

Nota editorial: En el momento actual en que la IA generativa acelera la ingeniería de software, el ánimo de la industria se está desplazando de “maravilla por las capacidades” hacia “ansiedad por la eficiencia”. No escribir lo suficientemente rápido, no usar lo suficiente, o no automatizar de manera completamente exhaustiva, parece generar la presión de que uno podría quedarse atrás. Pero cuando los agentes de codificación entran de verdad en entornos de producción, empiezan a surgir problemas más realistas: los errores se amplifican, la complejidad se sale de control y el sistema va volviéndose cada vez menos comprensible. El aumento de eficiencia no se traduce de forma proporcional en mejora de calidad.

Este artículo se basa en práctica de primera línea y ofrece una reflexión serena sobre esta oleada de “agentic coding”. El autor señala que un agente no aprende a partir de los errores como lo hace un humano. En ausencia de cuellos de botella y mecanismos de retroalimentación, los problemas pequeños se amplifican rápidamente; y en bases de código complejas, la perspectiva local y la capacidad de recuperación limitada solo agravan aún más el caos estructural del sistema. La esencia de estos problemas no reside en la tecnología en sí, sino en que los humanos, movidos por la ansiedad, entregan demasiado pronto la toma de decisiones y el control.

Por eso, en lugar de caer en la ansiedad de “¿hay que abrazar completamente la IA?”, conviene recalibrar la relación entre humanos y herramientas: hacer que el agente asuma tareas parciales y controlables, mientras que el diseño del sistema, el control de calidad y las decisiones clave permanezcan firmemente en tus manos. En este proceso, “ir más despacio” se convierte en una capacidad: significa que sigues entendiendo el sistema, puedes tomar decisiones y aún mantienes una sensación de control sobre el trabajo.

En una era en la que las herramientas siguen evolucionando, quizá lo verdaderamente escaso no sea la capacidad de generación más rápida, sino la habilidad para juzgar la complejidad y la determinación de elegir entre eficiencia y calidad.

A continuación, el texto original:

La cara de la tortuga, esa es mi expresión cuando veo esta industria

Hace aproximadamente un año aparecieron los agentes de codificación que realmente pueden ayudarte a “hacer un proyecto completo de principio a fin”. Antes también había herramientas como Aider y las primeras versiones de Cursor, pero eran más bien asistentes, no “agentes”. La nueva generación de herramientas resulta sumamente atractiva, y mucha gente también invirtió una gran cantidad de tiempo libre en convertir en realidad esos proyectos que siempre habían querido hacer pero no habían tenido tiempo.

Creo que eso por sí solo no está mal. Es feliz dedicar tiempo libre a hacer cosas, y la mayoría de las veces tampoco necesitas preocuparte demasiado por la calidad del código y la mantenibilidad. Además, te abre una ruta para aprender un nuevo stack de tecnología.

Durante las vacaciones de Navidad, Anthropic y OpenAI también lanzaron algunos “cupos gratuitos”, atrayendo a la gente como si fueran máquinas tragamonedas. Para mucha gente, fue la primera vez que experimentó de verdad la magia de “un agente escribiendo código”. Había cada vez más participantes.

Hoy en día, los agentes de codificación también empiezan a entrar en repositorios de código en producción. Después de 12 meses, empezamos a ver las consecuencias de este “progreso”. Esto es lo que pienso actualmente.

Todo se estropea

Aunque la mayoría de esto son experiencias y comentarios personales, el software de verdad ahora da la sensación de que “podría romperse en cualquier momento”. El 98% de disponibilidad está pasando de ser una excepción a convertirse en la norma, incluso en servicios grandes. Las interfaces de usuario están llenas de bugs absurdos, de esos que un equipo de QA debería detectar de inmediato.

Admito que esto ya existía antes de que aparecieran los agentes. Pero ahora, los problemas se aceleran claramente.

No podemos ver la situación real dentro de las empresas, pero a veces se filtra algo: por ejemplo, aquel rumor sobre un “apagón en AWS causado por IA”. Amazon Web Services lo “corrigió” de inmediato en la primera oportunidad, pero luego, en seguida, inició internamente un plan de reorganización de 90 días.

Satya Nadella (CEO de Microsoft) también ha venido insistiendo recientemente en que cada vez más código en la empresa es escrito por IA. Aunque no haya evidencia directa, sí se tiene esa sensación: la calidad de Windows está cayendo. Incluso en algunos blogs publicados por Microsoft por sí mismo, pareciera que ya lo dan por hecho.

Las empresas que afirman “nuestro producto es 100% generado por código de IA” casi siempre están produciendo los peores productos imaginables. No es que lo estén haciendo “a propósito” contra alguien, pero con frecuencia aparecen fugas de memoria por GB, caos en la interfaz, funciones incompletas, caídas frecuentes… Todo eso no es en absoluto el “respaldo de calidad” que ellos creen, ni es un buen ejemplo positivo de “dejar que el agente haga todo por ti”.

En privado, cada vez oirás más que tanto grandes empresas como equipos pequeños dicen una misma cosa: han sido empujados a un callejón sin salida por “agentes escribiendo código”. Sin revisiones de código, entregando decisiones de diseño al agente y apilando un montón de funcionalidades que nadie necesita: el resultado naturalmente no puede ser bueno.

Por qué no deberíamos usar agentes así

Casi hemos abandonado toda disciplina de ingeniería y el juicio subjetivo, y nos hemos metido en una forma “adictiva” de trabajar: el único objetivo es generar la mayor cantidad de código en el menor tiempo posible, y sobre las consecuencias no se piensa en absoluto.

Estás montando una capa de orquestación para dirigir un ejército de agentes automatizados. Pusiste Beads, pero no tienes idea de que en esencia es casi un “malware” que no se puede eliminar. Solo porque en internet dicen que “todos lo hacen”. Si no lo haces, “vas a estar jodido” (ngmi).

Te consumes a ti mismo en un bucle tipo “muñecas rusas”.

Mira: Anthropic usó un grupo de agentes para hacer un compilador de C; aunque ahora todavía haya problemas, la siguiente generación de modelos seguramente lo arreglará, ¿cierto?

Mira: Cursor usa un montón de agentes para hacer un navegador; aunque ahora básicamente no se puede usar y requiere que una persona intervenga manualmente de vez en cuando, la siguiente generación de modelos seguramente lo hará bien, ¿cierto?

“Distribuido”, “divide y vencerás”, “sistemas autónomos”, “fábrica con luces apagadas”, “resolver problemas de software en seis meses”, “SaaS murió, mi abuela acaba de montar un Shopify con Claw”……

Estas narrativas suenan genial.

Por supuesto, este enfoque puede funcionar para tu tipo de side project que casi nadie usa (incluyéndote a ti). Quizá, sí exista un genio que pueda hacer con este método un producto de software que no sea basura y que realmente sea utilizado por la gente. Si eres esa persona, de verdad te admiro.

Pero al menos en el círculo de desarrolladores que tengo cerca, aún no he visto casos reales en los que este método funcione de verdad. Claro, tal vez es que todos somos demasiado torpes.

Los errores se acumulan por falta de aprendizaje, ausencia de cuellos de botella y explosiones de latencia

El problema con los agentes es que cometen errores. Eso, en sí mismo, no tiene nada de malo; los humanos también cometemos errores. Quizá sean errores de corrección que son fáciles de identificar y de reparar, y con un poco de pruebas de regresión se vuelve más estable. O quizá sean “olores” de código que el linter no detecta: un método inútil por aquí, un tipo poco razonable por allá, y código duplicado, etc. Tomados por separado, estos errores no parecen gran cosa; un desarrollador humano también comete este tipo de pequeños errores.

Pero “la máquina” no es una persona. Después de repetir los mismos errores varias veces, normalmente el humano aprende y deja de cometerlos: o porque alguien lo reprende, o porque en el proceso real de aprendizaje se corrige.

Y un agente no tiene esa capacidad de aprendizaje; al menos, por defecto no la tiene. Repetirá una y otra vez los mismos errores, e incluso podría “crear” combinaciones de errores distintos y curiosos basados en los datos de entrenamiento.

Por supuesto, puedes intentar “entrenarlo”: escribir reglas en AGENTS.md para que no vuelva a cometer esos errores; diseñar un sistema de memoria complejo para que consulte errores históricos y mejores prácticas. En algunos tipos específicos de problemas, esto de hecho funciona. Pero el requisito es—primero debes observar que cometió ese error.

La diferencia más crítica es esta: los humanos tienen cuellos de botella, los agentes no.

Los humanos no pueden escupir veinte mil líneas de código en unas pocas horas. Aunque la frecuencia de errores no sea baja, en un día solo se introducen una cantidad limitada de errores, y la acumulación es lenta. Normalmente, cuando el “dolor” causado por los errores se acumula hasta cierto punto, los humanos (por instinto de rechazo al dolor) se detienen para arreglar algo. O bien el humano es reemplazado y otra persona se encarga de corregirlo. En cualquier caso, el problema se gestiona.

Pero cuando usas toda una “escuadrilla” de agentes orquestados, no hay cuellos de botella ni “sensación de dolor”. Esos pequeños errores que antes eran insignificantes se acumulan a un ritmo insostenible. Ya te sacaron del bucle: ni siquiera sabes que esos problemas aparentemente inofensivos ya se han convertido en una mole. Y cuando finalmente sientes el dolor, suele ser demasiado tarde.

Hasta un día en que quieres agregar una nueva funcionalidad y descubres que la arquitectura actual del sistema (en esencia, ya es una acumulación de errores) no lo puede soportar en absoluto; o cuando los usuarios empiezan a quejarse ferozmente porque la última versión rompió algo e incluso perdió datos.

Entonces te das cuenta: ya no puedes confiar en ese código.

Peor aún: ni las miles de pruebas unitarias, pruebas de snapshot y pruebas end-to-end generadas por el agente vuelven a ser confiables. La única forma que queda para juzgar si “el sistema funciona bien” es el testing manual.

Felicidades: te has metido un agujero tú (y tu empresa).

Los vendedores de complejidad

Ya ni siquiera sabes qué está pasando en tu sistema, porque entregaste el control al agente. Y, en esencia, un agente está “vendiendo complejidad”. Han visto en los datos de entrenamiento un gran número de malas decisiones de arquitectura, y en el proceso de aprendizaje por refuerzo también se refuerzan continuamente esos patrones. Le pides que diseñe el sistema y ya puedes imaginarte el resultado.

Al final obtienes: un conjunto entero de sistemas extremadamente complejos, mezclados con imitaciones torpes de “mejores prácticas de la industria”, y antes de que el problema se descontrole no pones límites.

Pero el problema no termina ahí. Tus agentes no comparten el proceso de ejecución entre sí, no ven el repositorio completo y tampoco conocen las decisiones que tú u otros agentes tomaron antes. Por lo tanto, sus decisiones siempre son “parciales”.

Esto deriva directamente en los problemas mencionados antes: mucho código repetido, estructuras “abstractas por el bien de la abstracción”, y todo tipo de inconsistencias. Estos problemas se van sumando y, finalmente, forman un sistema complejo e irrecuperable.

En realidad, esto se parece mucho a los repositorios de código empresariales escritos por humanos. Solo que esa complejidad normalmente es el resultado de años de acumulación: el dolor se dispersa entre muchas personas; cada individuo no llega al umbral “debo arreglarlo”; la organización en sí tiene alta tolerancia, y así la complejidad evoluciona en “simbiogénesis” con la organización.

Pero con la combinación de humanos + agentes, este proceso se acelera enormemente. Dos personas, más un montón de agentes, pueden alcanzar esa complejidad en pocas semanas.

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

Quizá esperas que los agentes te “resuelvan el desorden”, te ayuden a refactorizar, optimizar y dejar el sistema limpio. Pero el problema es que ya no pueden hacerlo.

Porque el repositorio es demasiado grande y la complejidad es demasiado alta, y ellos siempre solo pueden ver una parte. Esto no es solo que la ventana de contexto no alcance o que el mecanismo de contexto largo falle ante millones de líneas de código. El problema es más sutil.

Antes de que el agente intente arreglar el sistema, primero debe encontrar todo el código que necesita modificarse y también las implementaciones existentes que pueda reutilizar. Llamamos a este paso “agentic search” (búsqueda del agente).

Cómo hace esta tarea el agente depende de las herramientas que tú le das: puede ser Bash + ripgrep, o un índice de código consultable, servicios LSP, una base de datos vectorial……

Pero, sin importar qué herramientas uses, es igual en lo esencial: cuanto más grande es el repositorio, menor es la tasa de recuperación. Una tasa de recuperación baja significa que el agente no puede encontrar todo el código relacionado y, por tanto, tampoco puede hacer modificaciones correctas.

Por eso aparecen esos pequeños errores de “olor a código” al principio: como no encontró implementaciones existentes, repite la creación de la rueda e introduce inconsistencias. Finalmente, estos problemas se van extendiendo y acumulando, formando una flor extremadamente compleja de “malos parches”.

Entonces, ¿cómo evitamos todo esto?

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

Los agentes de codificación son como las sirenas: con una velocidad de generación de código muy rápida y una inteligencia “intermitente pero que a veces sorprende”, te atraen. A menudo logran completar algunas tareas simples a una velocidad y calidad sorprendentes. El problema real empieza cuando aparece en tu mente esa idea: “Esto es demasiado fuerte; computadora, ¡haz el trabajo por mí!”

Encargar tareas al agente en sí no tiene por qué estar mal. Las buenas tareas para agentes suelen tener varias características: el alcance puede acotarse bien y no requieren entender todo el sistema; la tarea es de ciclo cerrado, es decir, el agente puede evaluar el resultado por sí mismo; la salida no es parte del camino crítico, sino herramientas temporales o software para uso interno que no afecta usuarios reales ni ingresos; o, alternativamente, solo necesitas un “pato de goma” para ayudarte a pensar, básicamente una forma de chocar tus ideas con el conocimiento comprimido de internet y con datos sintetizados.

Si se cumplen esas condiciones, entonces esa es una tarea adecuada para un agente, con el requisito de que tú, como humano, sigues siendo el responsable final del control de calidad.

Por ejemplo, ¿optimizar el tiempo de arranque de una aplicación con el método auto-research propuesto por Andrej Karpathy? Bien. Pero con la condición de que tienes claro que el código que escupe no tiene disponibilidad real para producción. auto-research funciona porque tú le das una función de evaluación para que optimice alrededor de cierto indicador (como el tiempo de inicio o loss). Pero esa función de evaluación solo cubre una dimensión muy estrecha. El agente ignorará con argumentos todo lo que no esté dentro de la función de evaluación: la calidad del código, la complejidad del sistema e incluso, en algunos casos, la corrección. Y si tu función de evaluación ya tiene problemas, entonces peor.

La idea central es muy simple: deja que el agente haga esas cosas aburridas que no te harán aprender nada nuevo, o ese trabajo exploratorio que en realidad no tenías tiempo de intentar. Luego evalúas el resultado tú: eliges la parte realmente razonable y correcta, y luego terminas la implementación final. Claro que al final también puedes usar un agente para esa última parte.

Pero lo que más quiero recalcar es: de verdad, hay que ir más despacio un poco.

Date tiempo para pensar en qué estás haciendo y por qué lo estás haciendo. Date la oportunidad de decir “no”: “No, no necesitamos esto.” Ponle al agente un límite claro: cuántas líneas de código puede generar por día; esa cantidad debería corresponder con tu capacidad real de revisarlas. Las partes que determinan “la forma general” del sistema —como la arquitectura, las API, etc.— deberían escribirse por ti mismo. Puedes usar autocompletado para conseguir un poco la sensación de “código escrito a mano”, o puedes programar en pareja con el agente, pero lo clave es: debes estar dentro del código.

Porque escribir el código tú mismo, o verlo construirse paso a paso, te aporta una especie de “sensación de fricción”. Es precisamente esa fricción la que te hace entender con más claridad qué quieres hacer, cómo funciona el sistema y cuál es el “feeling” general. Ahí es donde entran la experiencia y el “buen gusto”. Y justo eso es algo que los modelos más avanzados de hoy todavía no pueden reemplazar. Ir más despacio, soportar un poco de fricción, es precisamente la manera en la que aprendes y creces.

Al final, obtendrás un sistema que sigue siendo mantenible —al menos no peor que antes de la aparición de los agentes. Sí, el sistema anterior tampoco era perfecto. Pero tus usuarios te lo agradecerán, porque tu producto es “útil”, no una pila de basura hecha a la carrera.

Vas a hacer menos funcionalidades, pero más correctas. Aprender a decir “no” es en sí una capacidad. También puedes dormir tranquilo, porque al menos sigues sabiendo qué está pasando en el sistema y sigues teniendo el control. Es precisamente esta comprensión lo que te permite compensar el problema de baja recuperación del agentic search, haciendo que la salida del agente sea más confiable y necesite menos parches.

Cuando el sistema falla, puedes ponerte a repararlo tú mismo; cuando el diseño es poco razonable desde el inicio, también puedes entender el problema y reestructurarlo en una mejor forma. En cuanto a si hay o no agentes, en realidad no es tan importante.

Todo esto necesita disciplina. Todo esto no se puede separar de los humanos.

[Enlace al texto original]

Haz clic para conocer las vacantes en Lydm BlockBeats

Bienvenido a unirte a la comunidad oficial de Lydm BlockBeats:

Grupo de suscripción de Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia