Cognition apuesta a que las pruebas de Devin GPT-6 Astra pueden sustituir la revisión de código con evidencias
Cognition ha ampliado las pruebas de Devin GPT-6 Astra en tres productos, convirtiendo la verificación en el último campo de batalla de la ingeniería de software autónoma. El modelo ahora admite pruebas dentro de Devin Cloud, Devin Desktop y Devin CLI. Puede operar aplicaciones, inspeccionar resultados y devolver evidencia visual junto con informes escritos.
El cambio importante no es que Devin pueda generar más código. Los agentes de programación ya producen parches, abren pull requests y ejecutan suites de pruebas. Cognition ahora quiere que Devin presente evidencia de que sus cambios funcionan, reduciendo cuánto código generado deben inspeccionar manualmente los ingenieros.
Esa promesa presiona al desarrollo tradicional que prioriza la revisión. También plantea una pregunta difícil para Cognition, OpenAI y todos los agentes de programación competidores. ¿Puede un agente evaluar de forma fiable el trabajo producido por el mismo sistema automatizado, o la atención humana simplemente se desplaza de la revisión de código a la revisión de evidencias?
Las pruebas de Devin GPT-6 Astra ahora producen evidencia revisable
Cognition posiciona la evidencia de pruebas, y no solo la generación de código, como el entregable que los ingenieros deberían evaluar.
OpenAI publicó su caso de pruebas de Devin el 11 de septiembre de 2026. La compañía afirma que Cognition está aplicando GPT-6 Astra en su agente en la nube, interfaz de línea de comandos y aplicación de escritorio.
Cognition ya había añadido Astra a Devin el 3 de septiembre. Su lanzamiento del modelo indica que Astra está disponible directamente en Devin Desktop y Devin CLI. El modelo también forma parte de la combinación de modelos que utiliza Devin Cloud.
La integración separa dos trabajos que los productos de programación suelen presentar como un flujo continuo. Un modelo puede implementar un cambio, mientras Astra puede ayudar a impulsar la fase de pruebas. Esta distinción importa porque editar código y validar una aplicación requieren capacidades diferentes.
Un modelo de programación razona principalmente sobre repositorios, especificaciones y cambios en el código fuente. Un probador de aplicaciones también debe interpretar pantallas, seguir el estado de la interfaz, operar software y reconocer si el comportamiento observado coincide con el resultado previsto.
Cognition afirma que Astra rinde especialmente bien en este segundo grupo de tareas. La compañía reporta resultados de vanguardia en un benchmark interno de pruebas. No ha publicado suficientes detalles para que terceros puedan reproducir o verificar de forma independiente ese resultado específico.
Los ejemplos públicos aclaran qué entiende Cognition por verificación autónoma. En una demostración, Devin prueba Otter Run, un juego para iPhone, dentro de un simulador. Devuelve una grabación del juego en ejecución y un informe que describe qué comprobaciones se aprobaron.
El informe también identifica áreas que Devin no probó. Esta salvedad es importante porque un vídeo pulido podría insinuar una cobertura más amplia de la que realmente logró la ejecución.
La grabación muestra un comportamiento observable, mientras que el informe define el alcance declarado. Juntos, ofrecen al revisor algo más cercano a un artefacto de prueba que a un resumen convencional del agente.
Otro flujo de trabajo comienza con una captura de pantalla de un error proporcionada por un cliente. Cognition afirma que el equipo puede enviar esa imagen a Devin, que diagnostica el problema, modifica el código y devuelve otra captura de pantalla que muestra el resultado.
La secuencia conecta un defecto visible con un resultado visible. Puede acortar el ciclo de retroalimentación para problemas de interfaz difíciles de explicar únicamente mediante registros o comentarios en pull requests.
Sin embargo, una captura de pantalla solo demuestra lo que apareció en un momento concreto. No establece que las rutas relacionadas sigan funcionando, que la implementación subyacente sea mantenible o que el defecto permanezca corregido en condiciones distintas.
Por tanto, la función más útil es el paquete de evidencias. Los ingenieros pueden comparar el comportamiento solicitado, el plan de pruebas declarado, las acciones registradas y las áreas no probadas antes de decidir si fusionan el cambio.
Esto modifica la unidad de revisión. En lugar de recibir solo un diff y la garantía escrita por un agente, el ingeniero recibe una afirmación respaldada por un rastro de ejecución.
Este cambio crea la apuesta central de Cognition. Si los revisores confían en el rastro, pueden dedicar menos tiempo a reconstruir lo ocurrido a partir del código generado. Si no confían en él, los artefactos adicionales se convierten en otra capa que requiere inspección.
Por qué la verificación se ha convertido en el cuello de botella de los agentes de programación
El recurso limitante en el desarrollo basado en agentes está pasando de la producción de código a la capacidad de revisión fiable.
Los agentes de programación pueden crear cambios más rápido de lo que la mayoría de los equipos puede evaluarlos. Cuando varios agentes operan simultáneamente, cada sesión exitosa puede producir otra rama, pull request, informe de pruebas o decisión de seguimiento.
Cognition afirma que sus propios ingenieros han ejecutado entre 10 y 20 sesiones de Devin en paralelo. Cada sesión puede operar un servidor de desarrollo independiente en la nube. Ese grado de concurrencia sería incómodo en el portátil de un solo ingeniero.
Más concurrencia no crea automáticamente más valor en producción. En cambio, puede generar una cola de cambios plausibles que esperan verificación humana.
Esa cola es especialmente difícil porque el código generado puede parecer razonable antes de fallar durante la ejecución. Un revisor quizá deba reconstruir el entorno, ejecutar la aplicación, repetir el flujo informado y examinar comportamientos cercanos.
Cognition ha descrito este desafío como parte de un movimiento más amplio hacia el desarrollo asíncrono. Ahora se activan más sesiones de Devin mediante calendarios, automatizaciones, eventos y otras instancias de Devin que mediante solicitudes interactivas directas.
Un agente de programación asíncrono trabaja mientras su responsable humano atiende otra cosa. Este esquema solo ahorra atención cuando el resultado devuelto es comprensible y suficientemente fiable.
Sin verificación, los ingenieros vuelven a una pila de diffs sin explicación. Deben recuperar el contexto de cada tarea antes de decidir si el trabajo es útil.
La explicación anterior de Cognition sobre la verificación de agentes afirma que las ejecuciones diarias de pruebas aprobadas se duplicaron con creces durante varios meses. Se trata de actividad de producto reportada por la empresa, no de una medición independiente de fiabilidad o valor para el cliente.
Aun así, la dirección tiene sentido. A medida que los agentes generan más cambios, los equipos necesitan evidencia compacta que les indique qué resultados merecen atención.
El objetivo no es eliminar de inmediato el juicio humano. Es abaratar ese juicio al acercar las observaciones relevantes a la tarea terminada.
Un paquete de evidencias útil puede responder varias preguntas antes de que un ingeniero lea la implementación. ¿Se inició correctamente la aplicación? ¿Apareció la función modificada? ¿Qué ruta de usuario ejercitó el agente? ¿Qué quedó fuera de la prueba?
Estas preguntas suelen ser más valiosas que la afirmación de un agente de que todas las pruebas aprobaron. Una suite de pruebas convencional solo evalúa afirmaciones que alguien anticipó y codificó.
Las grabaciones de interfaz pueden revelar cambios de estado que nunca se representaron en pruebas unitarias. Las notas escritas sobre el alcance también pueden exponer cobertura faltante en lugar de enterrarla en un largo registro de ejecución.
La presión va más allá de Cognition. Codex de OpenAI, los sistemas de programación respaldados por Anthropic, los agentes para desarrolladores de Google, Cursor y los frameworks de código abierto compiten por las cargas de trabajo de ingeniería.
Cada producto puede mejorar su puntuación de generación de código. Sin embargo, la adopción empresarial depende de lo que ocurre después de la generación, cuando una persona responsable debe aprobar un cambio importante.
Por eso el principal oponente no es un modelo rival. Es el flujo de trabajo que prioriza la revisión y se basa en leer cada línea significativa antes de confiar en el resultado.
Ese flujo existe por buenas razones. El código comunica arquitectura, costes futuros de mantenimiento, supuestos de seguridad y comportamiento ante fallos que una demostración breve quizá nunca revele.
Cognition no afirma que esas preocupaciones desaparezcan. Su objetivo declarado es que los ingenieros examinen menos código con el tiempo mientras entregan más trabajo terminado.
Esa formulación deja margen para una revisión selectiva. Los equipos podrían inspeccionar de cerca módulos de alto riesgo mientras aceptan una revisión guiada por evidencias para correcciones acotadas de interfaz, migraciones rutinarias o herramientas internas bien delimitadas.
El efecto práctico dependerá de lo bien que los equipos preserven el contexto de las tareas. Una base de conocimiento de ingeniería puede ayudar a los revisores a conectar la evidencia de un agente con requisitos, decisiones de diseño y fallos anteriores.
La verificación se vuelve más valiosa cuando refleja esas fuentes. Una grabación limpia significa menos si el agente malinterpretó el requisito que definía el éxito.
Astra convierte las pruebas en una habilidad independiente del agente
La contribución de Astra proviene de combinar uso de computadoras, juicio visual, razonamiento sobre la base de código e informes concisos dentro de un único ciclo de pruebas.
Un modelo de uso de computadoras interpreta una interfaz visual y realiza acciones como hacer clic, escribir, desplazarse y navegar entre pantallas. Las pruebas añaden otro requisito: esas acciones deben respaldar afirmaciones explícitas sobre el comportamiento esperado.
El ciclo de pruebas de Cognition comienza con un plan fundamentado en el repositorio. El agente examina el código relevante antes de declarar qué probará. Esto reduce la probabilidad de que invente rutas de interfaz o supuestos que la aplicación no respalda.
El plan también crea un punto de referencia para el informe final. Los revisores pueden comprobar si la ejecución cubrió el comportamiento previsto, en lugar de juzgar una grabación sin criterios establecidos.
Durante la ejecución, Devin puede anotar la línea de tiempo con notas de preparación y etapas de prueba con nombre. Puede marcar las afirmaciones como aprobadas, fallidas o no probadas.
Cognition afirma que exigir al agente que declare una expectativa antes de actuar reduce la racionalización. El agente tiene menos libertad para reinterpretar una pantalla inesperada como éxito después de ver el resultado.
Esto se parece al desarrollo guiado por pruebas, donde el comportamiento esperado se define antes de la implementación. Aquí, el compromiso ocurre durante la verificación del comportamiento, en lugar de antes de cada cambio de código.
Después, el agente puede operar un navegador, simulador o aplicación de escritorio. Captura lo ocurrido y devuelve artefactos que una persona puede inspeccionar de forma asíncrona.
Astra parece adecuado para esta etapa porque el modelo fue entrenado para el uso de computadoras y tareas profesionales largas de varios pasos. OpenAI afirma que puede instalar software, solucionar problemas visibles y ejecutar comprobaciones de calidad del frontend.
En los resultados de uso de computadoras publicados por OpenAI, Astra obtuvo un 72,6 % en OSWorld 2.0. GPT-5.6 Sol obtuvo un 65,7 % en la comparación reportada.
OpenAI también afirma que Astra completó esas tareas simuladas en unos 40 minutos de media. El modelo anterior necesitó aproximadamente 75 minutos. Estas cifras proceden del entorno de evaluación de OpenAI y no deben considerarse mediciones universales de producción.
El mismo lanzamiento informa de una puntuación del 57,9 % para Astra en Terminal-Bench 4.0. GPT-5.6 Sol obtuvo un 37,3 %, mientras que Claude Fable 5.1 obtuvo un 55,8 %.
En FrontierCode 1.1 Extended, Astra obtuvo un 64,5 %. Claude Fable 5 obtuvo un 64,9 %, por lo que Astra quedó ligeramente por detrás de ese modelo dentro del benchmark de Cognition.
Cognition describe FrontierCode como una evaluación propietaria de tareas reales de ingeniería. Su puntuación considera la calidad y la posibilidad de fusionar los cambios, y las soluciones que no superan criterios de bloqueo no reciben crédito.
Estas comparaciones sugieren que el atractivo de Astra no se limita a un mayor rendimiento bruto de programación. La declaración pública de Cognition enfatiza informes más claros, pruebas más completas y videos más fáciles de seguir.
Esas cualidades afectan directamente el tiempo de revisión. Una ejecución técnicamente exitosa aún puede desperdiciar atención humana si sus evidencias son confusas, extensas o no guardan relación con el cambio solicitado.
Un informe conciso debe identificar el comportamiento probado, el entorno, el resultado observado y la incertidumbre restante. Una grabación útil debe facilitar la localización de transiciones importantes, en lugar de obligar al revisor a recorrer una sesión sin editar.
Cognition también ha creado scripts deterministas para tareas de configuración repetidas. Un script determinista ejecuta una secuencia definida en lugar de pedir al modelo que improvise cada acción.
La autenticación es un ejemplo. Guiar un flujo de inicio de sesión mediante capturas de pantalla puede consumir tiempo e introducir fallos no relacionados con la función que se está probando.
Un script guardado puede crear rápidamente una sesión autenticada en el navegador. El agente puede entonces centrar su razonamiento en el comportamiento que importa.
Este diseño híbrido revela una lección de ingeniería importante. Unas mejores pruebas autónomas no significan asignar todas las operaciones a un modelo de lenguaje.
Los sistemas fiables reservan los pasos predecibles para la automatización convencional. Utilizan el modelo allí donde la interpretación, la recuperación o la navegación flexible aportan valor.
Cognition también permite que Devin proponga habilidades de prueba reutilizables tras resolver un problema de configuración difícil. El usuario puede revisar esa automatización antes de añadirla al repositorio.
Con el tiempo, esto puede convertir descubrimientos repetidos en infraestructura estable. El recorrido improvisado del modelo se transforma en un script revisado para futuras ejecuciones.
La combinación también controla la variabilidad. Si cada prueba comienza con un comportamiento de configuración diferente, comparar resultados se vuelve difícil y diagnosticar fallos resulta costoso.
Astra aporta percepción y razonamiento flexibles. Los scripts deterministas restringen las acciones repetitivas. El plan de pruebas define el éxito, mientras que el informe de evidencias expone qué cubrió la ejecución.
Ese mecanismo es más trascendente que otra ventaja en un benchmark. Describe cómo los agentes de programación pueden pasar de producir parches plausibles a participar en flujos de trabajo de ingeniería controlados.
El agente todavía no puede corregir sus propios deberes por sí solo
Las evidencias pueden reducir el esfuerzo de revisión, pero no pueden hacer que la autoverificación sea independiente, completa ni automáticamente fiable.
El riesgo más evidente es el fallo correlacionado. Si un agente malinterpreta la tarea al implementarla, el mismo sistema puede trasladar ese malentendido a su plan de pruebas.
El código y la prueba pueden entonces coincidir entre sí, aunque ambos discrepen del requisito real del usuario. Un informe limpio documentaría coherencia, no corrección.
Las pruebas independientes reducen este problema cuando proceden de especificaciones, de otro ingeniero o de un sistema de evaluación separado. Las suites de regresión existentes también aportan restricciones que el agente de implementación no inventó durante la sesión.
El enfoque de Cognition ayuda al fundamentar los planes en el código fuente y declarar expectativas antes de cada acción. Estas medidas pueden reducir la desviación, pero no crean una independencia real.
La empresa ha descrito abiertamente fallos anteriores. A veces Devin probaba áreas no relacionadas, quedaba atrapado en la configuración del entorno o no detectaba el comportamiento que una pull request pretendía modificar.
Estos problemas explican por qué el sistema necesita planes, anotaciones y herramientas de configuración determinista. También muestran que unas evidencias pulidas dependen de una orquestación que va más allá del modelo subyacente.
La prueba visual tiene límites adicionales. Un video puede mostrar que un flujo funcionó en un entorno y estado de datos concretos. No puede establecer una corrección amplia en distintos navegadores, permisos, condiciones de carga o entradas maliciosas.
Un informe puede identificar correctamente esas lagunas como no probadas. Los revisores aún deben decidir si las rutas omitidas importan lo suficiente como para bloquear el despliegue.
La cobertura cobra especial importancia en cambios de backend, infraestructura y seguridad. Muchos fallos graves no producen un síntoma visual evidente durante una ejecución breve.
Una migración de base de datos puede parecer exitosa antes de corromper un caso límite. Un cambio de permisos puede funcionar para la cuenta demostrada mientras expone los datos de otro tenant.
El código sensible para la seguridad requiere pensamiento adversarial, no solo confirmar que ocurrió el comportamiento esperado. Los equipos necesitan pruebas diseñadas para romper supuestos, en lugar de recrear el camino ideal.
OpenAI aplica restricciones a las capacidades avanzadas de ciberseguridad de Astra. El modelo puede ayudar con revisiones y parches seguros, mientras que algunos flujos de trabajo relacionados con exploits siguen limitados o monitorizados.
La cobertura independiente del lanzamiento de Astra también destacó cuestiones de seguridad no resueltas en torno al trabajo autónomo complejo. La fiabilidad en el mundo real sigue siendo menos segura de lo que sugieren las demostraciones controladas.
La calidad del software plantea un desafío a más largo plazo. Superar las pruebas de hoy no demuestra que los cambios repetidos realizados por agentes mantengan un código comprensible y adaptable.
Un análisis crítico de los límites de los benchmarks de programación sostiene que las pruebas actuales suelen pasar por alto la erosión estructural. El código puede seguir funcionando mientras se vuelve más difícil de modificar con seguridad.
Esa preocupación limita directamente la propuesta de “revisar menos código”. Los ingenieros leen código por más motivos que la corrección inmediata. Examinan abstracciones, límites de responsabilidad, lógica duplicada, observabilidad y coste de mantenimiento futuro.
Un video de ejecución no puede revelar todas esas cualidades. Tampoco un informe centrado en el comportamiento visible.
La política de revisión adecuada probablemente dependerá del riesgo. Un ajuste visual en un panel interno merece un escrutinio diferente de la lógica de autenticación, el procesamiento de pagos o la infraestructura crítica para la seguridad.
Los equipos pueden definir barreras de integración que combinen tipos de evidencia. Un cambio de bajo riesgo podría requerir una suite aprobada, un flujo de usuario grabado y un informe de alcance completo.
Un cambio de mayor riesgo también podría requerir revisión humana del diseño, pruebas de seguridad independientes e inspección manual de archivos sensibles. Las evidencias del agente pueden respaldar esos controles sin sustituirlos.
Otro problema es la integridad de las evidencias. Los revisores necesitan confiar en que las grabaciones correspondan al commit enviado, al entorno, la configuración y los datos de prueba.
Si los artefactos pueden desvincularse del código exacto bajo revisión, podrían describir una compilación anterior o configurada de forma distinta. Una procedencia sólida debería conectar cada afirmación con su estado de ejecución.
Cognition no ha detallado públicamente todos los controles de procedencia detrás del flujo de trabajo destacado. Su benchmark interno también sigue siendo propietario, lo que limita la comparación entre laboratorios independientes.
Por ello, la afirmación sobre el benchmark debe interpretarse como una señal de producto, no como una medida definitiva de la calidad de las pruebas autónomas.
Incluso los resultados públicos de OpenAI miden tareas acotadas. Los repositorios de producción contienen supuestos sin documentar, dependencias inestables, servicios privados y reglas de lanzamiento específicas de cada organización.
Astra puede mejorar la capacidad del agente para navegar esa complejidad. No elimina la necesidad de criterio de ingeniería para decidir qué evidencia es suficiente.
La distinción clave está entre prueba y evidencia. En la práctica habitual del software, las pruebas aportan evidencia de que ciertos comportamientos seleccionados funcionaron bajo condiciones definidas.
Rara vez demuestran una corrección total. El lenguaje público de Cognition utiliza a veces “probar” en sentido conversacional, pero los equipos deben conservar la interpretación de ingeniería más acotada.
Esta cautela no resta importancia a la función. Define dónde puede crear valor sin fomentar una confianza insegura.
Tres señales mostrarán si los ingenieros pueden revisar menos código
La siguiente prueba será si Cognition puede convertir demostraciones más sólidas en una adopción medible y consciente del riesgo en equipos de producción.
La primera señal es la reproducibilidad independiente. Cognition debería publicar suficientes detalles sobre su benchmark de pruebas para que terceros entiendan la selección de tareas, la puntuación, el enrutamiento de modelos y el manejo de fallos.
Los resultados reproducibles reforzarían la afirmación de que Astra mejora las pruebas, en lugar de limitarse a producir artefactos de mejor apariencia. También mostrarían con qué frecuencia el sistema informa honestamente de fallos o cobertura incompleta.
La calidad de las evidencias debe evaluarse por separado de la finalización de tareas. Un agente de pruebas puede alcanzar el resultado correcto y, aun así, proporcionar un informe inutilizable, o crear documentación persuasiva para una prueba incompleta.
Las mediciones útiles podrían incluir precisión de las afirmaciones, defectos no detectados, aprobaciones falsas, calibración de cobertura y tiempo de revisión. También deberían registrar si los revisores toman la decisión correcta de integrar el cambio.
Si evaluaciones independientes confirman mejoras en esas dimensiones, el flujo de trabajo de revisión ligera de Cognition ganará credibilidad. Si los resultados varían mucho entre repositorios, los equipos necesitarán reglas de despliegue más acotadas.
La segunda señal es el comportamiento en producción. Cognition afirma que las ejecuciones diarias de pruebas aprobadas han aumentado, pero el volumen de aprobaciones por sí solo no demuestra mejor software ni menor coste de revisión.
Los indicadores más sólidos son los cambios integrados, las tasas de defectos escapados, la frecuencia de reversión y el tiempo dedicado a revisar cada contribución aceptada. Los equipos deberían comparar esos resultados con cambios similares gestionados mediante revisión convencional.
Cognition ya ha explorado las “horas de ingeniería productiva” como métrica empresarial. Su evaluación utilizó 233 sesiones retenidas y concluyó que aproximadamente la mitad se situaba dentro de un factor de dos respecto a las estimaciones humanas.
La empresa también reconoció que las estimaciones individuales siguen siendo imprecisas. Según su análisis publicado, son habituales errores de dos o tres veces en cualquier dirección.
Esa franqueza importa porque las afirmaciones sobre productividad pueden desconectarse de los resultados del software. Una estimación de horas ahorradas no recoge el coste de un defecto descubierto tras el despliegue.
La evidencia más convincente conectaría una reducción del tiempo de revisión con una calidad estable o en mejora. Si los equipos inspeccionan menos código pero sufren más regresiones, el flujo de trabajo simplemente traslada el coste aguas abajo.
Si el tiempo de revisión disminuye sin empeorar los defectos, las reversiones ni el mantenimiento, la tesis central de Cognition se vuelve mucho más sólida.
La tercera señal es cómo los competidores rediseñan la verificación. Los proveedores de modelos y las empresas de agentes de programación pueden responder con agentes revisores independientes, trazas de ejecución más sólidas o formatos de evidencia estandarizados.
Una respuesta competitiva significativa confirmaría que la verificación se ha convertido en la capa principal del producto. También ofrecería a los compradores alternativas para evitar que un agente califique su propia producción.
Separar los modelos de implementación y revisión puede introducir una diversidad útil. Es menos probable que distintos proveedores, prompts o sistemas de generación de pruebas reproduzcan exactamente el mismo malentendido.
Sin embargo, la diversidad de modelos por sí sola no garantiza independencia. Dos agentes aún pueden depender de la misma especificación incompleta o de la suite de pruebas existente.
Los mejores sistemas combinarán diseño de pruebas independiente, controles deterministas, procedencia de artefactos y políticas de riesgo explícitas. La revisión humana podrá concentrarse entonces en decisiones que la automatización no puede comprimir con seguridad.
Los líderes de ingeniería deberían empezar seleccionando tareas acotadas en las que el comportamiento observable refleje claramente el éxito. Las correcciones de errores de interfaz, los flujos internos rutinarios y las regresiones bien especificadas son candidatos razonables.
Deberían exigir a Devin que indique qué no probó. También deberían comparar sus evidencias con el commit enviado y conservar los controles habituales para cambios sensibles.
Los desarrolladores pueden utilizar el nuevo flujo de trabajo como filtro de atención, no como autoridad. El informe identifica dónde mirar, la grabación muestra qué ocurrió y el código sigue disponible cuando el riesgo exige inspección.
El resultado que Cognition busca es plausible, pero no automático. Unas mejores pruebas pueden reducir el esfuerzo de revisión solo cuando la evidencia se mantiene fundamentada, acotada y conectada con los resultados en producción.
Por tanto, la pregunta más importante para los equipos es práctica: ¿qué cambios pueden aprobarse a partir de la evidencia de ejecución y cuáles siguen exigiendo revisar cada línea relevante? Pongan a prueba ese límite de forma deliberada antes de incorporar las pruebas de Devin GPT-6 Astra a su proceso predeterminado de integración.
