La codificación autónoma está pasando de mejores indicaciones a mejores sistemas de control. El cambio importante es que los ingenieros están aprendiendo a envolver agentes en objetivos, evaluadores, bucles y artefactos que les permiten seguir trabajando después de que el humano deja de escribir.
Esto importa porque la mayoría del trabajo serio de ingeniería abarca horizontes largos: requisitos ambiguos, restricciones ocultas, fallos parciales, contexto cambiante y verificación repetida. La nueva frontera es diseñar el sistema alrededor del agente para que pueda planificar, ejecutar, verificar su trabajo, recuperarse de errores y seguir progresando sin una dirección humana constante.
Este artículo se basa en una sesión de la Academia DAIR.AI sobre agentes de codificación autónomos de larga duración, donde expliqué el modo /goal de Claude Code, el comando /loop más reciente, verificadores, artefactos y patrones de orquestación en la práctica. Escrito en colaboración con Codex y Claude Code.
De las Indicaciones al Diseño de Objetivos
La idea central detrás de funciones como /goal de Claude Code es simple. Un agente de codificación sigue siendo el ejecutor, pero el humano ya no interactúa con él turno por turno. En cambio, el humano especifica el estado final deseado, la evidencia requerida para probar el éxito, las restricciones que no deben violarse y, cuando sea posible, el número de turnos y el presupuesto.
Ese objetivo funciona más como un contrato que como una indicación más larga. Un objetivo débil le da al modelo espacio para detenerse temprano, tomar atajos o redefinir el éxito de una manera que parezca plausible en la transcripción pero que falle en el sistema real. Un objetivo fuerte le da al agente un objetivo contra el cual pueda medirse repetidamente.
El criterio de ingeniería sigue siendo importante aquí. Los mejores objetivos codifican conocimiento del dominio que el modelo de otro modo adivinaría. Para un experimento de investigación, eso podría significar una puntuación objetivo en un benchmark, una evaluación con datos reservados, una curva de pérdida requerida y una regla de que el resultado debe superar una línea base inicial. Para una tarea de interfaz de usuario, podría significar una referencia de captura de pantalla, restricciones de diseño concretas y un paso de verificación en el navegador. El modelo puede ejecutar, pero el humano aún define lo que realmente significa "terminado".
El Evaluador se Convierte en un Componente de Primera Clase
Los agentes de larga duración necesitan un segundo rol además del objetivo. Ese evaluador puede ser otro agente de codificación, un LLM como juez, un script, un conjunto de pruebas, un harness de benchmark o una mezcla de todos ellos. La decisión de diseño clave es emparejar el evaluador con la tarea. Cuando el éxito es nítido, las comprobaciones deterministas son mejores. Se deben usar verificaciones de tipos, pruebas unitarias, reglas de lint, pruebas de integración y scripts de benchmark siempre que puedan expresar la condición claramente.
Cuando el éxito es difuso, un evaluador agente se vuelve útil. Un script puede decirte si las pruebas pasan, pero no puede decidir fácilmente si un informe de investigación generado es coherente, si una implementación sigue fielmente un artículo académico, o si una interfaz de usuario coincide con la intención de diseño. Aquí es donde el evaluador se beneficia del lenguaje, el juicio y, a veces, la visión.
El patrón práctico utiliza comprobaciones deterministas como base y la evaluación del agente como revisión de nivel superior. Esa combinación reduce el éxito alucinado al tiempo que permite la autonomía en tareas que no encajan claramente en una aserción de prueba.
Los Verificadores Definen el Límite de Confianza
El punto más profundo es que la autonomía solo funciona cuando el sistema tiene un verificador confiable. Un agente de codificación puede generar un plan, implementar una función y explicar por qué cree que el trabajo está completo, pero esa explicación no debe tratarse como evidencia. La evidencia proviene de una verificación externa que el agente no puede eludir fácilmente con argumentos.
Para el código, el verificador podría ser un conjunto de pruebas, un verificador de tipos, un benchmark, una ejecución en el navegador, una comparación de capturas de pantalla o un script reproducible. Para trabajos de investigación, podría ser una evaluación con datos reservados, una tabla reproducida, una curva de pérdida o una puntuación de benchmark que mejore la línea base. Para trabajos de diseño, podría ser una captura de pantalla de referencia más un paso de revisión visual. El verificador es lo que convierte a un agente de larga duración de un generador de texto seguro en un sistema en el que se puede confiar con más tiempo.
La mayoría de los atajos aparecen en este límite. Si el verificador es vago, el modelo a menudo satisfará la interpretación más fácil de la tarea. Si el verificador es demasiado estrecho, el modelo podría sobreajustarse a él y perder de vista la intención más amplia. Un buen flujo de trabajo autónomo, por lo tanto, necesita verificación en capas, con comprobaciones deterministas baratas que detecten fallos básicos y una revisión de nivel superior que detecte fallos con mucho juicio. Algunos de los modelos fronterizos ya pueden lograr cierto nivel de verificación, pero según mi investigación, todavía hay un evidente problema de OOD (fuera de distribución), donde si la tarea de verificación que asignas al agente cae fuera de la distribución de entrenamiento, los modelos luchan significativamente.
Los verificadores siguen siendo un área abierta de investigación, pero anticipo que más empresas comenzarán a hacer grandes inversiones en esta área. El concepto de verificadores ajustados (fine-tuned) también tiene una gran demanda en las empresas.
Los Bucles Hacen que la Autonomía sea Duradera
Un objetivo le da dirección al agente, pero un bucle mantiene el trabajo vivo. Esta distinción es importante porque los modelos a menudo se detienen antes de que la tarea real esté terminada. Pueden alcanzar un límite de turnos, perder confianza, agotar el contexto o decidir que una solución parcial es suficiente.
El bucle es el sistema de control externo. Se activa, inspecciona el progreso, ejecuta comprobaciones, compara el resultado con el objetivo y envía al agente de vuelta con la siguiente instrucción cuando no se ha cumplido el objetivo. En su forma más simple, este es el patrón de bucle de Ralph con un agente de codificación y una condición determinista. En una forma más flexible, el bucle incluye un agente evaluador que puede razonar sobre el progreso y decidir qué debería suceder a continuación.
La autonomía de larga duración funciona como un esfuerzo repetido bajo la supervisión de una capa de control, no como un acto continuo de inteligencia. El agente aún puede fallar, pero el bucle le da al sistema una forma de notar el fallo y continuar en lugar de declarar silenciosamente la victoria.
La Planificación es Donde Entra la Experiencia
Uno de los temas más fuertes de la sesión fue que la planificación sigue siendo crítica. Puedes pedirle a un modelo fronterizo que genere un plan, pero aún necesitas inspeccionarlo, desafiar las suposiciones y hacer más precisos los criterios de éxito antes de entregar la tarea a un bucle autónomo.
Esto lleva a una división útil del trabajo. Un modelo de planificación más fuerte puede ayudar a definir el objetivo, identificar restricciones faltantes y estructurar la evaluación. Un modelo de ejecución diferente puede entonces ejecutar la implementación una vez que el plan esté claro. En la práctica, esto significa que los ingenieros deberían dejar de pensar en "el modelo" como una elección única. La elección del modelo se convierte en una decisión de arquitectura.
Algunos modelos son mejores planificadores. Algunos son mejores ejecutores. Algunos son evaluadores más baratos. Algunos son mejores en la revisión basada en visión. Un buen orquestador te permite intercambiar estos roles en lugar de esperar a que un solo proveedor proporcione la interfaz de agente de codificación perfecta.
Los Artefactos Visuales se Convierten en Superficies de Control
Las transcripciones de terminal no escalan cuando muchos agentes están ejecutándose. Una vez que tienes varias sesiones trabajando en paralelo, el texto sin formato se convierte en una interfaz pobre para entender el progreso.
Los artefactos en vivo importan porque un panel con curvas de pérdida, puntuaciones de benchmark, estados de tareas, capturas de pantalla, estimaciones de costos y decisiones recientes le da al humano una forma mucho mejor de supervisar la autonomía. El artefacto se convierte en la superficie de control para decidir cuándo intervenir, en lugar de un informe generado después del hecho.
El patrón más útil es separar el almacenamiento de la presentación. Markdown o un vault pueden almacenar evidencia duradera, registros, notas, planes y resultados. Los artefactos HTML pueden renderizar ese estado en algo visual e interactivo. El agente puede buscar en el Markdown, mientras que el humano puede monitorear el artefacto.
Para el trabajo de UI y producto, las señales visuales son especialmente poderosas. Una referencia de captura de pantalla puede comunicar la intención de diseño con más precisión que la prosa, y un evaluador con capacidad de visión puede comparar la implementación con esa referencia. Esto reduce el modo de fallo común donde el agente implementa técnicamente el componente solicitado pero omite el espaciado, la jerarquía, la alineación o la sensación del producto.
La Minería de Sesiones Convierte el Uso en Memoria
Otra idea importante es que las sesiones pasadas del agente son una fuente rica de datos de flujo de trabajo. Si un agente falla repetidamente de la misma manera, se olvida de ejecutar la misma comprobación, usa la ruta incorrecta o reintenta el mismo comando roto, ese patrón no debería permanecer enterrado en los registros.
La minería de sesiones convierte esas transcripciones en reglas operativas. Un agente puede escanear los últimos treinta días de trabajo, encontrar modos de fallo recurrentes y proponer actualizaciones a las instrucciones del proyecto, los aprendizajes del vault o las reglas del agente. Así es como un equipo puede mejorar gradualmente su harness sin recordar manualmente cada error.
El objetivo es hacer que el entorno local sea más inteligente sin entrenar un modelo desde cero. Una pequeña regla en un archivo de instrucciones del agente puede prevenir fallos repetidos en sesiones futuras, especialmente cuando la regla es específica del proyecto.
Un Modelo Operativo Práctico
Para los ingenieros de IA, el flujo de trabajo emergente se ve así.
- Comienza con un subconjunto pequeño y económico antes de lanzar la ejecución autónoma completa.
- Escribe un objetivo con criterios de éxito medibles, restricciones explícitas y un presupuesto de turnos o tiempo (cuando sea posible).
- Separa el ejecutor del evaluador para que la implementación y el juicio no se colapsen en un solo rol.
- Define verificadores externos antes de que comience el bucle de larga duración.
- Usa comprobaciones deterministas siempre que sea posible, luego agrega revisión del agente para criterios difusos.
- Requiere artefactos de prueba como registros, capturas de pantalla, curvas de benchmark o archivos modificados.
- Minera sesiones pasadas y promueve lecciones repetidas a las instrucciones del proyecto.
Esa es la diferencia entre usar un agente de codificación e ingeniar un sistema de codificación autónomo. Uno te da una conversación. El otro te da un harness.
Lo Que Todavía se Rompe
Nada de esto elimina los problemas difíciles. Los agentes todavía toman atajos. Todavía se detienen temprano. Todavía sobreestiman la finalización. Todavía producen planes seguros pero débiles, especialmente en artículos recientes, benchmarks desconocidos o sistemas fuera de su distribución de entrenamiento.
Confiarlos más no resolverá esto. Mejores sistemas de control lo harán. Los objetivos, bucles, evaluadores, comprobaciones deterministas, artefactos visuales y memoria de sesiones son formas de hacer que la autonomía sea observable y corregible.
La dirección es clara. El futuro de los agentes de codificación depende de una mejor orquestación alrededor de modelos más capaces, donde los ingenieros diseñen las condiciones bajo las cuales los agentes puedan ejecutarse de manera segura durante horas o días y aún así producir trabajo que pueda ser verificado.
