GitHub Copilot: un programador que te acompaña y que no se cansa de sugerir
🟠 Intermedio · Importante · 5 min de lectura
Ayer GitHub abrió la vista previa técnica de Copilot, que escribe código
mientras tú escribes código. Llevo unas horas con él y esto no es el
autocompletado al que estamos acostumbrados.
Qué ha pasado
GitHub lanzó el 29 de junio la vista previa técnica de Copilot, desarrollado
junto a OpenAI y basado en Codex, un sistema nuevo de OpenAI. Lo anunció Nat
Friedman, consejero delegado de GitHub. El acceso es limitado y hay que
apuntarse a una lista.
La diferencia con lo anterior está en el alcance de la sugerencia. Copilot se fija en
el código en el que estás trabajando y propone líneas enteras o
funciones completas. No te ofrece el nombre del método que ibas a teclear, te
ofrece la implementación.
Funciona con muchos lenguajes, pero en esta vista previa se defiende
especialmente bien con Python, JavaScript, TypeScript, Ruby y Go.
Por qué importa
Hasta ahora, cuando no sabías cómo resolver algo, ibas a buscarlo. Abrías otra
pestaña, encontrabas una respuesta en un foro, la adaptabas. Ese viaje de ida y
vuelta es una parte enorme del día de cualquiera que programa, y nadie lo
contabiliza porque parece trabajo.
Copilot intenta eliminar el viaje. La sugerencia aparece donde estás, con el
contexto de tu fichero, con tus nombres de variable. Cuando acierta, te ahorra
la interrupción entera, que vale más que el tiempo de teclear.
Y hay un efecto de segundo orden más interesante: te enseña APIs que no
conocías. Escribes un comentario describiendo lo que quieres y ves aparecer una
forma de hacerlo que no se te habría ocurrido buscar. Para explorar una
biblioteca nueva es sorprendentemente eficaz.
Lo que no sabemos todavía
Tres cosas, y ninguna es menor.
La primera es la fiabilidad. Copilot sugiere con la misma seguridad cuando
acierta que cuando se inventa una función que no existe. No hay ninguna señal
en la interfaz que distinga un caso del otro, así que la revisión sigue siendo
tuya, entera. El riesgo real no es que escriba código malo, es que escriba
código plausible.
La segunda es la licencia. El modelo se ha entrenado con código público, y no
está resuelto qué significa eso cuando reproduce fragmentos reconocibles. GitHub
dice que es infrecuente. Infrecuente no es nunca, y en un proyecto comercial esa
diferencia importa.
La tercera es qué le pasa a quien está aprendiendo. Si el sistema te da la
implementación antes de que hayas entendido el problema, es razonable preguntarse
qué se queda sin practicar. No tengo respuesta, pero la pregunta no es retórica.
Qué haría yo esta semana
Apuntarme a la lista y probarlo con la guardia alta. Trátalo como a un
compañero rápido y confiado que a veces se equivoca: aprovecha las sugerencias,
lee cada línea antes de aceptarla, y no lo dejes tocar nada donde un error
salga caro.
Y una regla que me estoy aplicando: si no entiendo la sugerencia, no la acepto.
Suena obvio hasta que llevas dos horas aceptando cosas que funcionan.