Gemini Flash para desarrollo de software: capacidades, límites y revisión

Gemini 2.5 Flash frente a nueve lenguajes

Los modelos Gemini pueden ayudar a escribir, explicar y modificar código. Su utilidad depende de la tarea, del contexto que reciben y de que alguien ejecute y revise el resultado. No existe una puntuación única que permita afirmar que un modelo “domina” todos los lenguajes ni que el código generado sea correcto en un porcentaje fijo de proyectos.

Decir que una IA “domina” Python, Rust o JavaScript suena claro, pero no es una medida. Para evaluar esa capacidad con evidencia, este artículo toma como referencia el estudio The Matthew Effect of AI Programming Assistants: A Hidden Bias in Software Evolution, publicado en ICLR 2026. Sus autores midieron cuántas soluciones de Gemini 2.5 Flash resolvieron problemas de programación en el primer intento y publicaron resultados separados por lenguaje.

La evaluación permite comparar el rendimiento del modelo en ese conjunto de tareas. No demuestra que sea experto en un lenguaje ni predice qué porcentaje del código que genere será correcto en cualquier proyecto. Describe una tarea concreta: resolver problemas algorítmicos de LeetCode con una respuesta de código de un solo intento.

Ficha de la evaluación

• Modelo: Gemini 2.5 Flash, endpoint indicado por el estudio como gemini-2.5-flash.
• Interfaz: API del modelo; no la aplicación Gemini ni un IDE con agente.
• Parámetros publicados: temperatura 0,5, top_p 0,95 y máximo de 65.535 tokens de salida.
• Tareas: 3.011 problemas públicos de LeetCode: 765 fáciles, 1.526 intermedios y 720 difíciles. Cada problema se pidió en nueve lenguajes.
• Fecha: el estudio se envió a arXiv el 27 de septiembre de 2025; su versión 3 es del 9 de febrero de 2026 y fue publicado en ICLR 2026. El endpoint evaluado figura con lanzamiento en junio de 2025. Esta revisión del artículo es del 5 de octubre de 2026.

El equipo pidió código directamente, extrajo el código de las respuestas mediante un proceso automatizado y lo envió al juez de LeetCode. Pass@1 es la proporción de soluciones aceptadas en el primer envío. No se permitió corregir una solución a partir de errores del compilador o de las pruebas.

Resultados por lenguaje

La tabla reproduce los resultados publicados para Gemini 2.5 Flash. Al hacer clic en un encabezado, las filas se ordenan por esa columna; otro clic invierte el orden. “Otros errores” es una de las categorías que contabilizan los autores.

Python	67,92 %	2.045	0	726	217	23
C++	68,65 %	2.067	744	13	164	23
C	58,59 %	1.764	1.007	52	170	18
Java	68,65 %	2.067	739	39	157	9
JavaScript	64,50 %	1.942	0	781	275	13
Go	50,22 %	1.512	1.377	7	105	10
Rust	51,81 %	1.560	1.311	17	115	82
Erlang	1,26 %	38	2.824	145	4	33
Racket	17,10 %	515	2.184	200	94	18

Nota sobre los conteos: en la tabla del artículo fuente, las categorías de resultado de Rust suman 3.085 y las de Erlang 3.044, aunque se evaluaron 3.011 problemas por lenguaje. Reproduzco esos conteos tal como fueron publicados; esos dos repartos no cuadran y no deben interpretarse como categorías mutuamente excluyentes completas.

Qué significan estos porcentajes y qué no

Un Pass@1 de 68,65 % para Java significa que 2.067 de las 3.011 soluciones producidas para ese conjunto fueron aceptadas al primer envío. No significa que el 68,65 % de todo el código Java que Gemini escriba sea correcto. Tampoco mide calidad de diseño, mantenibilidad, seguridad ni desempeño en aplicaciones empresariales.

La prueba se concentra en algoritmos y en el formato esperado por LeetCode. No cubre por igual desarrollo web, consultas SQL, Bash, configuración de Linux, diseño de bases de datos o mantenimiento de repositorios grandes. SQL y Bash, por ejemplo, no formaron parte de los nueve lenguajes evaluados; no corresponde atribuirles una puntuación con esta tabla.

El resultado también depende del modelo y la versión concretos, del prompt, de los parámetros de generación, del juez y de la distribución de dificultades. Gemini 2.5 Flash es el modelo medido por este estudio; sus resultados no se pueden trasladar automáticamente a versiones posteriores de Gemini. El artículo evalúa llamadas a la API: no establece que el acceso usado fuera gratuito ni ilimitado.

Qué sugieren los errores

En los lenguajes con Pass@1 más alto, muchas fallas fueron respuestas incorrectas o errores de ejecución: la solución podía ser ejecutable, pero no resolver todos los casos o incumplir alguna condición. En Go, Rust, C y Erlang, el estudio registró muchos errores de compilación. En esta batería concreta, conseguir una solución que el compilador aceptara fue una dificultad importante en esos lenguajes.

En Rust, un error del compilador no debe describirse como una fuga de memoria del Borrow Checker. El compilador rechaza ciertos usos inválidos de propiedad y préstamos; el código generado puede no compilar por esos motivos. Si compila, todavía hay que revisar la lógica, el manejo de errores, las APIs y los requisitos del proyecto.

Conclusión

La publicación de ICLR aporta tasas de aceptación medibles para nueve lenguajes bajo condiciones descritas. En este conjunto, Gemini 2.5 Flash obtuvo resultados más altos en Java, C++, Python y JavaScript; más bajos en Go y Rust; y muy bajos en Erlang y Racket. La conclusión válida es acotada: su éxito al resolver problemas de LeetCode en un intento varió según el lenguaje. Para decidir si sirve en un proyecto, hay que validar el código con las pruebas y condiciones de ese proyecto.

Fuentes y metodología

• Versión publicada en ICLR 2026: The Matthew Effect of AI Programming Assistants
• Texto completo, tablas, parámetros y apéndices del estudio
• Código, prompts y pipeline de evaluación

Sobre el autor

Soy Marcelo, Programador Universitario de Aplicaciones (U.N.NE.).

Desarrollador independiente, enfocado en automatización.

¿Buscás desarrollo web en Argentina?

Ofrezco soluciones personalizadas para emprendedores y empresas locales.

¿Te sirvió este informe?

☕ Cafecito 💳 Mercado Pago

¡Muchas gracias por tu colaboración!