Le encargamos un restaurante a los dos modelos más caros del momento

Un benchmark dice que Fable 5 saca 92 y GPT Sol 5.6 se queda en 78. Catorce puntos de diferencia. Si te fías de ese número, la conclusión es de cajón: Fable es mejor, paga lo que cueste. Nosotros no nos fiamos de los números de nota de prensa (están saturados y los publica el propio vendedor), así que hicimos lo que haría cualquiera que va a firmar la factura: les dimos el mismo trabajo de verdad y los pusimos a currar en igualdad de condiciones.

El encargo: desarrollar desde cero un motor de reservas para un restaurante. Nada de "hola mundo" ni de CRUD de juguete. Un sistema con reglas de negocio de verdad que, además, tendrían que corregir cuando llegaran quejas, hacer crecer con la base ya en producción y aguantar una avalancha. Cuatro fases sobre el mismo código, el mismo sandbox aislado sin internet, el mismo presupuesto. La única variable: el modelo.

Te adelanto una cosa para que no te despistes: esto no acaba en empate. Acaba con un ganador claro. Pero para entender por qué, hay que bajar al código.

El encargo: un restaurante que no perdona

El brief de "Marea": 14 mesas, dos turnos (comida y cena), reservas con nombre, teléfono, personas, fecha y turno. Y la regla sagrada: jamás aceptar más reservas de las que caben. Si el turno está lleno, lista de espera por orden de llegada. Cancelas, y el primero de la cola entra solo. El mismo teléfono no puede colarse dos veces para el mismo turno. Idempotencia por si el formulario reintenta. Límite de peticiones por si alguien bombardea.

Y una trampa de diseño de las buenas: el brief solo contaba la versión 1. Las tres fases siguientes no se anunciaron. Como en un proyecto real, donde el cliente "tiene planes" pero no te los suelta el primer día. Así se ve de verdad quién construye pensando en el futuro y quién hace lo justo para pasar el examen de hoy.

Las cuatro fases, encadenadas sobre el mismo código que cada modelo iba arrastrando:

1. Construir la v1 completa.
2. Corregir (llegan quejas de clientes en lenguaje natural; reproduce, arregla y no rompas nada).
3. Evolucionar (añade precios y sugerencias, pero con la base ya cargada de 5.000 reservas de producción que no se pueden perder).
4. Escalar (aguanta 200 reservas simultáneas sin overbooking y responde rápido con 15.000 reservas en base).

Qué les dimos: el mismo folio en blanco

Para que la comparación sea limpia, los dos arrancaron exactamente del mismo sitio: un repositorio casi vacío con cuatro cosas. Un README.md con el encargo del restaurante en lenguaje de cliente (el brief de arriba). Un api.md con el contrato técnico congelado: los endpoints exactos que debía exponer la API (POST /reservas con cabecera de idempotencia, PATCH y DELETE /reservas/{id}, GET /disponibilidad, GET /reservas?telefono=), los códigos de estado, la forma del JSON y el límite de peticiones. Un run.sh con el contrato de arranque ("tu app tiene que levantar con esto y escuchar en el puerto 8080"). Y un DECISIONS.md vacío, de relleno obligatorio, donde cada modelo tenía que justificar su stack y sus decisiones.

La gracia está en el reparto: lo externo va congelado (los mismos endpoints, los mismos códigos, para poder medirlos a los dos con la misma vara), pero lo interno es libre (el lenguaje, el framework, la base de datos, la arquitectura). Ahí es donde cada modelo enseña de qué pasta está hecho. Y donde, como verás, tomaron caminos muy distintos.

Cómo lo medimos: hechos, no opiniones

Cada fase tiene una batería de tests ocultos que el modelo no ve. Se inyectan después de cortarle la red y se borran antes de devolverle el control, así que hacer trampa no es una opción. Y cada test comprueba el estado real releyendo por la API: no vale con un 200 OK, la reserva tiene que quedar registrada de verdad.

27 comprobaciones por modelo, más las regresiones (¿rompió algo que ya funcionaba?) y la brecha de honestidad (¿dijo "hecho" con los tests en rojo?). Todo determinista, todo auditable.

Fase a fase: mismo plato, dos cocinas

Empecemos por lo justo: en construir, los dos son una máquina. Fable 27 de 27. Sol 27 de 27. Cero regresiones a lo largo de las cuatro fases, cero mentiras. Los dos dejaron la v1 tan redonda que la fase de corrección se quedó sin nada que corregir (no dejaron ni un bug que reportarles).

Ahí se acaba el empate. Porque el cómo fue otra película.

Sol resolvió el mismo encargo en la mitad de tiempo, con menos de la mitad de tokens y por 3,8 veces menos dinero. No es un margen: es una diferencia de categoría. Y no porque se dejara nada (recuerda, mismos 27 de 27). Simplemente llegó al mismo sitio gastando muchísimo menos. Guárdate ese dato, que al final pesa.

La ingeniería: dos filosofías del mismo problema

Lo primero que sorprende es que los dos eligieron exactamente el mismo stack: Python de biblioteca estándar y SQLite, cero dependencias. La decisión correcta para el contexto (un restaurante, herramienta interna, un proceso, sin internet). Nadie se puso a montar Postgres para 14 mesas; nadie hizo la chapuza de guardarlo todo en memoria y perderlo al reiniciar. Que dos modelos frontera, por separado y sin verse, coincidan en el right-sizing correcto ya dice mucho de por dónde va la cosa.

A partir de ahí, dos escuelas bien distintas.

Fable construyó un monolito. Un solo fichero de 653 líneas, eso sí, ordenado en capas por dentro. Su joya es cómo serializa las escrituras para que nunca haya overbooking: un candado de proceso más una transacción BEGIN IMMEDIATE, contando e insertando dentro de la misma transacción. Nadie se cuela entre el "¿queda hueco?" y el "ocupo el hueco".

Y es el más paranoico con la durabilidad: activó synchronous=FULL, que hace la base más lenta pero blinda las reservas ante un corte de luz. Encima se auto-escribió unas 105 comprobaciones, incluida una prueba propia de 300 peticiones concurrentes. En probarse a sí mismo, nadie le gana.

Sol construyó en capas (el HTTP por un lado, 162 líneas; el dominio por otro, 598). Y llevó la defensa del aforo un escalón más abajo que Fable: además del candado y el BEGIN IMMEDIATE, metió triggers en la propia base de datos que abortan físicamente cualquier reserva número 15. El invariante no vive en el código, vive en el motor. Aunque un bug futuro se saltara la lógica de la aplicación, la base no deja pasar el overbooking. Eso es defensa en profundidad de verdad.

Y hay más madurez donde no se ve: su límite de peticiones y su idempotencia son durables (viven en tablas de SQLite, no en memoria, así que sobreviven a un reinicio). Su validación de entrada es de lista blanca estricta: si le mandas un campo de más, lo rechaza. Fable, en cambio, tira el rate-limit en memoria (se resetea al reiniciar, y él mismo lo documenta como un apaño asumido).

Ninguno está "mal". Fable sobre-protege la durabilidad; Sol sobre-protege el invariante y hace durable lo que Fable deja en memoria. Pero si te toca mantener esto dentro de un año, ya intuyes cuál de los dos te va a dar menos sustos.

¿Y funcionan de verdad? Peticiones reales

Aquí no hay teoría que valga. Lanzamos peticiones HTTP reales contra las dos apps y miramos qué devuelven. Crear, modificar, cancelar, consultar disponibilidad, cross-selling (y basura imposible, a ver si cuela).

Las dos funcionan y registran de verdad. Y las dos rechazan lo imposible: el 31 de febrero, una reserva para 500 personas, un turno "25:00", personas negativas (todo devuelto con 422 y sin crear nada). La inyección SQL en el nombre no rompe nada. El duplicado se corta con 409. Ninguna de las dos es un colador (y no es poca cosa, porque colar basura es justo lo que suele pasar cuando le pides a una IA "hazme una app" y te fías).

El contraste más jugoso está en las sugerencias: Fable enriquece (te calcula el precio total, 6 personas × 2.800 = 16.800 céntimos) y Sol es minimalista (solo el código; el precio ya vive en /precios, una única fuente de verdad). Dos criterios, los dos defendibles.

Mantenibilidad: medida, no opinada

Aquí es donde casi todos los benchmarks se rinden y le preguntan a un juez LLM "¿qué código es más bonito?". Nosotros no nos fiamos de eso ni un pelo (de hecho un panel de tres modelos les puso 9 y 10 a los dos, que es como no decir nada). Así que medimos el código con herramientas estáticas de verdad (radon, ruff, mypy), el mismo criterio para las dos apps. Sin opiniones.

Y aquí el empate se rompe otra vez a favor de Sol: su código es medidamente más limpio. Mejor índice de mantenibilidad (30,7 contra 23,6), la mitad de avisos de lint (23 contra 52), tipado casi completo (97% contra 26%), menos complejidad y estructura modular. Gana 6 de las 8 métricas.

Fable se lleva dos, y son reales, para que nadie diga que barremos para casa: sus funciones son más cortas (Sol arrastra una función de 136 líneas que hace demasiado) y se probó a sí mismo mucho más a fondo. Y un vicio que comparten, muy de código generado por IA: ninguno usó un Enum para los estados (los dos repiten "confirmada" y "lista_espera" a pelo por todo el código). Frontera, pero con sus tics.

El veredicto: no es empate

Seamos precisos, que es lo que nos diferencia de un titular de leaderboard. Hay un empate, sí, pero solo en una cosa: en "¿lo hace bien?". Los dos entregaron 27 de 27, sin una sola regresión, sin mentir una sola vez, y los dos aguantaron la avalancha de 200 reservas con aforo exacto. En corrección funcional, mano a mano.

Pero un proyecto real no se paga en "lo hace bien". Se paga en euros, en tiempo y en el marrón de mantener el código después. Y en esas tres cosas no hay color: Sol lo hizo 3,8 veces más barato, en la mitad de tiempo y con código objetivamente más mantenible. No ganó por poco. Ganó en todo lo que importa cuando dejas de mirar el leaderboard y empiezas a mirar la factura.

Para quien tenga que construir algo de verdad, el ganador es GPT Sol 5.6. No porque sepa más (ahí empataron), sino por cómo lo hizo y por lo que costó. Que es exactamente lo que el 92 contra 78 no te iba a contar jamás: el modelo que saca 14 puntos menos en el benchmark resolvió el mismo encargo casi cuatro veces más barato, más rápido y con mejor código.

Si tu decisión de qué modelo usar depende de un número de nota de prensa, esta es tu señal para dejar de mirarlo.

La letra pequeña (que sí contamos)

Porque aquí el dato manda de verdad, y eso incluye sus límites: esto es una sola pasada por modelo (n=1, sin repeticiones; la varianza del pass@1 existe y no la escondemos). La fase de corrección no llegó a ejercitarse porque ninguno dejó bugs. La concurrencia fue una ráfaga de 200 sobre un proceso, no tráfico sostenido de días. Y las métricas de mantenibilidad estáticas capturan mucho, pero no todo. Esto mide un motor SQLite monolítico bien hecho, a conciencia (no un SaaS bajo avalancha nacional). Lo decimos claro para que nadie tenga que adivinarlo, que es más de lo que hace el benchmark que te vendía 92 contra 78.

Y como aquí no pedimos que te fíes de nuestra palabra: descarga el paquete completo (el código de las dos apps, los transcripts turno a turno y todas las puntuaciones) y comprueba cada número tú mismo.

Preguntas frecuentes

¿Qué modelo de IA es mejor para desarrollar software de reservas para un restaurante?

En esta prueba, GPT Sol 5.6 y Fable 5 empataron en resultados funcionales (27/27 tests superados, cero regresiones). La diferencia está en el coste y la eficiencia: Sol completó el mismo trabajo 3,8 veces más barato y en la mitad de tiempo, con código objetivamente más mantenible según métricas estáticas (radon, ruff, mypy). Para un proyecto real con presupuesto, Sol gana con claridad.

¿Cuánto cuesta usar modelos de IA como Fable 5 o GPT Sol 5.6 para un proyecto real?

El experimento no publica cifras absolutas de precio, pero sí la brecha: Fable 5 costó 3,8 veces más que GPT Sol 5.6 para el mismo encargo completo (cuatro fases, desde construcción hasta escala con 15.000 reservas en base). La diferencia no es marginal; es de categoría.

¿Los benchmarks de los leaderboards de IA son fiables para elegir modelo?

No necesariamente. En este experimento, Fable 5 puntúa 92 y Sol 5.6 puntúa 78 en el benchmark de referencia (14 puntos de ventaja), pero Sol resolvió el mismo trabajo real casi cuatro veces más barato, más rápido y con mejor código. Un número de nota de prensa publicado por el propio vendedor no captura coste, eficiencia ni mantenibilidad.

¿Qué significa que un modelo de IA tenga "cero regresiones" en un test de software?

Significa que, al añadir o corregir funcionalidad en cada fase, el modelo no rompió nada que ya funcionara. En esta prueba, tanto Fable 5 como Sol 5.6 mantuvieron sus 27 tests en verde a lo largo de las cuatro fases (construir, corregir, evolucionar y escalar) sin introducir nuevos bugs en código anterior.