Saltar al contenido principal
Volver al blogCopiar Markdown
·Actualizado ·6 min de lectura
·aigeminigoogledevelopment

Gemini 3 Pro: una semana de pruebas como desarrollador

Una semana con Gemini 3 Pro: Deep Think planificando una migración de ejemplo, un bug diagnosticado desde un vídeo y el lado agéntico que hay que vigilar. →

Óscar Gallego

Ingeniero de software · Málaga

Logo de Gemini 3 y herramientas para desarrolladores
En este artículo

Llevo una semana probando Gemini 3 Pro, y ¿sabes qué? Me ha sorprendido lo bien que va.

Justo cuando me había acostumbrado a mi workflow con Claude/GPT-4, Google lanza esto en noviembre y toca reajustarlo todo otra vez.

Pero vamos al grano: después de obligarme a reconstruir una feature mía que ya tenía funcionando (sí, reescribí código que funcionaba solo para probar esto), entiendo el hype. No es el típico release de “un poco mejor en benchmarks”. Deep Think y multimodalidad real (no la fake de siempre) cambian cómo puedes trabajar.

Te explico.

Lo que de verdad ha cambiado esta vez

1. Deep Think, o por qué ahora se para a pensar

¿Sabes cómo los modelos anteriores simplemente empezaban a soltar tokens? En medio del pensamiento, cero planificación, solo predicción de palabras.

Gemini 3 realmente se para. Piensa. Verás “[Thinking…]” en la respuesta de la API, y al principio pensé que se me había caído la conexión. Pues no. Realmente está gastando tiempo de cómputo planificando la respuesta antes de soltarla.

Qué busco:

Si le pides planificar la migración de una SPA monolítica a micro-frontends (ejemplo hipotético, no un proyecto mío), en vez de soltar código lo que debería hacer es preguntar primero por el pipeline de deploy y por las dependencias legacy que se romperían, y proponer un rollout por fases. Esa es la diferencia que busco en un modelo que planifica antes de escribir.

El pero: Es más lento. Si estás acostumbrado a respuestas instantáneas, esa pausa mientras piensa se hace eterna. Pero para decisiones de arquitectura, prefiero precisión antes que velocidad.

2. Multimodalidad sin cinta aislante

Todos los modelos ahora dicen tener “multimodalidad”. Normalmente significa que pegaron tres modelos diferentes con cinta aislante y cruzaron los dedos.

Gemini 3 es diferente: un solo modelo lo maneja todo. Texto, código, vídeo, audio, imágenes. Mismos pesos, misma arquitectura.

Test real que hice:

Grabé un vídeo corto en Loom de un bug en la UI (un botón que no se deshabilitaba al hacer clic). Sin transcripción, sin snippets de código. Solo yo haciendo clic por ahí y quejándome en español.

Lo subí. Pregunté: “¿Qué está roto?”

Respondió:

  • Identificó que el event handler no estaba previniendo doble-click
  • Señaló el componente React por nombre (esto fue lo que más me sorprendió)
  • Sugirió añadir un estado isLoading con disabled={isLoading}

Lo comprobé. Tenía razón. El nombre del componente era correcto, y lo sacó de un vídeo.

La parte rara: Con vídeos largos me pareció que alucinaba nombres de componentes con más facilidad (impresión mía, no lo medí). Para cazar bugs rápido, no he usado nada mejor.

3. Capacidades de agente (con un asterisco gigante)

Los resultados en benchmarks que publicó Google pintan muy bien sobre el papel, pero no los he comprobado yo. En la práctica… es complicado.

Lo que funciona:

  • Ejecutar comandos de terminal (le dejé debuggear un problema de networking en Docker y usó docker inspect correctamente)
  • Editar archivos (hizo un refactor de varios archivos sin romper tests)
  • Ejecutar tests e interpretar fallos

Lo que no:

  • Todavía intenta ejecutar comandos que no existen (git commit -fix no es real, Gemini)
  • Se lía si la estructura de tu proyecto es poco convencional
  • Sugiere con confianza borrar archivos que en realidad son críticos (lo pillé más de una vez; revisa siempre)

Confía, pero verifica. Siempre.

Dónde encaja en un workflow real

1. Deja de escribir boilerplate a mano

Olvídate del “vibe coding”. Hablemos de lo que de verdad odias hacer.

Cómo lo plantearía (ejemplo hipotético):

Para el scaffolding de una API CRUD le pasarías algo así:

“Necesito un endpoint de FastAPI para autenticación de usuarios. Tokens JWT, lógica de refresh, PostgreSQL con SQLAlchemy. Sigue el patrón existente de los endpoints de /products.”

Con un módulo existente como contexto, el patrón queda claro. Lo que suele fallar con este tipo de generación son las rutas de imports y las variables de entorno.

Tiempo ahorrado: no lo cronometré, así que no te doy cifras.

El truco: Necesitas un patrón de codebase consistente. Si tu proyecto es un caos, Gemini 3 va a reflejar ese caos.

2. Code reviews (pero no como piensas)

Aún no confío en la IA para code reviews completos. Donde encaja es como “filtro de primera pasada”.

Cómo lo usaría: pegas el diff, dejas que marque lo obvio (credenciales hardcodeadas, falta de error handling, riesgos de SQL injection) y la review real de lógica y arquitectura la haces tú.

Así pilla lo aburrido y tú te centras en si el código resuelve el problema.

Aviso: A veces marca falsos positivos. En alguna ocasión se quejó de un archivo .env que en realidad era .env.example. No hagas merge ciegamente basándote en feedback de IA.

3. Código legacy (donde puede brillar)

¿Recuerdas ese espagueti de jQuery de hace años que nadie quiere tocar? El context window enorme que anuncia Google para Gemini 3 encaja bien con esto.

Cómo lo plantearía (ejemplo hipotético, no lo he probado con un proyecto real):

Imagina un panel de admin legacy en vanilla JS. Le pedirías que:

  • Identificara qué archivos se usan realmente
  • Creara un grafo de dependencias
  • Reescribiera el módulo de gestión de usuarios en React

Lo normal es que haya que arreglar a mano cosas como el manejo de eventos, así que trata su salida como un primer borrador.

Pro tip: Haz esto incrementalmente. No le pidas que reescriba toda tu app. Empieza con un módulo aislado, verifica que funciona, y luego sigue con el siguiente.

Entonces… ¿te debería importar?

Mira, no voy a dejar Claude del todo. Para brainstorming y escribir, Claude sigue sintiéndose más “humano”. Pero ¿para código? Gemini 3 me está convenciendo.

Para lo que usaría Deep Think es para eso, planificar antes de escribir código, y la multimodalidad es genuinamente útil (no un gimmick). Lo del context window grande para código legacy todavía no lo he probado con un proyecto real.

Mi consejo:

  • Pruébalo si estás haciendo refactoring o cazando bugs de UI desde un vídeo
  • Quédate con Claude/GPT-4 si necesitas escritura creativa o explicaciones matizadas
  • No confíes ciegamente: le he pillado sugiriendo malas prácticas cuando está fuera de su knowledge cutoff

El futuro del desarrollo probablemente es agéntico. Pero aún no estamos ahí. Gemini 3 es un paso grande, eso sí.

Lectura relacionada: más sobre dejar que la IA haga la primera pasada de review: probé usar IA para revisión de código en mis proyectos.


P.D. Si has probado Gemini 3, me encantaría saber qué piensas. ¿También te alucinó nombres de componentes, o soy solo yo? Escríbeme en LinkedIn.

Última actualización:

Comparte este artículo

Artículos relacionados