La ventaja de 1M tokens — trabajar con codebases completos

Referencias oficiales: Gemini CLI overview · Contexto con GEMINI.md · Token caching · Sub-agents

Ruta de aprendizaje

1. Primeros pasos con Gemini CLI — instalación, autenticación y memoria
2. La ventaja de 1M tokens — trabajar con codebases completos — análisis de repos sin derroche ← Estás aquí
3. Gemini Extensions & MCP — crear flujos personalizados — empaquetar comandos, MCP y skills
4. Trusted Folders, Sandboxing y Restore — confianza, aislamiento y rollback
5. Headless Automation con Gemini CLI — scripts, CI y salida estructurada
6. Sub-agentes y Orquestación de Skills — delegación y flujos especialistas
7. Gemini Loop Seguro del Primer Día
8. Playbook Gemini para Entregas de Escala Semanal
9. Controles de Cambios de Alto Riesgo en Gemini
10. Manual Operativo de Gemini — Ritmo Escalable de Entrega por CLI
11. Gemini Playbook de Recuperación de Incidentes
12. Gemini Bucle de Hardening Post-Incidente
13. Gemini Simulacros de Resiliencia Caótica
14. Gemini Métricas de Resiliencia y SLO

Documentación oficial usada en este artículo

• Cómo GEMINI.md reduce prompts repetidos — Contexto con GEMINI.md
• Cuándo aplica token caching y por qué importa la autenticación — Token caching
• Cómo usar sub-agents para mapear arquitectura amplia — Sub-agents

El número impresiona, pero el workflow importa más

La ventana grande de Gemini CLI sí cambia el tipo de preguntas que puedes hacer.

Permite cosas como:

• mapear un repo grande antes de editar
• razonar sobre src, docs, configuración y locales al mismo tiempo
• comparar patrones entre carpetas lejanas
• mantener el hilo arquitectónico mientras lees archivos concretos

Pero la mejor práctica no es “meter todo el repo siempre”. La mejor práctica es usar la ventana grande para construir un mapa mejor y luego trabajar con intención.

Piensa en un loop broad → narrow → delegate

1. Broad pass

Empieza con una pregunta de escala repo.

gemini "@src @content @messages mapea la arquitectura de contenido, la estrategia de locales y los riesgos de mantenimiento"

Aquí no pides implementación. Pides mapa.

2. Narrow pass

Cuando ya tienes el mapa, enfócate solo en zonas de riesgo o ambigüedad.

• ¿qué loader resuelve realmente los slugs?
• ¿dónde puede romperse la paridad del frontmatter?
• ¿qué componente controla la tarjeta de cada artículo?

La gran ventana funciona mejor cuando ya existe una hipótesis amplia y solo necesitas afinar.

3. Delegate

Si el espacio de búsqueda sigue siendo enorme, conviene delegarlo a codebase_investigator u otro sub-agent en vez de quemar el historial principal con búsqueda ruidosa.

Tener 1M tokens no elimina la necesidad de apuntar bien

Aunque el contexto sea enorme, leer demasiado sin criterio sigue siendo mala idea:

• aumenta la latencia
• aumenta el coste
• las respuestas se vuelven más difusas
• la atención se va a archivos irrelevantes

Por eso siguen importando @ bien acotados, reglas persistentes en GEMINI.md y sub-agents para exploración amplia.

GEMINI.md es la forma correcta de no repetir siempre lo mismo

Mover instrucciones estables a GEMINI.md es uno de los mayores multiplicadores de productividad.

Por ejemplo:

• reglas de paridad entre idiomas
• tono editorial
• invariantes del frontmatter
• validaciones obligatorias después de editar MDX
• terminología propia del repo

Eso reduce tamaño de prompt y mejora consistencia entre tareas distintas.

Token caching cambia la economía del contexto grande

La documentación deja claro que el caching depende de la vía de autenticación. En la práctica, los workflows repetidos de gran contexto salen mucho mejor con API key o Vertex que con un enfoque informal de login de navegador.

Si piensas repetir una auditoría arquitectónica en CI o como rutina periódica, elegir bien la autenticación puede convertir un experimento caro en un proceso sostenible.

Tipos de prompt que escalan bien

Bueno: pregunta estructural

@src @content @messages
Explica cómo fluye el frontmatter MDX hasta el render de páginas y SEO.

Bueno: análisis de impacto

@src @content @package.json
Queremos cambiar la navegación del contenido. ¿Qué loaders, rutas, UI y capas de localización se verán afectadas?

Malo: petición total y vaga

Lee todo y dime qué importa.

El prompt malo obliga al modelo a adivinar el criterio. El bueno le da una lente.

Dónde brilla de verdad la ventana grande

Gana mucho valor cuando el trabajo cruza capas:

• contenido + routing
• localización + SEO
• docs + artefactos generados
• scripts + estructura del repo
• arquitectura + riesgo de implementación

Por eso Gemini CLI suele destacar más en repos medianos o grandes que mezclan código, contenido y operación.

Cuándo no conviene leer el repo entero

• cambiar un título
• corregir una errata
• tocar una sola clase CSS
• confirmar un flag puntual

Para trabajo pequeño, el prompt estrecho sigue siendo mejor.

Siguientes lecturas recomendadas

• Ejecución segura a escala repo: Trusted Folders, Sandboxing y Restore
• Delegar investigaciones grandes: Sub-agentes y Orquestación de Skills