Constrói uma App Completa com Claude Code: Exemplos Reais

Um builder sem qualquer background em desenvolvimento de jogos lançou um jogo estilo GTA a correr em cidades reais do Google Earth num único fim-de-semana. O Claude escreveu cerca de 80% do código. O jogo puxa postos de polícia, aeroportos e portos reais do OpenStreetMap. O rádio do carro sintoniza automaticamente estações locais via Radio Garden API.

Não é uma demo. É uma waitlist ao vivo em cw.naveen.to.

O padrão por detrás dessa build, e de várias outras semelhantes, é específico e repetível. Este post percorre o que os bem-sucedidos fizeram e o que correu mal quando não o fizeram.

O que podes construir num fim-de-semana

Começa com três builds reais de abril de 2026. O alcance importa.

Naveen (@naveenvkt no X) lançou o Crimeworld: um jogo estilo GTA baseado no browser em cidades reais do Google Earth. Stack: Cesium, Google 3D Tiles, Three.js, Radio Garden API e dados do OpenStreetMap. Sem background em desenvolvimento de jogos. O Claude escreveu cerca de 80% do código. A build aconteceu num único fim-de-semana. É funcional, tem bugs em certos sítios, e tem uma waitlist ao vivo.

Santiago construiu o career-ops: um sistema de pesquisa de emprego com IA sem qualquer código de aplicação tradicional. O sistema completo são aproximadamente 3.200 linhas de ficheiros markdown de prompts. Catorze modos de skill vivem numa directoria modes/. O CLAUDE.md é a camada de orquestração. O sistema avaliou 740+ anúncios de emprego, gerou 100+ CVs optimizados para ATS, e conseguiu um cargo de Head of Applied AI. Usa processamento paralelo em batch com workers claude -p para sub-agentes. A revisão humana antes de cada submissão está incorporada no design. O sistema classifica empregos de A a F e recomenda não candidatar abaixo de 4,0/5. O código-fonte tem licença MIT em santifer/career-ops no GitHub.

Um terceiro builder sem background em finanças testou uma estratégia de contagem de carros em parques de estacionamento de fundos hedge usando imagens de satélite. Descreveu a hipótese em inglês simples: imagens ópticas de satélite de parques de estacionamento de retalhistas devem prever resultados financeiros. O Claude construiu todo o pipeline de análise a partir dessa descrição. Quando a abordagem óptica falhou com cerca de 33% de precisão, o builder descreveu uma nova hipótese em inglês simples: o radar reflecte de forma diferente em veículos metálicos e em asfalto. O Claude reconstruiu o pipeline do zero. O sistema final puxa dados ópticos Sentinel-2 e radar Sentinel-1 via Google Earth Engine, processa limites de parques de estacionamento do OpenStreetMap, e corre testes de permutação, testes binomiais e bootstrap resampling em 35+ scripts Python. O radar em três retalhistas atingiu 100% de precisão. Escalado para dez retalhistas caiu para 50%. A conclusão do builder: "the moat is data quality, not the algorithm." É o tipo de resultado honesto que se obtém quando se constrói para testar em vez de construir para provar.

Três domínios diferentes. Três backgrounds técnicos diferentes. Uma abordagem consistente. Todos descreveram o que queriam em inglês simples, dividiram o trabalho em partes e deixaram o Claude fazer a implementação.

Antes de escrever um único prompt

A spec vem primeiro. Sempre.

Orientação oficial da Anthropic para o Claude Code: deixa o Claude entrevistar-te antes de escrever qualquer código. Pede ao Claude que faça perguntas de esclarecimento sobre implementação técnica, UI/UX, casos extremos, constrangimentos e trade-offs. Escreve as respostas num ficheiro SPEC.md. Começa uma nova sessão para executar a partir dessa spec. O criador do WorthIt (um programador júnior num bootcamp, principalmente backend Java, sem experiência prévia em apps completas) descreveu assim: "prompts detalhados ganham sempre a prompts vagos, specs completas de produto, não 'build me a dashboard.'"

O CLAUDE.md não é documentação de projecto. Essa distinção importa mais do que a maior parte dos guias deixa transparecer.

O conselho padrão é preencher o CLAUDE.md com descrições do tech stack, convenções e notas sobre a estrutura de pastas. Esta abordagem tem um modo de falha real. Tudo no CLAUDE.md tem alta prioridade no contexto do Claude. Um CLAUDE.md inflado faz com que o Claude perca instruções específicas. Se o Claude continua a fazer algo que não queres apesar de uma regra que escreveste, o ficheiro está provavelmente demasiado longo e a regra está a ficar enterrada.

O uso mais poderoso do CLAUDE.md é como ficheiro de controlo de orquestração. Define workflows operacionais e padrões de delegação. Move a documentação do tech stack e as convenções de código para skills que carregam por demanda. Mantém o CLAUDE.md focado nas coisas que o Claude não consegue descobrir ao ler o teu código: comandos bash, convenções de naming de branches, instruções de teste, decisões arquitecturais que tomaste por razões não óbvias, peculiaridades do ambiente de desenvolvimento.

O teste oficial para cada linha no CLAUDE.md: remover esta linha levaria o Claude a cometer um erro? Se não, corta.

Usa /init para gerar um CLAUDE.md inicial a partir do teu codebase existente antes de escrever qualquer coisa do zero.

A hierarquia de prioridade de instruções para projectos estruturados é: CLAUDE.md (alta, sempre carregado) acima de directórios de regras (alta, filtrado por caminho) acima de skills (médio, carregado por demanda) acima de conteúdo de ficheiros (padrão, quando lido). O ponto óptimo para um projecto estruturado é entre 200 e 400 linhas de regras operacionais, não 60 linhas de trivialidades do projecto.

O SESSION.md é a outra peça que a maior parte dos builders salta. Mantém um ficheiro separado a registar o que foi feito, o estado actual, itens em aberto e ficheiros-chave modificados. Actualiza-o antes de terminar cada sessão. Começa novas sessões com "Resume project X." Regista porque decidiste implementar ou não implementar uma funcionalidade, com datas. O SESSION.md é o que torna o overflow de contexto um evento gerível em vez de algo que acaba com o projecto.

O processo de build de fim-de-semana

Cada build completa bem-sucedida usou o mesmo ritmo: uma funcionalidade por sessão, /clear entre funcionalidades.

O bleeding de contexto de funcionalidades anteriores causa suposições incorrectas e bugs subtis. Quando acabas uma funcionalidade e começas a seguinte, o Claude carrega suposições sobre o que estavas a fazer. Essas suposições estão muitas vezes erradas para a nova funcionalidade. O /clear reinicia o contexto e dá-te um estado inicial limpo.

Plan Mode antes de cada funcionalidade não trivial. Shift+Tab duas vezes ou /plan. O Claude pesquisa o teu codebase e descreve que ficheiros vai criar, que funções vai introduzir, que casos extremos existem. Revê e refina o plano antes da execução. Acrescenta sempre "List any assumptions" ao teu prompt de plano. As suposições que o Claude faz silenciosamente são de onde vêm os bugs.

O que entra num bom prompt:

Âmbito: o que esta funcionalidade faz e explicitamente o que não faz
Constrangimentos: que ficheiros estão fora de limites, que padrões seguir
Um ficheiro de exemplo: aponta para um ficheiro existente que segue a forma que queres
Critérios de sucesso: específicos, testáveis, não "make it work"

A peça dos critérios de sucesso vale a pena enfatizar. Em vez de "implement email validation," escreve "Write a validateEmail function. Test cases: user@example.com is true, invalid is false, user@.com is false. Run the tests after implementing." Sem critérios de sucesso, és tu o único feedback loop.

Revê sempre o diff antes de aceitar qualquer output. Verifica especificamente eliminações de ficheiros, renomeações de API públicas, alterações em ficheiros fora de limites, novas entradas em package.json e migrações de schema. O Claude pode renomear endpoints de API públicos em todo o teu codebase sem aviso. Todos os clientes que dependiam desses endpoints vão quebrar. O diff é onde o apanhas.

Gestão de contexto: a skill que separa boas builds de builds abandonadas

Perceber o que preenche a tua janela de contexto é o que separa builds que terminam de builds que se perdem em confusão.

A janela de contexto efectiva para o Claude Code é cerca de 200K tokens, mas aproximadamente 20K estão reservados para output de compactação. O auto-compact dispara quando restam cerca de 13.000 tokens. Um limiar de aviso aparece por volta dos 20.000 tokens. O compact manual fica bloqueado abaixo dos 3.000 tokens. Estes números vêm de análise do código-fonte do Claude Code.

Três comandos oficiais:

/clear: reinicia contexto entre tarefas não relacionadas. Após duas correcções falhadas no mesmo problema, para de tentar corrigir e usa /clear com um prompt inicial melhor.
/compact <instructions>: resume com foco personalizado. Exemplo: /compact Focus on the API changes mantém o contexto relevante e descarta o resto.
Esc + Esc ou /rewind: volta ao estado anterior ao que correu mal.

Para tarefas de investigação, usa sub-agentes. Corre-os em janelas de contexto separadas, faz-os reportar de volta sumários. A tua sessão principal mantém-se limpa. O padrão Writer/Reviewer funciona da mesma forma: usa uma sessão nova para rever código que a tua sessão principal acabou de escrever. Contexto novo apanha coisas que contexto cansado falha.

Três anti-padrões da documentação oficial:

A sessão kitchen sink: uma tarefa, depois algo não relacionado, depois de volta à primeira. O contexto enche-se com dados irrelevantes. Solução: /clear.

Corrigir repetidamente: abordagem falhada, corriges, ainda falha, corriges de novo. Após duas correcções no mesmo problema: /clear e escreve um prompt inicial melhor.

Exploração infinita: pedes ao Claude para "investigar" sem âmbito e ele lê centenas de ficheiros. O teu contexto enche-se de código que não precisas para esta funcionalidade. Solução: limita a investigação, ou usa um sub-agente.

O SESSION.md resolve o problema de memória a longo prazo. Após cerca de 30 mensagens, o Claude pode referenciar decisões que nunca foram tomadas, ficheiros que foram mencionados de forma diferente, ou código que foi modificado mais cedo na sessão. A sessão começa a confundir o que realmente aconteceu. SESSION.md como estado externo, combinado com /clear entre funcionalidades, impede que isto descarrile uma build.

Os modos de falha sobre os quais ninguém te avisa

Estão documentados, são específicos e todos têm origem em projectos reais.

Ficheiros fantasma. GitHub issue #26771 no repositório oficial do Claude Code: o Claude Code relata com toda a confiança a criação de ficheiros que nunca foram escritos para disco. O output da tool diz sucesso. O git status conta uma história diferente. As causas raiz incluem erros de permissão, falhas de resolução de caminho e tool calls perdidos. A solução é simples: verifica sempre com git status após operações em ficheiros. Não assumas que o ficheiro existe porque o Claude disse que existe.

Alucinação de métodos de API. O Claude gerou código usando prisma.$upload(). Esse método não existe no Prisma. Outros exemplos documentados: inventar opções de configuração (trustProxy como opção do rate-limiter), inventar nomes de pacotes que não existem no npm. A solução: corre os teus testes. Não assumas que o código gerado funciona porque parece razoável.

A armadilha do over-engineering. Um builder com 100+ sessões de histórico de projecto pediu ao Claude para corrigir um bug em que popups de aprovação às vezes não apareciam. A correcção proposta pelo Claude: guardar o estado de aprovação em disco para sobreviver a crashes. O problema: o agente retoma a frio a partir do log de sessão após crash, portanto o estado de aprovação não seria carregado de qualquer forma. Uma correcção completamente inútil que parecia boa engenharia. A pergunta a fazer antes de aceitar qualquer proposta complexa: este problema precisa mesmo de ser resolvido?

Renomeações silenciosas de API. O Claude renomeou endpoints de API públicos em todo um codebase sem aviso. Todos os clientes que dependiam desses endpoints quebraram. Solução: revê sempre o diff antes de aceitar. Verifica especificamente renomeações de API públicas e eliminações de ficheiros.

Layouts mobile. O Claude gera layouts desktop sólidos. As vistas mobile têm rotineiramente elementos sobrepostos, text overflow e espaçamento apertado. O Claude não tem mecanismo para testar em dispositivos reais. Solução: verifica cada layout num telemóvel real antes de marcar como concluído.

Falsas memórias de contexto. Após cerca de 30 mensagens, o Claude pode referenciar decisões que nunca foram tomadas, ficheiros que foram mencionados de forma diferente, ou código que foi modificado desde o início da conversa. A sessão começa a confundir o que realmente aconteceu. Solução: SESSION.md como estado externo, e /clear entre funcionalidades.

O problema dos 80/20

Podes ter 80% de uma app funcional num fim-de-semana. Os restantes 20% são onde a maioria dos projectos vibe-coded falha silenciosamente.

O que falha silenciosamente após a build inicial: conformidade com app stores, performance em dispositivos reais, segurança do fluxo de autenticação, decisões de arquitectura (sem testes, sem CI/CD), e casos extremos de lógica de negócio. Não é uma observação teórica. Uma empresa com milhões de utilizadores construída com aceleração de IA tinha cinco engenheiros a fazer code review de IA durante meses. A sua conclusão: "Even Claude plus a competent developer would look at this code and say 'yeah, that's fine.' It wasn't fine."

O builder do WorthIt fez um passe dedicado de hardening de segurança após o lançamento e encontrou lacunas na validação de input, tratamento de erros em falta e sem protecção XSS. A segurança não foi automática. A investigação da Columbia DAPLab identifica o tratamento de erros e a lógica de negócio como os padrões de falha silenciosa mais graves e comuns no código gerado por IA.

A solução prática: trata a segurança como parte de cada funcionalidade, não como um passo pós-lançamento. Faz um passe de segurança após cada funcionalidade major lançada. Verifica layouts mobile num dispositivo real antes de marcar qualquer coisa como concluída. Adiciona testes aos teus critérios de sucesso desde o início, não como reflexo tardio.

Não é um argumento contra construir com Claude Code. É um argumento para seres honesto sobre o que a ferramenta gere automaticamente e o que não gere.

A alternativa estruturada

As builds descritas acima são todas ad-hoc: uma pessoa, uma sessão do Claude Code, a construir funcionalidade a funcionalidade. Esta abordagem funciona e tem limites reais.

Os limites aparecem de forma previsível. A segurança não é automática. Os quality gates requerem disciplina para correr sempre. A infra-estrutura pós-lançamento (monitorização de erros, optimização de performance, scanning de segurança) tem de ser construída ou configurada separadamente para cada projecto. A armadilha do over-engineering e o problema dos ficheiros fantasma requerem vigilância manual.

O Build This Now é o que os melhores vibe-coders estão a construir para si próprios. Empacota a orquestração, os quality gates e a infra-estrutura pós-lançamento como um sistema pronto a usar. Os 14 comandos pós-lançamento (/security, /pentest, /performance, /audit) tratam do trabalho que os builders individuais descobrem que precisam após o lançamento. Row-level security em cada tabela de base de dados é o padrão, não um afterthought. Os agentes Quality Gate e Build Fixer apanham falhas que parecem completas no output do Claude mas falham na prática. O agente Planner separa as decisões arquitecturais da implementação, com três especialistas a analisar funcionalidades em simultâneo antes de qualquer código ser escrito.

A abordagem ad-hoc é gratuita e funciona para aprender. A abordagem estruturada é o que escala. buildthisnow.com tem os detalhes.

As builds de fim-de-semana acima não são casos excepcionais. São o que acontece quando especificas antes de fazer prompt, limpas o contexto entre funcionalidades, revês cada diff, e tratas a segurança como parte da build. O alcance vai de um clone de GTA no Google Earth a um sistema de pesquisa de emprego sem código de aplicação. As práticas que as fizeram funcionar são as mesmas.