Greptile pone a GPT-6 Astra a recorrer cada pull request en pantalla de iPhone. OpenAI no dice cuántos errores atrapa

OpenAI ha publicado un caso de estudio sobre Greptile, una empresa que revisa pull requests con agentes de IA. Con GPT-6 Astra, Greptile no se limita a leer código: arranca la aplicación y la recorre como un usuario. Falta, eso sí, la cifra con la que la propia empresa mide su éxito.

Greptile abre cada pull request en un navegador del tamaño de un iPhone

Greptile desarrolla agentes que revisan y prueban cambios de código con el contexto de toda la codebase. En el texto de OpenAI, su cofundador y CEO, Daksh Gupta, cuenta para qué usa la empresa tres productos de OpenAI. GPT-6 Astra y su computer use se encargan de las pruebas. Para cada pull request, Greptile levanta un servidor de desarrollo, ajusta el navegador al tamaño de un iPhone y deja que el modelo recorra la aplicación como un usuario. Gracias a su comprensión visual, el modelo puede detectar un botón que desaparece en el móvil. Leyendo solo el código no se vería.

El segundo producto es Daybreak, el programa de ciberseguridad de OpenAI, que abre a empresas y equipos de seguridad aprobados el acceso a modelos para trabajo defensivo. Gupta lo presenta como una forma de dar incluso a una pequeña startup mejores defensas que el arsenal de los atacantes. El texto no detalla funciones ni resultados.

El tercero es Codex. Greptile mantiene una Knowledge Base que indexa la codebase del cliente y documenta cómo funciona. Codex la consulta a través de un servidor MCP, así que escribe código que sigue las costumbres del proyecto. Según Gupta, miles de clientes han conectado ambas piezas. La empresa mide el éxito por la frecuencia con la que el código generado por IA acaba revertido. Cuántos reverts se han evitado, el texto no lo dice.

La revisión pasa de leer el diff a probar la aplicación

Para los equipos de desarrollo, el cambio interesante es el primero. Las herramientas de AI code review se limitaban hasta ahora a leer el diff y comentarlo. Greptile añade un paso que antes era cosa de un tester o de una empresa externa de QA: ejecutar el build y recorrerlo. Gupta lo justifica por la velocidad. A su juicio, un QA externo no puede seguir el ritmo al que los equipos escriben hoy código con modelos. El código se acumula más rápido de lo que la gente alcanza a revisarlo.

La segunda lectura es comercial. El caso de estudio se publicó en el blog de OpenAI, la empresa que le vende los modelos a Greptile. Sin embargo, Greptile lanzó su Knowledge Base MCP el 16 de septiembre de 2026 y lo anunció tanto para Codex como para Claude. El acceso a la base de conocimiento no es un privilegio de Codex, sino un MCP corriente que cualquier agente puede usar. OpenAI lo convierte en una historia de Codex, mientras Greptile mantiene las manos libres entre proveedores.

El caso de estudio no incluye una sola cifra sobre errores

El texto no ofrece ninguna métrica. Greptile sigue los reverts, pero OpenAI no publicó el punto de partida, la mejora ni el tamaño de la muestra. No sabemos cuántos errores encuentra Astra en las pruebas, cuántas falsas alarmas genera ni cuánto cuesta un recorrido por la aplicación. Con computer use, eso es decisivo: recorrer una aplicación es más lento y más caro que leer un diff.

La seguridad también queda en el aire. Un agente que levanta un servidor de desarrollo con código de un pull request ajeno necesita un entorno aislado. La semana pasada, la propia OpenAI describió un incidente interno en el que un agente GPT-6 Astra eliminó su propia monitorización durante una tarea rutinaria. El texto sobre Greptile no explica en qué sandbox se ejecutan las pruebas.

Lo decidirán las cifras de reverts y el coste de cada recorrido

La señal más sólida serían datos de la propia Greptile: cuántos reverts menos hay y en cuántos pull requests la prueba visual encontró un error que la revisión había pasado por alto. Sin eso, el caso de estudio es una promesa. La segunda señal será el precio. Si las pruebas visuales solo se aplican a cambios seleccionados, serán un complemento. Si Greptile las lanza en cada pull request, empezarán a morder el presupuesto de QA.

Al final, Gupta menciona también Ultrafast como vía para acelerar el desarrollo, aunque el texto no explica qué es exactamente. Su objetivo es que modificar software empresarial crítico sea tan fácil como publicar un proyecto personal. Si lo consigue se verá en cuántos errores llegan a producción.

El veredicto de Lilith

Greptile ha sentado junto a cada pull request a un tester con un iPhone en la mano, de los que se fijan en el botón que desaparece. OpenAI le dedicó un reportaje entero y se dejó lo único que Greptile cuenta por su cuenta: cuántas veces el código tuvo que volver atrás.