Construí meu site 100% com IA: o que deu certo e o que deu errado em 55 passos

Este site foi escrito inteiro por IA. Cada linha de código, cada componente, cada configuração de deploy. Levou 2 dias de execução, foi dividido em 55 passos e terminou com Lighthouse entre 99 e 100 em todas as páginas, medido em produção.

“100% com IA” não quer dizer que eu apertei um botão e o site apareceu. Quer dizer que eu não digitei o código. O resto (decidir o que construir, em que ordem, com qual cara, e dizer “não, isso está errado”) continuou sendo comigo. Este post é sobre essa divisão de trabalho, com os erros que aconteceram de verdade.

O método: um briefing, uma fila e um diário

A parte que mais fez diferença não foi o modelo de IA. Foi a estrutura em volta dele. Antes de qualquer código, escrevi três arquivos:

• CLAUDE.md: o briefing mestre. Stack, arquitetura, direção de design, modelagem de conteúdo e uma lista do que não fazer. A IA lê esse arquivo no início de toda sessão.
• PASSOS.md: a fila de execução. Cada passo tem um critério de “pronto quando” verificável, como “o build quebra com mensagem clara se faltar tradução”. A regra é executar só o primeiro passo pendente, nunca adiantar.
• DEVLOG.md: o diário. A cada passo concluído, a IA registra o que funcionou, o que precisou de correção, quantas tentativas levou e o que aprendeu. É de onde saem todos os números deste post.

Dois tipos de marcação na fila seguravam o processo:

• Checkpoint: a IA para e eu valido antes de seguir. Um a cada fase.
• Tarefa minha: coisas que a IA não deve ou não pode fazer, como criar o GitHub App, apontar o DNS ou cadastrar o primeiro case. Ela explica o passo a passo e espera minha confirmação.

Isso transformou “faça um site pra mim” em 55 tarefas pequenas, cada uma com começo, fim e um registro honesto.

A stack

O site usa Astro com Keystatic como painel de conteúdo, Tailwind CSS e deploy na Vercel. É a mesma stack que eu entrego em sites institucionais para clientes: o conteúdo fica em arquivos no próprio repositório, e o cliente edita tudo por um painel, sem banco de dados e sem CMS pago.

Por isso o painel não podia ser detalhe interno. Ele é mostrado ao vivo em reunião de venda. Labels em português, descrição em cada campo e ordem lógica foram tratados como parte do produto.

Os números

• Duração da execução: 2 dias (11 passos no primeiro, 44 no segundo)
• Passos concluídos: 55
• Resolvidos na primeira tentativa: 46 (84%)
• Lighthouse Performance (mobile, produção): 99 a 100
• Lighthouse Acessibilidade, Boas práticas e SEO: 100 em todas as páginas
• LCP em produção: 1,4 a 1,7 s

Usei três modelos da Anthropic pelo Claude Code: Opus nos 5 primeiros passos (setup e modelagem de conteúdo, onde um erro se propaga para tudo), Sonnet em 47 passos e Haiku em 3 passos simples, como varrer o código atrás de links de WhatsApp montados à mão.

O que a IA errou

Nove passos precisaram de mais de uma tentativa. Os erros têm um padrão, e vale conhecer.

Inventar coisas que pareciam existir. Em dois momentos a IA usou tokens de design que não existiam. O nome era plausível, seguia o padrão dos outros, só não estava definido. As verificações automáticas do projeto pegaram os dois.

Confiar em medição errada. A primeira rodada de Lighthouse deu Performance entre 53 e 73. O motivo: já havia um servidor de desenvolvimento rodando na porta, o servidor de produção não subiu, e o Lighthouse mediu o ambiente de dev, com JavaScript sem minificar. A nota real do build era acima de 90. Lição anotada no diário: sempre conferir a origem da página antes de confiar no número.

Erros que não dão erro. As imagens de compartilhamento (Open Graph) são geradas no build. Quando o layout estourava, a biblioteca não reclamava, só cortava a imagem. Foram três tentativas, e só olhando a imagem gerada deu para perceber.

Acidentes de terminal. Duas vezes um comando para encerrar o servidor de desenvolvimento acabou derrubando o próprio terminal da sessão. Sem dano, mas é o tipo de coisa que um humano experiente evita por reflexo.

Caminhos relativos. O caminho das imagens entre o painel e o Astro estava um nível errado. Esse eu já esperava: existia um passo só para validar isso antes de qualquer página depender dele.

O que a IA não resolveria sozinha

O erro mais difícil do projeto não era de código. No deploy, o login do painel falhava. O domínio sem “www” redirecionava para o domínio com “www”, então o GitHub devolvia o usuário para um endereço diferente do cadastrado. A IA diagnosticou certo, mas a correção estava no painel da Vercel e dependia de mim.

Decisões de projeto ou o rumo que ele deveria tomar a partir de certo obstáculo, onde teria que mudar alguma regra de negócio ou que conflitava com alguma diretriz.

O que eu faria igual (e o que mudaria)

Faria igual:

1. Escrever o briefing antes do código. Cada decisão que já estava escrita foi uma discussão a menos durante a execução.
2. Critério de pronto verificável. “Funciona” não é critério. “Sem JavaScript, todos os projetos continuam aparecendo” é.
3. Validar com um caso real cedo. Cadastrei um case de verdade e renderizei a página antes de construir a home. Assim o modelo de conteúdo foi aprovado antes de qualquer outra página depender dele.
4. Exigir o diário. Sem ele, este post não existiria, e eu não saberia que 84% dos passos saíram de primeira.

Mudaria: começaria o conteúdo (textos, números dos cases, depoimentos) bem antes. O código ficou pronto em 2 dias; o conteúdo é o que ainda está em andamento. A IA acelera muito a construção, mas não inventa a sua prova social. E nem deveria.

Para quem está pensando em fazer o mesmo

A IA escreve código bem e rápido. O que ela não faz é decidir o que importa para o seu negócio, notar que um número não tem fonte quando ninguém pediu para checar, ou saber que o seu cliente vai ver aquele painel numa reunião. Quanto melhor você define essas coisas antes, mais o resultado parece seu.

Se você quer um site institucional rápido, que você mesmo atualiza por um painel, é exatamente isso que eu entrego para clientes, com a mesma stack deste site.