Quien programa a diario conoce esa sensación: estás en plena racha, con el contexto fresco en la cabeza, y de repente toca salir del IDE para explicarle a un asistente de IA lo que quieres hacer… en un párrafo largo y bien redactado. Esa transición rompe el ritmo. Google reconoce justo esa fricción y, según el blog de Google for Developers, parte de un diagnóstico claro: a muchos desarrolladores les resulta poco natural describir cambios complejos con prompts extensos, y un solo prompt suele quedarse corto cuando el trabajo requiere varios pasos o un refactor grande.
Sobre ese problema concreto llegan dos funciones nuevas dentro de las extensiones de Gemini Code Assist para IntelliJ y Visual Studio Code: Finish Changes y Outlines, ambas impulsadas por Gemini 3.0. La idea no es “hablar” más con la IA, sino interactuar con ella de forma más parecida a como ya trabajas: editando código, dejando señales dentro del propio archivo y revisando cambios como lo harías con un compañero.
Gemini Code Assist en IntelliJ y VS Code: IA que se queda donde trabajas
La novedad importante aquí no es solo que haya IA, sino dónde se coloca. Estas funciones viven en las extensiones de Gemini Code Assist para IntelliJ y VS Code, con una ambición práctica: que el diálogo con el modelo ocurra dentro del editor y pegado al contexto del archivo que estás tocando. Es una apuesta por reducir el “cambio de ventana” mental y literal.
En el fondo, el planteamiento se parece a tener una persona a tu lado que entiende el proyecto mientras te ve trabajar. No le dictas un ensayo; le enseñas lo que llevas hecho, y a partir de ahí te ayuda a completar el resto o a entender el mapa del archivo.
Finish Changes: cuando el código que ya escribiste sirve de instrucción
Finish Changes parte de un principio sencillo: “muéstrame lo que quieres, no me lo describas”. En vez de pedirte un prompt formal, observa tus modificaciones en curso y, con Gemini 3.0, intenta completar la tarea interpretando tu intención a partir de código parcial, pseudocódigo o comentarios. Es, en la práctica, un modo de trabajar parecido a cuando dejas una frase a medias y alguien con contexto la termina sin preguntarte cada palabra.
En el anuncio, Google lo presenta como un “pair programmer” que actúa sin que tengas que formular una petición larga. Si estás implementando una función y te quedas en el esqueleto, puede rellenar la parte mecánica. Si has empezado un refactor y ya hiciste el primer cambio “modelo”, puede extrapolar ese patrón al resto del archivo. El objetivo es que no tengas que explicar con lenguaje natural algo que ya has demostrado con el propio código.
De pseudocódigo a implementación: convertir la intención en detalles
Una de las promesas más atractivas de Finish Changes es que acepta pseudocódigo o incluso frases en inglés llano dentro del archivo. Imagina que escribes algo como “validar entrada, normalizar, manejar errores, devolver respuesta” y dejas huecos. Esa es la típica parte que, hecha a mano, obliga a recordar detalles de sintaxis, excepciones y nombres exactos. Aquí, la IA intenta traducir esa “lista mental” a una implementación concreta.
La metáfora cotidiana sería cocinar con una receta escrita a grandes rasgos. Tú pones “hacer sofrito” y “cocer 15 minutos”; el asistente se encarga de los pasos intermedios que conoces, pero que te consumen tiempo cuando lo único que quieres es llegar al plato final.
Patrones repetitivos sin explicarlos: una demostración vale más que mil instrucciones
Otra situación frecuente: cambios repetitivos que cuesta describir. Por ejemplo, renombrar un objeto, ajustar un bloque de manejo de errores, cambiar la forma en la que se construyen respuestas, o introducir el mismo guard clause en varios puntos. A veces sabes exactamente qué patrón quieres… porque ya lo aplicaste una vez en el mismo archivo.
Según Google, Finish Changes se apoya en esa demostración: detecta el patrón que has aplicado y lo replica donde haga falta. No es magia; es un intento de capturar consistencia. En términos de flujo de trabajo, esto se parece a marcar una primera baldosa en un suelo y pedir que el resto se coloque igual, en lugar de explicar con palabras la distancia exacta entre cada pieza.
Instrucciones dentro del código: comentarios que actúan como órdenes
Para muchos equipos, el código ya está lleno de señales: TODOs, notas de revisión, recordatorios. Google formaliza ese hábito permitiendo escribir instrucciones como comentarios del tipo // TODO: <instrucción> o //! <instrucción>. Lo relevante es que esas instrucciones se colocan justo en el sitio donde deben aplicarse, como si fueran post-its pegados en el margen de un libro.
Esto encaja con situaciones muy reales: pegar un mensaje de error donde ocurre el fallo, dejar el feedback de una revisión en el bloque que hay que reescribir, o pedir que se mejore la legibilidad de una función concreta sin convertirlo en una conversación abstracta en un panel lateral.
Refactor y consistencia: cambios que se propagan y se revisan como un diff
Google también destaca que Finish Changes no solo completa el fragmento que falta, sino que puede propagar cambios relacionados corrigiendo referencias en el archivo para mantener coherencia. Es un punto importante porque muchos fallos de refactor vienen de ahí: cambias una firma, ajustas una llamada, y se te olvida la tercera.
Cuando se ejecuta, la herramienta incluye automáticamente otros archivos abiertos como contexto adicional, con la intención de captar estilos del proyecto y APIs internas. El resultado se presenta como un diff: puedes revisar, editar, aplicar o descartar los cambios sugeridos. Esto es clave para un uso responsable: se parece más a aceptar (o no) un parche que a delegar a ciegas. Para invocarlo, Google indica atajos directos: Option+F en Mac y Alt+F en Windows y Linux.
Outlines: un documento de diseño “vivo” dentro del propio archivo
La segunda función, Outlines, apunta a otro dolor clásico: entender código ajeno o un archivo grande sin documentación actualizada. Aquí la propuesta es que el IDE genere resúmenes en inglés, de alto nivel, intercalados con el código, alineando cada explicación con el bloque que describe.
La diferencia frente a una explicación en un chat lateral es de ergonomía: en lugar de leer un párrafo genérico y luego buscar “dónde encaja”, la explicación se pega al lugar exacto, como un guía que va señalando cada sala mientras caminas por un museo.
Menos carga cognitiva: ver el bosque sin perder los árboles
Google plantea que, con el panel de Outline abierto, el IDE puede generar automáticamente un esquema detallado del archivo activo. Ese esquema aparece tanto incrustado en el editor como en un panel dedicado, y cada elemento es clickable: al pulsarlo, el editor salta al inicio del bloque correspondiente. En la práctica, esto convierte el archivo en un mapa con puntos de interés, útil para orientarte rápido cuando no sabes ni por dónde empezar.
También se puede alternar entre una vista anotada y una vista solo de código para evitar “ruido visual”. Y, si modificas el archivo, puedes regenerar el outline para mantenerlo sincronizado. La invocación del panel se hace con Option+O en Mac y Alt+O en Windows y Linux.
Finish Changes + Outlines: una secuencia pensada para acelerar el “onboarding”
Las dos funciones tienen sentido por separado, pero el encaje que propone Google es casi una coreografía. Outlines serviría para reducir el tiempo de aterrizaje en un archivo desconocido, especialmente para gente nueva en un equipo, porque te da un resumen estructurado sin exigir que te sepas la arquitectura. Una vez entiendes qué hace cada bloque y localizas dónde tocar, Finish Changes entra para ejecutar la parte mecánica del cambio: completar la implementación, mantener consistencia y preparar un diff revisable.
Visto con una comparación cotidiana, Outlines sería el plano del centro comercial que te dice dónde está cada tienda; Finish Changes sería el asistente que, una vez encuentras la tienda, te ayuda a escoger talla y a tramitar el pago sin perder tiempo en los pasos repetitivos.