Los agentes de IA nunca se pierden, y eso está matando el impulso de refactorizar
AI Agents and the Refactoring That Never Happens
El autor, un ingeniero que trabaja con agentes de IA a diario, observa una tendencia alarmante: los equipos, incluso los más experimentados, han dejado de refactorizar sistemas complejos. Los agentes de IA no se pierden en el código enredado, por lo que la señal humana que solía disparar la refactorización —perderse en un sistema— ya no ocurre. Esto lleva a que los humanos pierdan la capacidad de entender y supervisar su propio código, confiando ciegamente en los agentes. El artículo argumenta que mantener el código limpio no solo es bueno para los humanos, sino también para la precisión y el costo de los agentes, y propone recuperar deliberadamente el hábito de preguntarse si es momento de refactorizar.
El agente nunca se pierde, por lo que la señal nunca se dispara.
- bunderbunder
No estoy de acuerdo con la afirmación de que "los agentes de IA nunca se pierden". Lo que he observado en cambio es que no experimentan la sensación de estar perdidos. Lo cual es bastante diferente.
Este verano pasé bastante tiempo usando un agente de codificación para ayudarme a desenredar un pipeline de procesamiento de datos profundo y complicado. Había sido construido por agentes, en una cantidad de tiempo notablemente corta. Pero también había quedado claro que estaba plagado de errores y producía muchos datos incorrectos.
Lo que descubrí rápidamente fue que más de la mitad de mis preguntas recibían respuestas muy equivocadas pero con gran confianza. E incluso una vez que finalmente había diagnosticado el problema en el que estaba trabajando, era difícil confiar en el agente para corregir errores. Como le costaba aún más rastrear los flujos de datos que a mí (aprovecho para proponer que más rápido no es necesariamente mejor), resultaba ser una especie de pata de mono. Sí, corregiría el error exacto que le pedía, pero normalmente introducía nuevos defectos en el proceso. Y sí, estaba teniendo esta lucha con todos los modelos más recientes y mejores.
Finalmente concluí que, en este código base, el agente estaba de hecho profunda y desesperadamente perdido. (edición: y probablemente este código se volvió tan malo en primer lugar porque los agentes que se usaron para construirlo habían estado perdidos durante un tiempo, pero no pudieron reconocer este problema y llamar la atención de sus operadores sobre ello.)
- joshstrange
Mientras tanto, estoy aquí refactorizando todo lo que puedo de años (o décadas) de código escrito por humanos. Convertir el desorden que heredé, ayudé a crear o construí encima en algo limpio y prístino podría ser mi uso favorito de los LLM. Lo mismo para proyectos personales, bases de código que evolucionaron durante muchos años cuando tenía tiempo y que no se mantuvieron tan "limpias" como desearía y que finalmente se han limpiado.
Siempre he querido que mi código sea limpio y fácil de seguir, pero la vida, los plazos, las prioridades cambiantes, etc., se han interpuesto en ese camino. Ahora finalmente puedo alcanzar mi nirvana personal.
Dicho esto, he tenido que alejar a los modelos de una abstracción demasiado pesada o similar porque hacía que el código fuera demasiado difícil de seguir.
- simonw
He descubierto que el acceso a agentes de codificación me ha ayudado a ser mucho menos tolerante con los malos patrones de código que se pueden refactorizar.
Refactorizar solía tener un costo muy real: era una cantidad sustancial de tiempo que tenía que apartarse de trabajar en nuevas funciones.
Ahora puedo detectar una posible refactorización, lanzar un prompt en un agente de codificación asíncrono (o en un worktree o lo que sea), y luego volver 20 minutos después y aceptarlo, modificarlo un poco o abandonarlo. Me cuesta casi nada.
- joshka
Mucho de esto parece reducirse al entrenamiento de los agentes para producir código que satisfaga los diversos benchmarks combinado con reacciones a cosas que antes eran desadaptativas. Es decir, cosas que fueron explícitamente entrenadas fuera del modelo en el post-entrenamiento. Creo que faltan muchos principios de ingeniería de software a largo plazo que no parecen estar integrados en la forma en que los modelos tienden a escribir código por defecto.
Tengo algunas especulaciones de que quizás las personas que hacen el post-entrenamiento de los modelos tienden a ser investigadores más jóvenes que no han trabajado en sistemas de software grandes y complejos, por lo que su gusto no está tan desarrollado en este aspecto sobre qué cosas son importantes aquí.
Pero esta es un área que se puede dirigir con instrucciones tempranas apropiadas ("Al elegir compensaciones de implementación, construye para la mantenibilidad a largo plazo y la comprensibilidad del código en lugar de implementar solo el código exacto necesario para resolver los problemas. etc. la cadena de pensamiento a menudo incluye información que tendría que repetirse en una futura sesión de agente, asegúrate de persistirla en código o documentación externa para que futuras sesiones y la comprensión del usuario sean respetadas.")
También se puede hacer como un paso posterior al cambio con efectos similares. Y puedes usar tus agentes para construir esta capa en tu modus operandi general para lidiar con los crímenes del código generado. Pero una de las cosas que todos los laboratorios de IA deberían estar haciendo es mirar AGENTS.md en proyectos reales como expresiones duras de qué modos de fallo tienen los proyectos reales […]
- moezd
Los agentes de IA se pierden todo el tiempo, particularmente si la base de código ya está descontrolada y en expansión.
Tu disciplina solo da frutos si ya entiendes tu código y/o estableces una línea base clara para tus estándares antes de lanzarte a una manía de desarrollo de funciones. Y debe aplicarse en cada turno, o la manguera de fuego de generación de código derriba fácilmente la puerta principal.