Qual modelo de IA usar para gerar um app

Por que não existe um vencedor

Um build completo passa por etapas que não se parecem entre si:

Planejar é decidir o que construir a partir de um pedido ambíguo. Pede raciocínio e tolera latência: vale esperar dez segundos por uma decisão que evita meia hora de trabalho errado.

Gerar é escrever muitos arquivos que seguem regras conhecidas. Pede vazão e obediência ao formato, e é a etapa onde o modelo mais caro entrega quase o mesmo que o mais barato.

Consertar é ler um erro de compilador e mudar o trecho certo. É a etapa mais sensível a raciocínio de todas, porque um conserto errado quebra o que estava funcionando.

Revisar o que foi feito é comparar código contra um critério escrito em português. É leitura, não escrita, e um modelo pequeno faz bem.

Revisar as telas exige visão. Não é preferência: um modelo sem visão simplesmente não pode olhar a captura de tela e dizer que o texto estourou o card.

Um modelo que ganhasse em todas as cinco seria uma coincidência. Na prática, o que ganha é o sistema que usa um modelo diferente em cada uma.

O que os benchmarks medem, e o que não medem

Os números que circulam vêm quase todos de benchmarks de engenharia de software: dado um repositório existente e um defeito relatado, o modelo produz um patch que faz o teste passar.

É uma medida boa, e mede outra coisa. Gerar um app do zero tem três diferenças que o benchmark não captura:

Não existe repositório para entender. Metade da dificuldade do benchmark é localizar onde mexer num código que o modelo nunca viu. Numa geração, esse problema não existe, e o que aparece no lugar é a coerência entre trinta arquivos que nascem juntos.

Não existe teste para passar. No benchmark, o critério de sucesso é objetivo e já está escrito. Num app novo, o critério é o que a pessoa pediu, em linguagem natural, provavelmente incompleto.

Nada mede se ficou bonito. Um app que compila e é feio reprova com o usuário e passa em qualquer benchmark.

Conclusão prática: use benchmark para descartar um modelo que vai mal em código, nunca para escolher entre os dois primeiros colocados.

As famílias, e para que servem

Sem citar versões, porque elas mudam mês a mês e a página envelheceria antes de você chegar aqui.

Modelos de raciocínio. Pensam antes de responder, gastam mais tokens e mais tempo, e acertam decisões que os outros erram. Valem nas etapas de decisão: planejar, e consertar depois que um conserto simples já falhou.

Modelos rápidos. Uma fração do preço, boa parte da qualidade em tarefas com regra clara. É onde a maior parte do volume de um build deve rodar, porque a maior parte de um build é mecânica.

Modelos com visão. Necessários para qualquer coisa que envolva olhar o resultado renderizado. Sem isso, não existe revisão visual, só revisão de código.

Modelos abertos. Fecharam boa parte da distância em geração de código e cobram bem menos. São a razão de o custo por app ter caído tanto em dois anos.

Como a Fabapp resolve isso

Somos parte interessada, então o que segue é descrição, não recomendação. Julgue pelo que dá para verificar abrindo a plataforma.

Um catálogo, não um modelo. A plataforma mantém um catálogo de modelos de vários provedores, cada um com o custo por mil tokens derivado do preço público do provedor. É esse catálogo que permite mudar qual modelo roda qual etapa sem mexer no código do produto. O que mais a plataforma faz está em recursos.

A etapa escolhe, não você. Por padrão, cada etapa do build usa o modelo adequado a ela: planejamento e conserto em modelos mais fortes, geração em modelos de vazão, revisão de aceite em modelo pequeno, revisão visual em modelo com visão. Você não precisa saber nada disso para construir um app.

Você pode escolher assim mesmo. O seletor de modelo existe, e a chave própria também: a partir do plano Builder você conecta a sua chave do provedor e o consumo passa a ser da sua conta. Isso interessa a quem já tem contrato com um provedor ou a quem precisa que os dados trafeguem por uma conta específica.

O crédito é uma unidade de custo. O consumo é normalizado contra um modelo de referência, então um crédito significa aproximadamente o mesmo trabalho independentemente de qual modelo executou. É o que impede que trocar de modelo mude silenciosamente quanto rende o seu plano.

A correção não é sua. Quando a verificação reprova e o sistema conserta, essa rodada não é debitada de você. A plataforma corrigindo o próprio erro não é serviço prestado.

Quando vale mexer no modelo

Na maioria dos casos, não vale. Três situações em que vale:

Você tem um contrato com um provedor. Chave própria transforma um custo de plataforma num custo que você já paga.

Você tem exigência de onde os dados passam. Alguns contratos corporativos e algumas legislações pedem isso, e é uma exigência legítima que o seletor resolve.

Você está gerando algo fora do comum. Domínio muito específico, idioma pouco representado, formato incomum. Aí testar dois modelos no mesmo pedido responde mais rápido que qualquer análise.

Fora dessas três, mexer no modelo é otimizar a parte que não é o gargalo. O gargalo quase sempre é a clareza do pedido.

O que realmente melhora o resultado

Se a sua meta é um app melhor, e não um experimento com modelos, a ordem de retorno é esta:

1. Descreva melhor. A diferença entre um pedido vago e um pedido específico é maior que a diferença entre dois modelos de ponta. Diga quem usa, o que cada pessoa pode ver, e o que precisa acontecer quando alguém envia o formulário.

2. Peça em pedaços. Um pedido grande produz um app grande e mediano. Três pedidos encadeados produzem um app que você conferiu em três pontos.

3. Confira contra o banco, não contra a tela. A mensagem de sucesso é exatamente o que um formulário quebrado também mostra.

4. Só então, o modelo. E provavelmente você vai descobrir que não precisava.

O fim da escolha de modelo

A direção da indústria inteira é essa, e ela é boa: a escolha de modelo é uma decisão de infraestrutura que vazou para o usuário porque, por um tempo, a diferença entre os modelos era grande demais para esconder. Ela está encolhendo.

O que não encolhe é a diferença entre um sistema que só chama o modelo e um sistema que verifica o que voltou. É onde a qualidade do app gerado é decidida hoje, e é a parte que nenhum provedor de modelo entrega pronta.

Na Fabapp, o plano Free não pede cartão, e é o jeito mais barato de comparar isso com qualquer alternativa.