Últimamente he estado trabajando en una librería tipo “boilerplate” para usarla en mis aplicaciones. La idea es tener resueltas de antemano las típicas funciones que un proyecto web puede necesitar (creación de cuentas, identificación de usuarios, acceso mediante Google, envío de correo electrónico, seguridad, persistencia, etc) de tal manera que si decido hacer una nueva web pueda dedicarme al grano de la propia aplicación.

Junto a la librería he preparado una aplicación de demostración y un manual donde explico cómo utilizarla. Todo está desarrollado con Java 21 y Spring Boot 4.1.0.

Una vez que tenía estos materiales se me ocurrió una prueba: entregar el manual y la aplicación de ejemplo a distintos modelos LLM y pedirles que construyesen una aplicación nueva.

La cosa no es tanto saber si un LLM puede construir una aplicación (hemos visto ya mil ejemplos de aplicaciones creadas con un sólo prompt) si no ver cómo se adapta a una librería nueva, que no está en su entrenamiento, y para la cual debe procesar un manual de cierto tamaño.

Además, la pregunta de verdad es si esto es capaz de hacerlo no solo modelos “grandes” o de “frontera” si no modelos pequeños y baratos.

La aplicación: «Mi Diario»

La aplicación que pedí construir era un pequeño diario personal.

Los usuarios debían poder crear una cuenta o acceder mediante correo electrónico o Google. Una vez identificados, podían escribir una entrada cada día, utilizando Markdown, y consultar el historial de entradas anteriores.

La entrada correspondiente al día actual debía poderse editarse. Las anteriores, en cambio, tenían que quedar como elementos de solo lectura.

También pedí que la aplicación estuviese disponible en español, inglés, francés y alemán.

La idea es suficientemente sencilla como para que todos los modelos puedan resolverla, pero se trata de evaluar la integración con la librería, la autenticación, el tratamiento seguro del Markdown, la internacionalización, la regla de una entrada diaria…

Condiciones de la prueba

Utilicé ocho modelos:

• GPT-5.6 Luna
• GPT-5.6 Sol
• Claude Sonnet 5
• Claude Opus 5 (aprovechando que acaba de salir)
• Claude Fable 5
• Kimi K3 (el nuevo rey de los open weights)
• Gemini 3.6 Flash (de reciente aparición también)
• DeepSeek-V4-Flash

Hoy en día, los harness de la aplicación tienen mucha ingeniería por detrás, muchos skills y mil cosas más, así que para intentar comparar los modelos y no las aplicaciones que los utilizan (codex, claude code, etc), en todos los casos usé Pi Coding Agent, que es un agente que me gusta y que mete poca cocina por detŕas.

Accedí a todos los modelos a través de Open Router y para todos ellos usé el nivel de razonamiento “High”.

Cada modelo recibió exactamente los mismos materiales:

• El manual de la librería.
• La aplicación de demostración.
• El mismo prompt con los requisitos de «Mi Diario», que es este:

Prompt
######

Siguiendo las instrucciones de docum/manual/ y la aplicación de ejemplo en docum/demo-app/ crea un proyecto aquí con las siguientes características: 

- Título del proyecto y de la página "Mi Diario"
- Leer para empezar el documento manual/13-guia-para-ia.md con instrucciones
- 4 idiomas: español (por defecto, inglés, alemán y francés)
- Configuración de puertos:
	- Servicio web http: 8080
	- Postgresql: 5432
	- Mailpit: 1025 (smtp) y 8025 (web)
- Monta Postgresql y Mailpit en un docker compose, tal y como aparece en el manual y la demo. El nombre del compose debe ser "mi-diario"
- Login por email y gmail
- Los datos de identificación de gmail los puedes coger del .env del proyecto demo-app.
- Aspecto moderno, elegante, editorial, con acento rojo oscuro. Utiliza tus mejores habilidades de diseño.
- Al logarse un usuario le permite acceder a su zona logada donde puede mantener su diario. 
- Puede escribir solo en la última entrada del diario. Se crea una nueva entrada si le da a un botón para ello (y ya estamos en un nuevo día desde la última entrada). 
- Una vez se crea una nueva entrada, no se puede escribir en las anteriores, solo en la última creada. 
- Las entradas se escriben en markdown y se visualizan como html. Aparece una debajo de otra en formato "blog", orden descendente. Cada entrada tiene la fecha. Cada entrada tiene un botón al lado "editar". Al pulsar ese botón, la entrada se cambia por una textarea donde se puede editar en formato Markdown.

La idea inicial era utilizar un sólo prompt y que generase la aplicación en un solo turno, sin conversación posterior. Esto no fué posible con Gemini 3.6 Flash: su primera versión no arrancó, así que le pasé el error y pudo corregir ese problema en un segundo turno. Lo he mantenido en la comparación, pero hay que tener en cuenta que no trabajó exactamente en las mismas condiciones que los demás.

Sistema de evaluación

La evaluación “de comportamiento” la hice yo, probando la propia aplicación: Si arrancaba o no, si funcionaba el login, la edición del diario.

Además, para tratar de “evaluar” la calidad del código, le pasé todas las soluciones (y el prompt original, documentación, etc) a dos modelos distintos (GPT-5.6 Sol y Claude Opus 5) que actuaron como evaluadores. Las puntuaciones que aparecen a continuación son la media entre las puntuaciones de cada evaluador.

Esto no pretende ser un benchmark general, está claro. Solo he realizado una ejecución por modelo, y ya sabemos la naturaleza variable de los llm. Además hay que tener en cuenta que para los modelos frontera esta aplicación no tiene dificultad, seguramente una prueba más difícil permitiría a algunos destacar más sobre otros.

Resultados

El mejor resultado lo ha obtenido Opus 5, que mejora la puntuación de sus hermanos Fable 5 y Sonnet 5. También es el más caro, superando incluso al mucho más caro Fable (caro en cuanto al precio por token) debido a un mayor consumo de tokens. Sonnet a pesar de ser mucho más barato que el resto de modelos de Antrhopic ha necesitado muchísimos más tokens que los demás, siendo el menos eficiente de los ocho modelos evaluados en el consumo de tokens.

GPT-5.6 Sol, junto a Kimi K3, son quizá el punto dulce de esta comparativa, obteniendo muy buenos resultados (especialmente Sol) a un precio mucho menor que los de Anthropic.

EL modelo GPT-5.6 Luna y DeepSeek-V4-Flash son los modelos baratos de la prueba. Luna sorprende por lo eficiente que es, no solo por precio, si no por consumo de tokens. Evidentemente estos modelos necesitan mayor interacción por nuestra parte. Necesitarían varios turnos de trabajo, pidiéndoles mejoras, para llegar a los resultados de los otros. Pero si estamos buscando modelos baratos son muy buenas opciones.

Gemini 3.6 Flash se queda en tierra de nadie, con un precio mayor que Sol y un resultado casi igual a Luna. Además, este modelo no generó una aplicación que funcionase a la primera y hubo que darle un segundo turno para que lo arreglase.

Si tuviesemos que trazar la “frontera eficiente” de esta prueba sería esta, formada por Luna, Kimi K3, Sol y Opus:

Los demás modelos pierden (quedan más abajo y más a la derecha de la línea marcada por estos cuatro), lo que quiere decir, que a mismo precio hay otro modelo que lo supera en resultados (o que a mismo resultado, hay otro modelo más barato).

Según esta prueba elegiríamos:

• GPT-5.6 Luna si queremos minimizar el coste.
• Kimi K3 si buscamos la mayor eficiencia dentro del tramo medio.
• GPT-5.6 Sol si preferimos algo más de calidad por un sobrecoste pequeño.
• Claude Opus 5 si buscamos la puntuación técnica más alta y el coste no es importante.

Aquí dejo cómo puntuaron los modelos en las distintas métricas de la evaluación:

Aspecto visual

El prompt pedía un aspecto “moderno, elegante, editorial, con acento rojo oscuro”. Todos los modelos generaron un diseño que cumplía este requisito y, de hecho, todos son un poco parecidos entre sí. Entiendo que esta convergencia en un diseño parecido puede estar influído por el poco detalle que daba el prompt y por la aplicación “demo” que se les dió de ejemplo, que pudo “guiarlos” hacia un diseño similar. Suele decirse que los modelos de Anthropic son buenos en diseño, y aunque entiendo que gran parte es debido a los skills de claude code (que aquí no se utilizaron) creo que en general me gustan más esos diseños, sí, sobre todo en el uso de la tipografía en los títulos.

Puedes juzgarlo tú mismo. Aquí hay un par de pantallazos de cada aplicación (pulsa para ampliar):

Además, he montado la aplicación “ganadora” (Opus 5) y la puedes probar aquí: https://mi-diario.bolsoncerrado.com/

¿Saco alguna conclusión?

Esta prueba evidentemente no testea las capacidades más potentes de los LLM. Lo que sí nos dice es que los modelos actuales, incluso los pequeños como Luna o DeepSeek, (con un coste de céntimos) pueden leer una documentación de una librería nueva, entenderla razonablemente bien, y generar una aplicación que la use en un solo turno.

Otra conclusión que se puede sacar es que, en el uso agéntico, si buscamos “ahorrar”, no solo hay que mirar el precio por token, si no lo eficientes que son en el uso de estos. Un modelo más caro puede resultar realmente mejor si utiliza menos tokens que otro modelo teóricamente más barato. Los agentes entran en un “bucle” de uso de herramientas en cada turno, y no es lo mismo que use 50 herramientas que use 100, no es lo mismo que necesite mucho razonamiento para lograr el éxito que si necesita menos. Esto además se junta con la práctica de poner al agente a trabajar en un “ralph loop” externo al propio turno, de tal manera que no para hasta llegar al objetivo. Ahí, el uso de tokens en los modelos poco eficientes se puede disparar y que nos pese en el bolsillo