AlphaEvolve: Un Agente AI para optimizar algoritmos

Desde hace años tengo la sana costumbre de disfrutar con mis amigos en un viaje de una semana donde solemos irnos de aventura por mares, países y lugares fuera de las tierras de España. Es un viaje donde las rias y la diversión son la tónica general, pero, como somos como somos, nuestras comidas, cenas y conversaciones suelen ser de programación de algoritmos con Q# para entornos de simulación de Quantum Computing y la Supremacía Cuántica, de cómo hacer transacciones de BitCoin sin usar un Exchanger y los problemas de los tamaños de bloques - que se explica bien en este libro - y el coste de la compra por eso, de las arquitecturas Serverless en plataformas de Cloud Computing, de mil y una aventura de Hacking y, cómo no, de Inteligencia Artificial.

Figura 1: AlphaEvolve: Un Agente AI para optimizar algoritmos

Una de las mañanas, en uno de esos viajes, el más madrugador de todos nosotros, es decir: yo, me desayunaba con el paper de AlphaDev, donde los investigadores habían sido capaces de generar un algoritmo de ordenación con menos instrucciones. Estábamos en mitad del mar, y desde el pequeño velero donde estaba desayunando con mi ordenador estaba emocionado esperando a que se levantaran mis amigos para comentarlo, y al mismo tiempo, preparar el artículo que a la postre os publiqué: "AlphaDev: La IA que optimiza la implementación de los algoritmos mejor que los humanos"

Figura 2: Artículo de "Faster sorting algorithms

discovered using Deep Reinforcement Learning

Pero han pasado dos años, y el uso de modelos de DeepLearning con entrenamiento reforzado que se usó en el paper de AlphaDev ha seguido evolucionando, y nos ha llevado al anuncio que ha hecho el equipo de Google DeepMind para publicar AlphaEvolve, un Agente AI que utiliza los LLMs para hacer optimización de algoritmos.

Figura 3: "AlphaEvolve: A coding agent for scientific and algorithmic discovery"

La idea es básicamente la misma que tenía AlphaDev, pero aprovechándose AlphaEvolve de los avances en los LLMs, lo que permite utilizar modelos de Deep Reasoning como Gemini 2.0 Pro, combinado con Gemini 2.0 Flash, y luego tener una arquitectura del Agente AI que permita evaluar las soluciones, tal y como podéis ver en el siguiente esquema.

Figura 4: Esquema de AlphaEvolve

Como podéis ver en la imagen, además de dar almacenar el código con todos sus componentes a evolucionar, y el Prompt de configuración del agente para generar la optimización, se ensamblan varios motores de LLMs para luego pasar por un conjunto de evaluadores que comprueban la validez y el resultado de las soluciones propuestas por los diferentes LLMs para responder con la mejor de ellas y evitar el problema del indeterminismo y las alucinaciones. Las características de AlphaEvolve son:

Figura 5: Características de AlphaEvolve

Como ejemplo de funcionamiento tenéis este ejemplo, donde se le pide optimizar el código de un algoritmo. En la siguiente imagen está la definición del código que se quiere optimizar, que se marca con EVOLVE-BLOCK.

Figura 6: Bloques de código a optimizar

Después, el Prompt de acción para generar el resultado del código optimizado en las métricas que se solicitan, que no siempre la optimización es el número de instrucciones, el tamaño en memoria o la velocidad de resolución.

Figura 7: Prompt de petición de optimización del código

Y el resultado mostrado por el Agente AI de AlphaEvolve es el que tenéis en pantalla, donde se índica qué partes del código son las que se recomiendan cambiar, y cuál es la optimización que se consigue a través de realizar esos cambios.

Figura 8: Ejemplo de optimización propuesta

La optimización de los algoritmos y el código, es algo que en los LLMs se lleva haciendo tiempo. Yo os publiqué el artículo de "ChatGPT: Cómo hacer (y mejorar) mi Trabajo de Fin de Carrera de la Universidad en un par de minutos" donde usaba el truco de hacer "challenge" constante al código generado por ChatGPT para ir mejorando el código en rendimiento, en calidad, en seguridad. Con AlphaEvolve se busca hacer un trabajo mucho más específico en optimizaciones de código a bajo nivel, y los resultados que presentan son muy interesantes.

Figura 9: Ejemplo de resultados en optimización.

En la imagen anterior tenéis los resultados de la optimización de un algoritmo para, dados tres números (m,n,p), multiplicar matrices m x n y n x p. En todos los supuestos la solución propuesta por AlphaEvolve es igual o mejor que el algoritmo original que se entrego. Y en la imagen siguiente tienes el código de entrada, el Prompt y la propuesta para el algoritmo de multiplicación de matrices.

Figura 10: Optimización del algoritmo de optimización de multiplicación

 de matrices. Haz clic para verlo en grande.

Google ha publicado varios ejemplos en distintas disciplinas donde han utilizado AlphaEvolve para optimizar sus soluciones en diferentes áreas de la compañía, como el algoritmo de planificación de Borg para los datacenters, el diseño de los circuitos en sus TPUs (Tensor Processing Unit)  o el entrenamiento de Gemini donde AlphaEvolve propuso optimizaciones del 32% del algoritmo de FlashAttention.

Figura 11: Ejemplos de optimizaciones hechas por AlphaEvolve

En el artículo recogen algún otro ejemplo completo para que puedas analizar cómo AlphaEvolve analiza y propone las mejoras de optimización según el objetivo que se le ha pedido, y los resultados que han obtenido en diferentes tipos de soluciones.

Figura 12: Optimizaciones de algoritmos en diferentes

ámbitos de aplicación.

Al final, la Inteligencia Artificial está transformando todos los sectores, la ciberseguridad como vemos artículo tras artículo, el trabajo diario de casi cualquier profesión, y por supuesto el desarrollo de software y la algorítmica. Y esto es algo que, al igual que os decía que GitHub y los repositorios de proyectos OpenSource deberían hacer para ciberseguridad, podrían hacer también para optimización. Mucha evolución en el desarrollo de software para que sea más rápido, más eficiente, más optimizado y más seguro..

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

¿Qué es el "Vibe Coding"?

A principios de febrero me encontré con este tweet de Andrej Karpathy, en el que hablaba de un estilo de programación que se encontraba usando de forma recurrente a la hora de programar con ayuda de LLMs, lo llamó “Vibe Coding”. El “Vibe Coding” consiste en que a la hora de crear un programa uno mismo se ha de dejar llevar totalmente por las sensaciones, olvidarse totalmente de que el código jamás ha existido y dejar que el que pique código por nosotros sean los LLM.

Figura 1: ¿Qué es el "Vibe Coding"?

Andrej comenta varios proyectos que ha hecho él siguiendo este esquema: “LLM reader app” para poder hacer preguntas sobre párrafos concretos de texto y “Battleship game” que le llevaron aproximadamente una hora y todas las instrucciones dándolas por voz.

Figura 2: Tweet de Andrej Karpathy

Y estoy seguro que como yo, muchos nos hemos encontrado en la misma encrucijada que Andrej, la de estar escribiendo programas en Lenguaje Natural y siendo el LLM una capa de abstracción más a la que le damos instrucciones y este nuestro “sabelotodo” personal el que hace el trabajo sucio por nosotros.

Casos de uso, últimas semanas

Y estas últimas semanas revisando X/twitter me he encontrado con que este término ha corrido como la pólvora. Mucha gente creando proyectos en áreas en las que su conocimiento es mínimo y gracias a los “sabelotodo” han sido capaces de crear cosas en minutos que antes empezando de cero podría llevar días hasta conocer las bases de cómo poder hacerlo. Todo esto potenciado por los modelos SOTA y las herramientas más utilizadas, los “AI code editors”.

Figura 3: Tweet levelsio juego hecho con Claude

Un caso que ha sido muy sonado y que me ha hecho gracia personalmente ha sido el de @levelsio, un influencer que haciendo “Vibe Coding” creó un sencillo simulador de vuelo pidiéndoselo a Claude 3.7 y en X cuenta el cómo va evolucionando. Lo hizo usando Cursor, y tras varios intentos consiguió algo en tan poco tiempo que sería inimaginable antes, comenzando con un prompt tan sencillo como:

“make a 3d flying game in browser with skyscrapers”

Estas semanas he estado entrando a su perfil a ver el progreso de este juego tan artificial como su creador el “sabelotodo”, y únicamente usando LLMs ha ido añadiendo más features: multijugador, diferentes vehículos, el poder disparar a otros jugadores y más características. 

Figura 4: Tweet sobre las modificaciones hechas con Claude

Sin tener conocimiento de desarrollo de videojuegos ha sido capaz de generar un juego que ha conseguido un récord de 22.000 jugadores. Y así como este muchos casos más que podemos ver si buscamos en X el juego de vocablos.

Mi propio juego con Vibe Coding

Incluso yo mismo decidí probar a ver qué es lo que conseguía “one shot” con Claude 3.7 a través del chat app y primero probé con a pedirle el mitiquísimo juego de la serpiente en Python diciéndole únicamente “Generarme el mítico juego de la serpiente en Python” y fue capaz de generarlo en menos de 20 segundos.

Figura 5: Snake game en Python hecho por Claude

También probé a pedirle que me generara el juego en Lenguaje C utilizando la librería SDL2 para manejar los gráficos y esta vez no fue “one shot” la generación del código, pero solamente tuve que copiar y pegar dos errores que generaba el compilador un par de veces y fue capaz de generar el juego.

Figura 6: Claude code for Snake game in C

Pero todo no son buenas noticias, haciendo “Vibe Coding” nos encontramos con muchos problemas también. 

Problemas del Vibe Coding

Los problemas que acarrea el generar código únicamente utilizando IA es que puede degenerar en el “Vibe Debugging”, que cuando falle esperamos que introduciendo el mensaje de error mágicamente solucione todos nuestros problemas sin saber que está mal.

Y es que delegar toda nuestra lógica de un proyecto en modelo de IA nos conlleva a que no sepamos qué hacemos, el por qué lo hacemos y el cuándo lo hacemos. Esto puede degenerar muy rápidamente si no sabemos cómo funciona nada, y a medida que crece la base de código generada va a ser difícil el continuar debido al límite de contexto y a las alucinaciones.

Conclusiones

Mis conclusiones sobre esta tendencia es que nos demuestra una y otra vez la impresionante habilidad de generar código de los “sabelotodo”, como esto sería completamente impensable hace unos años. El cómo puede ayudarnos a democratizar el acceso a la tecnología para todas las personas y que sin ser un experto en ella puedas ser capaz de usarla ayudándote de estos asistentes inteligentes.

Puede que un futuro de la programación sea el que el lenguaje natural sea una capa más de abstracción para hablar a las máquinas, que al igual que para abstraernos del ensamblador inventamos los lenguajes de alto nivel (Lenguaje C, Java, Python, …). Que los LLMs se puedan convertir en ese compilador no determinista que transforme pensamientos e ideas en código, que los humanos nos podamos dedicar a cosas más humanas como la creatividad, las ideas y que esta sea una capa más de la cebolla que es la tecnología.

Figura 7: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

Esto no creo acabe implicando en el desconocimiento de escribir código, ya que siempre hará falta alguien conozca cómo funciona la capa inferior de abstracción. Tampoco creo que signifique el reemplazo de ninguna persona sino que los que sean capaces de usarlo acaben siendo más productivos.

Un saludo,

Autor: Alejandro Garabito, Investigador IA en Ideas Locas

Contactar con Alejandro Garabito

El amo de los datos

Ayer tuve una jornada interesante de transformación digital en Londres. Hablando de datos, ML, GenAI, arquitecturas RAG, y normalización de datos. Cosas habituales hoy en día en cualquier empresa. En uno de esos momentos en los que estaba escuchando, sobre casos de uso que que se iban a crear usando ML, el debate acabó una vez en los datos. El Catálogo, el Data-Fabric, el Data Wharehouse, Data Curation, la validación de la ingesta, los Data Streams, etcétera. Cosas habituales en la vida de la digitalización de empresas.

Figura 1: El amo de los datos

Para mí, eso fue el día a día cuando en al año 2016 tuve la responsabilidad de ser el Chief Data Officer de Telefónica y tuve que tomar muchas, muchas, muchas decisiones sobre estos temas que, a día de hoy que soy el Chief Digital Officer, siguen perdurando en nuestro trabajo diario. 

Estando en ese debate, mi cabeza viajo temporalmente a mis inicios con los datos. Cuando bajaba la calle Barcelona de Móstoles, pasaba por delante del Eco Móstoles, y me metía en un pequeño parque a medio terminar que se encontraba y se encuentra a espaldas de calle Libertad de Móstoles. Allí estaba uno de los locales de la Academia RUS de la que os he hablado muchas veces. Tendría yo 14 o 15 años e iba a mi clase de Informática diaria. A seguir aprendiendo a programar.

En aquellos años ya había dejado el BASIC y el Logo atrás, y estaba con con COBOL, SQL y MS/DOS. También tocaría aprender DBASE, C y Pascal, pero antes de ellos, mi paso era hacer códigos con la IDENTIFICATION DIVISION y la PROCEDURE DIVISON. Había que aprender a identar el código, usar muchas mayúsculas, y ser muy disciplinado en la forma de hacer programas con este lenguaje llamado COBOL.

Las clases a las que asistía de informática se multiplicaban en mi agenda, normalmente hacía tres cursos a la semana diferente, haciendo clases los lunes y miércoles, y los martes y jueves, y repitiendo algunas de 17:30 a 18:30 y de 18:30 a 19:30, y luego había algunos cursos que se daban los viernes y sábados. De los 12 a los 16 años fueron años en los que mi afición era programar, así que no me importaba pasarme dos horas cada día en la academia, e incluso quedarme los viernes y sábado. ¿Qué podría haber más divertido que eso? Además, de vez en cuando daba yo la clase, y me llevaba de maravilla con Bea, mi profesora muchos de esos años.

Nada de lo que aprendí en aquellos años fue en vano. Todo ese aprendizaje sigue en mí, cambiado, adaptado, y mejorado, pero como base sobre la que construí mucho de mi conocimiento futuro. Y ayer me acordé de la época de COBOL y el acceso a Datos para hacer cosas. En aquellos momentos, cuando pasé de BASIC a COBOL, entré en el mundo de las reglas de estilo y la programación estructurada con técnicas de diseño de software muy metódicas. Formas de hacer las cosas de manera industrial. El trabajo de programador como factoría de software. Dados unos requisitos, escribir código como si fueras una máquina tú.

Los programas de gestión, hechos con COBOL y datos almacenados en bases de datos o ficheros tenían siempre las mismas estructuras. Y todos mis primeros Menús eran siempre ALTAS, BAJAS, MODIFICACIONES y CONSULTAS. Tendía que definir las fuentes de datos, los tipos de datos que iba a utilizar, si eran ficheros, los accesos que serían Secuenciales (si eran en cinta), acceso aleatorio (si eran en cintas modernas con aceleración de rebobinado y avanzado) o de acceso directo (si el almacenamiento era en disco). O los tipos de datos que se iban a leer de las bases de datos, en forma de registros que había que procesar,  pintar por pantalla en listados, etcétera.

La programación era una ingeniería. Las cosas tenía una forma de hacerse. Había metodologías de desarrollo de software. Hablábamos de los modelos de solucionar cada uno de los problemas. Y teníamos guías de estilo de programación, nombres de variables, llamadas a procedimientos, factorización del software, etcétera, para hacerlo mantenible, aduitable, y permitir que cualquier código fuera tocado por cualquier programador de COBOL. Me encantaba saber que era una pieza de parte de una industria de desarrollo de software. Podría ser programador o mi sueño entonces, ser "Analista", para poder asignar las tareas a los programadores siguiendo las guías de desarrollo del software de una empresa. 

Podéis imaginaros lo que un niño de 14 o 15 años sentía cuando se veía ahí. Siento un analista de software. Metiendo líneas de código y jugando con los decimales como Richard Prior en Superman III, desde tu terminal. Identando tu código. Flipante.

Y os cuento todo esto, porque de aquella época también aprendi parte de la gestión de los datos que décadas después usé como Chief Data Officer en Telefónica. Y es que, allí, en aquellos años, me explicaron cómo la Banca creaba sus aplicaciones para preservar sus datos. Cómo los informáticos habían creado para COBOL una metodología de trabajo con datos basada en mantener el core más sagrado de la empresa, LOS DATOS, a salvo de malos programadores. Metiendo una capa de seguridad, metiendo una capa de protección. 

Y yo escuchaba atento. ¿Cuál sería el truco? ¿Cómo lo han hecho? ¿Cuál es el secreto?

No había mucha magia. O sí. Según se mire. 

Lo habían hecho otros informáticos que llegaron a interesarme tanto o más que los Analistas, se trataba de tipos más duros aún. Que tenían más poder porque protegían el activo más valioso de las empresas. De la poderosa industria bancaria. Los datos, que al final de día era dinero. Se trataba de los Administradores de Bases de Datos.

¡¡Buaahhh!

¡Qué pasada!

Resulta que había unos tipos que para que los Analista de Programación pudieran diseñar sus programas de ALTAS, BAJAS, MODIFICACIONES y CONSULTAS, con sus infinitos listados por pantalla y por impresora (no conté yo espacios ni nada para cuadrar listados en papel continuo de impresoras matriciales), estos Analistas tenían que hablar con los Administradores de Bases de Datos para que les disponibilizaran los datos que necesitaban utilizar para sus programas. Y ellos decidían cómo lo hacían.

Esto, tenía su ciencia. Porque no iban a dejar que cualquier Programador tocara cualquier dato, así que se dedicaban a crear VISTAS, VISTAS para Actualización de datos, y Tablas de solo lectura que disponibilizaban a los Analistas para que hicieran su aplicación de ABMyC sobre estas fuentes de datos. Los Analistas repartían las tareas a los Programadores, y la Factoría de Software de la empresa seguía produciendo sistemas de información para la empresa.

Si habéis leído esto, sabréis porque cuando llegué a la Universidad me centré en aprender todas las asignaturas de Bases de Datos. A aprender a hacer el diseño lógico y el diseño físico de las bases de datos. A aprender cómo funcionaban los Tablespaces, las p-codes de las consultas de bases de datos, a descubrir los detalles de las formas normales de Boyce-Codd, a aprender PL/SQL, T-SQL, hacer optimización de bases de datos y aplicaciones, etcétera. El resto, ya os lo sabéis, trabajé mucho con las bases de datos Oracle cuando salí de la Universidad, luego llegó el SQL Injection... y el resto es historia moderna, desarrollando mi perfil profesional en datos y hacking.

Pero ayer volví a ello una vez más, porque el debate nos llevaba a cómo preservar los datos y disponibilizarlos a los modelos. Hoy hablamos de Data Streams, de Gestores de Consentimientos para acceso a datos, de políticas y procedimientos de anonimización y pseudoanonimización, de consultas con algoritmos de cifrado homomórfico, de roles de seguridad, de las plantillas de cumplimiento regulativo, etcétera. 

Entonces, el Administrador de la Base de Datos era el "amo de los datos" y de todo eso. Y yo lo aprendí en una academia de barrio de Móstoles. Leyendo libros y deseando un día poder ser parte de esa Industria y la Ingeniería del Software. Flipante.  

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Mojo: El lenguaje para programar Inteligencia Artificial que es un superconjunto de Python

Python es el lenguaje predominante para desarrollo de la Inteligencia Artificial. Su gran colección de bibliotecas para una extensa variedad de ámbitos dentro de este campo y su sencillez son motivos más que suficientes para justificar su uso, además de todo el contenido divulgativo que existe en torno a él permite que sea un lenguaje masivamente adoptado. Sin embargo, su rendimiento deja mucho que desear, y es muchísimo más lento que lenguajes como C. Por este motivo existen múltiples trucos para lograr una mayor eficiencia a la hora de ejecutar operaciones. 

Figura 1: Mojo - El lenguaje para programar Inteligencia Artificial

que es un superconjunto de Python

La librería Numpy es un ejemplo claro, donde muchas de sus operaciones están implementadas en  Lenguaje C, logrando bastante mejor rendimiento a la hora de hacer cálculos que si no la usáramos. Otro problema en Python es el procesamiento en paralelo, en donde ahora está existiendo hardware moderno para IA con núcleos de alto rendimiento, Python usa generalmente uno solo, aunque existen soluciones estas no son óptimas.

Figura 2: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

En definitiva, podría decirse que Python es un lenguaje lleno de parches, de trucos, que van permitiendo lograr mejores velocidades de computación, pero que finalmente van haciendo que sea difícil de depurar y menos manejable, sin llegar a exprimir completamente el hardware. La realidad es que para el mundo de la Inteligencia Artificial se usa principalmente Python porque es fácil de usar y no hay alternativa, y se hacen uso de estos trucos para intentar solventar sus problemas. Pero recientemente apareció el Lenguaje Mojo.

Figura 3: Web oficial de Mojo

El Lenguaje Mojo es un superconjunto de Python, y esto es una gran ventaja, ya que parte de este tan popular y querido lenguaje. El objetivo de este es claro: ser tan fácil de usar como Python, ser tan potente como el Lenguaje C. Ha sido creado por la empresa Modular, cuyo CEO es Chris Lattner, quien empezó a desarrollar el lenguaje Swift allá por el 2010, y apareció públicamente en mayo de este año 2023, donde para su uso era necesario solicitar permiso y únicamente se podía utilizar en navegador web, y desde este mes de septiembre ya es posible utilizarlo en GNU/Linux.

Características de Mojo

La extensión de un programa Mojo puede ser .mojo o el emoji con la llama de fuego. Así que por ejemplo si se tiene un programa hello.mojo, para ejecutarlo se escribiría mojo hello.mojo

Figura 3: Ejecución aplicaciones Mojo

Una de las ventajas clave es la paralelización. Mojo es el lenguaje diseñado para aprovechar al máximo MLIR, otro proyecto de éxito desarrollado por el mismo Chris Lattner con gran éxito, que es el reemplazo a la representación LLVM para esta nueva era de la Inteligencia Artificial, y que permite a los desarrolladores aprovechar al máximo los vectores, hilos y unidades de hardware de la IA.

Figura 4: Paralelización Mojo vs. Python

Otra diferencia esencial con Python es que Mojo se trata de un lenguaje compilado. En Python el comportamiento del programa desarrollado dependerá de la versión exacta que se esté utilizando de este lenguaje y de las librerías usadas, y para solventar este problema se crearon los entornos para instalar aplicaciones Python, existiendo también los contenedores.

Sin embargo, Mojo sigue la misma aproximación que el Lenguaje C, por lo que el despliegue de aplicaciones es increíblemente sencillo, simplemente ofreciendo el programa compilado para descarga directa. Esto significa que Mojo es mucho más que un lenguaje para aplicaciones de IA. De hecho, es una versión de Python que nos permite escribir aplicaciones rápidas, pequeñas y fáciles de desplegar que aprovechan todos los núcleos y aceleradores disponibles. Y como se ha comentado, al ser un superconjunto de Python, se puede hacer uso de este y sus librerías.

Figura 5: Importando módulos Python en Mojo

Hay muchas otras características que puedes leer en el manual. Por destacar algunas, introduce verificación de tipado fuerte, crítico para obtener el mayor rendimiento y comprobar errores; declaración de variables mediante let (inmutables) y var (modificables), lo cual mejora el rendimiento al establecer restricciones en el momento de compilar; se puede hacer uso de tipos struct similares a las existentes en C/C++ y Rust en vez de class existente en Python, que presentan diseños predeterminados durante la compilación que garantizará una mayor eficiencia; y por terminar con otra característica, en vez de utilizar funciones definidas con def, Mojo ofrece la palabra clave fn, que representa una función con más restricciones, creando así código máquina optimizado.

Rendimiento

Se realizó una comparativa ejecutando el algoritmo Mandelbrot. En Python la ejecución llegó a más de 1000 segundos, mientras que con Mojo apenas 0.03 segundos. En este artículo puedes leer con más detalle cómo se llega a obtener un speedup frente a Python de 68000x, con diferentes técnicas de optimización.

Figura 6: Rendimiento Mojo

En general, estos resultados prometen, y no hay nada mejor que ejecutarlo tu mismo y lanzar diferentes pruebas para hacerte tu propia idea sobre la mejora que se puede lograr con Mojo .

Conclusiones

Hay muchas esperanzas puestas en este lenguaje, el cual podría convertirse en un futuro próximo en el lenguaje para desarrollar IA, y como hemos visto no solo para este ámbito, sino que para propósitos generales también por todo lo que ofrece. Aquí tienes un vídeo con un repaso breve de Mojo tras su lanzamiento, por Jeremy Howard, referente en IA.

Figura 7: Presentación de Mojo por Jeremy Howard

Veremos si acaba convirtiéndose en lo que promete, y recuerda que puedes probarlo ya mismo en GNU/Linux, que programar Inteligencia Artificial va a sr una de las principales funciones que van a realizar los programadores de ahora en adelante.

Un saludo,

Autor: Javier del Pino

Contactar con Javier del Pino Díaz en MyPublicInbox