Qué modelo de IA usar para generar una app

Por qué no hay un ganador único

Una compilación completa pasa por etapas que no se parecen entre sí:

Planificar es decidir qué construir a partir de una petición ambigua. Pide razonamiento y tolera latencia: vale esperar diez segundos por una decisión que evita media hora de trabajo equivocado.

Generar es escribir muchos archivos que siguen reglas conocidas. Pide caudal y obediencia al formato, y es la etapa donde el modelo caro entrega casi exactamente lo mismo que el barato.

Corregir es leer un error del compilador y cambiar el fragmento correcto. Es la etapa más sensible al razonamiento de todas, porque una corrección equivocada rompe lo que funcionaba.

Revisar lo construido es comparar código contra un criterio escrito en lenguaje llano. Es lectura, no escritura, y un modelo pequeño lo hace bien.

Revisar las pantallas exige visión. No es una preferencia: un modelo sin visión sencillamente no puede mirar la captura y decir que el texto se salió de la tarjeta.

Un modelo que ganara en las cinco sería una coincidencia. En la práctica, lo que gana es el sistema que usa un modelo distinto en cada una.

Qué miden los benchmarks y qué no

Los números que circulan vienen casi todos de benchmarks de ingeniería de software: dado un repositorio existente y un defecto reportado, el modelo produce un parche que hace pasar la prueba.

Es una buena medida, y mide otra cosa. Generar una app desde cero se diferencia en tres puntos que el benchmark no captura:

No hay repositorio que entender. La mitad de la dificultad del benchmark es localizar dónde tocar en un código que el modelo nunca vio. En una generación ese problema no existe, y en su lugar aparece la coherencia entre treinta archivos que nacen juntos.

No hay prueba que pasar. En el benchmark el criterio de éxito es objetivo y ya está escrito. En una app nueva el criterio es lo que la persona pidió, en lenguaje natural, probablemente incompleto.

Nada mide si quedó bonito. Una app que compila y es fea suspende con el usuario y aprueba cualquier benchmark.

Conclusión práctica: usa los benchmarks para descartar un modelo malo en código, nunca para elegir entre los dos primeros.

Las familias, y para qué sirven

Sin citar versiones, porque cambian cada mes y la página envejecería antes de que llegaras aquí.

Modelos de razonamiento. Piensan antes de responder, gastan más tokens y más tiempo, y aciertan decisiones que los demás fallan. Compensan en las etapas de decisión: planificar y corregir después de que una corrección simple ya falló.

Modelos rápidos. Una fracción del precio, buena parte de la calidad en tareas con regla clara. Es donde debe correr la mayor parte del volumen de una compilación, porque la mayor parte es mecánica.

Modelos con visión. Necesarios para cualquier cosa que implique mirar el resultado renderizado. Sin eso no hay revisión visual, solo revisión de código.

Modelos abiertos. Han cerrado buena parte de la distancia en generación de código y cobran mucho menos. Son la razón de que el coste por app haya caído tanto en dos años.

Cómo lo resuelve Fabapp

Somos parte interesada, así que lo que sigue es descripción, no recomendación. Júzgalo por lo que se puede verificar abriendo la plataforma.

Un catálogo, no un modelo. La plataforma mantiene un catálogo de modelos de varios proveedores, cada uno con el coste por mil tokens derivado de la tarifa pública del proveedor. Ese catálogo es lo que permite cambiar qué modelo ejecuta cada etapa sin tocar el código del producto. Lo demás que hace la plataforma está en funciones.

Elige la etapa, no tú. Por defecto, cada etapa de la compilación usa el modelo adecuado: planificación y corrección en modelos más fuertes, generación en modelos de caudal, revisión de aceptación en un modelo pequeño, revisión visual en un modelo con visión. No necesitas saber nada de esto para construir una app.

Puedes elegir de todos modos. El selector de modelo existe, y la clave propia también: desde el plan Builder conectas tu clave del proveedor y el consumo pasa a tu cuenta. Eso interesa a quien ya tiene contrato con un proveedor o necesita que los datos viajen por una cuenta concreta.

El crédito es una unidad de coste. El consumo se normaliza contra un modelo de referencia, así que un crédito significa aproximadamente el mismo trabajo sin importar qué modelo lo ejecutó. Es lo que impide que cambiar de modelo altere en silencio hasta dónde llega tu plan.

La corrección no la pagas tú. Cuando la verificación falla y el sistema corrige, esa ronda no se te cobra. La plataforma corrigiendo su propia salida no es un servicio prestado.

Cuándo vale la pena cambiar de modelo

En la mayoría de los casos no vale. Tres situaciones en las que sí:

Tienes contrato con un proveedor. La clave propia convierte un coste de plataforma en un coste que ya estás pagando.

Tienes exigencias sobre por dónde viajan los datos. Algunos contratos corporativos y algunas normativas lo piden, y es una exigencia legítima que el selector resuelve.

Estás generando algo poco común. Un dominio muy específico, un idioma poco representado, un formato inusual. Ahí, probar dos modelos con la misma petición responde más rápido que cualquier análisis.

Fuera de esas tres, cambiar de modelo optimiza la parte que no es el cuello de botella. El cuello de botella casi siempre es la claridad de la petición.

Lo que de verdad mejora el resultado

Si tu meta es una app mejor y no un experimento con modelos, este es el orden de retorno:

1. Describe mejor. La distancia entre una petición vaga y una específica es mayor que la distancia entre dos modelos de frontera. Di quién la usa, qué puede ver cada persona y qué tiene que pasar cuando alguien envía el formulario.

2. Pide por partes. Una petición grande produce una app grande y mediocre. Tres peticiones encadenadas producen una app que revisaste en tres puntos.

3. Comprueba contra la base de datos, no contra la pantalla. El mensaje de éxito es exactamente lo que también muestra un formulario roto.

4. Solo entonces, el modelo. Y probablemente descubras que no hacía falta.

El fin de elegir modelo

Esa es la dirección de toda la industria, y es buena: la elección de modelo es una decisión de infraestructura que se filtró hasta el usuario porque, durante un tiempo, la diferencia entre modelos era demasiado grande para esconderla. Se está encogiendo.

Lo que no se encoge es la diferencia entre un sistema que solo llama al modelo y un sistema que verifica lo que volvió. Ahí se decide hoy la calidad de una app generada, y es la parte que ningún proveedor de modelos entrega hecha.

En Fabapp el plan Free no pide tarjeta, que es la manera más barata de comparar eso con cualquier alternativa.