Lo que hemos aprendido construyendo capacidades de pruebas integrales 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 con IA, y me ha impresionado ver al equipo detrás de él usar Devin a diario.
Algo 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 integral de agentes en la nube y cómo estamos abordando su construcción.
El cambio hacia la ingeniería de software asíncrona
En Cognition, recientemente alcanzamos 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 hacemos la transición a este mundo asíncrono, es crucial que los desarrolladores puedan volver a resultados verificados y listos para fusionar. A principios de este año lanzamos Devin Review, una herramienta de revisión de código que amplía la comprensión humana de diferencias complejas de código. No solo señala errores — Devin cierra el ciclo corrigiendo cada hallazgo hasta que la diferencia quede limpia. Pero una revisión limpia por sí sola a menudo no es suficiente: los ingenieros quieren ver el cambio probado de punta a punta, de la misma manera que ellos lo probarían.
Es una gran sensación cuando Devin publica un PR solucionando una queja de usuario antes de que siquiera tengas la oportunidad de ver el mensaje en el canal de errores. Lo que lo hace mágico es cuando ese PR viene con una 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 aumento de agentes proactivos, los cambios no verificados se volverán rápidamente inmanejables.
Desde el Principio
Desde que Devin fue lanzado, siempre ha sido capaz de demostrar su trabajo en una máquina virtual en la nube. Hace unos 6 meses, ampliamos las capacidades de uso de computadora de Devin. Lo que esto significa en la práctica es que agregamos herramientas al arnés de Devin para tomar capturas de pantalla, mover el mouse, hacer clic, arrastrar, escribir, presionar teclas, desplazarse, esperar, hacer zoom e iniciar/detener grabación. El uso de computadora ha existido por un tiempo, pero sentimos que la última cohorte de modelos de los laboratorios fronterizos ha comenzado a ser realmente buena utilizando estas herramientas.
El uso de computadora desbloqueó algunas capacidades 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 iniciará la aplicación, navegará por ella y confirmará 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 puedes 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 sencillo. Nos encontramos con 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 versiones iniciales, era muy común que Devin se desviara durante las pruebas. Ocurría de muchas maneras: probar en exceso partes no relacionadas del producto, perderse en la configuración antes de llegar a la funcionalidad, o simplemente omitir 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 estar basado 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 exitosamente. Algunas de nuestras solicitudes más ambiciosas incluían funcionalidades que requerían múltiples servicios en ejecución, configuraciones de administrador específicas y las banderas correctas activadas antes de que el comportamiento fuera siquiera accesible. Al leer el código de antemano, Devin tiene muchas más probabilidades de configurar el entorno correctamente en lugar de descubrir algo faltante a mitad de la prueba. El plan de prueba actúa como una forma de prealineación y hace que Devin tenga menos probabilidades de desviarse durante las pruebas activas.
A medida que Devin ejecuta el plan, agrega sus propias anotaciones en la línea de tiempo. Esto incluye notas de configuración, el inicio de cada prueba nombrada y aserciones 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, hace que sea mucho más difícil racionalizar un resultado inesperado como aprobado.
Algunas partes del flujo de pruebas se repiten en casi todas las ejecuciones. Iniciar sesión es el ejemplo clásico: manejar un formulario de inicio de sesión mediante el uso de computadora a menudo implica escribir un correo electrónico, completar SSO, hacer clic en redirecciones y esperar en cada carga de página, captura de pantalla tras 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 prueba 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 la manera difícil, Devin puede sugerir guardar ese conocimiento como una habilidad de prueba en el repositorio y proponer la solución al usuario como un PR de un clic.
También estamos experimentando con enrutar la fase de prueba 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 siguiente acción en el 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
Actualmente, Devin entra en modo de prueba de dos formas: 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 recién comienzas 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 allí.
Lo que obtienes como resultado
Cuando Devin termina las pruebas, 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 proceso.
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 que puedas saltar entre secciones de prueba, desplazarte por toda la ejecución e inspeccionar las aserciones 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í.
Limitaciones difíciles
El uso de computadora todavía tiene limitaciones difíciles. 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 acerca de 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 de forma programática en lugar de hacer clic a través de 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 mediante evaluaciones mejoradas, barreras de protección más estrictas en el arnés y cada nueva generación de modelos que mejora en el uso de computadora.
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 traen de vuelta. A menudo, esa confianza no puede provenir solo del código: para muchos cambios, quieres saber que la aplicación se ejecutó realmente, que los flujos importantes se probaron 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, registra y anota lo que sucedió, y finalmente devuelve artefactos que hacen que el resultado sea revisable. Todavía hay mucho por mejorar, pero creemos que esta es la forma correcta del futuro: agentes que no solo completen el trabajo de forma asíncrona, sino que regresen 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 normal de uso mientras está en modo de prueba.
Prueba nuestro trabajo en devin.ai o windsurf.com. Y si trabajar en problemas como estos suena divertido, escribe a ido [at] cognition.ai
