Github Copilot: 5 meses después

Llevo un tiempo usando a diario Github Copilot: una IA de autocompletado de código que parece tener vida propia.

Un caso real buscando una API de conversión de moneda.

GitHub Copilot está disponible como una extensión para Visual Studio Code, Neovim y JetBrains. Va mandando el código y el contexto del entorno (lenguaje de programación usado, todo el código del proyecto y los nombres de los archivos) a los servidores de OpenAI, donde es completado y enviado de vuelta como una sugerencia. Al pulsar Tab, la sugerencia se añade al código, y al pulsar Esc se descarta.

Está basado en una IA llamada Codex, un descendiente de GPT-3 ajustado para su aplicación sobre lenguajes de programación y entrenado sobre todos los repositorios de dominio público de Github. Esto incluye código, comentarios y documentación en todos los lenguajes de programación imaginables.

Usarlo por primera vez es emocionante. Poner el nombre de una función y que genere no sólo su código sino también un enlace válido a una API de conversión de moneda parece sacado de una novela de ciencia ficción. Pero pasado el hype inicial es fácil ver que la herramienta no es perfecta. Necesita ser guiada para llegar al resultado esperado y hay que entender qué está escribiendo para no perder el control.

Por ejemplo, en el segundo 0:30 del vídeo anterior intenta usar un servicio de pago, así que defino una URL del Banco Central Europeo para darle una pista de qué herramientas usar. Y aun así, el código generado no es perfecto y hay que corregir a mano la expresión regular para parsear los datos.

Las pirámides de la muerte son uno de sus errores más típicos.

Aun así, decidí dejar el plugin activado durante los últimos 5 meses, y entre trabajar y programar por hobby lo he probado con muchos lenguajes distintos: Python, JS, CSS, C++, PHP, SQL, Arduino, VBS, OpenScad, GLSL… y ha sido un cambio radical en mi forma habitual de programar. Uno de esos saltos que se producen pocas veces.

Cuando era pequeño, mi padre compraba la Computer Hoy todos los meses y yo me la leía de arriba a abajo. En una edición, había una guía que rezaba algo así como "aprenda a optimizar sus tareas con Visual Basic" y por algún motivo me dio por seguirla. Cuando vi la magia que había en pensar una idea, describírsela a un ordenador y verla hecha realidad, sentí el primero de esos saltos.

Desde entonces, empecé a programar en VBS sin mucho más que aquella guía y unas fotocopias que alguien me consiguió. Mi forma de resolver mis necesidades era mirar esos 20 folios fotocopiados una y otra vez hasta que daba con una respuesta. Cuando los folios ya estaban ajados y amarillentos, llegó internet a casa y se produjo el siguiente salto.

Programar se volvió muy distinto. Ahora mi conocimiento no se limitaba a unos pocos folios, sino a la referencia completa de Visual Basic o cualquier otro lenguaje que quisiera aprender. Y entre referencias online, foros e hilos de correo seguí programando hasta empezar la Universidad, que fue cuando aprendí lo que era un IDE con debugger.

Ese salto también fue muy grande. Ahora podía escribir en un editor de texto que le ponía colores a mi código, me autocompletaba algunos métodos, me permitía navegar por la referencia del lenguaje con solo pulsar Ctrl+Space y ver línea a línea cómo cambiaba el estado de mi aplicación. Y por si fuera poco ahora el foro era Stack Overflow.

En la actualidad sigo programando así, pero cuento con otro as en la manga: la habilidad de no mirar una API si no recuerdo algo, de dejar al IDE terminar mi código siguiendo el mismo estilo de mi codebase, y en general de dedicarme a la parte divertida de la programación en vez de pelearme con la API de Matplotlib, Puppeteer o PyTorch.

Programando reconocimiento de imagen con una webcam en una Raspberry con sólo pedírselo por favor en un comentario.

Cuando salió Copilot todas las opiniones con una semana de uso eran que iba a reemplazar a los programadores y que era una herramienta mágica, por eso me quise esperar a haberlo probado un buen tiempo para entender cuál era su sitio en la caja de herramientas del programador. Y mi conclusión es que es muy, muy útil si se usa con algo de filosofía.

Es fácil dejarse llevar por las soluciones que propone Copilot (al fin y al cabo no hay Oscar al mejor código). Pero como no es perfecto, sin saber qué está haciendo es fácil hacer código poco funcional. O lo que es peor: funcional pero con vulnerabilidades difíciles de detectar. Algo parecido a hacer copy-paste indiscriminado de Stack Overflow.

Está claro que hay una tendencia hacia una programación cada vez más asistida. Y si el futuro está en herramientas como Copilot, tendremos que atajar retos como evitar la distracción de las recomendaciones o favorecer el pensamiento crítico ante sugerencias que impliquen malas prácticas y aproximaciones anticuadas; algo parecido a lo que ocurre con las IAs entrenadas en datasets reales y sus prejuicios adquiridos.

Por el momento podemos probarlo para entender mejor sus implicaciones. Si has leído hasta aquí y estás interesado, te gustará saber que la telemetría sólo se usa para ver qué soluciones son aceptadas, pero el código que se escribe no alimenta al modelo. Siendo un producto de Windows es probable que estén tirando la caña para pescarnos luego con un servicio de suscripción, así que podéis apuntaros a la beta antes de que sea demasiado tarde.

Todos los vídeos de este post han sido generados así, sin tener que mirar la referencia de FFMPEG por enésima vez.

No hay comentarios

Thüring: un roguelike programable

Este fin de semana he estado en la Global Game Jam (GGJ) haciendo un juego en 48 horas junto a @pabletos y @j_coronel. El resultado ha quedado bastante guay así que lo dejo por aquí.

Banner de Thüring

Una game jam es un evento en el que los participantes tienen que desarrollar un juego en torno a un tema con un límite de tiempo. La GGJ es un evento anual a nivel mundial con sedes físicas por todo el mundo, como la que ofreció espacio_RES en esta ocasión. El límite eran 48 horas y el tema era Duality.

Ya habíamos participado en otras jams anteriormente como la Familiar Game Jam, Ludum Dare o GM48; pero este es uno de los juegos que más cerrados han quedado en tan poco tiempo. La mecánica consiste en superar niveles de un roguelike (un juego de exploración por turnos) añadiendo fichas a un tablero.

Captura in-game de Thüring

El comportamiento del tablero es bastante sencillo: va leyendo las instrucciones de arriba hacia abajo (como una máquina de Turing) y aplicándolas sobre el jugador. La mecánica es bastante emergente y con muy pocos elementos se pueden encontrar muchas estrategias distintas, así que seguiremos puliéndolo para subirlo a la App Store.

Pese a haber participado en muchas jams, esta ha sido la primera en la que no hemos ido a la modalidad remota. Y aunque eso de estar en una casa 48 horas en modo cueva haciendo un juego no está nada mal, conocer a tantos desarrolladores, diseñadores y artistas tan buenos no tiene comparación, así que definitivamente repetiremos.

No hay comentarios

La llegada de los transformers

Las siguientes conversaciones han sido completamente generadas por una inteligencia artificial a la que sólo le he suministrado las tres primeras frases en negrita:

-/-<>

La magia que hay detrás de este autocompletar hipervitaminado es GPT-3, un algoritmo entrenado para continuar textos de forma convincente. En algunos casos logra captar rasgos tan sutiles y humanos como el humor mientras mantiene conversaciones complejas alrededor de un tema.

GPT-3 pertenece a la familia de algoritmos conocidos como transformers, que han demostrado ser muy efectivos reconociendo patrones complejos en secuencias de elementos. Tratando el lenguaje como una secuencia de palabras se pueden entrenar para que, dado un texto de entrada (contexto), lo complete de la forma más creíble.

Gracias al Information Sciences Institute de Los Ángeles he recibido una invitación para probar esta herramienta, una de las más avanzadas en la actualidad, el Optimus Prime del lenguaje natural. Ya ha cosechado muchos éxitos resolviendo retos basados en texto como mantener conversaciones indistinguibles de las de un humano, ayudar a escribir novelas o incluso programar software a petición.

Un robot transformer arrasando una ciudad

Un grado tan profundo de entendimiento del lenguaje natural puede mejorar enormemente nuestra forma de comunicarnos con interfaces conversacionales como Google Assistant o Alexa. Y como un gran poder conlleva una gran responsabilidad, la empresa que hay detrás de esta herramienta la está abriendo al público de forma gradual y con cautela. Actualmente, sólo es posible usarla por invitación o pagando una suscripción con una tarifa por número de palabras generadas.

Pero lo que está inventado ya no se puede desinventar y han surgido una infinidad de proyectos que intentan replicar los éxitos recientes de GPT-3 en abierto. De hecho, cualquier persona sin ningún conocimiento de machine learning ya se puede instalar la versión open source GPT-Neo y probarla con un solo click (y una buena tarjeta gráfica).

Estas alternativas son bastante recientes -tienen menos de 6 meses- por lo que el tsunami de bots indistinguibles de un humano aun está por llegar, aunque ya se han visto algunos casos de mal uso, principalmente destinados a manipular la opinión pública para hacer bulto en los seguidores de un partido político o alterar la valoración de criptomonedas.

Clip del test de Voight-Kampff en Blade Runner

Hay estudios recientes que dicen que un 15% de las cuentas de Twitter podrían ser bots, y nuestros mecanismos para detectarlos aun son bastante poco efectivos. Y al igual que las fake news, han venido para quedarse, así que habrá que ir pensando soluciones escalables para distinguir humanos y bots. Al menos hasta que tengamos un test de Voight-Kampff.

No hay comentarios

Arctic Code Vault

Hoy me he enterado de que el código de algunos de mis proyectos está impreso en una película fotográfica y enterrado en el ártico. Y si has contribuido a proyectos públicos de Github, seguramente el tuyo también.

Rollo de película del Artic Code Vault

Nuestros sistemas de almacenamiento son mucho menos duraderos de lo que solemos creer. Los CDs tienen una vida útil de unos 10 años, mientras que los discos duros convencionales aguantan 8 años de media, o algo menos en el caso de los SSD. Y si tienes algún disquete por casa, seguramente ya esté desmagnetizado.

Existen formatos más duraderos como el Blu-ray M-DISC, que según aseguran sus creadores tiene una durabilidad de 1000 años. Aunque si ya resulta difícil encontrar sitios donde revelar carretes de fotos, nadie nos asegura que para entonces siga habiendo lectores de CDs.

Por eso Github ha lanzado la iniciativa Artic Code Vault, que tiene como objetivo preservar el mayor repositorio de código de la humanidad en el Artic World Archive. Esta instalación está enterrada en una montaña del ártico a 250 metros de profundidad, suficiente para evitar los daños provocados por armas nucleares o pulsos EM.

Entrada al Arctic World Archive

El objetivo de este búnker es preservar la información necesaria para reconstruir la humanidad en caso de colapso global. La isla en la que se sitúa es parte de Svalbard, un archipiélago al norte de Noruega que está considerado zona desmilitarizada por 42 países.

La información se almacena en carretes transparentes usando una tinta magnética legible con una lupa, que se espera que aguante entre 500 y 1000 años. Y en caso de apagón, el propio frío de la montaña mantendría la temperatura y humedad en un rango razonable durante décadas.

El 2 de febrero de este año, Github hizo un snapshot de los proyectos públicos para convertirlos a este formato. Un total de 21TB de código que representa algunas de las contribuciones más importantes de los últimos años, desde lenguajes de programación a sistemas operativos completos.

Para saber si tu código también está en este búnker, sólo tienes que irte a tu perfil de Github y buscar el badge Arctic Code Vault Contributor.

1 comentario

El problema del User Agent

Hace casi 25 años, un popular navegador web llamado Mosaic tuvo una idea: incluir una cabecera en sus peticiones con la versión del navegador. Así, cada vez que un servidor recibiera una petición, podría saber con exactitud qué versión del navegador se estaba usando al otro lado.

User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

Al principio no se le dio mucho uso. Sin embargo, otro navegador llamado Netscape la popularizó poco después. Como las funcionalidades de ambos navegadores eran distintas, algunos servidores empezaron a usar esta cabecera para determinar qué respuesta enviar a los usuarios.

User-Agent: Mozilla/1.0N (Windows)

En vez de usar su propio nombre, este predecesor de Firefox usó el nombre de su mascota: Mozilla, abreviatura de Mosaic-killer. Pero esto sólo era el principio de la confusión. Otros navegadores como Internet Explorer usaron el nombre de Mozilla para indicar que eran compatibles con él.

User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)

Y esto sólo fue a más. Algunos navegadores como Opera le dieron al usuario la opción de elegir a qué navegador querían suplantar mediante un menú desplegable. Los servidores estaban cada vez más confusos y saber quién había al otro lado se estaba volviendo muy difícil.

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en)
User-Agent: Mozilla/5.0 (Windows NT 6.0; U; en; rv:1.8.1) Gecko/20061208 Firefox/2.0.0
User-Agent: Opera/9.51 (Windows NT 5.1; U; en)

Actualmente, los navegadores utilizan un User-Agent que poco tiene que ver con su nombre. Algunos servidores usan gigantescas bases de datos para detectar el navegador actual a partir de esta cabecera y así servir la versión de la página más compatible. Por ejemplo, tu User-Agent es:

Desconocido

Es por esto que las herramientas modernas para asegurar la compatibilidad como Modernizr o Polyfill.io ya no confían en el User-Agent. En su lugar, hacen pequeñas pruebas en el propio navegador para saber qué es capaz de hacer. Esta técnica se conoce como feature detection.

La existencia de millones de User-Agent distintos también ha facilitado el browser fingerprinting: un conjunto de métodos que usan esta cabecera y otros datos de tu navegador para identificarte de forma única pese a que te conectes tras un proxy, en incógnito y con un bigote postizo.

Aunque esta cabecera nació con un buen propósito, el paso del tiempo la ha convertido en algo distinto. Por eso, Chrome ha anunciado que va a dejar de usarla y otros navegadores como Firefox han apoyado esta decisión. Pero ¿qué implica actualmente dejar de usarla por completo?

Hace una semana me instalé un plugin para Chrome llamado User-Agent Switcher and Manager y dejé esta cabecera vacía, para ver cómo respondían las webs que suelo visitar. Os dejo algunos de los resultados que resumen esta experiencia:

Como veis, aun no estamos preparados para un cambio en esta dirección, y seguramente muchas webs nunca lleguen a estarlo. Por suerte Chrome va a aplicar este cambio de forma gradual, empezando por no volver a actualizar el valor de esta cabecera. Adiós, User Agent!

1 comentario

🍪 ¿Cookies?

Esta web usa cookies para identificar qué contenido es interesante y mejorar su calidad. Más información aquí.

4d8cd43bbbfbbd2b7aed08d9a2b0ef251cebfd3e2603b74b710a2d38b7f8ec39