Aprendizajes de más de 100 experimentos comparando LLMs para AI Coding

Hola, chicos. Encantado de estar aquí. Honrado de tener una audiencia así. Así que la cantidad de preguntas a Mario realmente me asustó un poco, así que esta será como la parte principal. Pero antes de que comience la parte principal, hablaré sobre LLMs. Mario ha representado un poco el escenario de Skynet aquí, ¿verdad? Así que todo va a empeorar. Y ahora intentaré traernos de vuelta a la tierra a las tareas diarias de los desarrolladores individuales.

¿Cómo usan los LLMs y la cantidad de experimentos que hice alrededor de eso desde la perspectiva de un desarrollador individual, no tanto desde el punto de vista organizacional. Así que esto es brevemente sobre mí. Soy un YouTuber. Mi hija de 10 años está orgullosa de decirles a sus amigos que su papá es un YouTuber. Pero soy un desarrollador con 20 años de experiencia, principalmente sobre PHP y el framework Laravel. Y comencé a crear contenido hace 10 años y básicamente nunca paré.

Así que uno de mis canales, de los cuales tengo cuatro ahora, es AI Coding Daily. Y esto es exactamente de lo que hablaré. Y esto es lo que hago en mi canal de YouTube. Evalúo modelos. También trato muchos otros temas. Pero esto como que ganó tracción. Así que cada vez que surge algún nuevo modelo o versión, lo pruebo por mi cuenta. Benchmark probablemente sea una palabra demasiado fuerte porque no soy una organización. No puedo competir con SWE Bench u otros benchmarks oficiales. Pero ejecuto los modelos con mi prompt y mi evaluación automática desde el punto de evaluar el código.

Así que cada vez que surge algún nuevo modelo en Twitter, ves esos flappy birds y clones de varios juegos y experimentos HTML. Y personalmente odio esos porque intentan hacer un proyecto de un solo golpe que nunca saldrá tal cual de todos modos, lo cual no es un escenario realista. Así que estaba tratando de hacer básicamente este nuevo modelo. Intenté evaluar, ejecutar prompts, ejecutar evaluaciones. Y a la gente le empezó a gustar eso. Así que se convirtió en uno de mis temas atractivos básicamente en YouTube. Y estos son los comentarios habituales que recibo.

Así que similar a la pregunta, ¿cuál es el modelo más seguro para usar ahora mismo? La gente siempre tiene curiosidad sobre qué usamos en términos de herramientas y los modelos. Y estos son comentarios, solo capturas de pantalla aleatorias, pero hay muchos más, lo que hace difícil ahora con tantos modelos siendo lo suficientemente buenos. Y no es solo el modelo. ¿Puedes probar Opus 4.8 high? Porque high es diferente de medium. Y también hay X high. Así que ves la cosa, hay tantos modelos y tantos juguetes para que juegue. Y así es como nació mi tabla de clasificación.

En total, tengo más de 100 videos en mi canal de YouTube. Así que este es el resultado del que hablaré, mi propio benchmark, qué modelos son básicamente los mejores. Pero no es necesariamente, no puedo, de nuevo, no puedo competir con SWBench. Así que es para mis casos de uso, que mostrarán mi metodología y cómo evalúo en un minuto. Pero ves, básicamente, es bueno que la pantalla sea bastante grande y lo ampliaré poco a poco más tarde. Pero tengo 18 LLMs, puntuación máxima de 25 puntos en cinco proyectos. Y también evalúo el tiempo promedio por prompt hasta el final y el costo promedio por prompt, que es el precio de la API.

Y esta es la misma tabla, pero en costo y puntos. Así que los puntos maximizan hasta 25 a la izquierda y el costo está a la derecha, lo cual no es realmente la manera perfecta de describir eso visualmente. Supongo que podría estar sesgado o podría estar como ampliado o reducido. Pero lo que quiero enfatizar con esto es que esto es como de barato a caro y de malo a mejor. Y este es básicamente el mejor lugar para estar. Y ves cuán grande es la competencia. Muchos más modelos se volvieron lo suficientemente buenos en términos de costo y valor para, de nuevo, el uso diario, que la competencia es bastante feroz. Y muchos desarrolladores, muchas personas juran por su modelo, lo usan y todos están básicamente en lo correcto. Muchos modelos son lo suficientemente buenos hoy en día. Así que esto es básicamente para que entiendas el ecosistema.

Ahora, ¿cómo medí eso? Esta es mi metodología típica de prompt. Hay proyectos iniciales. Así que trabajo nuevamente con el framework PHP del lenguaje PHP y principalmente con el framework Laravel. Pero no importa tanto, el lenguaje y el framework, porque no estoy probando las capacidades del lenguaje y la sintaxis. Así que doy un prompt para crear algo. Y luego tengo pruebas automatizadas para básicamente cubrir los escenarios donde lo implementan o no. Y luego, si hay al menos un error, al menos una falla en la prueba automatizada, entonces ese modelo falló la tarea.

Mi primera prueba fue sobre asegurar que los datos sean correctos con la API. Nuevamente, es PHP y Laravel, pero podría ser cualquier lenguaje de back end. La segunda prueba fue implementar tecnologías específicas. En este caso, es Laravel y Filament con las mejores prácticas de múltiples herramientas. Así que el LLM debería poder ser entrenado en ellas o leer la documentación o leer cualquier información en línea para usar las mejores prácticas. Luego, el proyecto tres fue analizar un README grande de un paquete realmente desconocido, realmente, realmente pequeño. Así que no está entrenado en ningún LLM. Y el README es enorme. Y la evaluación fue, ¿usó el paquete de la manera correcta para evitar problemas de rendimiento? Así que solo se espera una consulta SQL.

Luego, el cuarto fue React y TypeScript. Así que front end para crear siete componentes con varios escenarios diferentes. Y estas son pruebas automatizadas de Playwright. Y luego el quinto fue importar CSV, que tenía muchos escenarios de casos límite. Así que si podemos importar el mismo archivo, podemos importar duplicados, podemos importar líneas vacías, podemos importar básicamente archivos incorrectos de cualquier manera posible. Y hubo 29 pruebas alrededor de eso, aunque no estaba en el prompt. Así que esa es la cuestión principal. Esas pruebas de evaluación no eran conocidas por el LLM. Eran pruebas externas. Así que tenía la plantilla inicial, luego el prompt, luego copié esas pruebas de otro lugar en la carpeta y luego evalué los resultados. Y esto es lo que he aprendido. Así que estos son mis comentarios sobre mis benchmarks. Este es un tweet de Cursor. Y pensamiento similar, Mario dijo en su charla que los modelos se dieron cuenta de que estaban siendo evaluados.

Así que el tweet de Cursor también, no estoy seguro ni siquiera de cómo comentar que está en pantalla, pero básicamente no puedes simplemente dar un prompt a los modelos y dar el benchmark. Entonces, en otras palabras, SWE Bench y otros benchmarks son conocidos por los LLMs y están tratando de competir en el benchmark. Así que cada vez que surge un nuevo modelo, siempre habrá, siempre habrá lo mejor de lo mejor, nuevos puntos porcentuales, nueva carrera de las tablas. Así que esos benchmarks oficiales no son, en mi opinión, son buenos, son mejores que nada, pero no son la manera de evaluar las capacidades reales del modelo en un mundo real porque esos benchmarks son en su mayoría, no todos, algunos de ellos son mejores, no están necesariamente en escenarios del mundo real, y los modelos están tratando de competir en benchmarks en lugar de en tareas reales.

Luego, el aprendizaje número dos, es que a lo largo de los años, comencé mi canal de YouTube hace alrededor de un año. En ese momento comencé con Sonnet, era Sonnet 4.5, creo. Opus, no, Opus 4.5 no era la cosa porque durante Navidad, como el mundo cambió cuando se lanzó Opus 4.5. Así que era Sonnet y GPT 5 punto algo, no recuerdo, probablemente 5.2 o 5.1. Y los modelos chinos, modelos orientales en ese momento, no estaban ni cerca de la calidad, cualquiera que probé en ese entonces. Y luego este es el último benchmark. Así que versión por versión, los modelos chinos se volvieron simplemente mejores, simplemente mejores en hacer tareas diarias. Nuevamente, mis prompts no están ni cerca de ser tan sofisticados como los ejemplos de Mario, y no estoy tratando de predecir este tipo de aquí, pero creo que muchos desarrolladores están haciendo básicamente tareas similares día a día. Así que mi evaluación, creo que al menos está evaluando algunas partes del mercado. Así que en esas tareas diarias, el modelo chino, versión por versión, así que por ejemplo, GLM 5.1 era malo, GLM 5.2 es como marginalmente mejor. Minimax 2.7 era realmente malo, y 3 es como el siguiente nivel. Kimi, Kimi fue el primer modelo que de alguna manera sacudió el mercado. Así que Kimi K2.5 ya estaba a la par con Sonnet. Algunas personas, algunos desarrolladores usan eso, y luego 2.6 y 2.7 ya estaban un salto adelante. Además, está DeepSeek. DeepSeek es su propia categoría, diría yo. Así que DeepSeek sacudió el mercado en ese momento cuando fue lanzado por primera vez, y ahora DeepSeek Flash, esos modelos están hacia el final de la tabla, pero aún así obtienen 13 y 11 respectivamente, y sorprendentemente Pro fue peor que Flash, pero volví a probar varias veces, y para esos proyectos específicos, por alguna razón, Flash fue de hecho mejor. Pero mira el precio. Quiero enfatizar el precio porque DeepSeek es el modelo. Es el número uno, creo, en OpenRouter o en uno de esos porque es realmente, realmente barato, sorprendentemente barato. Ni siquiera está en la misma área de baratura. Así que sé que muchos desarrolladores, especialmente los que quieren ahorrar mucho en tokens, usan DeepSeek para implementar el plan, por ejemplo, construido por Opus o un modelo más fuerte. Así que los modelos chinos mejoraron. Esa fue la principal conclusión, la primera. La siguiente fue que Opus y GPT, los últimos modelos, siguen siendo mucho mejores que los demás. Opus y GPT obtuvieron casi perfecto.

Así que mis 25 puntos significan que 5 éxitos en 5 proyectos, en 5 intentos. Una cosa que olvidé mencionar, así que ejecuté el mismo prompt 5 veces. Así es como se calculan los 25 puntos. Y tanto Opus como GPT obtuvieron solo 0.5 en una de las pruebas, y eso fue suficiente en un nivel medio de esfuerzo. Ni siquiera intenté alto o X alto y también Fable porque necesito tareas específicas para ellos. Para esas tareas diarias como en mis benchmarks, esos modelos son solo cacahuetes para ellos. Es lo mínimo. Ni siquiera está en la misma liga.

Así que cada vez que veo cómo la gente usa Fable, son solo diferentes tipos de tareas. Es simplemente tan, tan diferente. Así que esto está un poco fuera de este benchmark para tareas diarias. Opus y GPT seguían siendo mucho mejores que otros, pero más caros. Estos son, nuevamente, precios de API, y la gente debate en mis comentarios como, ¿cómo evalúo los precios? Porque puedes tener suscripción a Opus, Cloud, Anthropic, OpenAI. Puedes tener suscripción a Z.AI y modelos chinos, y puedes ahorrar mucho dinero solo teniendo una suscripción. Así que la única manera en que pude comparar los precios fue el precio de API, ya sea en Cloud Code o OpenCode, mostrar los precios, y esta es una de las conclusiones. Es como para la calidad, es bastante caro.

Pero luego hay como otra ola de modelos que comenzó con Composer 2.5 en Cursor. Así que Composer 1 era como, está bien, tenemos un modelo. Composer 2 estaba bien, algo, pero Composer 2.5 fue un salto sorprendentemente grande en términos de calidad mientras mantenía el precio bastante bueno. Y este precio, este tiempo, así que el tiempo promedio por prompt es como el doble de rápido que la mayoría de los modelos, y eso fue en Composer 2.5, no en modo rápido. Así que puedes hacerlo aún más rápido, entonces pagas un poco más. Pero Composer 2.5, incluso no rápido, es buena calidad por un precio sorprendentemente bajo.

Y luego, de manera similar, alguien mencionó en los comentarios y lo evalué, mini model, GPT 5.4 mini también fue sorprendentemente bueno mientras mantenía el precio bajo. Así que si quieres mantener el precio bajo, hay maneras de usar básicamente un modelo más pequeño o Composer 2.5 es también una especie de su propia categoría porque está solo en Cursor. Así que puedes tener suscripción a Cursor y tal vez ahorrar dinero de esa manera. Y esto es exactamente lo que se me ocurrió, con mis propios proyectos y mis propios experimentos. Esto es lo que mucha gente hace hoy en día y esta es una de las maneras.

Así que planificar y orquestar y pensar el proceso antes de escribir el código debería hacerse con un modelo caro como Opus o Fable o GPT 5.5. Luego la implementación puede ser, si quieres ahorrar dinero, puede ser dada a Composer o DeepSeek es inestable, pero posible. Y luego tienes que tener un tercer tipo de juez imparcial. Por supuesto, todavía puede ser parcial, pero al menos de una compañía diferente para revisar el código de ambos. Lo siento por mi voz. No esperaba eso. Lo que significa que ya no se trata del modelo.

Depende del harness. Así que si usas modelos en cloud code o open code u otros, ¿cómo haces el prompt? ¿Qué tienes en términos de contexto? ¿Cómo tienes evaluaciones, pruebas automatizadas y cosas así? Así que la pregunta se convierte no en qué modelo uso, sino en el proceso general, comenzando desde el principio hasta el resultado final.

Pero, por supuesto, tengo una gorra especial y como en los días de PHP Channel, creo una gorra especial para responder a todas las preguntas como ¿qué uso? Depende. Esa es básicamente la conclusión general de esta charla. Depende. Ese es mi meme favorito, por cierto. Depende. Siempre que alguien me pregunta algo, digo, bueno, depende. Depende de tu caso de uso.

Genial. Si aún no lo has hecho, por favor comparte tus preguntas en el Slido. El código es 0607. Voy a quedarme aquí para el live stream si está bien. Increíble. Así que la primera pregunta que veo aquí es, ¿probaste los diferentes esfuerzos de los modelos? ¿Esto cambió el orden en absoluto? Lo siento, no, diferente. Sí, esa es la pregunta. Sí, así que en algunos casos ya estaban en la pantalla los esfuerzos que probé. Fue mayormente medio. Lo hice, y ese fue el GPT. ¿Cuál fue el modelo? No recuerdo, pero cambié de medio a alto y cambió bastante los resultados. Así que no hay una respuesta única. Depende del modelo.

Depende del modelo. Pero, sí, cambia. Como Opus 4.8 es bueno incluso en medio. Pero, por ejemplo, ¿cuál era el ejemplo? GLM, creo que era medio y alto, gran diferencia. MiniMax, gran diferencia, medio y alto. Algunos de ellos eran realmente muy diferentes. Así que deberías ejecutar el mismo prompt en diferentes esfuerzos y es probable que obtengas resultados diferentes.

Genial. Pasemos a la siguiente pregunta. En tu opinión, ¿es probable que los modelos locales se queden más atrás que los modelos en la nube a medida que el hardware se vuelve más especializado y menos práctico para ejecutarse localmente? Correcto. Así que he probado algunos modelos localmente en mi MacBook Pro M4 hardware estándar. No funciona bien.

Así que primero tienes que tener, para incluso ejecutar LLMs localmente, tienes que tener un hardware bastante caro o ajustar las cosas un poco o mucho para siquiera ejecutarlos. Así que en mis experimentos, al menos para usuarios domésticos, sigue siendo mucho peor. Modelos locales en el momento para tareas similares. Así que logré ejecutar JAMA. No recuerdo qué modelo o qué cuenta de parámetros. Así que logré ejecutar uno de los prompts en JAMA. Tomó 35 segundos, creo, para obtener incluso el resultado, para obtener cualquier resultado, y fallaba totalmente en todas las pruebas. Y algunos modelos más que probé localmente y ni siquiera se ejecutaron con algún error extraño en OLAMA. Así que al menos en mi experiencia, los modelos locales todavía están muy, muy al principio.

Están mejorando. Veo los tweets y las noticias. Quizás en algún momento lleguemos allí, pero por ahora es realmente temprano. De hecho, creo que eso responde a la otra pregunta que tenemos aquí. ¿Crees que vale la pena invertir en LLMs locales? ¿Hay algo más que te gustaría añadir a eso? La palabra invertir es bastante precisa aquí. Tendrías que invertir mucho y luego, incluyendo electricidad, no estoy seguro de que obtendrías el resultado que esperas.

Fantástico. Muy bien, siguiente pregunta. ¿Ya has probado SONnet 5? Si es así, ¿dónde se sitúa en el benchmark? Sí, lo he hecho, y hay un video, pero intencionalmente no lo puse en mi benchmark porque fue el mismo resultado que SONnet 4.6, pero con un precio mucho mayor, lo cual fue realmente sorprendente para mí. Así que el precio de la API de SONnet 5 es astronómicamente alto. No recuerdo la cantidad de puntos, pero estaba funcionando de manera bastante similar a SONnet 4.6. Y también lo mismo, puedes leer los tweets al respecto en línea, sobre SONnet 5. La gente realmente no entiende el propósito de esa versión en absoluto porque es más o menos el mismo precio o incluso más caro que Opus. Así que fue realmente extraño, y en mi benchmark no funcionó bien en absoluto.

Ya que estamos en el tema de diferentes modelos, otra pregunta aquí es, ¿tienes experiencia con Proton Luma 2.0, y cómo se mide frente a los demás? ¿Has oído hablar de eso? No, no lo he hecho, pero en realidad pensando en ello, en los comentarios de mi canal de YouTube, la gente comienza a mencionar modelos que no conozco. Y parece que hay tantos nuevos provenientes de empresas desconocidas, parece. Algunos de ellos son locales, algunos de ellos son de código abierto. Así que sí, veo muchos más nombres nuevos además de esos 18. Este es uno de ellos del que ni siquiera he oído hablar. Lo siento, no soy lo suficientemente experto. Estoy seguro de que veremos más de estos modelos apareciendo y probablemente harás un video sobre eso.

Increíble. Bien, siguiente pregunta. Con respecto a estos puntos asignados a los modelos basados en resultados, ¿cómo has evaluado los resultados usando un agente para escribir el fragmento de código y ejecutar la evaluación usando el mismo agente o dos sub-agentes diferentes en aislamiento? Oh, eso es interesante. No ejecuté sub-agentes en este caso a menos que el modelo decidiera, por ejemplo, Opus a veces delega algunas cosas a Haiku o a Sonnet. Ya no tanto, pero sí, a menos que el agente decidiera usar sub-agentes, no lo sugerí de ninguna forma, o tal vez respondí la pregunta? Sí, no ejecuté la evaluación con el mismo agente.

La evaluación fue pruebas automatizadas. La evaluación no fue realizada por LLM. Fue como análisis estático o pruebas automatizadas, no determinísticas, no LLM. Genial, siguiente pregunta. ¿Se pueden mitigar las deficiencias en la salida mediante definiciones de habilidades? Sí, por supuesto, y el framework con el que trabajo, PHP y Laravel, es bastante bueno. No estoy seguro si alguien lo ha usado. PHP tiene una reputación bastante mala. Me encanta PHP. De todos modos, pero Laravel en sí, así que PHP no es atractivo, pero Laravel sí lo es. Laravel, es muy interesante cuando hablo en Laracon's y la comunidad de Laravel. Entonces, la gente odia PHP, pero Laravel de alguna manera lo ha vuelto a poner en el tema en general. Entonces, Laravel, cuando instalas un nuevo proyecto de Laravel, viene con una habilidad llamada mejores prácticas de Laravel. Detecta tus IDEs. Detecta qué otras habilidades se necesitan.

Así que, básicamente, tienes .agents y .codecs y .cloud preparados para ti ya, así que eso ya da muchos puntos de bonificación para LLMs. Así que sí, en general, los resultados pueden ser mucho mejores con mejores habilidades o directrices. Me encanta esta siguiente pregunta.

Oh, en realidad, ¿puedo pedirte que hables en este micrófono para nuestros asistentes remotos? Ya mencionaste sobre los costos de ejecución local, pero me pregunto en tu experiencia con estos modelos, ¿hubo alguno que fuera el mejor en términos de costo al ejecutarse localmente o, digamos, en un servicio de terceros como AWS, por ejemplo? Correcto. Desafortunadamente, no profundicé en eso. Así que, estaba usando modelos tal cual en código en la nube. Como, típicamente, no lo hice, como dije, intenté localmente, no me funcionó bien, y decidí no seguir ese camino por ahora. Tal vez ese sea el siguiente paso, pero, de nuevo, los primeros experimentos simplemente me desanimaron lo suficiente, al menos por ahora. Quiero decir, pregúntame en un mes, todo puede cambiar. Las cosas cambian tan rápido por aquí.

Así que, siguiente pregunta. Dijiste que el harness es más importante. ¿Puedes contarnos más sobre tu configuración? Bueno, mi configuración para el canal de YouTube está por todos lados, en realidad, porque depende de lo que pruebo y cómo, pero lo que estoy diciendo aquí, por ejemplo, el código en la nube funciona mejor, los modelos en la nube funcionan mejor en código en la nube que en código abierto, por ejemplo, y viceversa. Así que, no solo necesitas pensar en el modelo que ejecutas, sino dónde lo estás ejecutando. Así que, el harness, la definición de harness es tan vaga, pero me gusta una de las definiciones. Dice, como, el harness es todo excepto el modelo. Así que, el IDE, las habilidades que mencionaste, el prompt, los guardrails, las evaluaciones, todo eso. Así que, esto es a lo que me refiero como harness en general, y no hay, como, un gran secreto. De nuevo, depende de con qué tecnología estás trabajando, como React u otro lenguaje, así que probablemente el harness debería tener habilidades y guardrails alrededor de ese lenguaje específico, y eso daría mejores resultados que solo usar el modelo en sí. Increíble.

Siguiente pregunta. ¿Qué metodología recomendarías para medir la efectividad de usar LLMs para resolver un problema o realizar una tarea versus la automatización determinista y los procesos manuales? Creo que Mario habló sobre eso en algunas preguntas, así que, ¿cómo evalúas, como, el LLM, que evalúa el LLM, y no hay una respuesta definitiva, y por eso decidí mi metodología de pruebas automatizadas, porque creo que así encontré mi nicho en los canales de YouTube, así que la gente aprecia que mire el código en absoluto, porque algunos, como, videos de LLM en YouTube, como, oh, hay un nuevo modelo. Vamos a probarlo de una vez, y yay, funciona, y es la próxima gran cosa. Así que, ese es usualmente el típico YouTuber, Hype Bro los llamo. Así que, por eso estoy mirando el código y mi prueba determinista. Creo en esas porque creo que muestran escenarios más realistas para las personas que quieren preocuparse por la calidad del código y todos los casos extremos, y todos estamos ejecutando y escribiendo pruebas automatizadas de todos modos, así que este debería ser el benchmark, al menos por ahora, para tareas básicas. De nuevo, estamos hablando de tareas bastante simples como crear un CRUD, crear API, crear algo, así que para mis tareas, creo que el benchmark determinista con prueba automatizada es el mejor por ahora, pero por supuesto, a medida que llegamos a evaluar Fable u Opus High, no tengo la respuesta aún de cómo podemos evaluar si funciona bien porque es realmente difícil incluso revisar, así que si Opus te da, como, una pull request para revisar, como, 200 archivos cambiados, ¿cómo lo revisas incluso, como, a nivel humano? Así que, no tengo la respuesta de cómo evaluamos ese nivel de LLMs. Nos queda un minuto más, así que solo haremos esta última pregunta.