Una ejecución de un agente de un millón de tokens es un problema de revisión, no una ventaja de velocidad

Gemini 4 Argon está disponible de forma general desde el 13 de octubre de 2026 y eleva el límite de salida de Google de 64K tokens a aproximadamente 1M, de modo que el modelo puede «generar cientos de miles de tokens en una sola trayectoria». La guía para desarrolladores de Google explica cómo. Por defecto, una petición normal sigue deteniéndose en 65.536 tokens de salida. Si configuras un valor mayor de max_output_tokens en la API de Interactions con background: true, el servidor seguirá generando contenido en bloques de hasta 64K hasta alcanzar el límite: hasta 1.048.576 tokens menos tu entrada. Google advierte que los prompts complejos tardan varios minutos.

La frase que merece la pena leer dos veces en el artículo de lanzamiento no es la del límite. Es lo que Google hizo con una salida de semejante tamaño. Google afirma haber utilizado Argon internamente en migraciones de C/C++ a Rust que van desde «decenas de miles de líneas en librerías esenciales como re2 o libgav1 hasta más de 800K líneas para el kernel Zircon de Fuchsia», y que estas reescrituras están «sometiéndose a rigurosas auditorías manuales y automatizadas, pruebas de emulación y revisiones antes de pasar a producción». El propio laboratorio que entrenó el modelo sigue revisando antes de desplegar. Un equipo cuyos agentes ahora pueden generar resultados con un límite dieciséis veces mayor necesita un plan de revisión antes de necesitar el modelo.

TL;DR

Un límite de salida de un millón de tokens traslada el cuello de botella de la generación de código a su aprobación. Ahora que una sola ejecución puede devolver tanta información, divide el trabajo en Tareas que una persona pueda revisar de una sola vez, cada una con una definición de terminado por escrito y un límite de tiempo específico, exige evidencias en cada Tarea y calcula primero la capacidad de revisión. Los agentes investigan, ejecutan, prueban y reportan. Las personas marcan el rumbo, otorgan autorizaciones y aprueban el resultado.

Qué cambia cuando una sola ejecución puede devolver tanto

La capacidad de revisión es la cantidad de resultados finales generados por agentes que un equipo puede leer, evaluar y aprobar en un día, y la determinan las personas, no el modelo. Un límite de salida más alto solo incrementa cuánto puede llegar al mismo tiempo.

El límite anterior funcionaba como un control de alcance accidental: las respuestas solo podían tener cierta longitud, por lo que el trabajo se entregaba por partes con puntos de control entre ellas. El motivo que Google argumenta para este nuevo límite apunta a lo contrario: margen suficiente para «resolver problemas difíciles de una sola vez». Para un revisor, «de una sola vez» significa un solo resultado, una sola decisión y ningún punto de control intermedio donde alguien pudiera haber advertido: «dirección equivocada».

Además, este límite es compartido. La ventana de 1.048.576 tokens de Argon abarca la entrada, el razonamiento y la salida en conjunto, de modo que una ejecución que lea 300K tokens de código deja unos 748K restantes para razonar y escribir. Aun así, sigue siendo más de lo que cualquiera puede leer línea por línea de una sola vez.

Luego está la calidad. Tras el anuncio, Bloomberg informó de que empleados anónimos de Google afirmaban que Argon dejaba que desear en ciertas tareas de programación y frontend en comparación con sus benchmarks; Google tachó esto de inexacto. La propia tabla de Google muestra a Argon por detrás en dos de sus cuatro categorías de codificación agéntica (nuestra comparativa las analiza en detalle). Un benchmark es una afirmación sobre un conjunto de pruebas. Tu diff es una afirmación sobre tu base de código, y se aprueba a partir de evidencias, sin importar qué modelo lo haya escrito.

Define el alcance de la Tarea, no el presupuesto de tokens

La unidad que tú controlas es la Tarea, no el conteo de tokens. Si dejas que el límite del modelo determine el tamaño del trabajo, obtendrás el resultado más extenso que pueda producir. Si lo defines tú, obtendrás resultados que una persona pueda aprobar. Las recomendaciones de la propia Google coinciden: mantén el valor predeterminado de 65.536 para tareas estándar y utiliza el modo en segundo plano con 131.072 o 262.144 tokens para razonamiento complejo y programación, no el máximo.

La propia descripción de Google ya divide el trabajo por librería y kernel. Divide una migración de la misma manera: una Tarea por módulo que un revisor pueda completar de una sola vez. En Sharkly, esto se traduce en una Tarea principal con una subtarea por cada módulo, junto con enlaces de «bloquea / está bloqueado por» cuando un módulo debe integrarse antes. El objetivo, el alcance y los criterios de aceptación quedan reflejados en la descripción de la Tarea, tanto para el Agente como para el revisor:

SH-412  Port the tokenizer module to Rust
Parent: SH-400  Port the parser library to Rust
Blocked by: SH-411  Port the shared buffer types

Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work

Dos opciones de configuración del Agente respaldan esto. El tiempo de espera por Tarea se ajusta a la Tarea, no al modelo: por encima de la ejecución razonable más larga para un módulo, y por debajo de la ejecución que lamentarías pagar. La concurrencia máxima (tareas asignadas) limita cuántos módulos están en curso simultáneamente, ya que cuarenta subtareas ejecutándose a la vez generan cuarenta resultados esperando al mismo revisor.

La regla de decisión es doble: confía todo el trabajo a una sola ejecución cuando las comprobaciones automáticas puedan cubrir el resultado íntegro, como en un cambio de nombres sistemático respaldado por el compilador y una suite completa de pruebas. Divídelo cuando una persona deba evaluar cualquier parte, lo que en una migración de lenguaje representa la gran mayoría. Las ejecuciones que superan tu jornada laboral exigen las mismas condiciones previas: una condición de parada, un estado de espera y una persona a cargo a la mañana siguiente.

Añade las evidencias a la Tarea

Un resultado extenso sin evidencias no es una revisión: es una reejecución manual, realizada por una persona y a paso lento.

El ejemplo de libgav1 ilustra cómo son las buenas evidencias. Google explica que Argon sustituyó 32K líneas de código SIMD en una versión migrada a Rust preexistente, y el resultado «se ejecuta 2,7 veces más rápido que la versión de Rust, generando una salida de vídeo idéntica». La segunda mitad de esa frase es lo que permite que 32K líneas sean revisables: las mismas entradas pasaron por el código antiguo y por el nuevo, y las salidas coincidieron. Eso son pruebas diferenciales, y liberan al revisor para centrarse en lo que una comparativa no alcanza: código no seguro (unsafe), rutas de error y si la mejora de rendimiento se mantiene en cargas de trabajo reales.

Cada ejecución debe devolver cuatro elementos a la Tarea:

Esa es la estructura que plantea el propio flujo de trabajo de Sharkly: el Agente ejecuta la comprobación de tipos, las pruebas y la compilación; luego adjunta el resumen de cambios, los resultados de verificación y las limitaciones conocidas; finalmente, una persona aprueba, solicita cambios o decide el paso de fusión y despliegue. La respuesta definitiva del Agente se almacena en la Tarea y el registro de ejecución queda en la pestaña Executions, de modo que las evidencias vuelven a la Tarea en vez de perderse en una terminal. El artículo sobre cómo revisar código generado por IA con evidencias a nivel de tarea aborda el orden de lectura, y las plantillas de traspaso proporcionan un formato definido al informe.

Superar las comprobaciones automáticas no equivale a una aprobación, como tampoco lo es fusionar un pull request: en Sharkly, hacer merge de un pull request vinculado no modifica el estado de la Tarea. Las comprobaciones automatizadas validan lo que pueden, y el artículo sobre agentes de revisión de código con IA muestra cuáles son sus límites. Es una persona quien determina si el cambio cumple lo solicitado en la Tarea.

Calcula la capacidad de revisión antes de la ejecución

La revisión funciona como una cola: llegan resultados, una persona los despacha y, si el ritmo de llegada supera al de despacho, la cola crece. Un límite de salida mayor solo altera el lado de las entradas. Veamos un ejemplo práctico con datos hipotéticos en lugar de un proyecto real:

Revisando únicamente el diff, la migración requiere 80 horas de revisión, unos 27 días laborables. Con evidencias en cada Tarea, cuesta 20 horas, unos siete días. Ya sea con una sola ejecución gigantesca o con cuarenta más pequeñas, la carga en la balanza del revisor es equivalente.

Lo que cambia es la toma de decisiones. Cuarenta Tareas llegan a un ritmo que tú controlas y cada una recibe su propio veredicto. Un único resultado que abarque los cuarenta módulos recibe un único dictamen, por lo que un problema en el módulo 31 echa por tierra los otros 39. En cambio, con subtareas, un comentario en la que ha fallado permite iniciar una ejecución correctiva en esa Tarea específica mientras las demás continúan su curso.

Luego calcula los costes. Una ejecución al máximo genera alrededor de 1M de tokens de salida: aproximadamente 10 $ a la tarifa de 10 $ por millón hasta el 30 de noviembre, y unos 20 $ a partir del 1 de diciembre. En un proyecto de Tier 1, el límite de gasto de Google es de 10 $ por ventana móvil de 10 minutos, por lo que una sola ejecución al máximo consume el límite de una ventana completa a la tarifa actual y el doble de dicho límite a partir del 1 de diciembre. Mantén una concurrencia máxima reducida en cualquier Agente al que se le permitan ejecuciones tan extensas.

Haz tus propios cálculos antes de la primera gran ejecución, no cuando la cola ya se haya acumulado. El artículo sobre el cálculo de la capacidad de revisión detalla esta misma aritmética a nivel de equipo, y la revisión humana como cuello de botella analiza los estados y filtros de control que permiten visibilizar la cola.

Lista de comprobación antes de tu primera ejecución de un millón de tokens

• [ ] El trabajo está dividido en Tareas que un revisor puede completar de una sola vez, con subtareas y enlaces de tipo «bloqueado por».
• [ ] La descripción de cada Tarea especifica qué significa «terminado» y qué queda fuera de alcance.
• [ ] El tiempo de espera por Tarea se ajusta a la Tarea (las peticiones largas en segundo plano tardan minutos), no al límite de salida del modelo.
• [ ] Una ejecución al máximo se ajusta al límite de gasto del nivel de tu API.
• [ ] La concurrencia máxima del Agente para Tareas asignadas se adapta a lo que los revisores pueden procesar, no a lo que el Computer puede ejecutar.
• [ ] Cada ejecución devuelve un resumen de cambios, la salida de las comprobaciones, qué se verificó y las limitaciones conocidas.
• [ ] El trabajo que preserva el comportamiento incluye una verificación diferencial frente al código anterior.
• [ ] Cada Tarea tiene un revisor asignado, y la aprobación consiste en el cambio de estado realizado por esa persona, nunca como un efecto secundario de un merge.

Nada de esto depende de Argon, al que ya se puede llamar con cualquier clave de API de Gemini de pago. La frase de Google sirve de plantilla: una salida extensa, seguida de auditorías, pruebas de emulación y revisión, y solo entonces, producción. Sin importar qué laboratorio lance el próximo salto en volumen de salida, el plan reside en la Tarea, no en el modelo. Sharkly no elige modelos: según la documentación de Agents, un Agente utiliza el modelo predeterminado de su Runtime, que puede modificarse mediante Custom arguments o la configuración de la herramienta. Cuando un modelo de mayor capacidad llega a un Runtime en ejecución, ese valor cambia mientras que las Tareas, las evidencias y el control de revisión permanecen inalterados. El contexto, el progreso, los bloqueos, los resultados y la revisión humana se mantienen visibles desde la solicitud hasta el despliegue.

Si ya estás ejecutando varios agentes, Sharkly te ofrece un único lugar para gestionar sus tareas y resultados.