Gemini CLI activa Plan Mode: investigación segura, ask_user y MCP de solo lectura antes de editar
Google anunció Plan Mode para Gemini CLI como un flujo read-only para investigar código, preguntar al usuario y usar MCP de solo lectura antes de pasar a implementación. Para builders, la mejora útil es reducir cambios prematuros y planes basados en suposiciones.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google llevó a Gemini CLI una idea que muchos equipos de agentes ya aprendieron por las malas: antes de editar, el agente debería investigar. Plan Mode convierte esa fase en un modo explícito, de solo lectura, donde el agente analiza el repositorio, busca dependencias, usa herramientas permitidas y hace preguntas antes de proponer una implementación.
La novedad no es un botón de “plan”. La señal útil para builders es que los coding agents están separando cada vez más dos momentos: entender el sistema y cambiar el sistema.
Qué cambia para el flujo diario
La publicación de Google describe Plan Mode como un entorno read-only. En ese estado, Gemini CLI puede navegar archivos, buscar patrones, leer documentación y construir un plan, pero no modifica el proyecto salvo sus propios planes internos.
También suma una pieza importante: ask_user. El agente puede detenerse y preguntar por una decisión de arquitectura, una ruta de configuración o una restricción de producto. Eso suena básico, pero resuelve una falla común: agentes que avanzan rápido sobre una suposición silenciosa y luego obligan a revertir medio cambio.
La intención de búsqueda aquí es concreta: Gemini CLI plan mode, Gemini CLI ask_user, read only MCP tools, coding agent planning workflow. No hay volumen inventado; la demanda se defiende por el anuncio oficial, el repo de Gemini CLI y el crecimiento visible de flujos con Codex, Claude Code, Copilot y Gemini en terminal.
MCP de solo lectura es la parte más interesante
Plan Mode no se limita al filesystem local. Google dice que puede usar MCP tools de solo lectura para traer contexto desde GitHub, Postgres, Google Docs u otros sistemas sin abrir permisos de escritura durante la fase de investigación.
Ese detalle cambia el diseño de seguridad. Un agente puede leer un issue, revisar un esquema y consultar documentación interna antes de tocar código. La frontera ya no es “MCP sí o no”, sino qué herramientas son seguras para la etapa de análisis y cuáles deben esperar aprobación.
Dónde puede fallar
Plan Mode no arregla malos requisitos. Si el ticket es ambiguo, el agente puede producir un plan pulido pero equivocado. Tampoco reemplaza tests, ownership ni revisión humana. La ventaja es otra: vuelve más visible el momento en que todavía puedes corregir rumbo sin haber tocado el código.
Hay tres riesgos prácticos:
- planes demasiado largos que nadie revisa;
- MCP read-only que igual expone información sensible;
- equipos que tratan el plan como garantía en vez de hipótesis.
La disciplina sana es exigir planes cortos, con supuestos explícitos, archivos afectados y criterios de validación. Si el agente no puede decir cómo va a probar el cambio, todavía no está listo para salir de modo plan.
Cómo usarlo en un equipo real
Yo lo pondría como gate para tareas medianas: migraciones, bugs de arquitectura, refactors con múltiples paquetes o cambios donde el agente necesita leer contexto externo. Para cambios pequeños, puede ser exceso.
Un buen contrato sería:
- entrar a Plan Mode;
- leer repo, issue y docs relevantes;
- hacer máximo tres preguntas si falta información;
- entregar plan con riesgos y pruebas;
- recién ahí pasar a modo de edición.
La pieza conecta con nuestra guía de function calling y tools: la herramienta correcta no es solo la que puede actuar, sino la que tiene el permiso correcto para la etapa correcta. Si estás empezando, el curso gratis sigue siendo el punto base; Plan Mode es para cuando ya quieres que el agente trabaje con más contexto sin darle poder de escritura antes de tiempo.