Gemini 3.1 Pro frente a Gemini 3.7 Flash para mantener código: cómo medir si compensa pagar más

La decisión: pagar por una tarea resuelta, no por una impresión

Elegir entre Gemini 3.1 Pro y Gemini 3.7 Flash para mantener código no se reduce a preguntar cuál es «mejor». Para un equipo, la cuestión práctica es qué modelo completa una tarea concreta con un parche correcto, cuánto cuesta llegar a ese resultado y cuánto tiempo requiere. Un modelo que responde rápido, pero deja una regresión o exige varias rondas de corrección, puede resultar menos eficiente que otro con una llamada más costosa.

La comparación útil debe medir trabajo terminado. Eso implica evaluar si el cambio satisface la incidencia, supera pruebas pertinentes y evita alterar partes ajenas a la solicitud. También hay que contabilizar intentos fallidos, herramientas, reintentos, intervención humana y ejecuciones que no terminan en un parche aceptable. El coste por llamada, por sí solo, no describe el coste de mantener un repositorio.

No se dispone aquí de resultados de una prueba ejecutada en los mismos repositorios y bajo un arnés común. Por tanto, no sería riguroso afirmar que Flash basta para lo rutinario, que Pro justifica su coste en tareas complejas o que uno de los dos gana. Lo que sigue es un protocolo para obtener esa respuesta, y una guía para interpretar los resultados sin presentar hipótesis como hechos.

Qué modelos se comparan y qué debe verificarse antes de empezar

La primera tarea es fijar la identidad exacta de cada sistema. La ficha oficial consultada identifica Gemini 3.1 Pro con el ID `gemini-3.1-pro-preview` y señala que se trata de una versión Preview. La guía de razonamiento consultada incluye `gemini-3.7-flash` y `gemini-3.1-pro-preview` entre los modelos para los que presenta información de configuración. Estos nombres no deben sustituirse por etiquetas abreviadas en los registros de la prueba: el identificador que se envía a la API forma parte de la configuración experimental.

La disponibilidad y el estado pueden cambiar. Antes de iniciar las ejecuciones, y de nuevo al cerrar la prueba, hay que verificar los identificadores aceptados, el canal utilizado y si alguno dejó de estar disponible o cambió de estado. Si un modelo cambia durante el ensayo, el artículo debe indicar qué ejecuciones corresponden a cada versión o separar los periodos; no debe tratarlas silenciosamente como una sola muestra homogénea.

También deben registrarse proveedor y canal de acceso, fecha, parámetros de generación, límite de contexto, reglas de parada y cualquier configuración de razonamiento. La documentación oficial describe opciones y valores predeterminados, pero eso no demuestra que dos valores con el mismo nombre representen el mismo esfuerzo de cómputo, presupuesto interno o comportamiento. Una comparación con niveles «equivalentes» solo sería defendible si se define operacionalmente qué significa equivalente y se reportan los parámetros realmente usados.

Las tarifas tampoco deben copiarse de una tabla antigua ni inferirse del nombre del modelo. Hay que verificar los componentes de facturación aplicables en la fecha de ejecución y explicar qué se incluye: entrada, salida, llamadas a herramientas u otros cargos pertinentes. Si el acceso incluye una capa intermedia o una tarifa distinta de la API directa, debe medirse y describirse ese canal, porque los resultados no se trasladan automáticamente a otro.

Diseño: repositorios, incidencias y aceptación

El conjunto de prueba debe quedar congelado antes de ejecutar los modelos. Cada tarea necesita un repositorio y un commit base identificables, una descripción de la incidencia, un entorno que pueda reconstruirse y un criterio de aceptación escrito de antemano. Si se cambian tareas o reglas después de conocer qué modelo produjo cada parche, aumenta el riesgo de ajustar la evaluación a los resultados.

Conviene seleccionar incidencias de repositorios distintos y agruparlas por tipo y dificultad: diagnóstico de un fallo, corrección acotada, modificación que afecta varios archivos y tarea donde las pruebas existentes no cubren por completo el comportamiento esperado. La distribución debe publicarse. Una colección dominada por cambios pequeños podría favorecer un perfil de trabajo; una formada principalmente por problemas amplios podría favorecer otro. La diversidad reduce ese riesgo, aunque no lo elimina.

Las incidencias deben ser genuinas y pertinentes para mantenimiento, pero su selección requiere cautela. El paper de SWE-bench describe un antecedente basado en problemas derivados de incidencias reales de GitHub. Su documentación de conjuntos y arnés puede orientar la construcción de una evaluación, pero usar tareas de un benchmark no garantiza que una prueba concreta mida bien el trabajo de un equipo. Además, OpenAI ha publicado una advertencia sobre limitaciones de SWE-bench Verified; esa advertencia debe atribuirse como la posición de OpenAI, no presentarse como una auditoría independiente de los modelos aquí comparados.

Para reducir contaminación, hay que revisar si la solución o un parche equivalente está ya presente en el contexto entregado, en los archivos de la tarea o en materiales disponibles para el sistema. También es importante describir qué información recibe cada modelo: issue, historial, instrucciones, documentación y pruebas. No basta con decir que ambos tuvieron «el mismo prompt» si uno tuvo acceso a datos adicionales o a herramientas diferentes.

Las tareas se deben ejecutar sobre copias limpias del mismo commit. El arnés, las dependencias y los comandos de prueba tienen que mantenerse iguales. Un entorno reproducible ayuda a separar el efecto del modelo del efecto de una máquina, una versión de dependencia o una modificación manual del repositorio. Si una tarea falla por infraestructura y no por el parche, debe etiquetarse con una regla fijada antes de ver los resultados.

Definir «tarea aceptada» antes de ver los parches

Una prueba superada no equivale automáticamente a una solución aceptable. Las pruebas existentes pueden no cubrir el requisito central, y un parche puede hacerlas pasar mediante un cambio demasiado amplio o una modificación que oculte el fallo. La aceptación debe combinar pruebas automatizadas pertinentes con revisión humana estructurada.

Como mínimo, la rúbrica debe preguntar si el parche resuelve la incidencia, si preserva el comportamiento no relacionado, si introduce regresiones conocidas, si modifica únicamente lo necesario y si puede mantenerse. Debe precisar qué ocurre cuando el resultado parece correcto, pero las pruebas son insuficientes. En esos casos, se pueden añadir comprobaciones independientes o clasificar la tarea como incierta, en lugar de forzar un aprobado o un suspenso sin evidencia.

Los revisores deberían recibir parches anonimizados y aplicar la misma rúbrica sin conocer el modelo de origen. Conviene registrar desacuerdos y contar con un procedimiento de resolución, como una segunda revisión. La evaluación humana tampoco es infalible: por eso deben publicarse la definición de aceptación, las categorías de rechazo y la proporción de decisiones disputadas.

Dos lecturas distintas: presupuesto común y plazo común

Una comparación bajo el mismo presupuesto y otra bajo el mismo tiempo responden a preguntas diferentes. No deben combinarse en una cifra única. En la primera, se asigna a cada modelo un tope de gasto por tarea, incluyendo los componentes de facturación definidos para la prueba. Se observa cuántas tareas termina con un parche aceptable antes de alcanzar ese límite. Un intento fallido consume parte del presupuesto y debe seguir figurando en el resultado.

En la segunda, ambos modelos reciben el mismo plazo máximo medido desde el inicio de la tarea hasta la entrega. El reloj debe incluir esperas, llamadas a herramientas, reintentos y cualquier otra latencia que experimente el usuario. Si la revisión humana se mide por separado, hay que decirlo; si se incluye, debe aplicarse con el mismo procedimiento. De lo contrario, comparar solo el tiempo de respuesta del modelo con el tiempo total de un flujo de trabajo mezcla métricas distintas.

Para que las condiciones sean justas, deben fijarse antes de ejecutar: gasto máximo, plazo, número de reintentos, límite de pasos, permisos y criterio de parada. Si el modelo alcanza el tope sin un parche aceptable, el resultado es una tarea no resuelta bajo esa condición, no una ejecución que se elimina del análisis. Este enfoque permite responder a una pregunta concreta de compra: qué se consigue con una cantidad máxima de dinero o con una ventana de tiempo determinada.

Qué medir por tarea y por grupo

La métrica central debería ser la tasa de aceptación: la proporción de ejecuciones que producen un parche aceptado según la rúbrica. Para que sea interpretable, se informa junto con el número total de tareas e intentos, no solo como porcentaje. Una tasa alta en pocas ejecuciones tiene una incertidumbre distinta de la misma tasa en un conjunto amplio.

Hay que reportar regresiones, pruebas relevantes superadas, cambios innecesarios, reintentos, errores de servicio, intervención humana y tareas que terminan sin parche. El gasto se puede expresar por intento y por parche aceptado, siempre con la fórmula y los componentes de facturación. Si un modelo no resuelve una tarea, su coste no desaparece del denominador: excluir los fallos produciría una visión artificialmente favorable del coste por éxito.

La latencia debe separarse, al menos, en tiempo de modelo, espera o cola cuando pueda medirse, operaciones con herramientas y tiempo total hasta la entrega. Para equipos, la duración de la revisión y la corrección manual también puede ser relevante. Dos modelos con tiempos de generación similares pueden imponer cargas distintas si uno requiere más comprobaciones o reparaciones.

Los resultados deben desglosarse por tipo de tarea y dificultad, además de presentar un resumen general. La cifra agregada puede ocultar que un modelo resuelve mejor cambios pequeños y el otro evita fallos en modificaciones que cruzan archivos. No se debería llamar «mejor» al resultado que lidera una media si el equipo del lector trabaja en un perfil de tareas diferente.

Repeticiones, fallos del servicio e incertidumbre

La salida de un modelo puede variar entre ejecuciones, incluso cuando la tarea y el entorno se mantienen. Por ello, una sola corrida por incidencia no basta para describir estabilidad. El número de repeticiones debe fijarse antes de comenzar, justificarse por el alcance del ensayo y mantenerse igual por modelo y tarea. Cuando las condiciones de servicio impidan completar una ejecución, debe distinguirse un error de infraestructura de un resultado fallido del modelo, sin borrar el dato.

Hay que mostrar la variación y la incertidumbre, no solo una media. Se pueden publicar conteos, intervalos apropiados y resultados por tarea; la elección concreta del método estadístico depende del diseño y debe describirse. Si el conjunto es pequeño, la conclusión debe ser limitada: una diferencia observada en esos casos no demuestra que se mantenga en otros lenguajes, repositorios, equipos o niveles de dificultad.

También importa la sensibilidad al arnés. Cambiar el prompt, el límite de herramientas, el presupuesto de contexto o las reglas de parada puede alterar el resultado. Una prueba controlada identifica el efecto de una configuración concreta; no mide una capacidad universal desligada de la forma de uso. Si se hacen ensayos adicionales con otras configuraciones, deben presentarse como tales y no mezclarse con el resultado principal.

Matriz de decisión para equipos de ingeniería

Sin resultados de la prueba, la matriz no puede asignar a Gemini 3.1 Pro o a Gemini 3.7 Flash una ventaja empírica. Sí puede ayudar a traducir los datos que se recojan en una decisión acorde con el trabajo del equipo. La comparación debe considerar el umbral mínimo de calidad: si un modelo no alcanza la tasa de aceptación o el nivel de seguridad exigido, un coste bajo no compensa por sí solo.

Para tareas rutinarias y bien delimitadas, el equipo puede evaluar primero si Flash cumple ese umbral bajo su presupuesto y plazo. Eso es una hipótesis a comprobar, no una propiedad demostrada aquí. Para tareas difíciles, con cambios extensos o consecuencias relevantes, hay que comprobar si Pro eleva la aceptación o reduce la intervención humana lo suficiente para justificar el gasto adicional, sin asumir que el nombre Pro garantiza ese resultado.

En ambos casos, el flujo debe conservar revisión humana cuando el riesgo del cambio lo requiera. Si los dos modelos producen parches que requieren correcciones frecuentes, o si las pruebas disponibles no permiten verificar el comportamiento, la conclusión razonable puede ser que ninguno satisface el criterio de automatización para esa clase de trabajo. La decisión también puede ser híbrida, siempre que el enrutamiento entre modelos se mida y no se dé por sentado que elegir según dificultad mejora el resultado.

Materiales para reproducir y límites de la conclusión

Una comparación que pretenda orientar una decisión de ingeniería debe publicar el protocolo, las tareas incluidas, los commits base, la configuración de cada modelo, los límites y la rúbrica de aceptación. Cuando los permisos y licencias lo permitan, también conviene facilitar los parches, registros anonimizados, resultados de pruebas y motivos de rechazo. Las exclusiones y los intentos fallidos forman parte de la evidencia, no son detalles secundarios.

El arnés puede apoyarse en prácticas de evaluación reproducible, como ejecutar parches en entornos aislados y controlar la aplicación de cambios. La documentación del arnés de SWE-bench describe un enfoque con entornos Docker para ejecutar tareas y evaluarlas. Eso es una referencia metodológica; no significa que emplear ese arnés garantice por sí mismo que la prueba represente el flujo de trabajo de una empresa.

Los resultados solo respaldarán conclusiones sobre los modelos, versiones, tareas, configuración y fecha documentados. No permitirán inferir automáticamente cómo se comportan otros productos de Google, otras versiones ni otros proveedores. Tampoco reemplazan la evaluación en repositorios privados, con normas de seguridad y revisión propias. La pregunta «¿cuándo compensa pagar más por tarea resuelta?» solo puede responderse después de fijar qué cuenta como tarea resuelta y medir el coste completo en el contexto relevante.

Por ahora, la respuesta editorial rigurosa no es un ganador, sino una condición de decisión: comparar ambos modelos con tareas congeladas, aceptación ciega, límites comunes de gasto y tiempo, y publicación de la incertidumbre. Si esos datos muestran diferencias consistentes y útiles para el perfil del equipo, se podrá recomendar una opción para ese uso. Si no, será más honesto informar que la evidencia disponible no permite distinguirlas.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.