Automatización de QA Móvil con Agentes en la Nube

Hola, Londres. Parece que ahora usamos agentes para prácticamente todo. Como ingeniero móvil durante casi 90 años, me gusta lanzar agentes a mis desafíos y tareas móviles y probablemente automatizarme fuera de mi trabajo pronto. Afortunadamente, también estoy construyendo herramientas para el desarrollo móvil.

¿Cuántos de ustedes han construido alguna vez una aplicación móvil? Independientemente de si construyes aplicaciones móviles o web, probablemente hayas experimentado esto. La diferencia parece estar bien, las verificaciones de CI están en verde, apruebas una solicitud de extracción, y luego la aplicación hace algo completamente inesperado en un dispositivo real. El código cambió, pero el usuario no experimenta una diferencia. Ellos experimentan el producto.

En los últimos años, y especialmente en los meses recientes, la IA ha cambiado la forma en que escribimos código y lanzamos productos. De hecho, rara vez somos nosotros quienes escribimos el código ahora, enviando una, dos, tal vez tres solicitudes de extracción al día a la base de código a la que contribuimos. Nos volvimos un poco más rápidos cuando aparecieron los modelos de pestañas. Pero con agentes de IA, como Cloud Code o Codex, llegando a finales de 2025, simplemente explotó. No se trata solo de LLMs ahora, sino de los arneses, habilidades y bucles. Y estos agentes son muy buenos produciendo código rápidamente. Pueden redactar implementaciones, refactorizar archivos, abrir PRs y responder a comentarios de revisión.

Este es un cambio real. El costo de obtener una solicitud de extracción plausible está disminuyendo rápidamente. Pero la confianza no se ha abaratado al mismo ritmo. Alguien todavía tiene que decidir si enviar este cambio. Y esa decisión es más difícil cuando el código fue producido más rápido por sistemas más automatizados sin nuestra supervisión directa. La revisión de código tradicional asume un cierto ritmo. Un humano escribe el código, otro humano lee la diferencia, CI ejecuta pruebas, y el equipo construye confianza a partir de ese contexto. El modelo comienza a tensarse cuando los agentes aumentan tanto el volumen como la forma de los cambios. Los primeros datos de la actualización de disponibilidad de GitHub de 2026 muestran solicitudes de extracción fusionadas alcanzando su punto máximo cerca de 90 millones por mes, más del 100% de crecimiento en un año, anteriormente creciendo con dígitos dobles más bajos anualmente. No es por coincidencia, las plataformas ya están viendo la presión de los flujos de trabajo impulsados por agentes que tensan su infraestructura, lo cual experimentamos casi a diario recientemente en GitHub. Las reacciones son solo tan buenas como para atrapar a lo sumo el 60% de los posibles errores, siempre que las diferencias sean menores de 200 líneas y sean expertos en la base de código. Más que eso y se vuelve demasiado para manejar. Y creo que todos experimentamos eso. Sin mencionar que a los ingenieros les toma un tiempo considerable y enfoque realizar la revisión. Pero bueno, los problemas modernos requieren soluciones modernas.

Podemos simplemente lanzar más code agents, code review agents, a nuestra base de código y eso ciertamente lo hará. Bueno, no realmente. Investigaciones tempranas muestran que la revisión de código agentic aún encuentra menos defectos en comparación con los humanos que son expertos en el tema y, en mi experiencia, está mejorando y es mucho más efectiva cuando se realiza con un modelo diferente. Lo importante es que realmente escala con el tráfico pero sufre de algunos desafíos fundamentales. La mayoría de los agentes están mal configurados o optimizan el costo y solo detectarán detalles menores, algunos errores superficiales, problemas de tipo o falta de pruebas. La revisión de código agentic está perdiendo una visión más amplia de tu producto.

A menudo es tan extensa que se sale de control y requiere otra IA para procesarla. Aún no es mejor que los humanos para encontrar errores, al menos todavía no, y no puede verificar que la aplicación funcione de extremo a extremo. E incluso una revisión de código perfecta solo puede detectar una cierta clase de problemas mientras es totalmente ciega para otros. En aplicaciones móviles y web, un error a menudo se esconde entre archivos o en formas sutiles en que las bibliotecas y las APIs nativas que usamos funcionan. Por ejemplo, la navegación puede hacer un bucle inesperadamente, un aviso de permiso puede bloquear la primera ejecución, una biblioteca nativa que usamos se bloqueará inesperadamente bajo carga, un teclado cubre el botón de acción principal, un deep link aterriza en un lugar incorrecto, una versión de lanzamiento se bloquea donde una de depuración funcionó. El código puede ser internamente coherente y aún así producir un flujo roto.

Bueno, ciertamente podemos resolver la revisión de código con más pruebas de extremo a extremo. Están probando los flujos de usuario en tiempo de ejecución. El problema es que son bastante lentas de ejecutar, inestables, y a menudo no prueban el comportamiento que acabamos de alterar en nuestras pruebas y en nuestro div. ¿Cómo lo sabrían? La superficie de revisión tiene que expandirse. Todavía deberíamos revisar el código, todavía deberíamos ejecutar pruebas, pero para aplicaciones móviles, especialmente en un mundo lleno de agentes, también necesitamos revisar la aplicación en ejecución antes de fusionar, rápidamente. Necesitamos la revisión del comportamiento de la aplicación. Necesitamos un nuevo tipo de agente que verifique el comportamiento de la aplicación en cada pull request, idealmente.

La parte importante es que a este agente no se le dice que explore nada. Recibe una misión de producto delimitada, verificar la incorporación y el registro, comprobar la pantalla de pago, validar la edición de perfil, inspeccionar el flujo afectado por este PR, e idealmente, necesita inferir esto a partir de los metadatos disponibles.

Vamos a explorar la pila sobre la cual podríamos construir un agente de QA móvil. La pila que ya tienes o que puedes integrar fácilmente. Lo que necesitas es un servidor CI-CD como tu entorno, un proveedor de modelo de lenguaje grande, un arnés para el agente de IA, una herramienta para controlar simuladores de iOS y Android de manera eficiente, un almacenamiento de blobs para capturas de pantalla y grabaciones, y un bot de comentarios que lo une todo.

Entonces, AISDK nos da la estructura para llamadas de modelo, uso de herramientas, estado, y el bucle entre observación y acción. El agente no conoce mágicamente la aplicación, observa, decide, actúa e informa. Podemos programarlo como queramos, gracias a esta biblioteca. Este es nuestro arnés.

AI Gateway nos proporciona una interfaz para cualquier modelo de IA, por lo que podemos observar el uso, aplicar controles, y cambiar modelos sin reescribir el agente. Podemos experimentar con diferentes modelos para diferentes tipos de agentes también muy fácilmente en este flujo. Agent device es para el control de dispositivos móviles orientado al agente. Permite al agente abrir la aplicación, leer la pantalla a través de capturas de pantalla e información de accesibilidad que está adaptada y limitada a un tamaño más pequeño. Permite tocar, escribir, inspeccionar el estado, recopilar registros y capturar evidencia directamente desde dispositivos iOS y Android.

En esta demostración, puedes ver que está controlando la aplicación en mi iPhone, por lo que funciona con simuladores y dispositivos reales también. En este caso, necesitaremos simuladores. Un almacenamiento de blobs. Queremos ver capturas de pantalla y grabaciones en los comentarios de nuestra pull request, por lo que tenemos que almacenarlo en algún lugar. Y blob de Vercel es muy fácil de configurar, y simplemente funciona. Pero también podría ser S3 o R2, lo que tengas.

Así de fácil es construir un agente con AISDK cuando juntamos todo esto. Tiene llamadas de herramientas para agent device, configuración de dispositivo determinista, por lo que los agentes no tienen que adivinar cada vez, y un mensaje del sistema que ayuda al agente de QA a conocer tu producto e inferir criterios de aceptación y flujos relacionados a partir de la descripción de la pull request, el código afectado o los problemas vinculados. Y francamente, ni siquiera necesitas programarlo tú mismo, porque estas escalas pueden manejar eso por ti. Así que lo configuras en GitHub Actions, EAS workflows, u otro proveedor de CI que nos dé Mac OS y cajas de Linux con virtualización, y configuración de huellas digitales para reutilización rápida de compilaciones. Allí podemos programar la ejecución de nuestro agente de QA en cada PR, y conectar fácilmente un bot de comentarios.

Y recuerda, queremos que toda la configuración sea lo más determinista posible. Eso reduce la inestabilidad y también los costos de inferencia de IA. Así que, veamos cómo todo esto funciona junto en una pull request de ejemplo.

Así es como funciona en la práctica. Tengo aquí una pull request de ejemplo que está añadiendo una pestaña inferior de call stack a mi aplicación. Así que, puedo mirar el código, y puedo ver una pantalla superior con el título call stack, así que eso está bien.

Hay algunos servicios aquí, algunas cosas que call stack hace. Aparentemente, hay algún texto de tema, vista de tema. Bien, esto parece más o menos correcto. Hay algunas elecciones de iconos interesantes aquí.

Entonces, me pregunto cómo se ve esto en la práctica. Normalmente, necesitaría descargar esta app, ejecutarla en mi dispositivo. Pero con el agente de QA que acabamos de construir, obtengo información rápida de que este div está pasando las pruebas de Android y iOS, y tenemos capturas de pantalla para respaldarlo. Aquí podemos ver la pantalla de Android que tiene una nueva pestaña de call stack. No está clicada, así que el agente no se dio cuenta de dejar una captura de pantalla para esta. Pero para iOS, realmente presionó la nueva pestaña, y podemos ver que hay un call stack. Hay alguna oferta. Sí, esto se ve más o menos bien.

Veamos qué hizo realmente el agente de Android. Completó el QA para el PR, verificó correctamente el primer plano de la app, la nueva pestaña inferior, y la pantalla de call stack muestra las secciones de resumen esperadas. El agente realmente pudo visitar esa pantalla, pero simplemente no capturó la captura de pantalla relevante. Esto es algo que probablemente podamos investigar y mejorar en nuestro agente. Y si quieres ver cómo se ve esto en la práctica, en los scripts, agent QA index DS, tenemos nuestro agente completo. Como puedes ver, es un agente de bucle de herramientas de AISDK. Todo el archivo tiene alrededor de 900 líneas. Cuando la mayoría de las instrucciones están aquí, lo importante es que el agente tenga acceso a algunas llamadas de herramientas para obtener datos del contexto del PR, manejar el dispositivo del agente y escribir el informe.

Y si te gustaría ver cómo funciona esto con un framework diferente, Vercella lanzó un nuevo framework llamado EVE para que la mayoría de nuestro agente pueda caber en un archivo MD de instrucciones. Solo estamos definiendo nuestro modelo aquí. Y eso es la mayor parte de nuestro agente. Nos queda una llamada de herramienta al dispositivo del agente que es muy similar a la de nuestro AISDK. Así que esto es todo para la demo. Espero que esto sea bastante útil. Al construir tu propio agente móvil, debes recordar cinco reglas clave que harán que los revisores humanos confíen en él y disfruten trabajar con él. Primero, asegúrate de que esté configurado de manera determinista para evitar inestabilidad. Segundo, dale todo el contexto de tu producto, pantallas, capacidades, mejores prácticas de la plataforma, y guías para tu app. Usa modelos de IA económicos para que pagues centavos en lugar de dólares por prueba. Muestra evidencia relevante, capturas de pantalla, pantallas visitadas, notas relacionadas con tu diff. Y asegúrate de que los resultados sean repetibles mejorando el agente con planificación, memoria, y casos de prueba de ejemplo. El botón de merge se está convirtiendo en una decisión de confianza. Y en bases de código modernas que están llenas de código escrito por agentes, los revisores necesitan más que un diff plausible y un check verde.

Necesitan evidencia de comportamiento del producto en sí. No necesitamos aceptar el statu quo que tenemos hoy. Con las herramientas e infraestructura adecuadas, podemos cambiar, adaptarnos y aprovechar todo el potencial de los agentes de codificación de IA. Permitámonos iterar en nuestros productos más rápido que nunca con más confianza y confianza basada en evidencia.

Muchas gracias. Asegúrate de bifurcar el agente de QA en GitHub y prueba AgentDevice. Dale una estrella si te gusta y sígueme en Axe bajo este handle. Saludos. Muchas gracias, Michal, por tu sesión y a todos. En el backstage tuvimos una charla rápida con Michal sobre cómo se siente ligeramente diferente todo este desarrollo nativo de IA para el desarrollo web y para el desarrollo nativo móvil. Creo que ambos estuvimos de acuerdo en que es un poco más desafiante involucrar toda la asistencia verdaderamente nativa de IA y los flujos de trabajo y todo en el verdadero desarrollo nativo móvil, porque está un poco más cerca de la web.

Tal vez tengan la misma sensación, amigos. Siéntanse libres de publicar y compartir sobre eso. Pero veo que tenemos una pregunta de Alejandro. Creo que uno de nuestros asistentes más activos hoy. Sean como Alejandro, todos, amigos. Veo que intentó usar Playwright MCP, pero hubo algunas dificultades para organizar pruebas completas de extremo a extremo. La pregunta es cómo se almacena todo el flujo de la aplicación para ser utilizado por el agente. Creo que puedes elaborar sobre eso, Michal. Esto depende completamente de ti. Lo que estoy mostrando, por ejemplo, es construir un agente personalizado que es muy simple. No tiene memoria persistente, por ejemplo, que resuelve cosas sobre la marcha. Y creo que aún no tiene un modo planificado, por ejemplo, lo cual ayuda mucho en términos de crear flujos reutilizables.

Esto es solo el comienzo. El primer agente que puedes probar, puedes ver lo fácil que es comenzar. Y luego comienza a aumentar en complejidad, generalmente porque necesitas configurar algo de infraestructura. Para los proyectos que estamos haciendo diariamente, lo llamamos infraestructura de QA agentic. Y como parte de eso, ¿qué queremos decir con esta infraestructura? Son todas las habilidades, el conocimiento de tu aplicación. Estamos tratando de obtener del equipo existente, trabajando en la aplicación, de qué se trata esta aplicación. ¿Cómo se siente? ¿Cuáles son los objetivos que ayuda a los usuarios a lograr? Todo es importante porque le da al agente un contexto adicional. Así puede averiguar algunos flujos por sí mismo cuando no son conocidos.

Otro nivel de esa infraestructura son todas las habilidades necesarias, habilidades para las mejores prácticas en algunas plataformas como iOS y Android. O cuando se trata de una aplicación React Native, algunas mejores prácticas sobre el manejo de aplicaciones React Native, por ejemplo, con todos los servidores de desarrollo, etc. Y aún más importante es tener dos cosas adicionales, que es tu mapa de pantalla. Así que en aplicaciones móviles y también en aplicaciones web, tienes navegación. Así que es importante que los agentes entiendan cómo navegar por tu aplicación. Este es un proceso que a menudo hacemos manual o semiautomáticamente para comenzar. Así que lo importante es dar a los agentes tanto contexto sobre tu producto y los flujos de usuario como sea posible. Y también si tienes pruebas de extremo a extremo, por ejemplo, puedes convertirlas en planes, por ejemplo, y dar a los agentes esta lista de diferentes escenarios que puede elegir cuando está verificando tu cambio.

Y con respecto a Playwright MCP, no lo he usado, así que es difícil para mí decir si este fue el problema, probablemente no. Para uso web, ya sea que use soporte web de agent device o agent browser, que en realidad se ejecuta en segundo plano. No soy un desarrollador móvil, pero solo puedo agregar que escucho cada vez más a menudo que si hay una selección, hay MCP y CLI disponibles para la misma herramienta con las mismas capacidades. Si trabajas con agentes de IA, opta por CLI porque podría ser un poco más, no sé cómo decir esto, predecible y tal vez incluso puedas ahorrar algunos tokens en eso. Así que tal vez, quiero decir, comienza simplemente probando CLI. Sé que hay un increíble CLI para Playwright. Esa es mi recomendación personal.

Y tenemos una pregunta más sobre la comparación. Entonces, ¿cómo se compara la exploración autónoma del agente con una suite de regresión curada en términos de los tipos de errores que encuentra? ¿Realmente detecta cosas que una prueba escrita por humanos pasaría por alto? ¿Algo de tu experiencia, Michal?

Sí, creo que esta es realmente una pregunta sobre dogfooding. Cuando hablamos de agentes explorando autónomamente nuestra base de código, queremos darles algunas instrucciones y algo de libertad, pero no demasiada. Entonces, por ejemplo, en un agent device, tenemos una habilidad de dogfooding, que puedes esencialmente pedirle a tu agente que ejecute una sesión de dogfooding con agent device y comenzará a explorar tu aplicación de maneras aleatorias.

Puedes decirle que actúe como un cierto tipo de usuario, por ejemplo, como un Gen Z o millennial o lo que sea. Y en mi experiencia, este tipo de exploraciones están encontrando cosas que los humanos no están detectando, como texto inconsistente, especialmente en aplicaciones internacionalizadas donde algunas cadenas no están correctamente traducidas o algo que encontré en una aplicación fue como una promoción local en alguna tienda local para alguna tienda de comercio.

Así que al acceder a esta tienda, en realidad fui dirigido a algo diferente. Un agente me dijo que este enlace era incorrecto. Debería dirigirme a una ubicación de tienda, pero terminé en un lugar totalmente diferente. Y era como una promoción específica de tiempo en esa tienda, así que solo se mostraría por una semana o algo así. Y la forma en que me gusta ejecutar estos es escribir un buen prompt con algunas instrucciones extensas sobre qué buscar o qué romper, básicamente, o intentar romper y ejecutarlo cada semana o así como una sesión de caza de errores.

Y puedes recompensar a tu agente con ciertas cosas por cierto comportamiento o error encontrado, por ejemplo, para que pueda ser más persistente. O puedes darle un objetivo si estás usando un code code o codex harnesses, y puedes usarlos fácilmente incluso con tu agente personalizado. Así que, por ejemplo, ahora AISDK7 soporta el uso de Cloud Code, Codex y algunos otros harnesses para que no necesites crear el tuyo propio con tus propias llamadas de herramientas, etc. Así que es bastante genial. Realmente recomiendo simplemente jugar con ello.

Así que, como con cualquier cosa con IA, es muy fácil comenzar y luego toma un largo tiempo simplemente jugar con pequeños cambios de redacción. Lo bueno es que puedes delegar esto a la IA si eres bueno estableciendo metas y límites alrededor de ello. Muchas gracias por una respuesta tan detallada. Quiero decir, solo estoy pensando, ¿cómo podemos recompensar a los agentes? ¿Qué tipo de recompensa prefieren? Como más tokens, tokens más sabrosos, algo así. Muchas gracias, Michal. Fue un gran placer ver tu sesión y tener esta breve conversación. Mantengámonos conectados y mantengámonos conectados todos. Adiós, Michal. Gracias. Que tengas un buen día.