Todos hablan del Aprendizaje Continuo como si significara una sola cosa: actualizar los pesos del modelo. Pero hay una verdad incómoda sobre el ecosistema de agentes: la gran mayoría de los agentes en producción hoy en día aprovechan modelos frontera cerrados. Cuando no eres dueño de los pesos, ciertamente no puedes ajustarlos. Para la mayoría de los creadores de agentes, el aprendizaje continuo a nivel de pesos está fuera de la mesa, especialmente cuando se trabaja en la vanguardia de las capacidades (piensa en Fable 5 o GPT 5.6).
Eso no significa que los agentes no puedan aprender. Los sistemas de agentes pueden mejorar en tres capas: modelo, arnés y contexto [0], y las dos últimas están completamente bajo tu control. Aquí es donde reside una oportunidad masiva (pero a menudo pasada por alto): el aprendizaje a nivel de arnés te permite extraer trazas de producción para mejorar sistemáticamente el código, las herramientas y las instrucciones que impulsan cada instancia de tu agente, mientras que el aprendizaje a nivel de contexto te permite personalizar a nivel de agente, usuario y organización, para que tu producto mejore con cada interacción. Haz todo lo anterior y estarás acumulando mejoras que puedes implementar a diario.
En el resto de este artículo, explicaré cómo hemos estado aplicando el aprendizaje continuo a Replit Agent durante el último año y compartiré todas las lecciones que aprendimos en el camino.
Evaluando y mejorando Replit Agent a escala
La mayoría de los usuarios de Replit Agent comienzan con una idea. Describen el objetivo en lenguaje natural, sin un repositorio, suite de pruebas o framework elegido, y esperan que el agente lo convierta en una aplicación funcional. El resultado podría ser un sitio web, una presentación de diapositivas, una aplicación móvil, varios artefactos conectados o algo completamente diferente.
Los "vibe coders" generalmente no revisan diferencias de código ni resultados de pruebas. El éxito para Replit Agent es engañosamente simple: la aplicación debería funcionar cuando los usuarios hacen clic.
Eso cambia el trabajo de la evaluación. Una puntuación única puede ayudar con una decisión de lanzamiento específica, pero no puede decirnos, semana tras semana, si Replit Agent está mejorando para los usuarios. Para responder a esa pregunta, la evaluación debe convertirse en parte del ciclo de mejora.
NASA Lewis Research Center, Sala de Control Central en el Edificio de Investigación de Motores, 1968 — La medición importa cuando cambia lo que se envía.
La evaluación tiene que hacer más ahora
La evaluación de agentes solía parecerse a un proceso unidireccional: ejecutar la evaluación, producir una puntuación y tomar una decisión de lanzamiento. Esto funciona cuando los lanzamientos son lentos y lo que se mide rara vez cambia. Se descompone cuando los modelos, las indicaciones, las herramientas y las superficies del producto cambian rápidamente.
El ciclo anterior hacía que la evaluación se sintiera limitada. Pero Replit Agent cambia demasiado rápido para que una sola puntuación soporte toda la decisión. Una puntuación puede comparar dos candidatos en un segmento de tareas. No puede explicar lo que les importa a los usuarios, dónde se está rompiendo la producción o qué mejorar a continuación.
La evaluación tuvo que pasar de ser un control de lanzamiento a un ciclo de mejora.
El trabajo de evaluación anterior termina en una decisión humana de lanzamiento; el nuevo alimenta un sistema continuo que aprende de la producción y envía agentes mejorados.
El sistema tiene dos pilares de medición y un bucle de optimización. Los benchmarks fuera de línea nos indican si los cambios candidatos pueden completar tareas simuladas de creación de aplicaciones antes de que los enviemos. Las pruebas A/B en línea y las trazas de producción muestran cómo se ven afectados los usuarios reales después de que los cambios se envían. Esas señales luego fluyen de vuelta a las evaluaciones y decisiones de lanzamiento.
Ninguna capa es suficiente por sí sola. Los benchmarks detectan regresiones antes del lanzamiento. Las pruebas A/B muestran si el comportamiento de producción se movió. Los grupos de trazas explican las fallas bajo métricas agregadas. El juicio humano mantiene el ciclo de mejora apuntando a los resultados correctos de producto e ingeniería. La forma es análoga al modelo de queso suizo en ingeniería de seguridad: cada capa tiene agujeros, pero juntas atrapan más de lo que cualquier capa puede por sí sola.
Los benchmarks existentes se quedan cortos para el usuario
Los benchmarks de codificación de agentes como SWE-bench [1] y Terminal-Bench [2] califican el código en entornos restringidos y repetibles. Estos benchmarks son valiosos y ampliamente adoptados, pero pasan por alto la señal que le importa a un "vibe coder".
Replit Agent a menudo crea la base de código desde cero. Los usuarios no traen rutas fijas, firmas de funciones, selectores o pruebas; traen una solicitud de producto. El agente elige el stack, esquema, rutas, componentes y flujos de interacción.
Eso crea una brecha de corrección funcional. Un agente puede satisfacer las restricciones locales de un benchmark de codificación y aún así fallar en lo que el usuario ve: si la aplicación terminada hace lo que se le pidió. Para el "vibe coding", el objetivo de evaluación es el artefacto en sí mismo: ¿carga, funciona el flujo de trabajo principal y el resultado coincide con la solicitud?
Presentando ViBench
La necesidad de este estilo de evaluación de extremo a extremo es precisamente por lo que construimos ViBench [3], nuestro benchmark público para "vibe coding", que mide una señal simple pero importante: ¿la aplicación construida por el agente cumple con las especificaciones?
ViBench comienza con un documento de requisitos del producto (PRD) en inglés sencillo extraído de trazas de producción anonimizadas de Replit. A partir de ahí, el agente recibe el PRD y construye una aplicación en funcionamiento desde cero, sin estar limitado al andamiaje, rutas o referencias que requieren los benchmarks de codificación tradicionales.
Sin embargo, la misma flexibilidad que hace que ViBench sea realista exige un agente de evaluación igualmente flexible, uno que se mantenga fiel al PRD. En los benchmarks estilo SWE-bench, el proyecto ya existe, por lo que la superficie de evaluación es fija. En el "vibe coding", el agente elige el stack, rutas, componentes y flujo. La evaluación tiene que explorar lo que sea que haya inventado.
Con ese fin, cada tarea de ViBench empareja el PRD con un conjunto de planes de prueba en lenguaje natural que describen las interacciones a nivel de características y las afirmaciones que la aplicación terminada debe satisfacer. El agente de evaluación utiliza Playwright como una columna vertebral flexible, lo que le permite ejercitar características complejas como simulación fuera de línea, manipulación de archivos y multiinquilino. Debido a que no conoce los localizadores o la estructura de la aplicación a priori, funciona en un entorno de notebook, descubriendo progresivamente cómo está construida la aplicación e interactuando con ella paso a paso, un enfoque extraído de la investigación anterior de Replit sobre autoevaluación automatizada [4].
Ejecutar ViBench, y nuestras evaluaciones en general, a escala de Replit también exige un fuerte soporte de infraestructura [5]. Internamente, nos apoyamos en la misma infraestructura de producción que nos permite crear entornos aislados y con buenos recursos para construir aplicaciones y ejecutar nuestros agentes. Debido a que podemos bifurcar rápidamente esos entornos [6], ejecutamos gran parte de la evaluación en paralelo, sin riesgo de contaminación cruzada entre evaluaciones.
Más allá de construir aplicaciones desde cero, la misma base de ViBench, un PRD en lenguaje natural calificado por planes de prueba en lenguaje natural, se adapta a una variedad de escenarios de "vibe coding". Para evaluar cómo funciona un agente dentro de una aplicación existente, más cerca de las cargas de trabajo de mitad de trayectoria de Replit, lo iniciamos en una base de código existente y medimos qué tan bien implementa extensiones de características a partir de un PRD de características. Esa base de código puede provenir de nuestras propias implementaciones de referencia o de aplicaciones que el agente "vibe-codeó" por sí mismo, lo que llamamos Vibe-to-ref y Vibe-on-Vibe en nuestra publicación. Cuando lanzamos nuevas superficies de producto, la misma columna vertebral nos permite derivar rápidamente nuevos problemas para evaluar patrones de interacción novedosos, como lo hicimos para las descomposiciones paralelas y de fusión y subagentes del Agent 4.
ViBench mantiene fijo el evaluador de comportamiento mientras varía la estrategia de entrada y construcción.
Los primeros resultados de ViBench nos dieron dos lecciones útiles. Primero, las puntuaciones de los benchmarks de codificación de frontera no siempre se transfieren a la construcción completa de aplicaciones, especialmente para modelos de pesos abiertos. Segundo, la mayoría de los modelos empeoran al extender su propio código, ya que los errores a menudo se acumulan. Juntas, esas lecciones nos dan una mejor colina que escalar: no solo escribir código que pase pruebas, sino construir aplicaciones que puedan sobrevivir a la siguiente solicitud del usuario.
Las pruebas A/B son cómo nos mantenemos honestos
Confiamos profundamente en las evaluaciones fuera de línea, pero no son el único juez. Hemos visto suficientes actualizaciones de agentes que se veían bien en entornos controlados, solo para retroceder en el comportamiento real del usuario, como para saber que la producción necesita su propia capa de medición.
Los usuarios no están guionizados, siempre están activos y operan a una escala que ningún benchmark fuera de línea puede reproducir completamente. Abandonan proyectos, cambian de opinión, combinan características de maneras sorprendentes y descubren modos de fallo que no sabíamos que debíamos probar.
Por lo tanto, realizamos pruebas A/B en la mayoría de las actualizaciones que afectan al agente: indicaciones, herramientas, revisiones del arnés, cambios de modelo y cambios de comportamiento más grandes. Múltiples experimentos a menudo se ejecutan simultáneamente, manteniendo la atribución clara para evitar ocultar efectos de interacción. Las pruebas A/B revelan el comportamiento del usuario, el sentimiento y el éxito: ¿los usuarios continuaron?, ¿el costo se comportó inesperadamente?, ¿cambió el sentimiento?, ¿los usuarios enviaron algo?
Las pruebas A/B nos dan una lectura controlada del comportamiento de producción, pero las métricas agregadas no se explican por sí mismas. ¿Es esto una victoria? ¿Cuál es el cambio de comportamiento raíz?
Un desafío con las pruebas A/B es que los resultados son difíciles de interpretar. Si la duración de la ejecución aumenta, ¿el agente hizo más trabajo útil o se quedó atascado? Si el costo disminuye, ¿mejoramos la eficiencia o el agente dejó de hacer algo valioso silenciosamente? Si el sentimiento cae, ¿qué casos de uso retrocedieron?, ¿qué modos de fallo son nuevos?, ¿qué usuarios se rindieron?
Telescope: qué se está rompiendo
Las pruebas A/B nos dicen cuándo se movió el comportamiento de producción. Telescope, nuestro sistema para el análisis y agrupación de trazas, ayuda a explicar por qué.
A escala de producción, ningún ingeniero puede leer cada traza. Telescope organiza patrones repetidos en grupos de incidencias en los que los ingenieros y agentes pueden actuar. Resume las trayectorias de fallo, las incrusta, agrupa casos similares y clasifica nuevas sesiones a medida que cambia la distribución. El objetivo no es solo contar fallos, sino descubrir aquellos que están ocultos a simple vista.
GIF
Agrupando lo que no sabíamos que buscar.
Telescope utiliza facetas cortas y basadas en evidencia inspiradas en el mismo enfoque ascendente que Clio [7]. Para las trazas, reconstruye la sesión a partir de mensajes de usuario, respuestas visibles del agente, llamadas a herramientas, errores, metadatos y otro contexto. A partir de ahí, Telescope resume lo que salió mal, incrusta esos resúmenes y utiliza agrupación basada en densidad [8] para formar grupos de problemas emergentes.
Las facetas hacen que la investigación sea más rápida, especialmente cuando la agrupación por sí sola no es suficiente. Cuando los informes de soporte apuntan a un problema amplio, como fallos de puerto, los ingenieros y agentes pueden buscar primero en la capa compacta, explorar las facetas relevantes y luego profundizar en sesiones representativas con el contexto de registros y observabilidad necesario para explicarlo.
En conjunto, la misma estructura convierte los fallos dispersos en preguntas de producto: qué flujos de trabajo dominan, cuáles se abandonan, qué se rompe repetidamente y si una mitigación está reduciendo el grupo de incidencias previsto.
Para obtener más información sobre esta arquitectura subyacente, consulta la publicación detallada sobre Topics de nuestros colaboradores en Braintrust [9].
El ciclo: de la evidencia a las mejoras del agente
Una vez que existe la medición, el cuello de botella se mueve. ViBench, las pruebas A/B y Telescope pueden decirnos qué falló, dónde falló y con qué frecuencia está sucediendo. Todavía tenemos que convertir esa evidencia en correcciones plausibles.
Recurrimos a un ciclo de auto-mejora para abordar esto. El principio operativo es simple: si los agentes son útiles para construir software, también deberían ser útiles para mejorar al agente. Cada pasada comienza leyendo registros de producción, grupos de trazas y fallos recientes para encontrar una hipótesis que valga la pena perseguir. Luego construye un candidato, abre un PR borrador con el razonamiento adjunto, mide el resultado contra ViBench, los resultados A/B, los datos de trayectoria y las líneas base recientes, y recomienda si enviarlo, iterarlo o descartarlo.
El ciclo de optimización descubre problemas, propone cambios en el agente, los evalúa y decide si enviar, iterar o descartar.
El envío no se vuelve automático. El ciclo puede preparar la evidencia y la implementación de primera pasada; los ingenieros aún revisan el resultado y son dueños de la decisión de lanzamiento.
Cada ejecución registra lo que intentó y lo que sucedió, incluidos los fallos. Ese registro mejora el ciclo con el tiempo: las ejecuciones futuras pueden reutilizar lo que funcionó, evitar callejones sin salida conocidos y proponer cambios que se generalicen.
La iteración del agente se vuelve más rápida sin renunciar al control de ingeniería. Dado un nuevo modelo, superficie de producto u objetivo de confiabilidad, el ciclo puede encontrar de manera proactiva ediciones de indicaciones, propuestas de habilidades, correcciones de herramientas y cambios en el arnés, mientras los ingenieros mantienen el sistema apuntando hacia el óptimo de producto más amplio.
Un ejemplo concreto
Una ejecución reciente comenzó con un grupo de Telescope pequeño pero creciente. La configuración del entorno se estaba degradando silenciosamente en una larga cola de escenarios de arranque en frío. Estas sesiones no eran obvias a partir de las métricas agregadas, pero el grupo mostraba un patrón que valía la pena investigar.
Después de sacar a la luz el patrón, el ciclo leyó las trayectorias afectadas, propuso un parche, agregó una prueba de regresión y ejecutó el candidato contra ViBench para confirmar que la ruta feliz no retrocedía. Los ingenieros revisaron la evidencia, aprobaron el cambio y lo enviaron a producción el mismo día.
Después de que el parche se envió, el sentimiento se recuperó y los usuarios afectados fueron desbloqueados. Esta es la forma que queremos: un ciclo que encuentra un patrón de fallo real, lo conecta con los usuarios afectados, propone el nivel correcto de corrección y trae suficiente evidencia para que un humano decida si enviarlo.
Donde el gusto humano todavía importa más
Gran parte de esto puede ejecutarse de forma autónoma: agrupar fallos, proponer hipótesis, construir candidatos, ejecutar evaluaciones y ensamblar evidencia. Los humanos aún establecen la dirección y controlan la mayoría de las salidas, incluyendo:
- Selección de hipótesis. Un sistema puede sacar a la luz mil fallos, pero los humanos deciden qué preguntas merecen el presupuesto nocturno del ciclo. No todos los grupos son igualmente importantes, y no todas las regresiones apuntan al problema de producto correcto.
- Arquitectura de implementación. Las trazas pueden mostrar que los usuarios están abandonando un flujo de trabajo, pero decidir si suavizar ese camino, cambiar el comportamiento del agente o rediseñar la superficie es un juicio de ingeniería y producto.
- Curación de evaluaciones. Esto no es trabajo administrativo; da forma a la colina que el agente escala. Si la evaluación recompensa el comportamiento incorrecto, el ciclo de optimización optimizará fielmente hacia lo incorrecto.
- Aprobación de lanzamiento. Enviar un cambio de agente no es solo leer un número. La aprobación de lanzamiento significa leer la evidencia, comprender el radio de explosión, decidir si el riesgo es aceptable y ser dueño de la implementación.
Ese equilibrio importa: el ciclo puede hacer más de la búsqueda, medición y síntesis. Los ingenieros aún eligen la dirección, toman las decisiones de producto y deciden qué se envía.
Cerrando el ciclo
La evaluación ya no es solo una puerta antes del lanzamiento. Ayuda a decidir qué arreglar, qué probar y qué lanzar.
El trabajo no es producir un número mejor. Es convertir los fallos de los usuarios en mejores lanzamientos, para que más ideas se conviertan en aplicaciones de las que la gente se sienta orgullosa de publicar.
Estamos emocionados de seguir empujando la frontera de los agentes autónomos, con un enfoque en la confiabilidad para las tareas de codificación más complejas. Si estás interesado en trabajar en agentes de codificación autónomos, siempre estoy contratando en el equipo de Replit AI — contáctame en [email protected]
Autores: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Referencias
[0] Aprendizaje continuo para agentes de IA
[1] SWE-bench: ¿Pueden los Modelos de Lenguaje Resolver Problemas Reales de GitHub?
[2] Terminal-Bench: Evaluando Agentes en Tareas Difíciles y Realistas en Interfaces de Línea de Comandos
[3] ViBench: Un Benchmark sobre Vibe Coding
[4] Habilitando al Agent 3 para Autoevaluarse a Escala con Verificación Basada en REPL
[5] Cuantificando el ruido de infraestructura en evaluaciones de codificación de agentes
[6] Dentro del Motor de Instantáneas de Replit: La Tecnología que Hace Seguros a los Agentes de IA
[7] Clio: Perspectivas que Preservan la Privacidad sobre el Uso de IA en el Mundo Real
[9] Cómo hicimos posible la inteligencia de trazas continua a escala
