Lo que hemos aprendido construyendo capacidades de pruebas de extremo a extremo en la máquina virtual de Devin.
Hace 3 meses, me uní a Cognition para ayudar a construir el futuro de la ingeniería de software. Devin ha recorrido un largo camino desde su lanzamiento como el primer ingeniero de software de IA, y me ha impresionado mucho ver cómo el equipo detrás de él realmente usa Devin a diario.
Una cosa que destacó fue cómo Devin usa su computadora para verificar el trabajo de forma autónoma en la nube. Desde validar nuestra integración con Slack hasta probar funciones complejas de Windsurf, el equipo siempre tiene un ejército de Devins en modo de prueba. En este artículo, compartiré por qué estamos tan enfocados en la verificación de agentes en la nube de extremo a extremo y cómo estamos abordando su construcción.
El cambio hacia la ingeniería de software asíncrona
En Cognition, alcanzamos recientemente un nuevo hito. Por primera vez, más Devins se están activando de forma asíncrona, a través de eventos, automatizaciones, horarios y otros Devins. Esperamos que esto continúe acelerándose con nuestro reciente lanzamiento de Auto-Triage.
A medida que avanzamos hacia este mundo asíncrono, es crucial que los desarrolladores puedan volver a resultados verificados que estén listos para fusionarse. A principios de este año lanzamos Devin Review, una herramienta de revisión de código que escala la comprensión humana de cambios complejos en el código. No solo señala errores – Devin cierra el ciclo corrigiendo cada hallazgo hasta que el cambio vuelva limpio. Pero una revisión limpia por sí sola a menudo no es suficiente: los ingenieros quieren ver el cambio probado de extremo a extremo, de la misma manera que ellos mismos lo probarían.
Es una gran sensación cuando Devin crea un PR solucionando una queja de un usuario antes de que tú tengas la oportunidad de siquiera ver el mensaje en el canal de errores. Lo que lo hace mágico es cuando ese PR viene con la prueba de que la solución realmente funciona. Y esta magia pronto podría convertirse en una necesidad: a medida que más PRs provengan del auge de los agentes proactivos, los cambios no verificados se volverán rápidamente inmanejables.
Desde el principio
Desde que se lanzó Devin, siempre ha sido capaz de demostrar su trabajo en una máquina virtual en la nube. Hace unos 6 meses, ampliamos las capacidades de computer use de Devin. Lo que esto significa en la práctica es que añadimos herramientas al arnés de Devin para tomar capturas de pantalla, mover el ratón, hacer clic, arrastrar, escribir, presionar teclas, desplazarse, esperar, hacer zoom e iniciar/detener la grabación. El computer use existe desde hace un tiempo, pero sentimos que la última cohorte de modelos de los laboratorios frontera ha comenzado a ser realmente buena utilizando estas herramientas.
El computer use desbloqueó algunas capacidades nuevas y divertidas para Devin, como construir y jugar un juego de escritorio, o usar su navegador para pedir productos en Amazon. Pero el verdadero avance que notamos fue la capacidad de Devin para probar su propio trabajo. Devin inicia la aplicación, navega por ella y confirma que sus cambios realmente funcionan, de la misma manera que lo haría un ingeniero. Todo se ejecuta en la nube y puede escalar en paralelo. Esto realmente me impactó cuando vi a ingenieros ejecutando de 10 a 20 Devins en paralelo, cada uno con su propio servidor de desarrollo, trabajando en cambios – esto es algo que simplemente no se puede hacer en una sola laptop. Las pruebas automatizadas en la nube comenzaron a ahorrarnos una enorme cantidad de tiempo, ya que ya no tenemos que ejecutar y verificar el código localmente.
Para ser honesto, llegar hasta aquí no fue fácil. Encontramos muchos modos de fallo en el camino, cada uno nos enseñó algo sobre lo que se necesita para hacer este sistema más confiable.
Aumentando la confiabilidad
En las primeras versiones, era muy común que Devin se desviara durante las pruebas. Ocurría de muchas maneras: probando en exceso partes no relacionadas del producto, perdiéndose en la configuración antes de llegar a la funcionalidad, o simplemente omitiendo el comportamiento central que el PR realmente debía cambiar.
Para abordar esto, cuando Devin entra en modo de prueba, primero le hacemos escribir un plan de prueba detallando un objetivo claro sobre qué probar. Este plan debe basarse en el código fuente, no en suposiciones. Sin basarse en el código, descubrimos que los modelos tienden a asumir que pueden seguir caminos en la aplicación que no existen. Además, el plan de prueba aumenta enormemente la complejidad de los cambios que Devin puede probar con éxito. Algunas de nuestras solicitudes más ambiciosas incluían funciones que requerían que se ejecutaran múltiples servicios, configuraciones de administrador específicas, y las banderas correctas habilitadas antes de que el comportamiento siquiera fuera accesible. Al leer el código de antemano, es mucho más probable que Devin configure el entorno correctamente en lugar de descubrir algo que falta a mitad de la prueba. El plan de prueba actúa como una forma de prealineación y hace que Devin sea menos propenso a desviarse cuando está probando activamente.
A medida que Devin trabaja en el plan, añade sus propias anotaciones en la línea de tiempo. Estas incluyen notas de configuración, el inicio de cada prueba nombrada y afirmaciones marcadas como aprobadas, fallidas o no probadas. Descubrimos que Devin mentirá menos sobre sus hallazgos si anota su comportamiento esperado justo antes de realizar una acción – muy similar al desarrollo guiado por pruebas, si te comprometes con la expectativa de antemano, es mucho más difícil racionalizar un resultado inesperado como aprobado.
Algunas partes del flujo de pruebas se repiten en casi cada ejecución. Iniciar sesión es el ejemplo clásico: manejar un formulario de inicio de sesión a través de computer use a menudo significa escribir un correo electrónico, completar SSO, hacer clic en redireccionamientos y esperar en cada carga de página, captura de pantalla por captura de pantalla. Esto puede ser costoso tanto en tiempo como en tokens. Para mejorar la confiabilidad y el costo de estas acciones, Devin extrajo el trabajo a un script determinista que reside en una habilidad de testing en nuestro repositorio. De esta manera, Devin puede ejecutar el script y obtener una sesión de navegador autenticada en segundos y saltar a la parte central de la prueba. La naturaleza determinista de estos scripts ayudó a disminuir drásticamente la inestabilidad. Actualizamos a Devin para que también cierre este ciclo por sí mismo. Cuando descubre un paso de configuración de manera difícil, Devin puede sugerir guardar ese conocimiento como una habilidad de testing en el repositorio y proponer la corrección al usuario como un PR de un solo clic.
También estamos experimentando con enrutar la fase de pruebas a diferentes modelos. Dado que las pruebas se apoyan en fortalezas diferentes a las de escribir código, como leer capturas de pantalla, rastrear el estado de la interfaz de usuario y decidir la próxima acción del navegador, algunos modelos son simplemente mejores en esto que el típico que elegirías para editar código.
Usando pruebas autónomas en Devin hoy
Devin actualmente entra en modo de prueba de dos maneras: una solicitud explícita para probar un cambio, o, después de que Devin crea un PR, ofrecerá probar el cambio si corresponde. A partir de ahí, creará el plan de prueba y comenzará a trabajar.
A menudo, cuando empiezas a usar las capacidades de prueba de Devin, necesitará tu asistencia. Un buen ejemplo es si requiere secretos al ejecutar tu aplicación localmente. Para hacer este proceso más fluido, Devin puede pedirte en la sesión cualquier credencial u otra información que pueda faltar. Para casos más difíciles, puedes tomar el control de la computadora de Devin e ingresar cosas como códigos OTP. La buena noticia es que una vez que Devin termina de configurar tu repositorio, puede guardar una configuración declarativa en forma de un blueprint YAML que produce una instantánea para que cada sesión futura arranque desde ahí.
Lo que obtienes
Cuando Devin termina de probar, no solo te dice si la aplicación funcionó. Una grabación de pantalla en bruto es útil, pero sentimos que no era suficiente por sí sola: necesitas entender lo que estás viendo, por qué Devin tomó cada acción y qué partes de la prueba pasaron o fallaron.
Para una revisión rápida, Devin devolverá un informe de prueba con capturas de pantalla etiquetadas de momentos clave en la ejecución, para que puedas ver rápidamente qué probó Devin y cómo se veía la aplicación en el camino.
Si deseas una revisión más profunda, Devin también produce un video de prueba con una interfaz de reproductor enriquecida que tiene capítulos para saltar entre secciones de prueba, desplazarte por la ejecución completa e inspeccionar las afirmaciones que pasaron o fallaron en una vista de lista cronológica. En el postprocesamiento, el tiempo muerto entre acciones se comprime mientras que los momentos alrededor de las acciones se reproducen a velocidad normal. Esto hace que una ejecución larga se condense en una grabación que realmente puedes ver. Estos artefactos están disponibles en nuestra interfaz web y también se distribuyen a Slack si Devin se inició desde allí.
Bordes duros
El computer use todavía tiene bordes duros. Un ejemplo es la sincronización: si Devin está probando una notificación toast, una captura de pantalla tomada demasiado temprano o demasiado tarde puede perder el toast por completo y los modelos pueden confundirse sobre si el comportamiento esperado realmente ocurrió.
Otro modo de fallo es hacer trampa. Dejados a su suerte, los modelos a veces pueden apoyarse demasiado en ejecutar JavaScript en el navegador para activar estados mediante programación en lugar de hacer clic en la interfaz de usuario. Esto puede ser útil para probar funcionalidades, pero los usuarios a menudo querrán ver a Devin ejercitar la aplicación como lo haría un usuario real.
Estamos trabajando activamente en estos problemas a través de evaluaciones mejoradas, barreras de protección más estrictas en el arnés y cada nueva generación de modelos que mejora en el computer use.
El futuro del desarrollo asíncrono está verificado
En los últimos meses, las ejecuciones de prueba aprobadas por día en Devin se han más que duplicado. Ese crecimiento refleja algo simple: los agentes asíncronos solo son útiles si los desarrolladores pueden confiar en lo que devuelven. A menudo, esa confianza no puede venir solo del código: para muchos cambios, quieres saber que la aplicación realmente se ejecutó, que los flujos importantes se ejercitaron y que el resultado se capturó de una manera que puedas inspeccionar fácilmente.
Eso es lo que las pruebas autónomas en Devin están diseñadas para proporcionar. Devin planifica la prueba, opera la aplicación, graba y anota lo que sucedió, y finalmente devuelve artefactos que hacen que el resultado sea revisable. Todavía hay mucho que mejorar, pero creemos que esta es la forma correcta del futuro: agentes que no solo completan el trabajo de forma asíncrona, sino que regresan con pruebas.
Constantemente nos sorprende la cantidad de tiempo que Devin nos ahorra al probar su propio trabajo, y sentimos que muchos clientes aún subutilizan la función de pruebas automatizadas de Devin. Para apoyar la experimentación, actualmente facturamos a 1/5 del costo de uso normal mientras está en modo de prueba.
Prueba nuestro trabajo en devin.ai o windsurf.com. Y si trabajar en problemas como estos te parece divertido, contáctame a ido [at] cognition.ai
