Testinha: construí um app com IA em uma semana. E ainda precisei dos meus conhecimentos de dev

Criei o Testinha, um jogo de festa em português no estilo Heads Up: o celular vai na testa, a sala mostra a palavra e a inclinação resolve a vez. Do primeiro commit ao último foram seis dias (24 a 29 de outubro de 2026), 75 commits e muita IA no meio. Neste post eu conto o que usei, o que me surpreendeu e onde ainda precisei fazer o trabalho de desenvolvedora.

Quer testar? O Testinha está na App Store e no Google Play.

Do relatório de mercado à especificação

Antes de escrever qualquer linha de código, pedi para o Claude Opus olhar a App Store com a busca “heads up”. Ele leu os 11 apps da página de resultados (nove são jogos de charada) e os comentários de cada um. O relatório saiu com cinco reclamações que se repetiam:

1. Parece grátis e cobra. Gente que baixou achando que não pagaria e foi cobrada em assinatura semanal ou anual.
2. Anúncio demais. A queixa mais frequente no app com mais avaliações do grupo.
3. Não está em português, ou os temas não são do Brasil.
4. Assinatura difícil de cancelar, com pedidos de reembolso.
5. App parado. Um deles estava na mesma versão desde 2017.

Um limite honesto desse método: a loja mostra no máximo cerca de 10 comentários por app, então é uma amostra pequena. Serve para achar padrões, não para provar nada.

O relatório deu origem a uma especificação, também escrita pelo Claude Opus, com a skill tlc-spec-driven. Precisei ajustá-la, porque só com o que a IA escreveu ela não ia funcionar. As decisões ficaram registradas em um arquivo de estado, cada uma com motivo e trade-off. Uma delas, ainda no começo: o app é grátis, não tem anúncio, e a cobrança é compra única de cada tema pago, sem assinatura. Cada reclamação do relatório virou uma regra do produto.

A spec tinha um buraco: não dizia nada sobre como o app deveria parecer.

O que usei, peça por peça

Ferramenta	Para quê	Como foi
Claude Opus (com pesquisa na web)	Relatório dos apps de Heads Up e seus comentários	Rápido e útil, mas com amostra pequena de comentários
tlc-spec-driven (skill no Cursor)	Transformar o relatório em spec, design, tarefas e validação	Deu a espinha dorsal: tudo ficou registrado em arquivos do projeto
Cursor + Grok 4.7	Escrever o código a partir da spec	Entregou o que a spec pedia. Nada de extraordinário, nada de ruim
Figma	Redesenhar o layout a partir de prints, cores e referências	A parte que mais me impressionou
Expo (React Native) + TypeScript	O app em si	Base do projeto, com o mesmo código para iOS e Android
expo-iap	Compra única de cada tema pago	Funciona, mas só testa de verdade em build nativo, não no Expo Go
Módulo Swift com Apple Intelligence	Gerar palavras para categorias criadas pela pessoa, no próprio aparelho	Um módulo pequeno, com tratamento de aparelho sem suporte
Vercel	Catálogo de temas em JSON remoto	Tema, palavra e preço mudam sem versão nova do app
EAS Build e EAS Submit	Gerar o build e enviar para a loja	O deploy foi tranquilo

O Figma foi a surpresa

Sem layout na spec, o Cursor com Grok implementou o que conseguiu, e o resultado funcionava e estava péssimo. Era previsível: quando você não diz como quer, a IA escolhe por você.

Peguei os prints das telas que já estavam implementadas e levei para o Figma, junto com o que eu queria de layout, as cores e algumas referências. No primeiro prompt já veio um resultado muito satisfatório, bem acima do que eu esperava para uma primeira tentativa. A melhoria em layout e nos ajustes de animação foi visível de uma versão para a outra.

O Figma entrou depois, quando já existia algo rodando, e funcionou como um revisor de design. Num próximo app, eu colocaria essa etapa antes da implementação.

Precisou de ajuste? Precisou. O layout bonito não decide o fluxo do jogo nem a ordem das telas. Isso ficou comigo.

Onde a IA não chegou

O fluxo do jogo. O ponto mais crítico do projeto foi decidir de qual tela se vai para qual, e quais informações aparecem nos modos festa e infinito. No código isso aparece como mais de 15 fases de tela na mesma máquina de estados, e o histórico de commits mostra a briga: uma sequência de mudanças só em rodadas, modo infinito, placar por time, tela de resultado e tutorial, inclusive a remoção de uma etapa inteira que eu tinha aceitado antes.

A spec mostra o mesmo. Ela tem uma tabela de premissas com uma coluna “confirmado?”, e várias linhas ficaram como não confirmadas, porque eram decisões de produto que a IA só podia propor um padrão. Quem confirma é a pessoa que vai jogar o jogo.

O aparelho de verdade. O jogo depende de inclinar o celular, e isso só se valida direito na mão, com gente jogando. Sensibilidade, vibração, tempo da vez e o toque nas bordas da tela são coisas que o teste automatizado não sente.

O código, visto por uma desenvolvedora

Depois de pronto, fui ler o que a IA escreveu. Tem coisa boa e tem coisa que eu não manteria.

O que está bom

• A lógica do jogo está separada da interface, o que facilita testar.
• Há bastante teste automatizado, e o código passa na checagem de tipos sem gambiarras.
• As decisões de arquitetura estão documentadas no repositório, com motivo e trade-off.

O que eu não manteria

• Duplicação. Há duas versões de interface quase idênticas. A segunda parece a versão para tela larga, copiada em vez de adaptada.
• Arquivos enormes. Alguns passam de mil linhas, e o componente raiz concentra responsabilidades demais.
• Pastas misturadas. Componentes, regras e testes ficam lado a lado, sem organização por funcionalidade.
• Cores soltas. As mesmas cores aparecem repetidas em vários arquivos, sem um tema único.
• Pequenos sinais de IA: dois gerenciadores de pacotes no mesmo projeto.

Pontos que só uma pessoa que conhece loja pegaria. A spec falava só de iPhone, mas o app roda em iOS e Android, e a configuração do Android pedia permissões de gravação de áudio e de serviço em primeiro plano, num app que só toca um som curto. Permissão sensível sem uso é motivo de pergunta na revisão da loja. Um problema no build também me obrigou a bloquear a permissão ACTIVITY_RECOGNITION. A IA não avisou de nenhuma dessas coisas antes.

O que eu faria diferente, e o que fica

Se eu recomeçasse hoje, mudaria quatro coisas:

1. Colocaria o layout na spec desde o começo, ou faria o Figma antes da implementação.
2. Desenharia o fluxo de telas num diagrama antes de pedir código.
3. Escreveria na spec as regras de organização do código: pastas por funcionalidade, um tema único, nada de componente com mil linhas.
4. Revisaria cada entrega no aparelho e no diff, em vez de só aceitar.

A IA acelerou muito a parte de fazer: pesquisa, spec, código, layout e até um módulo nativo em Swift saíram em dias. Mas decidir o que o produto deve ser, validar no aparelho, enxergar o que a loja vai questionar e deixar o código em um estado que eu consiga manter continuam sendo trabalho de quem sabe desenvolver. Quem não sabe ler o que a IA escreveu fica refém dela.

Se você está construindo com IA, me conta nos comentários: onde ela mais errou no seu caso?