El 1 de octubre, GitHub metió a Copilot dentro de toda tu computadora, no solo en tu editor de código. Con la nueva función computer use, ahora en preview público para Copilot CLI y para la app de escritorio en macOS y Windows, el agente puede ver lo que hay en pantalla, clickear botones, escribir texto, arrastrar elementos y moverse entre aplicaciones que nunca tuvieron una API pensada para que una IA las operara. Lo interesante no es solo lo que ahora puede hacer, sino que el mismo GitHub, en su changelog oficial, recomienda no usarlo si existe cualquier otra forma de resolver la tarea. Eso dice mucho sobre en qué punto está esta tecnología hoy, y por qué conviene entenderla bien antes de meterla en el flujo de trabajo de un cliente.
Qué es exactamente "computer use" en Copilot
Según el anuncio oficial de GitHub Changelog, la función le da a Copilot la capacidad de leer el contenido accesible y el contexto visual de cualquier aplicación abierta, y a partir de ahí:
- Clickear controles, botones y menús.
- Escribir y editar texto en cualquier campo.
- Presionar teclas, hacer scroll y arrastrar elementos.
- Navegar flujos completos entre dos o más aplicaciones distintas.
Está pensada para el software que hasta ahora era imposible de automatizar sin un humano operándolo: herramientas legadas, apps de escritorio sin CLI ni integración MCP, o sistemas internos que solo existen como interfaz gráfica. GitHub mostró casos de uso concretos en su propio anuncio: llenar un reporte de gastos dentro de Safari, resumir información de una app legada, actualizar una presentación, capturar datos y mover información entre dos herramientas que no se conectan de ninguna otra forma. Se activa con el comando /computer on en Copilot CLI, o desde Configuración → Computer Use en la app de escritorio.
El permiso que pide antes de tocar tu pantalla
Copilot no toma control solo porque sí. Antes de operar una aplicación, pide aprobación explícita, y el desarrollador puede marcar apps como "siempre permitidas" o revisar y resetear esa lista cuando quiera. En macOS, el sistema guía al usuario para otorgar los permisos de Accesibilidad y Grabación de pantalla que la función necesita para funcionar. Y para quienes trabajan en equipo, los administradores de una organización pueden desactivar computer use por completo desde la configuración gestionada, o restringir si los developers pueden saltarse los prompts de aprobación.
Por qué GitHub te dice que no lo uses primero
Esta es la parte que más nos llamó la atención en Geek Vibes. En su propia documentación, citada por The New Stack, GitHub recomienda priorizar alternativas antes de recurrir a computer use: si una API, un servidor MCP, un comando de terminal, una herramienta de sistema de archivos o una herramienta de navegador dedicada pueden resolver la tarea, típicamente dan información más estructurada y resultados más predecibles que interactuar con el escritorio. En otras palabras: la propia GitHub posiciona su función más nueva y más vistosa como el último recurso, no como la solución por default.
Y no es solo prudencia de marketing. GitHub advierte explícitamente que el agente puede repetir acciones o quedarse atascado por cambios de timing o de ventana, seleccionar el control equivocado, escribir en el campo que no es, batallar con interfaces dinámicas y flujos complejos, o actuar sobre contenido inesperado en pantalla si la instrucción es ambigua. Y hay una advertencia de seguridad que cualquier agencia debería subrayar: "la información sensible visible en una ventana de aplicación también puede convertirse en contexto para el agente", según la nota de The New Stack sobre el lanzamiento. Si tienes datos de un cliente, credenciales o cifras financieras abiertas en otra ventana mientras Copilot opera tu pantalla, eso puede terminar siendo parte de lo que el modelo "ve" y procesa.
De la terminal al mouse: el salto que representa
Hasta ahora, los agentes de código como Copilot, Claude Code o Cursor vivían casi exclusivamente en la terminal o el editor: leían archivos, corrían comandos, abrían pull requests. Computer use rompe esa frontera y lleva al agente al mismo lugar donde trabaja un humano: el mouse y el teclado de todo el sistema operativo. Es el mismo movimiento que ya vimos con Operator de OpenAI o con el "computer use" de Claude, pero ahora integrado directamente al flujo diario de un developer dentro de GitHub Copilot, sin salir de la herramienta que ya usa para programar.
Ese salto importa para una agencia por una razón simple: abre la puerta a automatizar procesos operativos que antes quedaban fuera del alcance de un agente de código, como actualizar un ERP sin API, llenar formularios en un portal gubernamental o mover datos entre un CRM viejo y una hoja de cálculo. Pero también multiplica el radio de lo que puede salir mal, porque ya no se trata de un comando controlado en una terminal, sino de un agente operando software real con consecuencias reales si se equivoca de botón.
Lo que esto significa para agencias y developers
Si en tu agencia ya usan Copilot o están evaluando sumarlo al stack, esto es lo que cambia con computer use:
- Resuelve primero con la vía estructurada. Antes de prender computer use para un flujo de un cliente, revisa si existe una API, un servidor MCP o un comando de terminal que haga lo mismo. Resérvalo solo para el software legado que de verdad no tiene otra entrada.
- Audita qué hay abierto en pantalla antes de soltar al agente. Si vas a automatizar algo en el escritorio de un cliente, cierra o minimiza cualquier ventana con credenciales, información financiera o datos personales que no necesiten estar visibles durante esa tarea.
- No uses "siempre permitido" en entornos de cliente. Deja la aprobación en modo sesión por sesión mientras el feature siga en preview, y define a nivel organización quién puede saltarse ese control.
- Trata cualquier automatización con computer use como no verificada hasta que la pruebes tú mismo. El propio GitHub admite que puede equivocarse de campo o de ventana; no la conectes a un flujo de producción sin un humano revisando el resultado, al menos durante esta etapa de preview.
La lección de fondo conecta con algo que ya hemos repetido en este blog: cada vez que un agente gana más autonomía, el trabajo de la agencia no desaparece, se mueve. Deja de ser "quién programa la automatización" y pasa a ser "quién define los límites, los permisos y el punto donde un humano tiene que mirar antes de que algo se ejecute".
Esta función todavía está en preview y cambiará en las próximas semanas. Si quieres que evaluemos si tiene sentido meterla en algún proceso de tu operación, o si prefieres que primero diseñemos la alternativa vía API antes de tocar la pantalla de nadie, escríbenos a comercial@geekvibes.agency.
