El COO de GitHub explica cómo la IA generativa hace que los desarrolladores sean más eficientes

GitHub, la plataforma en línea para desarrolladores que permite a los usuarios crear, almacenar, gestionar y compartir su código, ha estado en un viaje de IA generativa desde antes de que ChatGPT o Copilot estuvieran ampliamente disponibles para el público.

A través de una temprana asociación con Microsoft, la plataforma de desarrollo adoptó Copilot hace dos años y medio, modificándolo para crear su propia versión: GitHub Copilot. 

La interfaz de chat conversacional basada en IA generativa se utiliza ahora como una herramienta tanto para los usuarios de GitHub y los empleados internos para ayudar en el desarrollo de código, así como una herramienta automatizada para el servicio de asistencia de TI o help desk.

Hay quien cree que a medida que la IA generativa siga evolucionando y pueda producir más código basándose únicamente en las peticiones de los usuarios, los desarrolladores dejarán de ser necesarios. Como dijo la semana pasada el CEO de Nvidia, Jensen Huang, gracias a la IA "todo el mundo es ahora programador. Este es el milagro de la inteligencia artificial". 

En lugar del desarrollo de software, Huang cree que los humanos deberían centrarse en habilidades más importantes como la biología, la educación, la fabricación o la agricultura, y el lenguaje de la programación es ahora el lenguaje humano.

Kyle Daigle, que lleva 11 años trabajando en GitHub, asumió el cargo de director de Operaciones (COO) hace aproximadamente un año. Ha formado parte de una estrategia de desarrollo de IA generativa centrada en descubrir cómo la tecnología puede beneficiar a sus aproximadamente 3.000 empleados -desarrolladores y no desarrolladores por igual- y a su comunidad externa de usuarios desarrolladores. Hasta ahora, IA generativa está consiguiendo que los desarrolladores sean un 55% más productivos. 

Daigle habló con ComputerWorld sobre las diversas formas en que IA generativa ha creado eficiencias y ayuda tanto a desarrolladores como a no desarrolladores. A continuación se recogen extractos de esa entrevista.

Cuando desplegaron Copilot, ¿por qué lo hicieron? ¿Y qué ha permitido hacer a GitHub?

Llevamos unos dos años y medio de viaje con Copilot. Empezamos a trabajar en Copilot cuando obtuvimos acceso anticipado a los modelos de OpenAI a través de nuestra asociación con Microsoft. Al igual que muchas empresas ahora, la pregunta principal era ¿cómo podemos hacer un buen uso de estos LLM? Tardamos un poco en descubrir la salsa secreta que ahora es Copilot. Al principio, cuando utilizábamos los modelos, pensábamos que íbamos a crear herramientas que documentaran el código. Ya sabes, le das tu repositorio y te dice lo que hace el código. 

Pero a través de la experimentación, la idea del 'texto fantasma' -la especie de modelo de finalización de lo que hace Copilot, donde te muestra la totalidad de un sólo mensaje frente a una sola línea- fue una especie de gran avance para ser capaz de sacar el máximo provecho de una herramienta de gran alcance. Y así, ahora tenemos más de un millón de usuarios de GitHub utilizando Copilot todos los días. Nuestras estadísticas muestran que les está haciendo un 55% más productivos, y está escribiendo alrededor del 60% del código; esperamos que llegue a alrededor del 80% con el tiempo y en muchos idiomas. 

Creo que lo más importante, y algo de lo que hablamos mucho con nuestros equipos internos, es que hace que los desarrolladores se sientan más realizados. Les permite hacer un trabajo más creativo y no el trabajo pesado. En lugar de buscar la IA generativa para hacer el trabajo creativo, estamos permitiendo que el ser humano esté en el asiento del piloto como el desarrollador.

Así, hemos tenido mucho éxito durante este tiempo en conseguir que cada desarrollador en nuestro mundo permita a GitHub ayudarles a escribir código. 

Internamente, nos hemos centrado en aprender de Copilot y aplicarlo a otros lugares en los que utilizamos herramientas de IA, incluido Copilot fuera de los casos de uso de desarrollo de software. Y, por supuesto, otras herramientas creadas a medida que salen al mercado para ayudarnos a todos a ser un poco más productivos.

La asistencia en el desarrollo de código parece ser uno de los primeros frutos maduros que abordó su plataforma de IA generativa. ¿Cuánto tiempo llevan utilizándola para ayudar en la producción de código y con qué lenguajes les ha ayudado?

En nuestros primeros experimentos, trabajábamos mucho con Python, JavaScript y lenguajes similares. GitHub es principalmente una empresa de Ruby, pero también escribimos en Go, C y FirGit. Y así fuimos ampliando nuestros casos de uso de Copilot y utilizándolo en diferentes idiomas. Pero en general, Copilot es capaz de trabajar en la gran mayoría de los lenguajes que están en la esfera pública. 

Si tienes un lenguaje propietario, puede emular ese lenguaje porque está mirando el código dentro de tu repositorio y puede hacer un trabajo bastante bueno averiguando qué necesita usar para alimentar la siguiente línea de código o el siguiente método.

Así, hemos pasado de un par de lenguajes de prueba a esencialmente todos los lenguajes de programación modernos que tienen suficiente contexto en código abierto e Internet.

¿Cómo va Copilot en términos de completar código?

En cuanto a las tasas de finalización de código, de lo que hablamos es de que, en algunos casos, al escribir con Copilot, puede que termine una línea de código, pero también puede que termine un método entero; puede que termine un archivo o una clase entera, dependiendo del lenguaje en el que estés.

Con algo como Copilot Chat, puedes hablar con Copilot y decirle: 'Este es el problema que intento resolver', y puede generar la totalidad de un archivo para ti. Entonces puedes decir: 'No quiero que sea azul, quiero que sea rojo. O quiero que utilice esta API o aquella API', ese tipo de ajustes.

Cuando hablamos de la cantidad de código generado, estamos hablando de la cantidad de código que Copilot dio y la cantidad que el usuario mantuvo a lo largo del tiempo. Obviamente, cuando recibes una finalización, puedes pensar: 'Oh, eso no está bien'. O si eres un desarrollador que puedes hacer que escriba un montón de código y luego darte cuenta de que puedes refactorizarlo ahora mismo, y que no es del todo correcto.

Lo que estamos viendo es que la gran mayoría del código generado por Copilot se mantiene. Más adelante, después de escribir código, envías un PR, ejecutas la integración continua, los siguientes pasos también son más rápidos. Así, la revisión del código escrito por Copilot con un desarrollador tiende a ser más rápida porque el código acaba siendo más correcto. La integración continua acaba siendo verde más a menudo que roja en la primera compilación porque el código tiende a ser más correcto. Así que hay un montón de impactos interesantes cuando eres capaz de utilizar Copilot como parte de tu flujo de trabajo como desarrollador.

¿Ha observado algún problema (imprecisiones) al utilizar Copilot?

El código que te proporcionamos también está imitando el código que ve en tu repositorio. Así que en algunos casos, si tiene una base de código más antigua, va a tener eso en cuenta y tal vez haga una práctica que ya no es moderna, como el encajonamiento de las variables o si tienes una biblioteca que va a llamar porque está tratando de emular tu proyecto existente junto con el modelo subyacente. Así que para algunos desarrolladores, la forma en que lo hacen es utilizar el chat Copilot para decir: 'Hey, estamos actualizando activamente esto en este momento, así que me gustaría utilizar el nuevo enfoque'. Y esa es una forma de superarlo.

Pero también estamos tomando una gran cantidad de la tecnología que tenemos con Copilot y los modelos de IA que tenemos debajo de ella y encontrar otros lugares en los que podemos ayudar a los desarrolladores a permanecer seguros solucionando vulnerabilidades. Así, una de las cosas que compartimos en la conferencia GitHub Universe en noviembre fue algo llamado Security Autofix, que utiliza una tecnología de IA subyacente similar. Cuando le dices que eres consciente de una vulnerabilidad en una base de código, no sólo vamos a decirte que tienes una vulnerabilidad que necesitas corregir; también vamos a hacer la corrección allí mismo. Todo lo que tienes que hacer es decir: 'Sí, estoy listo'. 

Así pues, Copilot sigue estando en el 'asiento del copiloto'. Todavía tienes que seguir las mejores prácticas. Sigues necesitando hacer escaneos de seguridad y escaneos secretos y todas las cosas que han sido verdad para las buenas prácticas de desarrollo de software, a pesar de todo. Pero estamos tratando de encontrar maneras de llevar la IA a lo largo de todo el ciclo de vida de desarrollo de software en GitHub para ayudarte. Para que no esté solo en tu IDE cuando escribes código.

A algunos en la industria tecnológica les preocupa que la capacidad de la IA para generar código automáticamente pueda eliminar a los desarrolladores. ¿Cuál es tu opinión?

Creo que a lo largo de la historia moderna ha habido muchos momentos en los que una tecnología ha llegado al mundo, como la imprenta, y todo el mundo se preguntaba: 'Un momento, ¿dónde va a ir a parar mi trabajo?' Pero en realidad lo que ha ocurrido es que muchos trabajos y oportunidades que ya no eran rentables han pasado a serlo de repente, porque los desarrolladores no tienen que dedicar el 60% o el 70% de su tiempo a resolver problemas que ya se han resuelto docenas, cientos y miles de veces.

La realidad es que GitHub Copilot está haciendo que los desarrolladores sean un 55% más productivos. Algunos clientes reaccionan diciendo: '¿Significa eso que acabo de recuperar el 55% del tiempo de mis desarrolladores?' La realidad es que lo que sus desarrolladores recuperan es la capacidad de resolver problemas más difíciles de forma más creativa de lo que antes eran capaces cuando tenían que hacer todo ese trabajo rutinario ellos mismos. 

Así que en GitHub seguimos contratando desarrolladores. Estamos contratando ahora mismo. Realmente, lo que encontramos es que estamos centrando más tiempo en esa discusión inicial o arquitectura y el problema que estamos resolviendo con los clientes. Porque a medida que la codificación se vuelve más rápida, es más importante que dediques tu tiempo a ese trabajo creativo de resolución de problemas que al trabajo rutinario que todos hemos hecho en algún momento de nuestra carrera. 

Estoy más entusiasmado con la oportunidad que la IA está empezando a darnos, que es que podemos hacer más de lo que hacíamos antes porque somos capaces de escribir más código que antes. Así, podemos resolver problemas más grandes que antes quizá no eran posibles, como esa gran reescritura de tu aplicación. Muchos clientes lo posponen y lo posponen porque ¿cómo podrían permitírselo? Pero, si es un 50% más barato, tal vez puedas pasar a esa nueva tecnología y utilizarla para avanzar aún más rápido en la resolución de la siguiente serie de problemas. 

Creo que nos queda mucho trabajo por hacer. Según todos los analistas del mundo, no hay suficientes desarrolladores. Así que aún nos queda bastante camino por recorrer antes de que tengamos que preocuparnos de que los desarrolladores no tengan suficiente trabajo que hacer.

¿Qué beneficios obtienen los equipos no desarrolladores de la IA generativa?

Una de las principales ventajas de Copilot que no se valora lo suficiente es la capacidad de aprendizaje y desarrollo, o de mejora de las competencias en el trabajo. Si alguien es nuevo en un puesto, en una empresa o en un lenguaje, puede llegar y tener inmediatamente a alguien a quien hacer preguntas, con quien escribir código y obtener esa retroalimentación inmediata con Copilot.

No se trata sólo de los nuevos. En muchos casos, también se trata de los desarrolladores más veteranos, a los que se les asignan esos viejos y desagradables proyectos que son extremadamente importantes para la empresa, pero que han estado guardados en un armario en algún lugar, manteniéndolo todo en funcionamiento. Cuando tienen que entrar en esos proyectos y hacer actualizaciones, la parte de formación y desarrollo ha sido muy importante porque pueden entrar y decir: 'Sé Java, pero no sé Scala. O sé Java, pero no sé .Net', o lo que sea. Y, '¿puedes ayudarme a saber cuáles son los siguientes pasos?'

En una línea similar, también centramos Copilot en esa experiencia de usuario, es decir, simplemente empiezas a teclear. No hay una verdadera capacitación; no hay aprendizaje, no hay botones que descifrar.

Así que cogí esos dos aprendizajes y empezamos a buscar internamente en otros lugares donde pensábamos que había trabajo y donde podíamos implementar la IA sin tener que habilitarla. Ese es el verdadero secreto. Si tienes que enseñar a la gente a utilizarla, no es mucho mejor que cualquier otra opción tecnológica que puedas elegir.

¿Cuáles han sido sus otras grandes victorias?

Una de las primeras grandes victorias que tuvimos en GitHub, y he visto esto en otros lugares, es tomar la IA y llevarla al entorno de TI. Tenemos algo más de 3.000 Hubbers [empleados de GitHub] que han introducido cientos y cientos y cientos de tickets [de help desk] en un sistema antiguo, para obtener ayuda sobre por qué su portátil no funciona, cómo consiguen acceder a la VPN, etc.

GitHub funciona esencialmente en Slack. Somos una empresa remota. Tenemos empleados en todo el mundo; no somos una empresa que vuelva a la oficina. Lo que hicimos fue decir, si todos estamos en Slack, ¿por qué no hacer que esa interacción con TI en Slack también sea impulsada por IA?

Así que, en lugar de entrar en un portal y enviar un ticket, tenemos un canal llamado IT Help Desk, y en ese canal hay un bot al que llamamos OctoBot. Y cuando haces una pregunta, un proveedor llamado MoveWorks con el que nos hemos asociado ve esa pregunta y OctoBot vendrá y dirá: 'Sí, sé exactamente lo que tienes que hacer. Estos son los siguientes pasos'. Y en muchos casos incluso podemos automatizar el flujo de trabajo para decir 'iremos a configurar esto en estos otros sistemas para usted'. 

Quizá es lo que todo desarrollador quiere y es el día de la actualización de su portátil y ha esperado sus dos años. Haga clic en este bot y le enviaremos su nuevo portátil, y como no hemos creado un nuevo sistema ni hemos tenido que enseñar a nadie un nuevo portal, hemos visto una enorme mejora. Hemos llegado a un punto en el que OctoBot resuelve el 30% de las incidencias desde el primer momento. Estamos ahorrando horas al día de tiempo de cada miembro del personal de TI que podemos reinvertir en otras iniciativas de IA.

Y, lo más interesante, la satisfacción del cliente subió 12 puntos. Así que ahora está en el 98%. No tuve que enseñar a nadie. No tuvimos que desplegar esta tecnología de una manera que normalmente se haría en un entorno corporativo. Simplemente la pusimos en marcha en un lugar donde todo el mundo pedía ayuda. 

Ese ha sido el gran secreto, creo, cuando hablo con compañeros de otras empresas sobre cómo se puede eliminar el trabajo manual y ahorrar tiempo a la gente cada día sin introducir comportamientos netamente nuevos, este es un ejemplo. 

Ahora estamos tomando ese proceso y probando unas seis o siete herramientas más actualmente dentro de la empresa. Alrededor del 10% de nuestra base de empleados está en algún tipo de prueba de herramientas de IA, donde estamos haciendo el mismo proceso: ¿cómo lo hacemos sin habilitación? ¿Podemos ponerlo en flujo? Entonces medimos el tiempo ahorrado. 

Si se ahorra tiempo y la herramienta se amortiza sola, adelante. Lo que no hacemos es tener una herramienta sobre la que haya que aprender, formarse o que sea muy abierta. Esta herramienta puede hacerlo todo por ti. Porque nos hemos dado cuenta de que realmente hace que la gente sea más productiva, más feliz y, en última instancia, le quita trabajo pesado.

¿Están considerando otras herramientas IA generativa?

En términos de GitHub, hemos tomado gran parte de la tecnología subyacente de Copilot y la hemos aplicado a nuestros casos de uso de soporte. Así, cuando estás en GitHub y tienes un problema y tienes que introducir un ticket, es muy similar a lo que hemos aprendido de nuestra experiencia en TI. Cuando empiezas a pasar por el flujo, y hacemos el proceso normal de cómo pasamos por el problema, hay una etapa en la que puedes terminar hablando con Copilot. Y lo llamamos Support Copilot. 

Básicamente, es capaz de recorrerlo con el contexto de lo que estás preguntando y qué acceso tienes, resolviendo potencialmente tu problema allí mismo. 

Por otro lado, mirando al exterior, también hemos ido más allá de la idea de que Copilot te ayuda a escribir código y a resumir una solicitud de extracción.

¿Qué pasa cuando le das la vuelta al modelo y empiezas a describirle a Copilot el problema que intentas resolver? Esa es la exploración en la que estamos trabajando, a la que llamamos Copilot Workspace. Básicamente, en lugar de empezar directamente en el código, empiezas con un problema; empiezas con una incidencia de GitHub en la que describes lo que intentas conseguir. Copilot puede tomar eso y pasar de la prosa [indicaciones escritas] de lo que estás tratando de hacer, al código, entonces puedes editar la prosa y cambiará el código. Luego puedes editar el código si lo necesitas. Por último, puedes probarlo, ejecutarlo, compilarlo y desplegarlo todo a partir del lenguaje natural. 

Intentamos ir más allá y descubrir cómo escribir más código, más rápido y con más precisión. A veces, el mejor código es el que no existe y se basa en el lenguaje humano.

¿Cómo se determina el retorno de la inversión y se ha calculado el de esta tecnología?

Se pueden medir millones de cosas [internamente]; lo mismo ocurre con el desarrollo de software. En el desarrollo de software, hay prácticas en las que se pueden medir las métricas DORA, es decir, la cantidad de código que se está introduciendo en el proceso. Se pueden medir las métricas espaciales. Hay todo tipo de métodos. 

Internamente, cuando intentábamos trabajar en estos casos de uso de TI, ocurría lo mismo. ¿Cuántos tickets se desviaron? ¿Cuántos tickets se cerraron? Al fin y al cabo, todos estamos midiendo la actividad. En última instancia, lo que intentamos medir es el tiempo. ¿Cuánto tiempo se recupera?

Para mí, cuando realizamos todas estas mediciones, la rentabilidad de la inversión está incorporada porque estamos recuperando tiempo que antes los empleados utilizaban para resolver esas incidencias, realizar flujos manuales, escribir código... sea lo que sea. Así que aprovechamos ese tiempo y lo invertimos en algo más estratégico. Así, el retorno de la inversión ha sido bastante claro en esta idea de OctoBot; el 55% más de productividad se reinvierte en última instancia automáticamente porque eres capaz de moverte más rápidamente como desarrollador de software, y luego estamos probando otras herramientas que están devolviendo a los empleados, potencialmente, de 30 minutos a una hora cada día. Así pueden hacer el trabajo más estratégico para nuestros clientes y avanzar más rápidamente.

Creo que se puede ver que en GitHub cómo se siente que somos capaces de hacer mucho más que antes, y no es porque hemos crecido un 50% en el último año; es porque somos capaces de invertir ese tiempo de nuevo. 

Para mí, cada medida que el sector intenta imponer a la IA es un intento de encajar a nuestros redactores en una modalidad de imprenta, pero todos estamos de acuerdo en que si dispusiera de una hora al día para hacer algo más que me gusta, sería una medida fácil. Puedo tomar eso e invertirlo en lo que es más estratégico para mí en GitHub.

¿Qué consejos daría a las empresas que se plantean utilizar o ampliar el uso de la IA generativa?

Lo mejor que pueden hacer las empresas para empezar es encontrar métodos para integrar la IA en los flujos de trabajo existentes: los equipos no necesitan reinventar la rueda, ya que es más fácil utilizar funcionalidades de IA que te mantengan en el flujo, no que requieran un comportamiento nuevo. Acérquese a los empleados allí donde estén, proporcióneles las herramientas de IA que necesiten y, con el tiempo, serán ellos quienes las difundan entre los demás. 

Otros consejos derivados de mi experiencia en GitHub son:  

• Haz un plan que puedas repetir. No estamos en la época del 'muévete deprisa y rompe', pero tampoco es el momento de desarrollar una estrategia de despliegue de seis meses que sirva para todo. Sin embargo, podemos aprender de décadas de escribir software que iterar es más importante que un enorme proyecto de reescritura que esperas que sea correcto. Es importante hacer pruebas piloto a menudo, al principio, en grupos pequeños. Tienes que hacer de la experimentación una parte fundamental de tu cultura. En GitHub, esto significa que más del 10% de nuestra empresa participa en proyectos piloto de IA. 
• Deja que la IA te quite trabajo. Las mejores herramientas de IA son las que permiten que brillen nuestras mejores cualidades humanas. No necesitamos que la IA sea creativa mientras nosotros nos afanamos en manipularla para que haga lo que queremos. Céntrate en lo que distrae a los empleados de hacer su trabajo -como la gestión del calendario, por ejemplo- y deja que la IA se ocupe de ello para que tus empleados puedan dar rienda suelta a su creatividad de formas más grandes y profundas.