Gemini CLI y Claude Code: 5 patrones de terminal 2026

TL;DR

Gemini CLI ha vuelto a coger tracción en GitHub y Hacker News con guías muy prácticas de uso agentic en terminal. Si trabajas con Claude Code, no hace falta cambiar de herramienta: hay cinco patrones (gestión de contexto, MCP, hooks de shell, perfiles por proyecto y verificación previa) que puedes adoptar hoy y que mejoran tiempo de respuesta, fiabilidad y coste por sesión.

Por qué mirar a Gemini CLI si usas Claude Code

El movimiento alrededor de Gemini CLI en mayo de 2026 no es solo ruido. El repositorio oficial de Google supera las 100k estrellas y aparecen guías como "Gemini CLI tips and tricks for agentic coding" con cientos de votos en Hacker News. Esto no convierte a Claude Code en obsoleto, pero sí señala dónde la comunidad está afinando ergonomía.

En mi flujo diario con Claude Code en repos enterprise (Python/FastAPI y Java/Spring), he ido tomando ideas de la conversación de Gemini CLI sin renunciar a Anthropic. La clave: los patrones de CLI son portables entre agentes. Lo que cambia es el motor.

¿Qué es un patrón de terminal agentic?

Un patrón de terminal agentic es una convención reutilizable que estructura cómo invocas, supervisas y verificas un agente de código desde la línea de comandos. No es un comando suelto: es una manera de organizar contexto, herramientas y validaciones para que la sesión no dependa de improvisar cada vez.

Patrón 1: contexto comprimido al arrancar

Gemini CLI insiste mucho en abrir cada sesión con un "contexto base" mínimo: arquitectura, convenciones y decisiones activas. Claude Code ya lo soporta vía CLAUDE.md, pero la gente suele dejarlo crecer sin control.

El patrón útil es comprimir el CLAUDE.md a menos de 200 líneas con secciones fijas: stack, convenciones, scripts críticos, lo que está fuera de alcance. Si necesitas detalle, lo invocas bajo demanda con un @ a un fichero específico, igual que harías con --all-files en Gemini CLI. Para profundizar en cómo estructurar el archivo, este post sobre separación de responsabilidades aplica también al diseño del contexto.

Patrón 2: MCP como capa de herramientas, no como atajo

Gemini CLI normalizó hablar de servidores MCP con configuración explícita y permisos por proyecto. En Claude Code la tentación es enchufar MCP a saco (GitHub, filesystem, Notion, base de datos) y dejar que el agente decida. Mala idea: cada herramienta extra suma tokens a cada turno y aumenta la superficie de error.

El patrón que sigo en producción:

Un MCP por dominio del proyecto, no por capricho.
Permisos de escritura desactivados por defecto. Si el agente quiere escribir, te pregunta.
Auditoría: revisar settings.json antes de cada sprint largo.

Ejemplo mínimo de configuración local de Claude Code con MCP filesystem en solo lectura:

{
  "mcpServers": {
    "fs": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./src"],
      "env": { "MCP_READ_ONLY": "true" }
    }
  }
}

Esa variable MCP_READ_ONLY evita escrituras inesperadas durante exploración. Si trabajas con repos sensibles, complementa con secret scanning en GitHub MCP.

Patrón 3: hooks de shell para validar antes de aceptar

Una de las ideas más copiables de la comunidad Gemini CLI es ejecutar verificaciones en shell antes de que el agente proponga el siguiente paso. Claude Code lo permite mediante hooks definidos en settings.json.

Lo que uso para evitar commits con tests rotos:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit*)",
        "command": "pytest -q --maxfail=1 || exit 2"
      }
    ]
  }
}

Si los tests fallan, el hook devuelve código 2 y Claude Code aborta el commit antes de ejecutarlo. La validación sucede fuera del modelo, lo que evita falsas confirmaciones.

Patrón 4: perfiles de configuración por tipo de tarea

Gemini CLI fomenta tener perfiles distintos para "explorar" vs "editar". El patrón equivalente en Claude Code es alternar configuraciones según objetivo:

Modo	Modelo	Permisos	Cuándo usarlo
Exploración	Sonnet rápido	Solo lectura	Entender repo, buscar bugs
Edición	Opus 4.7	Lectura/escritura local	Refactor, feature nueva
Revisión	Sonnet	Solo lectura + git diff	Code review previo a PR

Los tres modos viven en perfiles distintos de settings.json. Cambiar entre ellos cuesta menos que tunear un único archivo gigante. Si vas a trabajar varias horas seguidas, planifícate como en este post sobre sesiones largas en horas pico.

Patrón 5: verificación con un segundo agente

La comunidad de Gemini CLI popularizó el uso de un "crítico" separado: un agente que revisa el output del agente principal antes de aceptarlo. En Claude Code, lo más cercano son los subagentes que dispara Task.

Mi patrón mínimo: cuando el agente principal acaba un refactor grande, lanzo un subagente con prompt corto del tipo "revisa el diff contra los tests existentes y los principios SOLID, devuelve solo los riesgos en menos de 200 palabras". El subagente no comparte el contexto sucio del principal, así que detecta cosas que el otro ya daba por buenas.

En producción

Adoptar estos patrones tiene coste real. Hooks mal escritos rompen flujos enteros. MCP mal configurados disparan tokens por turno. Perfiles duplicados se desincronizan con el tiempo. Lo que aplico al subir a producción interna:

Coste API: con cinco MCP activos noté un aumento de aproximadamente 30 a 40% en tokens por turno. Bajar a dos o tres lo dejó plano.
Latencia: hooks que llaman a pytest añaden segundos. Para repos grandes, conviene un subset rápido (tests unitarios) en lugar del suite completo.
Rollback: versiona settings.json en git. Cuando un cambio rompe el flujo, el git revert es la salida más limpia.
Equipo: documenta perfiles en el README del repo, no solo en tu home. Los compañeros no leen tu dotfiles.

Si trabajas con pipelines más complejos, esta lógica conecta con lo que escribí sobre preparación de datos con Python y LangChain: los patrones de validación previa aplican igual.

Errores comunes y depuración

Error: el hook bloquea siempre el commit aunque los tests pasen. Causa: códigos de salida mal interpretados. Solución: asegura que el hook devuelve 0 en éxito y 2 (no 1) en fallo bloqueante.
Error: el agente ignora MCP filesystem. Causa: ruta relativa mal resuelta al lanzar Claude Code desde otra carpeta. Solución: usa rutas absolutas o variables de entorno.
Error: el subagente revisor no ve el diff. Causa: el principal no commiteó los cambios antes de invocarlo. Solución: stage previo con git add -p y pasa el diff explícito en el prompt.

Preguntas frecuentes

¿Tengo que elegir entre Gemini CLI y Claude Code?

No. Son agentes CLI con motores distintos, pero los patrones de terminal son portables. Puedes usar Gemini CLI para exploración rápida y Claude Code para edición sin que se pisen.

¿Cuántos MCP servers son razonables en una sesión?

En mi experiencia, dos o tres por proyecto. Más de cinco activos a la vez aumenta tokens por turno entre 30 y 40% sin aportar valor proporcional. Activa MCP bajo demanda cuando sea posible.

¿Los hooks ralentizan mucho la sesión?

Depende del comando. Un linter o un subset de tests unitarios añade segundos y compensa. Lanzar la suite completa en cada commit rompe el ritmo: usa CI para esa parte.

Cierre

Hemos visto cómo cinco patrones de Gemini CLI (contexto comprimido, MCP disciplinado, hooks de shell, perfiles por tarea y verificación con segundo agente) encajan en el día a día de Claude Code sin cambiar de herramienta. La clave está en tratar el CLI como una superficie operativa, no como un chat con autocompletado.

¿Has copiado algún patrón entre agentes CLI que te haya ahorrado tiempo? Cuéntamelo en Twitter @sergiomarquezp_. En el próximo post toca llevar esta idea un paso más allá: cómo orquestar dos agentes CLI distintos en el mismo repo sin que se pisen los cambios.