Si lo llevamos a un ejemplo cotidiano, es como abrir el capó del coche para revisar el motor con la llave fuera del contacto. Puedes inspeccionar, señalar piezas, seguir cables y detectar qué falta, pero no hay riesgo de que el motor arranque por error. Con plan mode, esa “llave fuera” es el bloqueo deliberado a acciones que puedan modificar archivos o ejecutar tareas que alteren tu entorno.
Solo lectura como cinturón de seguridad para explorar
El corazón de plan mode es el enfoque de solo lectura. Cuando está activo, Gemini CLI queda restringido a un subconjunto de herramientas que sirven para orientarse y validar hipótesis: leer archivos, buscar patrones, navegar por carpetas y consultar documentación. La regla práctica es que el agente puede mirar todo lo necesario para entender tu petición, pero no puede cambiar nada del proyecto, con una excepción muy controlada: puede escribir su propio plan interno.
Este matiz tiene consecuencias importantes en el día a día. En proyectos grandes, muchas “meteduras de pata” ocurren por acciones impulsivas: generar archivos donde no toca, ejecutar un comando con parámetros incorrectos o proponer una refactorización sin haber visto dependencias ocultas. El modo de planificación obliga a que el primer paso sea comprender el terreno, como cuando recorres un piso nuevo antes de mover muebles: mides puertas, miras enchufes, localizas vigas y decides por dónde entra el sofá.
Para qué sirve en la práctica: migraciones, features y auditorías rápidas
Google plantea que en Gemini CLI puedes pedir cosas del estilo “investiga cómo migrar esta base de datos” o “planifica una nueva funcionalidad”, y el agente responderá con un mapa de dependencias y una estrategia de implementación sin tocar el repositorio. Es especialmente útil cuando el trabajo implica varias capas: código, configuración, infraestructura, pruebas, documentación y, a veces, decisiones de producto.
En una migración, por ejemplo, el valor no está en que alguien escriba rápidamente un script, sino en identificar riesgos: versiones de librerías, compatibilidad de drivers, esquemas que se transforman, puntos de integración con colas o caches, y planes de rollback. El plan mode empuja a que todo eso salga a la luz antes de escribir el primer comando de transformación. En una feature, el beneficio se nota cuando hay que decidir entre alternativas de arquitectura: el agente puede estudiar el patrón actual del proyecto, buscar precedentes internos, localizar dónde se aplican validaciones y proponer una implementación que “encaje” con lo existente.
ask_user: el agente que pregunta antes de suponer
Un plan solo es tan bueno como sus requisitos, y aquí aparece otra novedad: la herramienta ask_user. La idea es que el agente no rellene huecos a base de suposiciones, sino que pueda detenerse y hacer preguntas concretas. Eso cambia el tono de la colaboración: pasa de “te propongo algo y ya está” a “necesito aclarar dos decisiones para que el plan tenga sentido”.
En proyectos reales siempre hay información que no está en el repositorio o que no se deduce con seguridad: dónde vive una configuración “oculta”, qué nivel de compatibilidad se exige, qué tráfico soporta un servicio, si hay ventanas de mantenimiento o si el equipo prioriza rapidez frente a cambios mínimos. Con ask_user, el agente puede ofrecer opciones, pedirte que elijas una ruta arquitectónica o preguntarte por el lugar exacto de un archivo de configuración que no está donde esperaría. Es un gesto pequeño, pero es como ese mecánico que te pregunta si el ruido aparece en frío o en caliente: sin ese dato, el diagnóstico puede irse por el camino equivocado.
Contexto más allá del repositorio con herramientas MCP en modo lectura
Otro punto interesante es que plan mode no se queda limitado al sistema de archivos local. Google explica que también soporta herramientas MCP de solo lectura, lo que le permite a Gemini CLI incorporar contexto de otras piezas del “stack” de desarrollo sin poner en riesgo nada. El ejemplo que dan es muy representativo: leer una incidencia en GitHub, inspeccionar un esquema en Postgres o consultar información en Google Docs.
Esto encaja con cómo trabajan la mayoría de equipos hoy. El conocimiento no vive solo en el código; vive en tickets, documentos de arquitectura, discusiones técnicas, especificaciones y decisiones históricas. Poder traer ese contexto a la fase de planificación ayuda a que el plan no sea una receta genérica, sino una propuesta con memoria del proyecto. El matiz de solo lectura importa porque el agente no va a “tocar” tu base de datos ni a cambiar un issue por accidente: se limita a leer para entender.
Conductor y el enfoque de Context-Driven Development
Para flujos todavía más complejos, la publicación destaca Conductor, una extensión para Gemini CLI orientada a lo que llaman Context-Driven Development. En la práctica, Conductor actúa como un orquestador: divide el trabajo en pistas o etapas, guía una migración o una implementación larga, y aprovecha tanto plan mode como ask_user para ir confirmando decisiones clave.
Imagina una migración grande como una mudanza de oficina. No basta con llevar cajas; necesitas un orden, etiquetas, verificación de inventario, confirmaciones en puntos críticos y un plan para volver atrás si algo se pierde. Conductor busca cumplir ese papel: permitir comprobaciones previas exhaustivas y recopilar contexto sin riesgo, para luego transformar ese análisis en subtareas accionables. Google lo presenta como ejemplo de extensibilidad, casi como un “kit” para que cada equipo construya su propio flujo de planificación encima de estas piezas. También adelantan que están trabajando para integrar Conductor como modo incorporado en Gemini CLI más adelante.
Cómo empezar: activación por defecto, comandos y modelos de razonamiento
Según el anuncio, plan mode está habilitado por defecto para todos los usuarios. Entrar es tan directo como escribir /plan en el cuadro de entrada. También se puede alternar entre modos de aprobación con Shift+Tab, lo que sugiere una experiencia pensada para moverte rápido entre “planificar” y “ejecutar” según el momento. Si quieres adoptar una rutina de investigación primero, se puede ajustar en /settings estableciendo el “Default Approval Mode” en Plan.
Hay otro detalle relevante: el enrutamiento de modelos también aplica al modo de planificación. Google menciona que modelos “Pro” de mayor capacidad de razonamiento, como Gemini 3.1 Pro, se utilizan durante la planificación para mejorar la calidad de las decisiones arquitectónicas y la solidez del plan. Traducido a lo cotidiano, es como elegir una linterna más potente para inspeccionar un sótano complicado: ves más, te equivocas menos, tomas mejores decisiones antes de actuar.
Desactivarlo cuando estorba: la herramienta al servicio del flujo, no al revés
No todo el mundo quiere un flujo estructurado, y el equipo parece haberlo tenido en cuenta. Se puede desactivar desde /settings buscando “Plan”, lo que elimina el modo de la rotación de Shift+Tab y deja de registrar herramientas como enter_plan_mode y exit_plan_mode. El mensaje implícito es claro: si tu estilo es ir directo a ejecutar en un modo tipo “Auto-Edit”, puedes mantener ese enfoque.
En el fondo, la gracia de plan mode no es imponer un ritual, sino darte un espacio seguro para pensar con ayuda del agente. Hay tareas que se benefician de ese paso intermedio, sobre todo cuando el coste de un error es alto o cuando el sistema es lo bastante grande como para que una intuición inicial sea engañosa.