Una de las novedades mas interesantes que se acaban de anunciar hoy en el Microsoft Build 2025, son GitHub Copilot coding agent, y las mejoras en la gestión de modelos sin salir de GitHub, amén de otras novedades como el soporte en la modernización de aplicaciones, y los Agentes SRE. Iremos revisando las diversas novedades en las próximas entregas, pero hoy nos centraremos en el Coding Agent.
Para empezar, veamos la definición que ha sacado Microsoft al respecto: GitHub Copilot evolucionará de un asistente en el editor a un socio de IA con un agente de desarrollo autónomo y asíncrono, el primero de su tipo, integrado en la plataforma GitHub. GitHub Copilot podrá probar, iterar y refinar el código en GitHub como un agente de IA que los desarrolladores pueden delegar tareas rutinarias y especializadas para avanzar en los proyectos. Copilot es un compañero de equipo de IA, no solo una herramienta.
Luego de haber probado esta nueva funcionalidad, podemos entender mejor la descripción y quedarnos con las siguientes ideas fuerzas que vienen con ello:
- Agente autónomo y asíncrono. Aquí lo asíncrono es clave, ya hemos trabajado con GitHub Copilot y como su nombre lo dice, es tu copiloto, programa a tu lado, conforme vas avanzando en tu desarrollo. El cambio aquí es que este agente opera tras bastidores, una vez que le dejas una tarea, pudiendo tu continuar con otra parte del proyecto de desarrollo
- Compañero de equipo de IA, si pues, quienes hemos trabajado en desarrollo de software conocemos bien a herramientas como JIRA o Azure Boards, donde esencialmente registramos tareas o actividades a ser desarrolladas, y muy frecuentemente ya asignando quien lo va a hacer, y ahora ese miembro de tu equipo que hará la tarea será… GitHub Copilot.
Ya con la parte teórica definida, pasemos a la acción para que tu mismo puedas empezar a probarlo, y también para entender sus límites.
Primero lo primero validemos que tenemos la funcionalidad activada, así que (estando logueado a nuestra cuenta de GitHub) vamos a https://github.com/settings/profile
Validamos que podemos hacer uso de la funcionalidad de acuerdo a los términos del preview del servicio, y tomemos una decisión muy importante, definir el alcance a nivel de nuestros repositorios:
Esto nos permitirá definir si todos los repositorios de nuestra cuenta podrán usar la funcionalidad o solo algunos repos selectos, esta decisión es importante especialmente si varias personas trabajan en nuestros repos, ya que el uso de esta funcionalidad esta sujeto a unas tarifas premium extras, por lo que puede que nos interese regular en donde podamos hacer uso de esta funcionalidad. En mi caso, como soy el único que usa el repo, lo he habilitado en todos mis repos.
Nota adicional, de momento esto solo puede activarse en los repos privados, lo comprobé directamente porque no pude usar la funcionalidad en uno de mis repos públicos, por lo que tuve que volver dicho repo en privado para hacer ciertos experimentos que necesitaba hacer.
Ahora si, manos a la obra ¿Cómo hago uso de la funcionalidad? En corto: creando una tarea razonablemente detallada en un Issue de GitHub, y en lugar de asignar la tarea a un humano, se lo asignamos a …. GitHub Copilot, como lo vemos en esta pantalla:
Como podemos ver tenia dos opciones respecto a quien asignar el Issue: yo mismo y Github Copilot, como es obvio se lo asigne a Copilot, y ahí empezó a trabajar por su cuenta para crearme los unit test solicitados:
Y en ese momento empezó a explicar lo que estaba haciendo, su plan, su descomposición del entendimiento del problema y los siguientes pasos a seguir:
Esta fue una captura de pantalla cuando Copilot aún estaba “pensando”, nótese los mensajes de que esta “In progress”, esto es muy importante ya que luego de proponerte cambios, va a intentar de ejecutar unos pipelines/workflows en GitHub Actions, para lo cual te presenta el botón de “Aprove and run workflows” que ya aparece desde que empieza a procesar la tarea, y aquí mi primera recomendación, no lanzar ese botón hasta que Copilot haya terminado la tarea. Y si, el proceso de solución no es instantáneo y el tiempo de duración de la resolución variara según la complejidad, recordemos, este agente es asíncrono por lo que aprovechemos estos 10 minutos para tomarnos un té o ir pensando que otro issue asignarle.
Concluida su tarea, y luego de haber ejecutado los workflows respectivos ya podríamos aceptar el Pull Request que nos ofrece, el cual es muy detallado respecto a los cambios propuestos
Esto del Pull Request es muy importante tenerlo en cuenta, ya que Copilot no aplica los cambios directamente sobre la rama master/main sino que crea una rama “copilot/fix-xxx” cada vez que atiende uno de los issues que vamos creando. Por lo que si, no era necesario aclararle que cree un PR.
Ok, esta fue la versión rápida de como funciona este Agente, vayamos un poco mas allá, para empezar, debo comentar que la aplicación con la que estuve trabajando es una sencilla aplicación Blazor desplegada en Static Web Apps, la cual muestra una tabla con fabricantes y modelos de autos, la aplicación Frontend no consume directamente los datos sino que los consulta a un API hecho en .NET, API que es quien consume los datos de un Table Storage de Azure. Si les interesa pueden ver como hacer dicha aplicación aquí.
Siendo una aplicación tan básica, era ideal para ir evolucionándola usando Copilot, como han podido ver, lo primero que hice fue pedirle que agregara las necesarias pruebas unitarias, y así sucesivamente le fui solicitando cosas como:
- Que mostrara data hardcodeada en caso de que el frontend no pudiera conectarse con la fuente
- Mejorar la claridad del código y actualizar las librerías
- Mejorar la gestión de la configuración centralizando en un único punto del código el lugar donde al frontend se le pasa la URI de la API. En ese momento empecé a escribir todas las tareas en español, aunque de todas formas Copilot detallara todo su razonamiento en inglés.
Luego decidid agregarle un buscador al sistema, originalmente la aplicación solo mostraba el contenido total de la tabla, pero luego de los cambios que hizo Copilot, la pantalla quedo así:
Lo importante aquí ya no es tan solo el resultado obtenido, sino el ver el proceso detrás, como convirtió mi pedido original:
En este análisis y plan detallado ya orientado al código:
Por cierto ¿se fijaron como Copilot para definir su tarea/PR utiliza un nombre mas prolijo que el original de mi issue?
Ya en este momento estaba emocionado con lo que estaba logrando, por lo que decidí pedirle que me permitiera editar y agregar nuevos registros, lo cual me llevo a esto (con la inclusión de nuevas pruebas unitarias, por supuesto):
Nada mal, pero en ese momento me percate de que la aplicación no podía editar bien un registro existente, así que estuvimos iterando mediante 7 issues, y en cada etapa me indicaba posibles soluciones, que involucraban la gestión de cadenas, manejo de excepciones, pero no funcionaba, hasta que me di cuenta que había un tema respecto a cómo había definido los datos en la tabla del Azure Storage, que siempre iba a generar errores si trataba de modificar cierto registro, eso no lo tenia Copilot en su contexto, por lo que por mas que volviera a razonar no iba a ser capaz de resolver el problema.
Así que si, esta nueva herramienta es muy útil, sumara mucho para poder avanzar en nuestros trabajos, siempre que tengamos unas consideraciones importantes:
- La decisión final esta en nosotros, durante este proceso rechace dos PR porque en las pruebas en ambientes efímeros no obtenía la respuesta deseada.
- Debemos revisar bien el “proceso de razonamiento” mediante el cual Copilot va armando su plan y la solución respectiva.
- Reducir la ambigüedad cuando detallemos la tarea a pedir, una de las razones del éxito que tuve cuando agrego en el buscador fue que mi pedido era razonablemente explicito y detallado.
- Debemos ser conscientes de que el sistema no tiene acceso a todo el contexto, en este caso Copilot no puede acceder a mi Azure y por ende no podía “ver” la forma en que su solución no estaba funcionando.
¿Qué les parece? ¿Se animan a probarla? Yo de momento tengo algunos experimentos en mente que probar, ya les ire contando y mil disculpas por la ausencia de estos meses.
No nos entretendremos explicando cómo funciona el servicio, solo debemos recordar Azure Functions se basa en proporcionar una abstracción al desarrollador, donde no tenemos que interactuar con una máquina virtual, por mas que por detrás haya una, y que su modelo de trabajo se orienta esencialmente a los eventos, donde un evento puede ser una invocación HTTP, un timer, la inserción de un elemento en una cola, etc. Y con esos pilares se pueden construir aplicaciones cloud native muy interesantes.
