Me gusta mucho probar modelos de IA, a tal punto que ya me dicen el Chico IA. Cuando aparece uno nuevo, enseguida estoy pensando qué proyecto podría darle, con qué herramientas conectarlo y hasta dónde podría llegar.
Con ChatGPT-6 Astra me pasó exactamente eso.
Lo que más curiosidad me daba era verlo trabajar durante un buen rato: entender un proyecto, usar otras aplicaciones y resolver lo que fuera apareciendo. Esa posibilidad me entusiasma bastante. También hace que me ponga más exigente con el resultado.
Porque después de la primera impresión llegan preguntas bastante prácticas.
¿Terminó lo que le pedí?
¿El código está bien?
¿Cuánto de mi cuenta consumió?
¿Cuánto trabajo me dejó para después?
Mi primera prueba terminó justo en medio de esas preguntas.
Quince componentes después, me quedé sin créditos
Para probarlo diseñé WIRBI Freefall, un prototipo 3D de paracaidismo donde recoges las letras WIRBI y esquivas obstáculos.
Le pasé el diseño a Astra y lo conecté con Higgsfield mediante MCP.
En unos 50 minutos generó 15 componentes, entre ellos el personaje, el paracaídas, el avión, las letras y varios obstáculos.
Me gustó verlo interpretar lo que necesitaba el proyecto y utilizar otra herramienta para producirlo. Ahí se entiende el atractivo de estos agentes: puedes dedicar más atención a lo que quieres construir mientras ellos avanzan con parte de la ejecución.
Entonces me quedé sin créditos de Work.
Y ahí terminó la primera tanda.
En ese momento tenía bastantes piezas del juego, pero todavía faltaba lo más importante: integrarlas y comprobar si realmente podían convertirse en una experiencia jugable.
Por eso quise hacer una segunda prueba.
Segunda tanda: ahora sí existe un juego
Retomé WIRBI Freefall en una segunda tanda y esta vez el objetivo ya no era generar componentes.
Era hacer que todo funcionara junto.
El resultado ya está disponible y se puede probar directamente aquí:
https://wirbi-freefall.higgsfield.app/
Y para mí esto cambia bastante la evaluación.
Ya no estoy mirando solamente imágenes, componentes o fragmentos de código generados por una IA. Ahora puedo abrir lo que hizo, jugarlo, probar las mecánicas y ver qué tan bien quedó realmente.
¿Está terminado?
No.
La cámara todavía resulta algo incómoda de utilizar y creo que necesita bastante más trabajo para sentirse natural.
La recolección de objetos también está un tanto rota. Hay momentos donde la interacción no se siente tan consistente como debería y definitivamente es una de las primeras cosas que habría que corregir en una siguiente iteración.
Pero, considerando que estamos hablando de una primera versión funcional surgida de este flujo entre Astra, MCP y Higgsfield, me parece un resultado bastante bueno.
Y personalmente prefiero esto a una demo donde solamente puedo decir que la IA produjo quince componentes.
Ahora tengo algo que realmente puedo jugar.
También tengo algo que puedo evaluar de verdad.
Porque una vez que existe el producto puedo dejar de mirar solamente cuánto generó Astra y empezar a fijarme en algo bastante más importante: qué tan bien convirtió todo ese trabajo en una experiencia coherente.
La primera tanda me mostró que Astra podía producir las piezas.
La segunda empezó a responder una pregunta mucho más importante:
¿Puede convertirlas en algo que realmente funcione?
La respuesta, por ahora, es sí.
Pero todavía necesita iteración.
Y justamente eso es lo que quería comprobar.
Pero con el código, prefiero mirar dos veces
Revisando otras pruebas encontré un resultado que me pareció interesante.
En la comparativa de Serudda entre Astra y Fable 5.1, ambos trabajaron sobre el mismo proyecto y recibieron el mismo encargo: añadir una funcionalidad de descarga de videos.
Según el análisis de esa prueba, Astra terminó en unos 13 minutos y Fable en casi 19.
Los dos entregaron una solución funcional.
Serudda valoró la limpieza del código de Astra y su comunicación más concisa, pero encontró que Fable había contemplado mejor errores como una URL inválida o un video privado.
Ese detalle pesa bastante para mí.
Una implementación puede verse ordenada, funcionar en la primera prueba y dejar sin resolver situaciones que aparecerán en cuanto la use otra persona.
En una página web, un panel administrativo o un backend, esas situaciones llegan:
datos incompletos, usuarios sin permisos, servicios externos que fallan.
Me interesa cuánto tarda el agente en desarrollar una funcionalidad, pero también qué ocurre cuando algo sale mal.
Por eso no sacaría una conclusión general sobre la calidad de Astra a partir de una sola prueba.
El resultado de Serudda fue bueno en varios aspectos y dejó dudas en otros.
Todavía falta ver cómo se comporta en proyectos grandes, con deuda técnica y después de muchas modificaciones.
Yo seguiría revisando arquitectura, validaciones, dependencias y pruebas.
Si una entrega rápida me obliga a pasar la tarde corrigiéndola, ese tiempo también forma parte del costo.
Y ahora que tengo WIRBI Freefall funcionando, esa idea me parece incluso más evidente.
Generar algo rápidamente es una cosa.
Conseguir que el resultado final se sienta bien al utilizarlo es otra.
La cuenta importa más de lo que parece en una demo
Mi prueba me dejó muy presente la diferencia entre tener acceso a Astra y tener suficiente uso disponible para terminar lo que quiero hacer.
En la investigación que revisé también se recoge un consumo alto en la prueba de Serudda: una tarea de alrededor de 20 minutos habría utilizado más de la mitad de la cuota de cinco horas de una cuenta de US$20.
Es una observación de esa ejecución, no una medida que pueda aplicarse a todos los proyectos.
Esa cuota tampoco equivale a cinco horas continuas de trabajo garantizadas.
Aun así, la pregunta queda planteada.
Si voy a incorporar un agente a mi jornada, necesito saber cuántas tareas parecidas a las mías puedo completar con la cuenta que estoy pagando.
Para quien está evaluando usarlo, esta es la comparación de suscripciones que me parece más útil:
Plus: US$20 al mes.
Incluye acceso a Astra en Work y Codex, sujeto al despliegue y a los límites de la cuenta.
Pro: US$100 o US$200 al mes.
Incluye acceso a Astra en Work y Codex, con mayor asignación de uso que Plus.
Business: US$25 por usuario al mes, o US$20 con pago anual; mínimo dos usuarios.
El acceso está contemplado en Business estándar, con límites y permisos del espacio de trabajo.
Enterprise: cotización comercial.
El acceso depende de la elegibilidad y de la habilitación del administrador.
Precios y acceso consultados al 10 de septiembre de 2026 en la documentación oficial de precios.
Enterprise tiene condiciones adicionales durante el despliegue inicial.
Esta comparación se refiere al acceso a Astra.
La suscripción ChatGPT Pro y el modo Pro del modelo son cosas distintas; esa diferencia merece una explicación aparte.
Si tienes Plus y no ves Astra en el chat habitual, revisa Work o Codex.
La disponibilidad y el selector pueden variar durante el despliegue, como explica la guía de novedades de OpenAI.
Antes de subir de plan, yo probaría con una tarea representativa del trabajo diario.
Así tendría una base para decidir si necesito más capacidad, una mejor definición del encargo o repartir el trabajo entre modelos.
Astra Pro también me interesa, aunque todavía no lo he probado
Me quedé con curiosidad por Astra Pro.
Todavía no he podido probarlo, así que aquí hablo de lo que pude documentar y de las preguntas que me deja.
Las pruebas de los videos que revisé se centran en Astra y no ofrecen una comparación directa con Pro.
Para empezar, hay que ordenar los nombres.
La guía oficial de Astra confirma que admite un modo Pro en la API.
La documentación de razonamiento lo describe como una modalidad que dedica más trabajo del modelo a tareas difíciles, a cambio de mayor espera y consumo.
Es una configuración de ejecución; no basta con subir el nivel de esfuerzo ni con contratar una cuenta llamada Pro.
A mí eso me da ganas de llevarlo a un problema que realmente cueste resolver:
una migración de backend, un error difícil de reproducir o una decisión de arquitectura con varias alternativas.
Son las pruebas que yo le pondría.
Con lo investigado todavía no puedo decir que escriba código más limpio, detecte más errores o necesite menos revisión que Astra en modo estándar.
Sobre las cuentas, lo confirmado es que los planes Pro de US$100 y US$200 ofrecen, respectivamente, una asignación de uso de 5 y 20 veces la de Plus para Work y Codex.
Eso da más margen para trabajar con Astra, pero no confirma por sí solo un selector Astra Pro en Chat.
Las fuentes consultadas tampoco permiten asignar ese acceso por cuenta.
El modo Pro documentado en la API tiene facturación aparte de la suscripción de ChatGPT.
La propia investigación me hace bajar un poco a tierra: John cuenta que llegó a exprimir varias cuentas Pro durante sus pruebas.
Eso habla del consumo de sus cuentas, no demuestra que estuviera usando el modo Pro.
Para mí, antes de pagar más, la prueba sería muy concreta:
darle el mismo encargo, revisar ambos resultados y ver si la mejora compensa la espera y el trabajo que todavía tengo que hacer yo.
Lo que más me interesa llevar a una empresa
En paralelo a los experimentos visuales, la investigación recoge un caso de John, del canal Inteligencia Artificial, con una pyme simulada de aire acondicionado.
A partir del correo conectado, fue construyendo un diagnóstico comercial, un tablero de oportunidades y una herramienta para ayudar a responder dudas de clientes.
Ese tipo de uso me interesa mucho para el día a día.
Hay empresas que tienen presupuestos sin seguimiento, información repartida entre correos y hojas de cálculo, y personas dedicando horas a consolidarla.
Poder convertir esa información en algo que ayude a trabajar tiene un valor bastante concreto.
Habría que comprobar los datos, las conexiones y el funcionamiento, por supuesto.
Una demostración con una empresa simulada sirve para explorar una idea; llevarla a una operación real exige más trabajo.
También rescato un punto del análisis de John: parte de ese resultado depende de Work, sus conectores y la forma de plantear el encargo.
No todo lo que vemos en una demostración tiene que atribuirse exclusivamente al modelo nuevo.
Eso me parece sano recordarlo.
Antes de cambiar todas las suscripciones de un equipo, vale la pena comprobar cuánto podemos conseguir con las herramientas que ya tenemos.
En desarrollo web veo una oportunidad parecida.
Que el agente construya una interfaz, la abra, detecte un problema visual y vuelva a corregirla puede ahorrar muchas idas y vueltas.
En backend me interesa que entienda el proyecto, implemente el cambio y ejecute pruebas.
En ambos casos quiero poder revisar lo que hizo y entender por qué lo hizo así.
Hay una parte de la autonomía que quiero decidir yo
Uno de los detalles de la investigación que me hizo detenerme fue una tarea recurrente que, según el creador, el agente programó por iniciativa propia para revisar correos y generar documentación.
Entiendo que pueda resultar útil.
También quiero saber que va a hacerlo antes de dejarlo conectado a información de una empresa.
Yo establecería desde el comienzo qué puede leer, qué puede modificar y qué debe dejar pendiente de revisión.
Preparar un borrador y enviar un correo son acciones distintas.
Lo mismo ocurre con probar un cambio en desarrollo y aplicarlo en producción.
Me entusiasma delegar más trabajo.
Para hacerlo con tranquilidad necesito ver las acciones, entender los permisos y poder intervenir cuando haga falta.
Creo que este punto va a volverse cada vez más importante.
Mientras más capaces sean estos agentes, menos sentido tendrá evaluar únicamente qué cosas pueden hacer.
También tendremos que decidir cuáles queremos que hagan sin preguntarnos.
Lo que esto cambia para Wirbi
Desde una empresa de staffing, hunting y tecnología, creo que aquí hay una conversación más interesante que contar cuántas líneas de código puede producir un agente.
En staffing, me importa cómo trabaja el equipo con estas herramientas.
Quién define el problema, quién revisa la solución y quién responde cuando aparece un fallo.
Un equipo puede ganar velocidad con IA, pero necesita organizar esa revisión para que el avance sea sostenible.
En hunting, me interesaría ver a un candidato utilizar IA y después explicarme qué aceptó, qué corrigió y qué decidió descartar.
Ahí se puede observar bastante de su criterio.
Detectar que una solución aparentemente correcta tiene un problema puede ser tan valioso como construirla.
Y en nuestros proyectos web y backend, quiero aplicar lo que realmente ayude a entregar mejor:
menos tareas repetitivas, pruebas útiles, documentación que se mantenga al día e integraciones que resuelvan problemas del cliente.
WIRBI Freefall terminó siendo una prueba bastante buena de esa filosofía.
La primera vez Astra produjo una cantidad considerable de elementos y me dejó con una colección de componentes.
Eso se veía bien.
Pero todavía no era un producto.
La segunda tanda fue mucho más interesante porque pude ver qué ocurría cuando Astra tenía que tomar ese material, conectarlo y convertirlo en algo que pudiera ejecutarse.
Hoy puedo abrir WIRBI Freefall y jugarlo.
También puedo decir inmediatamente qué cosas no me gustan.
La cámara es incómoda.
La recolección de objetos necesita correcciones.
Seguramente aparecerán más cosas mientras sigamos probándolo.
Pero ahora tengo una referencia mucho más concreta para evaluar hasta dónde llegó Astra y qué tanto trabajo queda después de su intervención.
Y eso me interesa bastante más que una lista de componentes generados.
Después de dos tandas, ¿qué pienso de Astra?
Astra me dejó con ganas de seguir probando.
En la primera tanda me dejó un proyecto incompleto y una razón muy concreta para mirar los límites de la cuenta.
En la segunda consiguió convertir buena parte de ese trabajo en una primera versión funcional de WIRBI Freefall.
Eso me permite evaluar algo que me interesa mucho más que una lista de funcionalidades generadas.
Puedo evaluar el resultado.
La versión actual todavía tiene problemas.
La cámara necesita mejoras y la recolección de objetos está algo rota.
No lo presentaría como un videojuego terminado.
Pero sí como una buena primera versión.
Y sobre todo como una demostración bastante interesante de lo rápido que está cambiando la forma de desarrollar con IA.
Hace un tiempo el punto de comparación era:
“Mira, la IA puede escribir código.”
Después fue:
“Mira, puede construir una aplicación.”
Ahora estamos entrando en algo distinto:
“Dale herramientas, un proyecto y cierto margen para trabajar y veamos hasta dónde consigue llegar.”
Eso me parece mucho más importante.
También hace que tengamos que ser más exigentes.
Si el agente puede trabajar durante largos períodos, utilizar herramientas externas y tomar decisiones, entonces no basta con que produzca mucho.
Tiene que producir cosas que podamos mantener, revisar y utilizar.
WIRBI Freefall ya está disponible para probarlo:
https://wirbi-freefall.higgsfield.app/
No está terminado.
Y justamente ahora tengo una forma mucho más clara de continuar la prueba.
Puedo volver a pasarle el resultado a Astra y decirle:
“Bien. Esta es tu primera versión. Ahora mejora la cámara, corrige la recolección de objetos y veamos qué tan bien puedes trabajar sobre lo que tú mismo construiste.”
Creo que esa tercera prueba puede ser incluso más interesante que las dos anteriores.
Porque una cosa es generar un proyecto desde cero.
Otra bastante distinta es recibir una versión existente, entender qué debe mejorar y conseguir hacerlo sin perjudicar lo que ya funciona.
Ahí es donde quiero seguir probando Astra.
Fuentes y alcance
La experiencia con WIRBI Freefall es propia.
Las observaciones sobre Serudda y John proceden de la investigación adjunta, basada en videos de Serudda, Inteligencia Artificial y Benjamín Cordero.
Son resultados reportados por esos creadores, no pruebas realizadas por mí.
La comparativa de código corresponde a GPT-6 Astra vs Fable 5.1, de Serudda, y el caso empresarial a He probado GPT-6 ASTRA al límite: esta es mi conclusión, del canal Inteligencia Artificial.
La sección sobre Astra Pro se apoya además en la documentación oficial enlazada y no describe una prueba propia de esa modalidad.
La prueba de WIRBI Freefall sí corresponde a mi experiencia directa: tanto la primera tanda de generación de componentes como la segunda integración que dio lugar a la versión jugable publicada.
Andre Lopez
COE de IA · Wirbi
Integrante del Centro de Excelencia de IA de Wirbi. Evalúa y documenta herramientas de inteligencia artificial aplicadas a marketing, contenido y operaciones.