Probar una aplicación va más allá de revisar que el front-end se vea bonito. Aquí aprenderás cómo usar Codex para validar un flujo real de usuario, desde agregar una fuente en Notion hasta verificar datos en Supabase y reportar fallos como issues en GitHub. Es una guía práctica para quien construye apps con IA y quiere asegurar que todo funcione de punta a punta.

¿Cómo abrir y probar el front-end dentro de Codex?

Codex incluye un skill nativo de manejo del navegador. Eso significa que puedes pedirle que abra tu front-end en su navegador interno, lea la información renderizada y la despliegue de forma automática.

En pocos segundos tienes la app cargada sin salir del entorno. A partir de ahí, puedes empezar a probar casos de uso reales como si fueras un usuario más.

¿Qué es un caso de uso en pruebas de software? Es un escenario concreto que describe cómo un usuario interactúa con la aplicación para lograr un objetivo, por ejemplo, agregar una fuente y verificar que se guarde correctamente.

¿Cómo pedirle a Codex que pruebe un flujo end to end?

La clave está en redactar un prompt claro, con pasos secuenciales y verificaciones explícitas. En el ejercicio se le pidió a Codex que ejecutara cuatro acciones encadenadas:

• Agregar una nueva fuente a Notion y verificar que exista.
• Buscar las últimas noticias de inteligencia artificial en paralelo, asegurando que la nueva fuente fuera tomada en cuenta.
• Confirmar que en Supabase se guardaran las nuevas noticias.
• Validar en el front-end que la información de la base de datos fuera visible.

Una instrucción extra marcó la diferencia: si algo falla, anótalo y repórtalo al final, sin implementar cambios todavía. Esto evita que Codex modifique código antes de que tú revises los hallazgos.

¿Qué reportó Codex después de la prueba?

Tras un par de minutos, Codex devolvió un reporte limpio. Notion OK, búsqueda en paralelo OK, Supabase OK. Pero apareció una falla en el front-end: no mostraba la información nueva desde Supabase y seguía renderizando datos del 22 de mayo.

Ese tipo de hallazgo es justo lo que buscas en una prueba: un punto concreto donde el flujo se rompe.

¿Cómo crear issues en GitHub desde Codex?

Un buen reporte de bug no es solo decir no funciona. Como buena práctica de programación, cada issue debería incluir:

• Evidencias del problema.
• Pasos para reproducirlo.
• Resultado esperado.
• Resultado actual.
• Archivos probables involucrados.
• Criterio de aceptación.

Para que Codex pueda crear estos issues automáticamente, necesitas habilitar la integración con GitHub.

¿Cómo se instala el plugin de GitHub en Codex?

El proceso toma menos de un minuto y se hace en pocos clics:

1. Entra a Complementos dentro de Codex.
2. Baja hasta la opción de GitHub y habilítala.
3. Da clic en instalar GitHub.
4. Inicia sesión con tu usuario, por ejemplo desde Google.
5. Autoriza el acceso y abre Codex de nuevo.

Con eso, GitHub queda conectado como plugin de tu Codex y puedes empezar a generar issues desde el chat.

¿Qué es un criterio de aceptación en un issue? Es la condición que debe cumplirse para considerar el bug resuelto. Por ejemplo: el front-end muestra las noticias guardadas en Supabase en tiempo real, sin datos desactualizados.

¿Qué pedirle a Codex para generar los issues?

Una vez instalado el plugin, vuelves al chat y le pides algo así: crea issues en GitHub para cada hallazgo, cada uno debe incluir evidencia, pasos a reproducir, resultado esperado, resultado actual, archivos probables y criterio de aceptación.

En el ejercicio, Codex tardó 53 segundos en crear tres issues completos en el repositorio. Al abrir el primero, ya aparecía estructurado con todo el detalle necesario para que cualquier persona del equipo pudiera reproducir el problema.

¿Por qué separar pruebas, reporte y solución?

Pedirle a Codex que reporte sin implementar cambios te da control. Primero ves los hallazgos, luego decides qué arreglar y en qué orden. Esa separación entre QA, documentación y desarrollo es lo que hace que un flujo asistido por IA se sienta profesional y no caótico.

Además, dejar el rastro en GitHub convierte cada bug en algo trazable, no en un comentario perdido en un chat.

Reto: ¿puede Codex arreglar sus propios hallazgos?

Ahora te toca a ti. Pídele a Codex que vaya a GitHub, tome los issues creados, los arregle y vuelva a probar todo el flujo de principio a fin.

Déjame en los comentarios cuántos errores encontró Codex, cuántos issues creó y cuántos logró arreglar en su segunda pasada.