GitHub Copilot CLI mete rubber duck, prompts programados y voz local: donde si mejora el trabajo diario
GitHub refresco Copilot CLI el 2 de junio de 2026 con rubber duck, scheduling de prompts, voice input y una UI experimental. Lo importante no es la novedad por separado: es que el terminal gana revision, cadencia y entrada multimodal sin salir del flujo.

GitHub le dio una actualización importante a Copilot CLI el 2 de junio de 2026. El changelog viene cargado: rubber duck, comandos /every y /after, voice input y una interfaz experimental con pestañas para issues, PRs y gists.
Pero si aterrizas todo eso a trabajo real, la historia no es “el CLI tiene más features”. La historia es que el terminal gana tres capacidades que antes estaban repartidas o ausentes: crítica interna, cadencia automática y entrada más cómoda.
1. Rubber duck ya no es una metáfora, es un subagente
La mejora más interesante es rubber duck. GitHub lo documenta como un agente crítico que revisa plan, implementación o pruebas antes de seguir. No toca archivos; revisa. Y lo más importante: lo hace usando un modelo distinto al de la sesión principal.
Eso es una decisión bastante inteligente.
Si dejas que el mismo modelo se revise a sí mismo, muchas veces solo replica sus propios sesgos. En cambio, GitHub busca deliberadamente contraste entre familias de modelos. La doc incluso dice que si estás en Claude, el critic puede ser GPT, y viceversa.
Para builders, esto traduce a algo muy práctico: meter un segundo punto de vista antes de consolidar una decisión técnica.
No hace milagros, pero sí reduce un patrón común: el agente avanza convencido sobre un plan mediocre y solo te enteras cuando ya escribió código de más.

2. /every y /after sirven, pero no para lo mismo que una automation
Aquí hay una diferencia que conviene dejar muy clara porque mucha gente la va a mezclar.
Los nuevos comandos:
/everyrepiten un prompt a un intervalo fijo;/afterlo disparan una sola vez después de un delay;- y ambos funcionan solo mientras la sesión interactiva del CLI sigue abierta.
Eso los vuelve muy útiles para tareas dentro del loop de una sesión viva:
- volver a correr pruebas cada cierto tiempo;
- revisar comentarios nuevos en un PR;
- pedirle un chequeo posterior a un cambio que tardará en estabilizarse.
Pero no sustituyen una automation de repositorio. Si necesitas trabajo programado sin sesión abierta, la propia doc te manda a scheduler externo o a la capa de automations del cloud agent.
Ese límite es sano. Evita prometer un sistema de jobs persistentes cuando en realidad es una herramienta para ritmo dentro del trabajo interactivo.
3. Voice input suma más de lo que parece
La documentación de voz tiene un detalle que vale mucho: la transcripción corre completamente en la máquina local y el audio no se envía por red. Además, ya soporta dictado en inglés y español.
Eso hace que voice input no sea solo una curiosidad para demos. Puede servir de verdad para:
- prompts largos cuando estás pensando arquitectura;
- dar contexto verbal mientras inspeccionas logs o diffs;
- o registrar una instrucción rápida sin romper el flujo del teclado por mucho tiempo.
No va a reemplazar el texto para todo, pero sí reduce fricción cuando lo que te frena no es pensar sino teclear demasiado contexto.

4. La UI experimental importa menos que las primitivas
La interfaz nueva con tabs para issues, PRs y gists puede llamar mucho la atención. Y sí, probablemente hará más cómodo cierto trabajo.
Pero mi lectura es que el valor duradero está en las primitivas:
- crítica automática con rubber duck;
- prompts temporizados;
- voz local;
- y la posibilidad de escalar la sesión con
/experimental.
Esas piezas sí cambian cómo operas el CLI día a día.
Cómo la usaría yo sin caer en gimmicks
Si tuviera que probar esta release mañana, haría algo así:
- dejaría rubber duck activo para cambios no triviales;
- usaría
/every 30mpara correr chequeos o pedir resúmenes de feedback; - usaría
/afterpara revisiones puntuales después de una espera; - activaría voz solo para prompts largos o cuando el contexto verbal fluya mejor que escribir.
Lo que no haría es meter todo junto por moda. Porque entonces el CLI se vuelve más ruidoso, no más útil.
Donde Agente IA sí puede competir con esta historia
Las búsquedas buenas aquí no son genéricas. Son cosas como:
github copilot cli rubber duckcopilot cli /every /aftercopilot cli voice inputcopilot cli scheduled prompts
Esa intención es oro editorial porque viene de gente que ya usa el terminal para construir y quiere saber cómo trabajar mejor, no solo enterarse de una release.
Si luego quieres llevar esa lógica a ejecución más gobernada, enlaza bien con GitHub Copilot ya tiene sandboxes locales y en la nube. Y si lo tuyo ya pide trabajo recurrente a nivel repo, la siguiente parada natural es GitHub Copilot ya corre automatizaciones por horario y eventos.
Mi conclusión: esta actualización del CLI vale menos por el “wow” y más por otra cosa. Hace que el terminal se parezca más a un entorno de trabajo agentic serio, donde puedes pedir una crítica, temporizar acciones y hasta dictar en español sin sacar el flujo de su sitio natural.