Gemini 4 Argon apareció en mi plan Google AI Pro y aproveché para pedirle varias tareas de programación. Quería comprobar algo bastante concreto: si podía ayudarme a construir cosas que me interesaran, no solamente generar una respuesta convincente sobre lo que sería capaz de hacer.
Probé una simulación de gravedad, un minijuego de carreras y una web de arquitectura con una casa 3D interactiva. También le encargué una presentación a partir de notas desordenadas. Hubo resultados interesantes, especialmente la casa, pero mi impresión general fue bastante clara: esperaba más.
Por ahora sigo prefiriendo trabajar con GPT-6 Astra y Opus 5.5. Eso no significa que Gemini no tenga utilidad. Significa que, después de estas primeras pruebas, todavía no me dio motivos suficientes para cambiar mi forma de trabajar ni para pasar a un plan más caro.
Además, me encontré con una diferencia de acceso que importa mucho si tu intención es programar: tener el modelo disponible en Gemini no significa poder utilizarlo también en Antigravity. Y justo ahí era donde yo quería probarlo.
Tabla de contenido
- 🧩 Qué quería comprobar con Gemini 4 Argon
- 🔐 Mi primera decepción: Pro no me daba acceso en Antigravity
- ⚙️ Primera prueba: una simulación de gravedad con Three.js
- 🏎️ Segunda prueba: un juego de carreras que funciona, pero se siente genérico
- 🏡 Tercera prueba: una web con una casa 3D que sí me dio ganas de continuar
- 🎨 Dínamo Sites y recursos para seguir construyendo
- 📝 La presentación: un error pequeño que me obliga a revisar
- 🛠️ Las demos oficiales tienen más herramientas detrás
- 💳 Planes, disponibilidad y límites de uso
- 🎯 Mi conclusión: aprovechar Pro antes de pensar en Ultra
🧩 Qué quería comprobar con Gemini 4 Argon
Cuando sale un modelo nuevo, mi primera pregunta no es qué posición ocupa en una clasificación. Me interesa saber qué puedo construir con él y cuánto trabajo me queda después de recibir la primera versión.
Google está destacando la programación y el razonamiento espacial en este lanzamiento. El razonamiento espacial consiste, dicho de forma sencilla, en entender formas, posiciones y relaciones entre objetos dentro de una escena. Por eso me pareció interesante salir de la típica página estática y pedir algo que tuviera volumen, movimiento e interacción.
Argon es el primer modelo de la familia Gemini 4 y puede trabajar con texto, imágenes, audio y video como información de entrada. Todo eso suena bien, pero mis pruebas se concentraron en una parte específica: generar aplicaciones visuales mediante instrucciones de texto.
Elegí tres propuestas con necesidades diferentes:
- Una simulación de gravedad: objetos que se mueven dentro de un recipiente y controles para modificar su comportamiento.
- Un juego de carreras: una escena que responde al teclado, registra una puntuación y permite volver a empezar después de un choque.
- Una web de arquitectura: una casa que se puede explorar y modificar dentro de una página con una identidad visual coherente.
No son pruebas equivalentes. La simulación sirve para comprobar interacción y movimiento. El juego añade reglas y estados. La web exige que la parte técnica también encaje con una propuesta de diseño.
Eso me permitía separar varias cosas que a veces mezclamos al evaluar una IA: que genere código, que ese código funcione, que cumpla el pedido y que el resultado realmente dé ganas de seguir trabajando. Un modelo puede resolver algunas de esas partes sin destacar en todas.
🔐 Mi primera decepción: Pro no me daba acceso en Antigravity
Lo primero que hice fue buscar Gemini 4 Argon en Antigravity. Quería usarlo trabajando con un proyecto y sus archivos, que es el contexto que más me interesa cuando pruebo una herramienta de programación.
Pero no lo tenía disponible. En cuentas personales, ese acceso estaba reservado al plan Ultra. Yo pago Pro y podía utilizar el modelo en Gemini, pero ese mismo plan no me servía para usarlo dentro de la herramienta de programación de Google.
La diferencia no es menor. Para mí, probar un modelo en una conversación y probarlo dentro del entorno donde trabajo con mis proyectos son experiencias distintas. Mi intención era evaluar cómo se integraba en mi flujo habitual, no solamente qué podía producir en una demostración aislada.
Al final hice las pruebas en Gemini, seleccionando el modelo y utilizando Canvas. Canvas permite abrir y probar la aplicación dentro de la misma conversación. Para experimentar con estas ideas resultó útil, aunque no era el entorno en el que inicialmente quería trabajar.
La lección práctica es revisar el acceso por herramienta, no solamente por nombre de modelo. Antes de contratar o cambiar un plan, conviene comprobar dónde podrás utilizarlo. Que esté incluido en un producto no garantiza que esté habilitado en otro, aunque ambos sean de la misma empresa.
⚙️ Primera prueba: una simulación de gravedad con Three.js
Empecé con una simulación 3D de bolas de colores que caen y rebotan dentro de un recipiente transparente. La idea era poder jugar con la gravedad y ver inmediatamente cómo cambiaba la escena.
Le indiqué que utilizara Three.js, una biblioteca para crear gráficos 3D en el navegador. No quería únicamente una animación que se repitiera, sino una pequeña aplicación con controles que modificaran lo que estaba ocurriendo.
Cómo planteé el pedido
La solicitud combinaba una escena sencilla con una lista concreta de interacciones. Le pedí que construyera la simulación dentro de Canvas, con las bolas contenidas en un espacio transparente y la posibilidad de explorar ese espacio con el mouse.
Los controles solicitados eran estos:
- Rotar la cámara con el mouse.
- Cambiar la intensidad de la gravedad.
- Ajustar la fuerza del rebote.
- Agregar más bolas a la simulación.
- Pausar el movimiento.
- Reiniciar la escena.
Lo importante del pedido era la relación entre el control y el resultado. Si modifico la gravedad, quiero notar el cambio. Si agrego bolas, quiero que aparezcan dentro del recipiente y que la interfaz refleje esa acción. Esa respuesta visible es lo que convierte una escena en algo con lo que puedes experimentar.
Qué funcionó y qué tuve que corregir
Gemini generó el código de la aplicación y la base funcionó. Al agregar bolas, aparecían en el recipiente y se sumaban al contador. También podía modificar el rebote, detener la simulación y girar la cámara para revisar dónde habían quedado.
Una de las pruebas más entretenidas fue llevar la gravedad a cero y utilizar el control para agitar. Las bolas seguían moviéndose por la escena, y los cambios se apreciaban enseguida. Como demostración visual, tenía sentido y resultaba divertida de usar.
El problema de la primera versión estuvo en la distribución de la interfaz. El panel de controles aparecía abajo y tapaba parte de la escena. Le pedí que lo trasladara a una columna lateral compacta y que reservara el resto del espacio para mostrar el recipiente completo.
Con ese ajuste quedó mucho mejor. No fue necesario replantear la aplicación, pero sí corregir algo que afectaba directamente a su uso. Tener controles disponibles no sirve de mucho si esos controles ocultan aquello que necesitas observar.
Este caso muestra una forma de iterar que me interesa: señalar el problema concreto y describir el resultado deseado. En lugar de pedirle simplemente que mejorara el diseño, le indiqué dónde debía colocar el panel y qué espacio debía quedar libre.
Una demo visual no es una validación de la física
Aquí quiero ser preciso: no comprobé la exactitud de la física. Mi objetivo era una demo para experimentar con gravedad y rebotes, no verificar que todos los movimientos correspondieran a una simulación rigurosa.
Por tanto, mi valoración es que cumple como prueba visual interactiva. Puedo manipular parámetros, obtener una respuesta y explorar la escena. Eso no me permite afirmar que el comportamiento físico esté validado.
Es una distinción importante al crear con IA. Que algo parezca razonable y sea entretenido no demuestra que sea correcto en todos sus detalles. El nivel de revisión depende del uso que quieras darle después.
🏎️ Segunda prueba: un juego de carreras que funciona, pero se siente genérico
Después pasé a un minijuego de carreras. Quería añadir algo que la simulación anterior no exigía de la misma manera: controlar un vehículo con el teclado y comprobar una secuencia de juego con movimiento, obstáculos, choque y reinicio.
La propuesta era conducir por una ciudad nocturna con luces de neón, esquivar obstáculos y recoger cápsulas de energía. De nuevo pedí Three.js para construir la escena 3D.
Los requisitos del minijuego
El pedido no se limitaba a la ambientación. También definía cómo debía jugarse y qué información tenía que aparecer en pantalla:
- Controles sencillos con las flechas o las teclas A y D.
- Una cámara situada detrás del auto.
- Un marcador visible.
- Obstáculos que hubiera que esquivar.
- Cápsulas de energía para recoger.
- Dificultad que aumentara progresivamente.
- Un botón para empezar otra partida al chocar.
La intención era obtener una base simple para seguir probando una idea. No le estaba pidiendo un juego terminado ni una propuesta especialmente compleja. Eso también hay que tenerlo presente al juzgar el resultado.
La parte que sí pude comprobar
El auto se movía de lado a lado, podía esquivar obstáculos y el marcador iba aumentando. La estética también correspondía bastante bien a lo solicitado: una ciudad de noche, colores de neón y la cámara siguiendo al vehículo desde atrás.
Choqué durante la prueba, utilicé el botón para volver a jugar y la partida comenzó de nuevo. Así que la secuencia básica estaba resuelta: mover el auto, encontrarse con obstáculos, perder y reiniciar.
Sin embargo, el juego no me entusiasmó demasiado. Funciona, pero se siente genérico. Lo veo como un primer prototipo aceptable, no como un resultado que por sí mismo me haga pensar que quiero dedicarle más tiempo.
También sería injusto atribuirle toda esa falta de personalidad al modelo. Mi solicitud era sencilla y estaba pensada como punto de partida. Si quiero una experiencia más particular, tendría que definir mejor qué la hace diferente y seguir iterando.
Aun así, esa primera impresión cuenta. Cuando pruebo herramientas para construir, me interesa tanto la funcionalidad como el impulso que me deja el resultado. Aquí tenía una base operativa, pero no la misma sensación de posibilidades que me produjo la web de arquitectura.
Lo que quedó pendiente de revisar
No confirmé la recolección de cápsulas de energía. Tampoco jugué lo suficiente como para evaluar de forma seria cómo aumentaba la dificultad.
Eso no significa que esas funciones estuvieran ausentes. Significa que no las verifiqué. Las partidas fueron demasiado cortas para sacar conclusiones sobre esos puntos.
En un pedido con varias funciones, conviene separar lo solicitado de lo comprobado. En este caso pude confirmar movimiento, puntuación, choque y reinicio. Las cápsulas y la progresión de dificultad requerían una revisión adicional.
Esa separación evita dar por terminado un proyecto solo porque la primera interacción funciona. Un prototipo puede resolver bien su recorrido más evidente y todavía necesitar pruebas en otras partes.
🏡 Tercera prueba: una web con una casa 3D que sí me dio ganas de continuar
La web de arquitectura fue el resultado que más me gustó. Aquí las interacciones no estaban sueltas: formaban parte de una página que tenía sentido y ayudaban a explorar una propuesta.
El estudio era ficticio y se llamaba Forma. Quería que la protagonista fuera una casa moderna en 3D, construida con Three.js, que pudiera girar con el mouse.
Además, pedí alternar entre día y noche y elegir tres acabados de fachada: madera, hormigón y blanco. Había una condición importante: los cambios debían notarse en la casa, no quedarse únicamente en el estado de un botón.
Una solicitud visual con límites claros
Para el diseño pedí tonos cálidos y bastante espacio. También limité la escena a una sola casa y especifiqué que no se cargara un modelo externo.
Ese límite ayudaba a mantener el foco de la prueba. Lo que quería evaluar era una propuesta generada para esa página, con una casa explorable y unas pocas opciones bien definidas. No necesitaba añadir más edificios ni complicar la escena.
El pedido tenía tres capas relacionadas:
- El objeto: una casa moderna en 3D.
- La interacción: rotación, materiales y cambio de iluminación.
- La presentación: una web cálida, espaciosa y coherente con un estudio de arquitectura.
Para mí, esa relación es la clave del resultado. La casa no era una decoración añadida a la página. Era el centro de la experiencia, y los controles servían para entender mejor la propuesta.
Explorar la casa y comparar acabados
El modelo incluía ventanas, terraza y vegetación alrededor. Podía girarlo y examinarlo desde distintos ángulos mientras probaba las opciones de la interfaz.
Al pasar de madera a hormigón y después a blanco, el aspecto de la casa cambiaba de forma visible. Eso me parece útil para presentar una idea: puedes mantener el mismo diseño y comparar cómo se percibe con distintos acabados.
No necesitas imaginar cada alternativa a partir de una descripción. Tienes una misma casa, una misma perspectiva que puedes mover y varias opciones para contrastar.
Lo que me gustó no fue simplemente que hubiera tres botones. Fue que esos botones tenían un propósito claro dentro de la página y producían una transformación reconocible en el objeto principal.
El cambio entre día y noche
La iluminación también quedó bien. Al activar el modo nocturno, el entorno se oscurecía y se encendían las luces interiores. Después podía volver a girar la casa y revisar cómo se veía desde el otro lado.
Aquí había algo más interesante que un cambio de fondo. La transición afectaba a la percepción del proyecto: el interior iluminado pasaba a tener protagonismo y la escena transmitía otra sensación.
Al bajar por la página aparecía otra sección del proyecto, con una vista del modelo que también podía mover. La web mantenía el mismo estilo, así que la exploración continuaba sin sentirse como una aplicación independiente pegada a un sitio.
De las tres pruebas de programación, esta fue la que me dejó una base visual que realmente me gustaba. Los cambios de materiales y de iluminación funcionaban, y la interacción estaba integrada en una presentación coherente.
Para comunicar una propuesta como esta, le veo bastante utilidad. No estoy diciendo que el trabajo estuviera terminado. Estoy diciendo que el punto de partida me daba ganas de continuar, y eso no me ocurrió con la misma intensidad en las otras pruebas.
🎨 Dínamo Sites y recursos para seguir construyendo
Precisamente por esa diferencia entre una base que funciona y una base que te inspira, quiero mencionar Dínamo Sites, mi web de diseños y secciones animadas.
Allí tienes demostraciones, prompts, código y recursos para adaptar las secciones a tus propios proyectos. La idea es que puedas explorar propuestas visuales y partir de algo más pulido cuando quieras construir una web con personalidad.
La casa de Forma me recordó por qué valoro tanto ese punto de partida. Cuando la composición ya tiene sentido y la interacción acompaña al contenido, las siguientes decisiones son más concretas. Puedes pensar en qué conservar, qué adaptar y qué mejorar, en lugar de empezar por corregir toda la dirección visual.
Si estás trabajando en una aplicación, también tienes prompts profesionales para crear tu app. Y si necesitas alojamiento para un proyecto web, dejo mi enlace de descuento de Hostinger. Son recursos complementarios, no parte de las pruebas de Gemini que hice aquí.
Para compartir este proceso de creación con IA, puedes sumarte a mi comunidad de creación de apps con IA. Lo importante sigue siendo lo mismo: utilizar las herramientas para construir algo concreto y aprender de los resultados, no quedarse solamente con la promesa del lanzamiento.
📝 La presentación: un error pequeño que me obliga a revisar
Además de los ejemplos 3D, probé una tarea más cotidiana. Le entregué notas desordenadas sobre cómo grabar un video de una cafetería con el celular y le pedí que las organizara en una presentación.
Las condiciones eran claras: seis diapositivas, un plan de tomas cuya duración total fuera de 20 segundos y un máximo de 25 palabras por diapositiva.
Pude descargar el PowerPoint y los tiempos del plan sumaban los 20 segundos solicitados. Esa parte se cumplió.
Pero una diapositiva tenía 27 palabras. Son solamente dos palabras por encima del límite y el arreglo es sencillo. Lo que me incomodó fue que Gemini afirmara que todas las diapositivas cumplían la restricción.
El problema no es únicamente el incumplimiento, sino la verificación incorrecta. Si me dice que algo ya está comprobado, espero poder confiar en esa comprobación. Cuando no es así, tengo que revisar también aquello que la herramienta presenta como resuelto.
Este caso no invalida toda la presentación. El archivo se generó y la duración total estaba bien. Pero sí cambia cómo interpreto su respuesta final: la tomo como una afirmación que todavía debo contrastar, no como una garantía.
La revisión puede organizarse de forma bastante sencilla:
- Comprobar que el entregable existe y se puede utilizar.
- Revisar las condiciones objetivas, como cantidades y límites.
- Separar esas comprobaciones de la valoración del contenido y del diseño.
En la presentación, el número de palabras era una condición objetiva. En el juego, había funciones pendientes de probar. En la simulación, la precisión física estaba fuera de lo que había comprobado. Son revisiones distintas, pero todas ayudan a evitar conclusiones demasiado rápidas.
🛠️ Las demos oficiales tienen más herramientas detrás
Las demostraciones que publicó Google tienen otro nivel de sofisticación. Entre ellas están un juego que convierte un escritorio en un circuito de carreras y una escena de una pagoda con bastante detalle.
Son resultados llamativos, pero me interesa tanto el resultado como el proceso necesario para llegar a él. En el juego del escritorio se utilizaron varias herramientas: Antigravity, Blender para los objetos, Nano Banana para las texturas y otro modelo de Gemini para el audio.
Eso cambia la comparación. No es lo mismo pedir una aplicación sencilla dentro de Canvas que desarrollar una demo combinando herramientas para programación, objetos, texturas y sonido.
No le resta mérito a la demostración. Al contrario, muestra posibilidades interesantes. Pero no conviene atribuir todo ese resultado a una única respuesta del modelo.
Para decidir si una herramienta me sirve, necesito entender qué parte hace cada componente y cuánto trabajo requiere el conjunto. Una demo sofisticada puede inspirarme, pero mis propias pruebas me dicen mejor qué estoy obteniendo con el acceso y el flujo que tengo disponibles.
💳 Planes, disponibilidad y límites de uso
Al momento de estas pruebas, Gemini 4 Argon estaba incluido en Pro y Ultra dentro de Gemini. Para utilizarlo en Antigravity con una cuenta personal, hacía falta Ultra.
El plan gratuito y AI Plus no lo incluían, y no había una fecha confirmada para su llegada al plan gratuito. Había acceso en España y en muchos países de Latinoamérica.
Conviene resumirlo sin mezclar disponibilidad con uso ilimitado:
- Gemini: acceso con Pro y Ultra.
- Antigravity en cuentas personales: acceso con Ultra.
- Gratis y AI Plus: sin acceso en ese momento.
- Disponibilidad regional: España y muchos países latinoamericanos.
- Uso: sujeto a límites por periodos de cinco horas y a límites semanales.
Tener el plan no significa que puedas utilizar el modelo sin restricciones. Si vas a trabajar durante bastante tiempo en un proyecto, revisa cuánto uso te queda en la cuenta.
Y si tu motivo para pagar más es utilizarlo en una herramienta concreta, comprueba primero ese acceso. En mi caso, la separación entre Gemini y Antigravity fue uno de los puntos que más pesaron en la decisión.
🎯 Mi conclusión: aprovechar Pro antes de pensar en Ultra
La casa de Forma fue el resultado que más me convenció. Me gustó poder crear directamente en Gemini una página con una casa explorable, materiales intercambiables y un modo nocturno que modificaba la iluminación.
La simulación cumplió como demo visual después de corregir la posición de los controles. El juego resolvió su funcionamiento básico, pero me pareció genérico. La presentación fue útil, aunque falló en una restricción que el propio modelo aseguró haber verificado.
Con todo eso sobre la mesa, sigo prefiriendo GPT-6 Astra y Opus 5.5 para mi forma de trabajar. Es una impresión basada en estas primeras pruebas, no una comparación exhaustiva de todas sus capacidades.
Voy a seguir probando Gemini 4 Argon. Pero, por ahora, prefiero mantener mi plan actual y esperar antes de pasar a Ultra solamente para utilizarlo en Antigravity.
Si ya tienes Pro, mi recomendación es aprovechar que está incluido y pedirle algo que de verdad te interese construir. Define qué debería hacer, prueba sus interacciones y comprueba si el resultado te deja una base útil. Esa experiencia vale más para tu decisión que una demostración que no corresponde a tu proyecto.
Para profundizar en ese flujo de trabajo, tienes mi explicación sobre modelos de Claude en Antigravity y la serie de webs animadas premium con IA.
Mi criterio sigue siendo construir, probar y después decidir. Gemini 4 Argon me dejó una propuesta que sí quiero seguir desarrollando, pero todavía no una razón suficiente para cambiar de herramientas o pagar más. Y me parece importante poder reconocer las dos cosas a la vez.
Aviso: este artículo puede incluir enlaces promocionales. Si realizas una compra, puedo recibir una comisión sin costo adicional para ti.
