Cómo evaluar Gemini 4 Carbon en agentes de programación sin arriesgar producción

Un agente puede pasar veinte pruebas y dejar una migración imposible de revertir. Para evaluar Gemini 4 Carbon, no basta con comprobar que genera código correcto: hay que observar cómo trabaja cuando una tarea exige planificar, ejecutar herramientas, corregir errores y mantener restricciones.

Google habilitó gemini-4-carbon en la API de pago el 10 de noviembre de 2026. Puedes consultar el registro de cambios de la API y el anuncio original de Google.

Qué afirma Google y qué falta comprobar

Google presenta Carbon como un modelo especialmente capaz en trabajo agéntico prolongado, incluida la programación compleja. Publica resultados destacados en evaluaciones como CursorBench 4.0 y afirma ventajas de coste por tarea frente a otros modelos.

Son afirmaciones del proveedor. No demuestran que Carbon resuelva mejor los problemas de tu repositorio. Este artículo propone un protocolo de evaluación; no presenta pruebas propias ni resultados medidos.

La pregunta útil es otra: ¿completa más tareas aceptables con los mismos permisos, herramientas y límites que tu modelo de referencia?

Elige tareas que puedan salir mal de formas distintas

Prepara un conjunto fijo de encargos, con criterios de aceptación escritos antes de ejecutar el agente. Incluye casos como estos:

• SaaS: corregir un fallo de autorización entre organizaciones sin romper el acceso legítimo.
• Herramientas de desarrollo: modificar una CLI conservando sus códigos de salida y compatibilidad.
• Pruebas: reproducir un error y añadir una regresión que falle antes del arreglo.
• Migraciones: transformar un esquema con datos sintéticos, validar integridad y ensayar la reversión.
• Arquitectura de agentes: recuperar una ejecución interrumpida sin duplicar escrituras ni repetir acciones externas.

Evita encargos ambiguos como «mejora este servicio». Define qué debe cambiar, qué debe permanecer intacto y qué evidencias debe entregar el agente.

Compara modelos, no configuraciones distintas

Ejecuta Carbon y el modelo de referencia sobre el mismo estado del repositorio. Mantén constantes las instrucciones, las herramientas disponibles y los límites de ejecución. Registra también los parámetros de cada modelo.

Separa el modelo que resuelve la tarea del mecanismo que la evalúa. Si utilizas otro modelo como juez, su valoración debe ser auxiliar: la aceptación debe apoyarse en comprobaciones independientes y revisión humana.

Repite cada caso. Una ejecución brillante no permite saber si el comportamiento es consistente.

Aísla las pruebas y limita los permisos

Usa entornos desechables, bases de datos de prueba y credenciales sin acceso a producción. Restringe la red a los destinos necesarios. Exige aprobación humana para despliegues, borrados y cambios de permisos.

Guarda trazas de llamadas, comandos, errores y modificaciones. Comprueba si el agente reconoce un bloqueo o intenta sortearlo ampliando el alcance.

Conserva pruebas de aceptación fuera de los archivos que puede modificar. Un agente que cambia el test para hacerlo pasar no ha demostrado que corrigiera el problema.

Mide el coste de una solución aceptada

Registra éxito, duración, tokens, reintentos, herramientas utilizadas y minutos de revisión humana. Calcula el gasto total del conjunto dividido entre las tareas aceptadas; incluye también los intentos fallidos.

Según Google, el precio introductorio hasta el 30 de noviembre de 2026 es de 2 dólares por millón de tokens de entrada y 10 por salida. Después pasa a 4 y 20 dólares. Presupuesta ambos escenarios sin convertir la tarifa por token en el único criterio.

Decide antes qué justificaría adoptarlo

Fija umbrales de aceptación, gasto máximo y fallos inadmisibles. No compenses una vulneración de permisos con varios aciertos menores.

Prepara cinco tareas reales en un entorno aislado y compara cuántas soluciones aceptables entrega cada modelo antes de darle acceso a producción.