Esto lo explica Carlos Santana.
¿Recordáis Devin, la IA capaz de hacer labores de ingenieros de software que lograba resolver un 13% de las tareas de benchmark de software Engineer Bench en marzo?
Hoy la empresa Cosine anuncia un 30% con su nuevo sistema Geni.
Geni, vamos a ver de qué es esto y a ver si nos quita el trabajo, como dicen.
Dice, el salto logrado por esta compañía es notable.
Ya lo han conseguido a partir de hacer un fine tuning del modelo de OpenAI con datos de cómo ingenieros de software razonan y resuelven este tipo de tareas.
Esta semana escucharemos bastante sobre el Software Engineering Bench, ya que parece que se convertirá en el nuevo benchmark para evaluar las capacidades de racionamiento y resolución de tareas complejas de la próxima generación de modelos.
¿Esto de qué es?
Esto es como básicamente una serie de pruebas que se le hacen pasar al modelo para entender hasta qué punto se podría hacer pasar por un ingeniero de software.
Y este 30% que quiere decir, pues sería el tanto por ciento de tareas que puede resolver como dentro de unas tareas, unas issues o problemas que podrías tener en un Jira.
Que se lo pasas y ya está.
Dice, si en agosto estamos a un 30%, ¿a cuánto creéis que subirá este valor a final de año?
Carlos ahí con el hype.
Claro, en marzo supuestamente era del 13%, supuestamente era del 13%, aunque fijaos aquí, fijaos aquí, que aquí Devin es del 3,4%.
No sé si lo veis, pero fijaos aquí que Devin le ponen un 3,4%.
O sea, ¿qué es lo que pasa con esto?
Han hecho otra vez las pruebas y Devin, que en su momento parecía que era un 15% y tal, pues ahora resulta que solo solucionan 3,44%.
Esto lo vemos luego porque esto también es un poco polémico.
Luego, fijaos, el que aparece arriba, ¿ves que pone 13,8?
Aquí pone Devin, pero pone Claim.
Esto significa, esto es lo que dice Devin, que pasa un 13,8%.
Y este es el que realmente pasa.
O sea, ya hay un poco de polémica aquí porque les está dando a Devin mucha peor puntuación de la que realmente tenía.
Entonces ya ahí, yo ya un poco, una ceja para arriba, una ceja para arriba.
Dice, esto me ha gustado.
La mayoría del código publicado por humanos ya es funcional.
Y esto hace que en muchas casos la IA no se entrene con código que falla y por tanto no está acostumbrada a que las casas vayan mal.
Para solucionar esto, han usado datos sintéticos generados por primeras iteraciones del modelo.
Para automejorar el modelo y obtener modelos más potentes.
Vale, más info.
Aquí tenemos el reporte, ¿vale?
Vamos a darle por aquí y vamos a ir a la página esa de Cosine.
Que la página está muy bonita.
Las cosas como son, está muy bonita.
Fijaos ahí, este efectillo.
Muy bien.
Ahí se han gastado bastante dinero.
Ahora veremos un poco el vídeo.
Dice, Jenny tiene la puntuación más alta del mundo en este benchmark de Software Engineer.
Dice, es un benchmark diseñado para evaluar las habilidades de código de modelos de lenguaje grandes.
Diferentes tareas de Software Engineer.
Y aquí en el Technical Report este, aquí es donde podemos ver realmente cómo lo han evaluado, qué es lo que han tenido en cuenta, cuál es la arquitectura, cómo han mezclado código.
Por ejemplo, pues hay 21% de JavaScript, 21% de Python, 14% de TypeScript, ¿vale?
El tipo de código que han hecho para arreglar un fix o para arreglar un bug, para hacer una feature, para hacer un refactor, pequeños cambios de código, ¿vale?
Escribir test.
Aquí podemos ver un poco cómo ha sido.
Yo al menos he estado mirando porque, claro, esto está bien, pero yo digo, vale, pero ¿cuáles son los datos?
O sea, he querido mirar el dataset, dice, sería reducido y tal, pero no he encontrado cuáles son los datos que han utilizado.
O sea, pone como los tantos por ciento, pero yo quería ver realmente si podíamos ver de dónde han sacado esto.
Se supone que es este, entiendo que es este, que aquí tenemos el código.
Sí, me imagino que es este, ¿no?
Y aquí tendríamos todas las issues.
Claro, ¿cuál es el problema de este benchmark?
En mi opinión, ¿eh?
No, se supone que es este, es este.
Vale, porque estaba antes buscándolo y no lo he encontrado.
Se supone que es este, que aquí es donde deberíamos tener todas las issues y tal.
Esto me parece un poco peligroso.
Puede ser que sí, que tenga sentido lo que dicen y aquí tendríamos el benchmark, ¿vale?
Aquí tendríamos como, entiendo que en algún sitio tendríamos como las issues que le tiene que pasar y todo esto.
Pero claro, ¿quién no nos dice que se están entrenando los modelos a partir de esto?
Y entonces sería mucho más fácil el hecho de decir, pues bueno, voy a hacer que mi modelo sea muy bueno con todo este benchmark, ¿vale?
Para que todas estas issues pues las pueda arreglar bien o las entienda muy bien y luego no sea tan bueno para el resto de cosas.
Estos benchmarks muchas veces como que me da la sensación que es una trampa, ¿no?
Porque al final si tú sabes el benchmark exactamente que quieres hacer, sí que puede ser que vayas mejorando y sí que obviamente muchas veces necesitamos como una puntuación.
Pero por otro lado no deja de ser como la trampa de saber exactamente a lo que te enfrentas como para ver qué es lo que tienes que solucionar.
Y te pueden salir mejores puntuaciones porque, claro, si ya sabes la solución, dices, vale, pues este es el tipo de problema que tengo que arreglar, pues lo puedes arreglar y entonces cada vez lo vas mejorando para el benchmark, ¿no?
Realmente así son la mayoría de los benchmarks. Están usando lo que mejor les sale a su producto.
Claro, claro, totalmente, ¿no?
Esto de que ahora de repente pasa un 30% tendríamos que ver si realmente esto quiere decir que es tan bueno, ¿no?
O sea, si puede solucionar un 30% real de tareas.
Por cierto, este logo está de moda, ¿eh? Sale un montón por todos lados.
Vale, este es el...
Claro, dice, es que tiene... Fijaos que es aquí como empieza, ¿no?
Es que tiene la puntuación más alta del benchmark de no sé qué.
Y claro, eso es lo que me da un poco de...
Que es un poco sesgado, me da la sensación.
Me encanta porque es un creador, es un CEO, pues, más majo, ¿vale?
Que se equivoca, porque no es una inteligencia artificial.
¿Vale?
Vale, es el cofundador y CEO.
Alistar Pullen.
Venga, van a enseñar... Vamos a ver cómo está.
Bueno, aquí podemos ver el benchmark, 30% de las tareas, las están solucionando.
¿Vale?
Dice, ¿y cómo lo hemos encontrado? ¿Cómo lo han hecho?
Es con un approach totalmente diferente.
En realidad, lo más impresionante, dice, que quieren que sea como un ingeniero de software.
El tema es que lo que han hecho en realidad no es crear su propio modelo.
Han entrenado el modelo de OpenAI realmente.
O sea, que estamos utilizando como un GPT-4O, pero como mejor enseñado de cómo tiene que funcionar, ¿vale?
Para ser ingeniero de software.
Venga, aquí vais a ver cómo resuelve un problema real.
Aquí tenemos diferentes triggers.
Le podéis poner un prompt, le podéis decir una tarea, una ISU de GitHub, le ponéis un ticket de linear o la API.
Y así es como se supone que funciona.
¿Vale?
Con lenguaje natural o con una ISU.
En este caso van a utilizar una ISU de GitHub.
¿Vale?
Le dan a Start.
Dice, venga, pásame la ISU.
Vale, lo importa.
Aquí tiene la ISU.
Le dice, venga, Resuélvelo.
Hostia, qué bueno lo que dice Lord Moore.
Dice, escucho Benchmarks y me recuerda a lo de Volkswagen con el escándalo de las emisiones.
Totalmente de acuerdo.
No sé si sabéis lo que pasó con Volkswagen, que al final lo que hicieron es que el coche emitía menos partículas de dióxido de carbono cuando detectaba que se estaba haciendo un benchmark.
Es brutal.
O sea, brutal.
Y es increíble que pese a eso, pese a eso, a ver, escándalo.
Siga Volkswagen como si nada.
Un análisis del escándalo de emisiones de Volkswagen.
O sea, es brutal que lo que hacía el coche era ser inteligente y cuando detectaba que se estaba haciendo el benchmark, trucaba las emisiones, bajaba unas potencias y tal para asegurarse que las partículas que desprendía eran mucho menores y así podía pasar sin ningún problema todos los test de contaminación.
Pero claro, luego cuando tú utilizabas realmente el coche fuera de ese benchmarking, pues obviamente emitía mucha más contaminación.
Y lo peor es que esto lo hacía en casi todos los coches que salieron en aquel momento y lo peor es que lo sabía todo el mundo.
Todo el mundo.
O sea, lo sabía gente con mucho poder dentro de la compañía.
No es que decían, no, es que no lo sabe nadie, no, es que lo sabía todo el mundo.
Bueno, total, sigamos con Cosine.
¿Vale?
Está encontrando los archivos, se pone a navegar como todo el COIVES para encontrar código relevante.
Aquí va hablando como que está entendiendo tu código y todo esto.
¿Vale?
Ha encontrado como los archivos que son importantes para la ISU que tenía.
Está planeando la acción, analizando los resultados para los próximos pasos.
¿Vale?
Y ahora, claro, dice que esto es iterativo, que va a escribir el código que lo ejecuta y que verás cómo funciona.
¿Vale?
Ahora escribe el código, te dice como el diffing.
Dice, vale, aquí pongo esto.
Y aquí pongo esto otro.
¿Vale?
Te está haciendo como el código.
Y ahora, encima, ejecuta los test para ver si pasan los test.
Verá que los test no pasan.
¿Vale?
Aquí ha habido un problema.
Dice, ostras, esto no pasa.
Voy a ver por qué falla este test.
Que, bueno, esto ya va a ser gracioso porque tampoco hay muchos test ahí fuera.
Tendrá la inteligencia artificial, primero tendrá que hacer test.
Y luego dice, vale, es que como ha fallado este test, voy a tener que hacer este drop null,
porque si no va a fallar aquí.
Tengo que convertir aquí el null.
¿Vale?
Ahora volveré a ejecutar los test.
Ahora parece ser que funciona bien.
¿Vale?
Dice que este proceso puede continuar indefinidamente.
Dice que ha hecho dos commits, que ha tardado 84 segundos y que ha cambiado dos archivos con 17 test.
¿Vale?
Aquí puedes volver a hacer un prompt.
¿Vale?
Si no, pues le dices finish y ya te comité a esto.
Dice, y esto te va a escribir al PR.
Sí que va a estar totalmente, la PR te abrirá la PR y luego tú ahí pues lo ejecutas y tal.
Bueno, no se puede probar, ¿vale?
Porque es ahí con una get list, te hay que hacer ahí poner un montón de información, obviamente, las cosas como son.
No hay mucho más que esto, con lo que habéis visto.
Está bastante interesante.
Pero yo la verdad es que esta cosa me queda un poco frío.
No sé, ¿cómo la habéis visto?
Midu, ¿por qué crees que tiene tanto interés en sacar un ingeniero de software y no ocurre tanto en otros sectores como, por ejemplo, un auditor o un contable?
Yo creo que es por el hype, ¿no?
Y Niter, yo creo que, uno, hay muchas ganas.
Le hay muchas ganas a los desarrolladores y programadores.
La gente le tiene ganas.
Lo segundo es que es muy goloso el hecho de decir, no, programa lo que tú imagines.
Lo puedes programar en un prom y esto te lo itera automáticamente ad infinitum y te lo soluciona todo.
Y no tienes que contratar más a esa gente maldita, mala gente, ¿no?
¿Qué tal?
No sé.
O sea, yo creo que estas cosas no tienen mucho sentido.
Entonces, yo lo que diría es eso, es el hype.
Es el hype de que la gente te pueda invertir dinero.
Lo de siempre hasta que lo liberen, ¿no?
No tienes que contratar más a esos dioses del Olimpo, puede ser.
Pero a los contables le hicieron eso con Excel.
Bueno, y fíjate, los contables tampoco desaparecieron realmente.
No sé si lo vieron, o sea, no sé cómo lo veis.
Pero yo la verdad, vi lo de Devin, que lo de Devin fue una cosa.
¿Y dónde está Devin? ¿Dónde está? Que no lo veo.
¿Puede ser que esto algún día lo implementen?
A ver, yo creo que eventualmente, algún día, en algún momento, va a ocurrir que algo así pueda funcionar.
Yo creo que sí, ¿vale? Yo creo que sí.
Pero más allá de eso, al corto plazo, yo creo que van a estar así como...
Intentando hacerlo y hacerlo y hacerlo.
Pero veo que están como siempre con los mismos ejemplos, con códigos que ya los veo como muy preparados.
Que arreglar un bug y cosas así, al final como...
Los veo como chajepetes un poco glorificados.
Que todavía va a tener que revisar un humano ese código para no liar la parda.
Porque a lo mejor, sí, esto lo puede hacer, pero al final ese código lo va a tener que revisar alguien.
O sea, no veo que no sea algo no revisable.
Veo que en un vídeo todo queda muy bien y muy bonito.
Y que luego a la hora de la verdad no es tan fácil.
Y sobre todo, muchas veces veo que sí que es para pequeños bugs o para iterar algunas features.
Pero no veo que esto sea algo realista para, por ejemplo, yo qué sé.
Que se pueda iniciar sesión en Twitch.
Mira, por ejemplo, ¿no?
Lami.du.com, ¿vale?
Y le digo, no, quiero que aparezca un ticket aquí en medio que se pueda iniciar sesión con otro botón en GitHub.
Y entonces lo guardes en una base de datos.
De esto y que haya diferentes sabores y tal.
Que sí que de forma iterativa se podría hacer.
Pero me parece que cuanto más iteras, más puede ir equivocándose y al construir algo sobre un error así que te puede quedar totalmente porque te vas fiando y tal, puede ser como mucho peor.
Entonces no dudo, ¿eh?
Que me parece interesante y creo que el día de mañana pues podamos ver cosas así.
Pero creo que como que se ha sobrevalorado.
Voy a decir algo un poco polémico, ¿eh?
Mira, lo dice Liam.
O sea, mira, voy a leer lo de Liam y así ya.
Liam dice, ChagPT está sobrevalorado para solucionar problemas de desarrollo.
Totalmente.
Ahí está.
Estoy totalmente de acuerdo.
Yo creo que se ha sobrevalorado un poco el hecho de pensar que realmente que se podían solucionar cosas muy bestias en el mundo del desarrollo.
Porque sí que soluciona cosas, pero yo creo que tienes que tener una buena base.
No te soluciona ahí como te paso todo el código y ya está.
Te puede solucionar algo, te puede encontrar cosas, pero no creo que sea tan mágico.
Estoy estudiando JavaScript y quería preguntarte si es normal que algunas cosas no entiendo y qué puedo hacer.
Estoy tomando un curso y estoy viendo todos los videos, pero hay muchas cosas que no entiendo y no sé cómo lo puedo aplicar.
¿Es un proceso normal?
Es totalmente normal.
Lo que tendrías que hacer, hay cosas que no entiendes.
Es que eso nos pasa a todos todavía.
O sea, no pasa nada.
Al final puede ser que no entiendas cosas por más años de experiencia que tengas.
Y entonces tendrás que practicar.
Yo creo que eso es lo más importante.
Porque especialmente las cosas que dices que no entiendo.
Mira, por ejemplo, tenemos lo de JavaScript 100, que son 100 proyectos que queremos hacer con JavaScript, que son totalmente en vanilla.
Y yo creo que está muy bien porque ayer que hicimos lo de las hojas de cálculo estas de Excel, que se podían hacer y sumar y no sé qué.
Pues al final vas aprendiendo porque dices, ostras, esto no se me había ocurrido o cómo puedo iterar esto.
Y vas desbloqueando cosas a base de la práctica, que creo que es lo más importante.