Grok 4.5 y Kimi K3 acaban de salir: les pusimos el mismo encargo que a los buques insignia

Esta semana han aterrizado dos modelos nuevos: Grok 4.5 y Kimi K3. Como todos, llegaron con su gráfica de barras, su tabla comparativa y su "state of the art". Y como siempre, las cifras las publica quien vende.

Nosotros teníamos algo mejor que una gráfica: un encargo de verdad, congelado y ya resuelto. Hace una semana pusimos a dos buques insignia —GPT Sol 5.6 y Fable 5— a construir un motor de reservas para un restaurante. Mismo brief, mismos tests ocultos, mismo presupuesto, mismo contenedor sin internet. Los ficheros están sellados por hash desde entonces: nadie los ha tocado.

Así que hicimos lo obvio. Les dimos exactamente el mismo trabajo a los dos recién llegados y nos sentamos a mirar.

Las reglas, en treinta segundos

El encargo son cuatro fases encadenadas sobre el mismo código, y el modelo no sabe que habrá una siguiente. Primero construir la v1 completa. Luego corregir, con quejas de cliente en lenguaje natural. Después evolucionar, añadiendo precios y sugerencias sobre una base de datos que ya tiene 5.000 reservas de producción que no se pueden perder. Y por último escalar: aguantar 200 reservas simultáneas sin vender la misma mesa dos veces.

La verdad la dicen 27 comprobaciones ocultas que el modelo nunca ve, para que no pueda programar contra el examen. Medimos también si rompió algo que antes funcionaba (regresiones) y si dijo "hecho" con los tests en rojo (brecha de honestidad). El coste va en euros reales a la tarifa de cada uno, con un tope idéntico de 15 dólares por modelo. Y la calidad del código no la puntúa nadie a ojo: la miden herramientas estáticas, con el mismo criterio para los cuatro.

Una cadena por modelo. Sin repeticiones, sin best-of. Lo decimos ahora para no venderte significancia estadística que no tenemos.

Grok 4.5: el único que trajo un framework

Grok fue el primero en enseñar carácter, y lo hizo en la primera decisión: es el único de los cuatro que asumió dependencias externas. Escribió un requirements.txt con Flask y Waitress, y montó su API encima.

Merece la pena defenderlo antes de criticarlo, porque la decisión es perfectamente razonable: Flask está probado por millones de proyectos, te ahorra escribir el enrutado y el parseo a mano, y Waitress es un servidor WSGI multihilo de verdad. De hecho la propia documentación de Python dice que el servidor HTTP de su librería estándar no es apto para producción. Los otros tres se lo montaron a mano con ese servidor. Sobre el papel, Grok eligió el camino sensato.

Y su diseño de concurrencia es, con diferencia, el más elaborado de los cuatro sobre el papel. Su documento de decisiones no describe un diseño: describe una reparación. Lista sus propios puntos débiles anteriores y cómo los arregló, en una sección que titula "v3 — picos TV". Quitó el candado global de Python porque serializaba también las lecturas, y dejó que el motor haga el trabajo: cada escritura abre una transacción BEGIN IMMEDIATE, que coge el bloqueo de escritura al empezar y no al primer INSERT. Contar y confirmar ocurren dentro de la misma transacción, así que dos peticiones simultáneas no pueden ver ambas "queda una mesa". Un índice único parcial remata la regla del teléfono.

Y para que consultar disponibilidad no se arrastre con 15.000 filas, se construyó una tabla de contadores desnormalizada que se actualiza en la misma transacción que cambia el estado, con reconstrucción automática al arrancar si se desincroniza.

Todo eso es buena ingeniería. El problema es lo que no está.

Grok no escribió ni un solo test. Ninguno. Los otros tres se auto-escribieron baterías de pruebas para verificarse; Grok entregó el código y se fue. Y cuando pasamos las herramientas de análisis, el resultado es incómodo: con framework y todo, produjo el código menos mantenible de los cuatro. El peor índice de mantenibilidad (22,3), la complejidad más alta, una función de 111 líneas, solo 6 constantes definidas y la palabra "confirmada" repetida ocho veces a pelo por el código en vez de vivir en un Enum.

Ahí está la conclusión que importa, y no es "usar un framework está mal". Es que Grok pagó el peaje de la dependencia sin cobrar el beneficio. Flask existe para que escribas menos código y más limpio. Grok acabó con el monolito más grande, más enrevesado y sin red de seguridad. La rueda ya inventada no le sirvió de nada.

Kimi K3: el obseso de la verificación

Kimi es el reverso exacto.

Empezó por donde Grok no miró: el entorno de despliegue. Su documento de decisiones lo razona explícitamente —"en el entorno no hay red: no hay nada que instalar, nada que pueda faltar"— y de ahí saca la conclusión de irse a librería estándar pura, cero dependencias. Su run.sh es literalmente python3 app.py y se acabó.

Su diseño es más humilde que el de Grok: un candado global serializa la lógica de dominio y cada mutación va en su transacción. A este volumen —14 mesas, dos turnos— serializar no cuesta nada y compra corrección. Pero los detalles finos son de alguien que ha sufrido bugs de verdad. La lista de espera se ordena por el rowid de SQLite en vez de por reloj, para no depender de la hora del sistema. La regla del teléfono se comprueba en el código y se refuerza con un índice único en la base de datos, "doble red de seguridad" en sus palabras. Y hay un matiz que casi nadie ve: responde el reintento idempotente antes de aplicar el rate-limit, para que reintentar una petición que ya funcionó nunca te devuelva un 429.

Pero lo que de verdad define a Kimi es cuánto se revisa a sí mismo. Escribió 95 comprobaciones de contrato y 33 más para la ampliación. Probó la durabilidad matando el proceso con kill -9 y comprobando que no se perdía nada. Cuando llegó la fase de la base de datos de producción, hizo una copia de seguridad, ejecutó sus reglas contra una copia de las 5.156 reservas reales y verificó fila a fila que no había tocado ninguna. En total: 896 líneas de tests, más de las que tiene su código de producción.

Y ahora el dato que lo explica todo. Kimi tardó 89 minutos. Sol tardó 11,7. Es 7,6 veces más lento, y se comió el tope de tiempo en la última fase.

La causa no es que Kimi elija pensar mucho: es que no puede pensar menos. La API de Moonshot fuerza el esfuerzo de razonamiento al máximo y no permite bajarlo — su documentación lo dice sin rodeos: el modo de pensamiento va siempre activo y el nivel de esfuerzo sólo admite el valor máximo. Con los demás modelos puedes pedir menos deliberación para tareas mecánicas. Con Kimi, no hay perilla. Cada turno, para todo, a fondo.

Eso tiene un lado bueno —el cuidado obsesivo que acabas de ver— y un lado caro: en un ciclo de desarrollo real, esperar hora y media a que termine algo que otro hace en doce minutos se nota en la cara.

Y con todo ese esmero, Kimi deja un agujero llamativo: no anotó un solo tipo. Cero de 39 funciones. Ni una. Lo tienes ahí arriba en la captura, en la propia firma de su función central. Escribió más tests que código y a la vez renunció a la comprobación que el lenguaje le regalaba.

¿Funciona de verdad o es fachada?

Un modelo puede pasar tests y entregar algo que se cae al primer empujón. Así que arrancamos las dos aplicaciones y les lanzamos peticiones reales.

Las dos rechazan la basura sin despeinarse: el 31 de febrero, una reserva para 500 personas, un turno llamado "25:00", personas en negativo y un intento de inyección SQL en el nombre. Cinco de cinco, con su código de error correcto.

Y luego la prueba de fuego: 200 reservas simultáneas al mismo turno. El resultado es idéntico y es el correcto en los dos casos: exactamente 14 confirmadas —las 14 mesas—, las otras 186 a lista de espera, cero errores y cero overbooking. Ni una mesa vendida dos veces bajo una avalancha que llega toda a la vez.

Eso no es cosmético. Es control de concurrencia funcionando de verdad.

Ahora sí: contra el listón

Hasta aquí los novatos por separado. La pregunta era si aguantan el nivel de los buques insignia, y la respuesta corta es sí.

En calidad funcional hay empate a cuatro. Los cuatro modelos pasan las 27 comprobaciones, ninguno provoca una sola regresión y ninguno miente diciendo que ha terminado cuando no. En "¿lo hace bien?", los recién llegados no se distinguen de los veteranos.

Donde se separan es en lo que cuesta y en cómo queda el código.

Sol sigue siendo el más limpio: el mejor índice de mantenibilidad, menos avisos del linter, tipos casi al cien por cien y el único que separó la capa HTTP del dominio en vez de tirar de monolito. Kimi es el segundo más limpio y el de menor complejidad, con la mayor batería de tests de los cuatro. Fable se queda con el peor recuento de avisos del linter (52). Y Grok cierra la tabla.

Un vicio compartido por los cuatro, que conviene decir: ninguno usó un Enum para los estados. Los cuatro repiten "confirmada" y "lista_espera" como cadenas sueltas. Es el olor a código de IA más constante que hemos visto.

En dinero, el orden es este: Sol 1,77 € · Grok 2,22 € · Kimi 3,86 € · Fable 6,76 €. Y ahí hay un titular que no esperábamos: el recién llegado Grok resuelve el mismo encargo por un tercio de lo que cuesta Fable, que es un buque insignia con tarifa de buque insignia.

El ranking de los cuatro

Para no acabar en un "depende", ordenamos con un método aburrido y a la vista: en cada dimensión objetiva se ordena a los cuatro y se les da un puesto del 1 al 4; el ranking es la suma. Todas pesan igual. La parte funcional no puntúa, porque es empate.

GPT Sol 5.6 sigue siendo el mejor de los cuatro, y no por poco: gana coste, tiempo, turnos, tokens y limpieza de código. Ni Grok ni Kimi lo destronan.

Pero el resultado interesante no es ese. Es que los dos lanzamientos de esta semana entran directamente por delante de un buque insignia. Grok se queda segundo, entregando lo mismo que Fable por un tercio del precio. Kimi le pisa los talones —16 contra 17, prácticamente empatados— cambiando velocidad por cuidado: peor tiempo de los cuatro, pero el segundo mejor código y los mejores tests.

Si tuvieras que elegir con esto delante: Sol si quieres lo mejor en casi todo. Grok si el presupuesto manda y vas a poner tú los tests que él no escribe. Kimi si prefieres que se lo piense todo y no te importa esperar. Y Fable entrega, sí, pero hoy te cobra casi cuatro veces lo que Sol por el mismo trabajo.

Lo que este experimento NO demuestra

Toca la parte honesta, que es la que casi nadie escribe.

Es una sola cadena por modelo. Sin repeticiones y sin best-of: no hay significancia estadística, y otro día los números bailarían algo.

Kimi necesitó una ayuda del banco de pruebas y hay que declararlo. Al forzar el razonamiento al máximo, a veces devuelve un turno entero de pensamiento puro, sin texto ni herramientas. Nuestro arnés lo interpretaba como "he terminado" y cerraba la cadena en falso. Lo arreglamos para que en ese caso le pida continuar, y con eso Kimi construyó sin problemas. Es una adaptación del banco de pruebas, no del modelo, y los otros tres no la necesitaron.

La última fase de Kimi se cortó por tiempo (2.430 segundos contra un tope de 2.400). Ya había construido la solución que pasa las cuatro comprobaciones; el corte sólo dice que necesitaba más presupuesto de reloj del que le dimos.

La fase de corrección apenas se ejercitó en tres de los cuatro: dejaron la primera versión tan completa que las comprobaciones de esa fase ya estaban en verde antes de empezarla. El mecanismo es el mismo para todos.

Y "escalar" aquí significa una ráfaga de 200 peticiones contra un proceso y un SQLite, no infraestructura repartida ni carga sostenida. Las métricas de mantenibilidad, por su parte, capturan una parte real de la calidad, no toda.

---

Nada de esto sale de una nota de prensa. Sale de cuatro modelos construyendo el mismo sistema, en el mismo contenedor, con las mismas reglas, y de las herramientas midiendo lo que quedó. Los dos fichajes de esta semana aguantan el listón de sobra. El listón, de momento, sigue donde estaba.