La codificación autónoma está pasando de mejores prompts a mejores sistemas de control. El cambio importante es que los ingenieros están aprendiendo a envolver a los agentes en objetivos, evaluadores, bucles y artefactos que les permiten seguir trabajando después de que el humano deje de escribir.
Esto importa porque la mayor parte 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 dirección humana constante.
Este artículo se basa en una sesión de DAIR.AI Academy sobre agentes de codificación autónomos de larga duración, donde expliqué el modo /goal de Claude Code, el nuevo comando /loop, verificadores, artefactos y patrones de orquestación en la práctica. Escrito en colaboración con Codex y Claude Code.
De los *prompts* al diseño de objetivos
La idea central detrás de funciones como el /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 su lugar, el humano especifica el estado final deseado, la evidencia necesaria para demostrar 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 un prompt más largo. Un objetivo débil le da al modelo espacio para detenerse antes de tiempo, tomar atajos o redefinir el éxito de una manera que parezca plausible en la transcripción pero falle en el sistema real. Un objetivo sólido le da al agente un blanco contra el que puede 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 en 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, podría significar una captura de pantalla de referencia, restricciones de layout concretas y un paso de verificación en el navegador. El modelo puede ejecutar, pero el humano sigue definiendo qué significa realmente «estar 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 benchmarks 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. Deberían usarse comprobaciones de tipos, pruebas unitarias, reglas de lint, pruebas de integración y scripts de benchmarks siempre que puedan expresar la condición con claridad.
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 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 usa comprobaciones deterministas como base y la evaluación del agente como revisión de alto nivel. Esa combinación reduce el éxito alucinado al mismo tiempo que permite autonomía en tareas que no encajan limpiamente 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 fiable. Un agente de codificación puede generar un plan, implementar una funcionalidad y explicar por qué cree que el trabajo está completo, pero esa explicación no debe tratarse como evidencia. La evidencia proviene de una comprobación externa que el agente no puede fácilmente sortear con palabras.
Para 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 trabajo de investigación, podría ser una evaluación en datos reservados, una tabla reproducida, una curva de pérdida o una puntuación de benchmark que mejore la línea base. Para trabajo 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 un agente de larga duración de un generador de texto seguro en un sistema en el que se puede confiar 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 puede sobreajustarse a él y perder de vista la intención más amplia. Por lo tanto, un buen flujo de trabajo autónomo necesita verificación en capas, con comprobaciones deterministas baratas que atrapen fallos básicos y una revisión de alto nivel que atrape fallos que requieren juicio. Algunos de los modelos de frontera 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 tienen dificultades significativas.
Los verificadores siguen siendo un área de investigación abierta, pero anticipo que más empresas comenzarán a hacer grandes inversiones en esta área. El concepto de verificadores ajustados también tiene una gran demanda en el ámbito empresarial.
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 exterior. Se despierta, inspecciona el progreso, ejecuta comprobaciones, compara el resultado con el objetivo y envía al agente de vuelta con la siguiente instrucción cuando el objetivo no se ha cumplido. En su forma más simple, esto es el patrón de bucle 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 pasar después.
La autonomía de larga duración funciona como un esfuerzo repetido bajo 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 manera 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 sólidos de la sesión fue que la planificación sigue siendo crítica. Puedes pedirle a un modelo de frontera que genere un plan, pero aún necesitas inspeccionarlo, cuestionar suposiciones y hacer los criterios de éxito más precisos 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 única elección. La elección del modelo se convierte en una decisión arquitectónica.
Algunos modelos son mejores planificadores. Algunos son mejores ejecutores. Algunos son evaluadores más baratos. Algunos son mejores en revisión basada en visión. Un buen orquestador te permite intercambiar estos roles en lugar de esperar a que un solo proveedor ofrezca la interfaz de agente de codificación perfecta.
Los artefactos visuales se convierten en superficies de control
Las transcripciones de terminal no escalan cuando hay muchos agentes 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 coste y decisiones recientes le da al humano una manera 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 trabajo de interfaz y producto, las señales visuales son especialmente poderosas. Una captura de pantalla de referencia 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 contra esa referencia. Esto reduce el modo de fallo común donde el agente implementa técnicamente el componente solicitado pero se salta 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 de los agentes 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 quedar 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, aprendizajes del vault o reglas del agente. Así es como un equipo puede mejorar gradualmente su harness sin tener que recordar manualmente cada error.
El objetivo es hacer el entorno local 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 tiene este aspecto.
- Comienza con un subconjunto pequeño y barato 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 estén colapsados 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 añade revisión del agente para criterios difusos.
- Exige artefactos de prueba como registros, capturas de pantalla, curvas de benchmark o archivos modificados.
- Extrae lecciones de sesiones pasadas y promueve lecciones repetidas a instrucciones del proyecto.
Esa es la diferencia entre usar un agente de codificación e ingeniería de 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 antes de tiempo. Todavía sobreestiman la finalización. Todavía producen planes seguros pero débiles, especialmente sobre artículos recientes, benchmarks desconocidos o sistemas fuera de su distribución de entrenamiento.
Confiarlos más no solucionará esto. Lo harán mejores sistemas de control. 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 verificarse.
