Nota del editor: En un momento en que la IA generativa se está integrando rápidamente en la ingeniería de software, el sentimiento de la industria está pasando de un "asombro por las capacidades" a una "ansiedad por la eficiencia". Escribir código no lo suficientemente rápido, no usarlo lo suficiente o no automatizarlo por completo parecen generar presión por la posibilidad de quedarse obsoleto. Pero cuando los Agent de codificación comienzan a entrar en entornos de producción, surgen problemas más reales: los errores se amplifican, la complejidad se descontrola, los sistemas se vuelven gradualmente incomprensibles, y las mejoras en eficiencia no se traducen proporcionalmente en mejoras de calidad.
Este artículo, basado en la práctica de primera línea, ofrece una reflexión serena sobre este auge de la "codificación agentica". El autor señala que los Agent no aprenden de los errores como los humanos; sin cuellos de botella ni mecanismos de retroalimentación, los pequeños problemas se amplifican rápidamente. Además, en bases de código complejas, su perspectiva local y su capacidad de recuperación limitada agravan aún más la confusión estructural del sistema. La esencia de estos problemas no radica en la tecnología en sí, sino en que los humanos, impulsados por la ansiedad, ceden prematuramente el juicio y el control.
Por lo tanto, en lugar de caer en la ansiedad de "si debemos adoptar la IA por completo", es mejor recalibrar la relación entre las personas y las herramientas: que los Agent se encarguen de tareas locales y controlables, mientras que el diseño del sistema, el control de calidad y las decisiones clave se mantienen firmemente en manos humanas. En este proceso, "desacelerar" se convierte en una habilidad, que significa que aún comprendes el sistema, puedes tomar decisiones y mantienes el control sobre tu trabajo.
En una era de evolución constante de herramientas, lo verdaderamente escaso quizás no sea la capacidad de generar más rápido, sino el criterio para juzgar la complejidad y la firmeza para elegir entre eficiencia y calidad.
A continuación, el texto original:
Hace aproximadamente un año, comenzaron a aparecer Agent de codificación que realmente podían ayudarte a "hacer proyectos completos de principio a fin". Antes también existían herramientas como Aider o las primeras versiones de Cursor, pero se parecían más a asistentes que a "agentes". Las nuevas herramientas son extremadamente atractivas, y mucha gente ha dedicado mucho tiempo libre a realizar todos esos proyectos que siempre quiso hacer pero para los que nunca tuvo tiempo.
Creo que esto no tiene nada de malo. Hacer cosas en el tiempo libre ya es divertido de por sí, y la mayoría de las veces tampoco necesitas preocuparte demasiado por la calidad del código o su mantenibilidad. También te brinda un camino para aprender nuevos stacks tecnológicos.
Durante las vacaciones de Navidad, Anthropic y OpenAI incluso repartieron algunos "créditos gratuitos", atrayendo a la gente como una máquina tragaperras. Para muchos, esta fue la primera vez que experimentaron la magia de que "un Agent escriba código". Cada vez más personas se están sumando.
Hoy, los Agent de codificación también están comenzando a entrar en las bases de código de producción. Doce meses después, empezamos a ver las consecuencias de este "progreso". Aquí está mi opinión actual.
Todo está roto
Aunque en su mayoría son experiencias anecdóticas, el software actual da la sensación de que "puede romperse en cualquier momento". Una disponibilidad del 98% está pasando de ser la excepción a la norma, incluso para servicios grandes. Las interfaces de usuario están llenas de bugs absurdos, del tipo que cualquier equipo de QA detectaría de un vistazo.
Admito que esta situación ya existía antes de la llegada de los Agent. Pero ahora, el problema se está acelerando notablemente.
No podemos ver lo que sucede dentro de las empresas, pero ocasionalmente se filtra información, como ese presunto "apagón de AWS causado por IA". Amazon Web Services "aclaró" la historia inmediatamente después, pero acto seguido inició internamente un plan de reestructuración de 90 días.
Satya Nadella (CEO de Microsoft) también ha estado enfatizando recientemente que cada vez hay más código en la empresa escrito por IA. Aunque no hay evidencia directa, ciertamente existe la sensación de que la calidad de Windows está decayendo. Incluso a juzgar por algunos blogs publicados por la propia Microsoft, parecen dar esto por sentado.
Aquellas empresas que afirman que "el 100% del código del producto es generado por IA" casi siempre producen los peores productos que uno pueda imaginar. No es personal, pero fugas de memoria de gigabytes, interfaces de usuario caóticas, funcionalidades incompletas, cierres inesperados frecuentes... esto no es para nada el "aval de calidad" que ellos creen que es, y mucho menos un ejemplo positivo de "dejar que el Agent haga todo por ti".
En privado, se escucha cada vez más, tanto en grandes empresas como en pequeños equipos, que dicen una cosa: se han metido en un callejón sin salida debido a que "los Agent escriben código". Sin revisiones de código, delegando las decisiones de diseño al Agent, y añadiendo un montón de funciones que nadie necesita: el final, naturalmente, no es bueno.
Por qué no deberíamos usar así a los Agent
Casi hemos abandonado toda disciplina de ingeniería y juicio subjetivo, cayendo en un modo de trabajo "adictivo": el único objetivo es generar la mayor cantidad de código en el menor tiempo posible, sin considerar en absoluto las consecuencias.
Estás construyendo una capa de orquestación para dirigir un ejército de Agent automatizados. Instalas Beads, sin saber que esencialmente es casi un "malware" que no se puede desinstalar. Solo porque en internet dicen que "todo el mundo lo hace". Si no lo haces, "estás perdido" (ngmi).
Te consumes en un "ciclo recursivo interminable".
Mira: Anthropic usó un grupo de Agent para hacer un compilador de C, aunque todavía tiene problemas, pero la próxima generación de modelos lo arreglará, ¿verdad?
Mira también: Cursor usó un gran grupo de Agent para hacer un navegador, aunque actualmente es básicamente inusable y necesita intervención manual de vez en cuando, pero la próxima generación de modelos lo resolverá, ¿verdad?
"Distribuido", "divide y vencerás", "sistemas autónomos", "fábricas oscuras", "resolver el problema del software en seis meses", "SaaS está muerto, mi abuela acaba de montar un Shopify con Claw"...
Estas narrativas suenan muy bien.
Por supuesto, este método para ese proyecto secundario que casi nadie usa (incluido tú mismo), quizás "funciona". Tal vez, realmente exista un genio que pueda usar este método para crear un producto de software que no sea basura y que la gente use de verdad. Si eres esa persona, te admiro sinceramente.
Pero al menos en mi círculo de desarrolladores, no he visto ningún caso en el que este método funcione realmente. Claro, quizás solo seamos todos muy malos.
Los errores se acumulan sin aprendizaje, sin cuellos de botella y con explosiones retardadas
El problema de los Agent es: cometen errores. Esto en sí mismo no es nada, los humanos también cometen errores. Pueden ser solo errores de corrección, fáciles de identificar y reparar, y se solucionan añadiendo una prueba de regresión. También pueden ser malos olores de código que un linter no detecta: aquí un método inútil, allá un tipo poco razonable, código duplicado, etc. Por separado, estos son inofensivos, los desarrolladores humanos también cometen este tipo de pequeños errores.
Pero la "máquina" no es humana. Después de cometer el mismo error varias veces, un humano generalmente aprende a no repetirlo: ya sea porque lo regañaron o porque lo corrigió en un verdadero proceso de aprendizaje.
Y el Agent no tiene esa capacidad de aprendizaje, al menos por defecto no la tiene. Cometerá el mismo error una y otra vez, e incluso puede "crear" combinaciones maravillosas de diferentes errores basándose en los datos de entrenamiento.
Por supuesto, puedes intentar "entrenarlo": escribir reglas en AGENTS.md para que no vuelva a cometer ese error; diseñar un sistema de memoria complejo para que consulte errores históricos y mejores prácticas. Esto puede ser efectivo para ciertos tipos específicos de problemas. Pero前提是 – primero debes observar que cometió ese error.
La diferencia más crucial es: el humano es un cuello de botella, el Agent no.
Un humano no puede escupir veinte mil líneas de código en unas pocas horas. Incluso con una frecuencia de errores no baja, solo puede introducir una cantidad limitada de errores por día, y su acumulación es lenta. Normalmente, cuando el "dolor causado por los errores" se acumula hasta cierto punto, el humano (por aversión instintiva al dolor) se detendrá para repararlos. O la persona es reemplazada, y otro viene a reparar. En resumen, los problemas se abordan.
Pero cuando usas todo un ejército de Agent orquestados, no hay cuello de botella, ni "sensación de dolor". Estos pequeños errores aparentemente insignificantes se acumulan a un ritmo insostenible. Has sido eliminado del ciclo, y ni siquiera sabes que estos pequeños problemas aparentemente inofensivos han crecido hasta convertirse en un monstruo. Cuando finalmente sientes el dolor,往往 ya es demasiado tarde.
Hasta que un día, quieres agregar una nueva función y descubres que la arquitectura actual del sistema (esencialmente una acumulación de errores) no admite modificaciones; o los usuarios comienzan a quejarse frenéticamente porque la última versión falló, o incluso perdió datos.
Entonces te das cuenta: ya no puedes confiar en este código.
Peor aún, las miles de pruebas unitarias, pruebas snapshot, pruebas end-to-end que hiciste generar al Agent, también han dejado de ser confiables. La única forma de determinar si "el sistema funciona correctamente" es probarlo manualmente.
Felicidades, te has metido (y a la empresa) en un gran problema.
Vendedores de complejidad
Ya no tienes idea de lo que está pasando en el sistema, porque le diste el control al Agent. Y el Agent, esencialmente, está "vendiendo complejidad". Han visto muchas malas decisiones arquitectónicas en sus datos de entrenamiento, y refuerzan constantemente estos patrones durante el proceso de aprendizaje por refuerzo. Dejas que diseñe el sistema, y el resultado es predecible.
Al final obtienes: un sistema extremadamente complejo, una mezcla de imitaciones torpes de las "mejores prácticas de la industria", y no impusiste restricciones antes de que los problemas se salieran de control.
Pero el problema no termina ahí. Tus Agent no comparten el proceso de ejecución entre ellos, no ven la base de código completa, y no comprenden las decisiones que tú u otros Agent tomaron previamente. Por lo tanto, sus decisiones siempre son "locales".
Esto conduce directamente a los problemas mencionados anteriormente: montones de código duplicado, estructuras abstractas por abstracción, varias inconsistencias. Estos problemas se acumulan,最终 formando un sistema complejo e irreparable.
Esto en realidad se parece mucho a las bases de código empresariales escritas por humanos. Solo que esa complejidad suele ser el resultado de una acumulación a lo largo de años: el dolor se distribuye entre muchas personas, nadie llega individualmente al punto crítico de "tener que reparar", y la tolerancia de la organización en sí es alta, por lo que la complejidad y la organización "coevolucionan".
Pero en una combinación de humanos + Agent, este proceso se acelera enormemente. Dos personas, con un montón de Agent, pueden alcanzar esta complejidad en semanas.
La recuperación (recall) de la búsqueda agentica es baja
Podrías depositar tus esperanzas en que el Agent "arregle el desastre", te ayude a refactorizar, optimizar, limpiar el sistema. Pero el problema es: ya no pueden hacerlo.
Porque la base de código es demasiado grande, la complejidad demasiado alta, y ellos solo pueden ver localmente. Esto no es solo que la ventana de contexto sea insuficiente, o que los mecanismos de contexto largo fallen frente a millones de líneas de código. El problema es más sutil.
Antes de que el Agent intente reparar el sistema, primero debe encontrar todo el código que necesita modificar, así como las implementaciones existentes que puede reutilizar. Este paso, lo llamamos búsqueda agentica (agentic search).
Cómo hace esto el Agent depende de las herramientas que le des: puede ser Bash + ripgrep, puede ser un índice de código consultable, un servicio LSP, una base de datos vectorial...
Pero no importa qué herramienta uses, la esencia es la misma: cuanto más grande la base de código, más baja la recuperación (recall). Y una recuperación baja significa: el Agent no puede encontrar todo el código relevante, y por lo tanto no puede hacer las modificaciones correctas.
Esta es también la razón por la que aparecieron esos pequeños errores de "mal olor" al principio: no encontró la implementación existente, así que reinventó la rueda, introduciendo inconsistencias.最终, estos problemas se difunden, se acumulan, y florece una "flor podrida" extremadamente compleja.
¿Cómo podemos evitar todo esto?
Cómo deberíamos colaborar con los Agent (al menos por ahora)
Los Agent de codificación son como sirenas, te atraen con su velocidad extremadamente rápida de generación de código y esa inteligencia "intermitente pero ocasionalmente impresionante". A menudo pueden completar algunas tareas simples con una velocidad asombrosa y alta calidad. Los problemas reales comienzan cuando surge la idea: "¡esto es demasiado potente, computadora, haz el trabajo por mí!".
Delegar tareas al Agent en sí no tiene nada de malo. Una buena tarea para un Agent suele tener varias características: su alcance puede estar bien delimitado, no necesita entender todo el sistema; la tarea forma un circuito cerrado, es decir, el Agent puede evaluar el resultado por sí mismo; la salida no es crítica, son solo algunas herramientas temporales o software de uso interno, que no afecta a usuarios reales o ingresos; o simplemente necesitas un "pato de goma" para辅助思考 – esencialmente, chocar tus ideas con el conocimiento comprimido de internet y datos sintéticos.
Si se cumplen estas condiciones, entonces esta es una tarea adecuada para el Agent,前提是, tú, como humano, sigues siendo el garante final de la calidad.
Por ejemplo, ¿usar el método auto-research propuesto por Andrej Karpathy para optimizar el tiempo de inicio de una aplicación? Genial. Pero前提是 sabes claramente que el código que escupe no es apto para producción en absoluto. Auto-research funciona porque le das una función de evaluación, permitiéndole optimizar en torno a una métrica (como el tiempo de inicio o la pérdida). Pero esta función de evaluación solo cubre una dimensión muy estrecha. El Agent ignorará descaradamente todas las métricas que no estén en la función de evaluación, como la calidad del código, la complejidad del sistema, e incluso en algunos casos la corrección – si tu función de evaluación本身 está mal.
La idea central es muy simple: deja que el Agent haga las cosas aburridas, las que no te enseñan nada nuevo, o esos trabajos exploratorios para los que nunca tienes tiempo. Luego evalúas los resultados, seleccionas las partes que son realmente razonables y correctas, y completas la implementación final. Por supuesto, este último paso también puedes hacerlo con la ayuda del Agent.
Pero quiero enfatizar más: de verdad, hay que desacelerar un poco.
Date tiempo para pensar, qué estás haciendo exactamente y por qué. Date la oportunidad de decir "no", "no, esto no lo necesitamos". Establece un límite claro para el Agent: cuánto código puede generar por día, esta cantidad debe coincidir con tu capacidad real de revisión. Todas las partes que determinan la "forma general" del sistema, como la arquitectura, las API, etc., deberías escribirlas tú mismo. Puedes usar el autocompletado para tener una "sensación de código escrito a mano", o puedes programar en pareja con el Agent, pero la clave es: debes estar en el código.
Porque, escribir código personalmente, o ver cómo se construye paso a paso, este proceso en sí mismo genera una sensación de "fricción". Es esta fricción la que te hace entender más claramente qué quieres hacer, cómo funciona el sistema, cómo se "siente" en general. Aquí es donde entra en juego la experiencia y el "gusto", y esto es precisamente lo que los modelos más avanzados actualmente aún no pueden reemplazar. Desacelerar, soportar un poco de fricción, es precisamente tu forma de aprender y crecer.
Al final, obtendrás un sistema que sigue siendo mantenible – al menos no peor que antes de que existieran los Agent. Sí, los sistemas del pasado tampoco eran perfectos. Pero tus usuarios te lo agradecerán, porque tu producto es "usable", y no un montón de basura improvisada.
Harás menos funciones, pero más correctas. Aprender a decir "no" es en sí mismo una habilidad. También podrás dormir tranquilo, porque al menos aún sabes qué está pasando en el sistema, sigues teniendo la iniciativa. Es esta comprensión la que te permite compensar el problema de recuperación de la búsqueda agentica, haciendo que la salida del Agent sea más confiable y necesite menos parches.
Cuando el sistema falle, puedes intervenir personalmente para repararlo; cuando el diseño no sea adecuado desde el principio, también podrás entender el problema y refactorizarlo en una mejor forma. Que haya o no Agent, en realidad no es tan importante.
Todo esto requiere disciplina. Todo esto,离不开人 (no puede prescindir de las personas).
