Trabalhando com IA

A intuição comum é que mandar uma referência torna o resultado melhor. O efeito real é outro: ela torna o resultado previsível. Sem referência, o modelo escolhe entre milhares de caminhos plausíveis e tende ao mais comum — que é a média da internet. Com referência, ele escolhe perto daquilo.

A consequência prática é que uma referência ruim produz um resultado ruim com muita fidelidade. E que uma referência sem explicação vira ordem de cópia: ele reproduz inclusive o que era acidental, como a cor de fundo que você nem tinha reparado.

"Moderno", "clean", "elegante", "sofisticado", "profissional". Cada uma dessas palavras cobre milhares de resultados visuais diferentes. Quando o pedido é feito só de adjetivo, não há redução de escolha nenhuma — e o resultado cai no padrão.

É exatamente por isso que tanto material gerado por IA tem cara de template: não porque a ferramenta seja limitada, mas porque o pedido não decidiu nada.

RUIM
"Quero um visual moderno e elegante para um bar de drinks."
→ fundo escuro, dourado, foto de drink, serifada. O padrão.

BOM
"Fundo preto, marsala como única cor de destaque, tipografia
 didone nos títulos. A gramática visual é a de um cardápio:
 rótulo em caixa alta, linha pontilhada ligando nome e valor.
 Nada de dourado, nada de foto de banco de imagem."
→ cinco decisões fechadas, o resto aberto.

Repare que a segunda versão não é mais detalhada em tudo. Ela é específica em cinco pontos e silenciosa no resto — e é o silêncio deliberado que deixa espaço para a máquina resolver bem o que você não se importa.

As restrições dadas no começo do pedido pesam menos conforme a geração avança. Na oitava seção de uma página, a regra que a primeira seção respeitou pode simplesmente não ser aplicada.

O sintoma é característico: a seção final usa um espaçamento que não existe na escala, esquece o alt das imagens, inventa uma cor fora da paleta. Não é aleatório — é o efeito de distância.

Duas consequências: quebre o trabalho em partes, porque cada pedido novo reancora as regras; e repita a restrição crítica no fim do pedido, porque o começo e o fim são as posições de maior atenção, e o meio é onde se perde coisa.

Cada resposta tem um limite de tamanho. Uma landing page completa em arquivo único, com CSS e JS embutidos, chega fácil a 40–80KB — e páginas longas passam do teto.

O corte não é limpo nem avisado: vem HTML truncado, tag aberta, CSS pela metade. Você só descobre abrindo o arquivo.

Avaliar um resultado pronto e produzir um resultado do zero são tarefas diferentes, e a segunda é mais difícil. Na prática, um modelo aponta com facilidade problemas que não evitou enquanto escrevia — porque durante a escrita ele está ocupado produzindo.

Isso abre uma técnica barata e muito eficaz: pedir a autocrítica como passo separado.

"Liste três problemas com o que você acabou de escrever,
 do mais grave ao menos grave. Não corrija ainda."

Com frequência o terceiro item da lista é algo que você não teria notado sozinho. Só depois de ler a lista você decide o que mandar corrigir — e corrige um de cada vez.

Rabisco à mão, fotografado. A mais subestimada de todas. Um desenho tosco de caixas e linhas comunica hierarquia e ordem com precisão total e não contamina com estilo nenhum — porque não tem estilo. Um print de site, ao contrário, entrega layout e aparência grudados, queira você ou não.

Wireframe ou arquivo de design. Mesma função, mais preciso: medidas, proporções e espaçamentos reais. Use quando o layout já está decidido e você quer execução fiel em vez de interpretação.

Print de site, só pelo layout. Funciona, desde que você diga explicitamente o que ignorar: "quero a estrutura de seções, ignore cores e tipografia". Sem essa frase, vem tudo junto.

Paleta pronta. Cinco cores com o papel de cada uma — fundo, destaque, texto, superfície, apoio — eliminam a maior fonte isolada de resultado genérico. Só a lista de hexadecimais, sem os papéis, resolve menos.

Fonte nomeada. "Bricolage Grotesque no título, Source Serif no corpo" trava peso, personalidade e metade do clima numa linha.

Moodboard. Com uma imagem, ela é copiada. Com cinco, o que sobressai é o denominador comum — que costuma ser exatamente o que você quer e não sabe nomear. Funciona melhor com imagens visualmente variadas que compartilham um sentimento.

Referência fora da web. Capa de disco, embalagem, pôster de cinema, página de revista, rótulo de vinho, menu impresso, fachada. Como não é site, não existe "cara de site" para copiar — é preciso traduzir, e tradução gera coisa nova. Quase todo resultado com identidade real vem de uma referência assim, não de outro site do mesmo setor.

Gravação de tela. Nenhuma imagem parada comunica interação. Quinze segundos rolando a página de referência mostram o ritmo: o que aparece quando, o que é sutil, o que é chamativo. Se movimento importa no projeto, é a única referência que resolve.

GIF de um componente. Para uma coisa específica — o menu abrindo, o card virando — é mais eficiente que qualquer descrição.

Descrição de temporização. Sem arquivo nenhum: "quero o reveal quase imperceptível, não aquele que sobe cinquenta pixels" já direciona.

A copy real, mesmo crua. O design de uma página é quase todo determinado pelo texto que vai dentro dela. Um título de quatro palavras e um de dezoito pedem hierarquias diferentes. Quando o pedido vem com "lorem ipsum" ou "texto aqui", o layout é projetado para um texto médio imaginário — e depois nada encaixa.

As fotos reais. Se as fotos do cliente são verticais, mal iluminadas e sem sobra nas bordas, isso muda o layout inteiro. Projetar para foto horizontal profissional e receber foto de celular é retrabalho garantido.

Os números reais. Três drinks ou trinta? Dois depoimentos ou doze? A resposta decide se a seção é uma grade, um carrossel, ou se ela simplesmente não deveria existir.

Dizer o que não pode aparecer corta o espaço de possibilidades muito mais rápido que dizer o que pode. É a categoria com melhor relação entre esforço de escrita e efeito no resultado.

Contra-referência: "o site do concorrente X — não quero parecer com aquilo". Uma frase elimina uma região inteira.

Lista do proibido: sem gradiente roxo, sem ícone genérico de foguete, sem foto de banco de imagem, sem contador regressivo falso, sem seção de FAQ.

Restrição técnica: arquivo único, sem build, funciona com JavaScript desligado, só Google Fonts de externo. Não parece referência de design, mas é — ela elimina de saída toda solução que dependeria de biblioteca e força a resolver com CSS, o que costuma produzir resultado mais enxuto.

A analogia. "Quero que pareça um bar de hotel dos anos 30, não uma balada." "Quero que pareça consultório, não clínica popular." Carrega um mundo inteiro de convenções visuais junto, e funciona sem nenhum arquivo.

A pessoa concreta. Descrever quem vai abrir a página — "noiva de 28 anos, organizando o casamento pelo celular, à noite, cansada" — muda decisões reais de tamanho de fonte, contraste e quantidade de texto. É mais útil que "público A/B feminino 25-40".

Referência demais vira papa. Acima de quatro ou cinco, elas começam a se contradizer e o resultado tende à média delas — que é justamente o genérico que você queria evitar. Três com motivo valem mais que dez sem.

Referência sem motivo é ordem de cópia. Toda vez que mandar algo, junte uma frase dizendo o que ali interessa. É a diferença entre "faça assim" e "entenda isso e aplique".

1. O que a página precisa fazer — uma ação só. Se houver duas, escolha a principal e rebaixe a outra.
2. Quem chega nela, e de onde — tráfego de anúncio e tráfego de indicação pedem páginas diferentes.
3. O mundo concreto do negócio — objetos, termos e rituais daquele ofício.
4. As decisões já tomadas — paleta com papéis, tipografia, formato de entrega.
5. As referências, com o motivo de cada uma.
6. O que não pode aparecer.

Os itens 3 e 6 são os que quase todo brief pula, e são os dois que mais afastam do genérico.

Essa é a parte que quase ninguém usa e que mais muda o resultado. Descrever a categoria do negócio produz design de categoria. Descrever o material dele produz design daquele negócio.

A coluna da direita é material de design. Dela saem decisões que nenhuma referência de site produziria — a linha pontilhada de cardápio, a linha do tempo com semanas marcadas, a grade que lembra planta baixa.

Abaixo um brief de verdade, com o comentário do que cada bloco está fazendo.

Crie uma LP para Vanessa Carvalho, arquiteta em Campo Grande.
   └ quem, e onde. Define língua, referência cultural e escala.

Foco: reforma e interiores de apartamento, ticket R$ 8–25k.
   └ o ticket diz o nível de acabamento esperado da página.
     Serviço de 500 reais e de 25 mil não têm o mesmo visual.

Público: adultos querendo reformar um ambiente, querem confiança.
   └ "querem confiança" é estado mental, não demografia.
     Isso muda o que a página precisa provar.

Diferencial: acompanha a obra semanalmente e entrega
cronograma fechado.
   └ diferencial concreto e verificável, não adjetivo.
     Isso vira seção, não frase de efeito.

Paleta: #305546 primária (botões, títulos, footer)
        #567A6B secundária (hover, ícones, detalhes)
        #B7C5D1 apoio (fundos alternados, cards)
        #FFFCF7 fundo — não use branco puro
        #3F444D texto
   └ cor COM papel. "Não use branco puro" é uma
     restrição negativa valendo por si só.

CTA único: WhatsApp com mensagem pré-preenchida.
Sem formulário.
   └ uma ação, e a exclusão explícita da alternativa.

Entrega: HTML único autocontido, CSS e JS inline.
   └ restrição técnica: elimina toda solução com build.

Começa só pela hero.
   └ fatiamento. Provavelmente a linha mais valiosa
     do brief inteiro.

O que aumenta a qualidade é densidade de decisão, não volume de texto. Um brief de duas mil palavras cheio de frases que caberiam em qualquer projeto informa menos que duzentas palavras que fecham dez escolhas.

Um teste rápido: leia cada frase do seu brief e pergunte "isso poderia estar no brief de qualquer outro cliente?". Se puder, ela não está informando — está ocupando espaço e diluindo o que importa.

São três motivos independentes, e cada um sozinho já justifica fatiar.

O teto de saída. Página longa em arquivo único estoura o limite e vem truncada, sem aviso.

A deriva de atenção. As regras do começo pesam menos na oitava seção.

O custo de correção. Se a hero saiu na direção errada e a página inteira já foi construída em cima dela, corrigir significa regenerar tudo — e regenerar introduz variação nova nas partes que estavam certas. Uma seção por vez faz o erro custar uma seção.

Parte pequena demais também é ruim: pedir um botão por vez destrói o que importa em design, que é a relação entre as partes. Ritmo de espaçamento, hierarquia entre seções, alternância de fundo — nada disso existe dentro de um componente isolado.

O tamanho certo para o primeiro pedido é o sistema visual mais uma seção construída em cima dele:

• o bloco :root completo — cores com papel, escala de espaçamento, escala tipográfica, raio, transição
• as fontes carregadas, com os pesos definidos
• o reset e as classes base de botão, container e seção
• a hero inteira, usando apenas o que está acima

Depois disso cada seção nova é barata e sai consistente, porque as decisões já estão escritas no arquivo e são lidas em vez de reinventadas. Se você pedir só a hero sem o sistema, as decisões ficam implícitas e espalhadas no CSS dela — e na terceira seção começa a divergir.

O horizontal é um wireframe feito em código: todas as seções existindo, com texto real e visual cru. Fazer horizontal quando a dúvida era visual é desperdício, e o contrário também.

Numa ferramenta que edita arquivos no disco, o jeito de pedir decide se a edição é cirúrgica ou se o arquivo inteiro é reescrito. Reescrita é mais lenta, mais cara e introduz variação em partes já aprovadas.

VAGO  → pode reescrever tudo
"agora faça a seção de serviços"

PRECISO → edição pontual
"adicione a seção de serviços depois da hero,
 usando os tokens que já estão no :root.
 Não toque em nenhuma outra parte do arquivo."

Duas frases a mais que mudam completamente o custo da operação e protegem o que já estava certo.

Revisão feita junto com criação sai superficial, porque a atenção está ocupada produzindo. Como pedido separado, vira outra tarefa — ler o que existe com olhar crítico — e o resultado é bem melhor.

"Não escreva nada novo. Revise o arquivo e me diga o que
 está errado nestes pontos:
 - responsivo em 390px: algo estoura na horizontal?
 - contraste: todo texto atinge 4.5:1?
 - toda imagem tem alt descritivo?
 - title, description e og:image estão preenchidos?
 - prefers-reduced-motion está respeitado?
 - tem algum valor fora da escala de espaçamento?
 Liste os problemas. Não corrija ainda."

"Antes de escrever qualquer código, me diga em cinco linhas
 qual é o plano: paleta, tipografia, estrutura da hero e o
 que você vai assumir onde o brief não decidiu."

Se o plano estiver errado, corrigir custa uma frase. Se trezentas linhas já existirem, custa tudo de novo. E há um efeito colateral bom: um plano escrito antes gera código mais coerente do que decidir enquanto escreve.

"Me dê três direções possíveis para a hero, uma frase cada. Não escreva código ainda."

Três frases custam segundos e evitam construir a direção errada inteira. Funciona especialmente bem quando você não sabe o que quer mas reconhece quando vê — que é o estado mais comum no começo de um projeto.

Isso resolve dois problemas opostos: perguntas demais e suposições demais.

"Paleta e fonte estão travadas, não mude.
 Estrutura da hero, escala de espaçamento e microcopy são
 sua decisão — não pergunte, decida e me diga o que decidiu."

A segunda metade é a que importa: "decida e me diga o que decidiu" mantém você no controle sem travar o andamento.

Instrução negativa específica muda o comportamento mais que qualquer instrução positiva. "Meu medo é ficar com cara de template de arquiteta" faz evitar ativamente a região genérica. "Faça bonito" não faz nada.

Vale para qualquer eixo: "meu medo é o cliente achar caro demais pro que aparenta", "meu medo é ficar pesado no celular", "meu medo é parecer clínica popular".

Este é o ponto que mais economiza tempo no processo inteiro. Feedback vago faz o resultado oscilar: "não gostei, tenta de novo" provoca mudanças aleatórias, inclusive nas partes que você tinha aprovado. Aí você pede para voltar, e começa o vaivém.

Feedback que converge tem três partes: o que manter, o que está errado, e por quê.

OSCILA
"o texto tá estranho, arruma"

CONVERGE
"A estrutura e a paleta estão certas, mantenha.
 O título está grande demais em relação ao subtítulo —
 a hierarquia ficou desequilibrada.
 Reduza só o título."

Mude uma variável por vez. Se você pedir cor, tipografia e espaçamento no mesmo comando e o resultado piorar, não dá para saber qual das três causou. Em revisão visual isso pesa muito.

Diga o que não pode mudar. "Não toque na hero, ela está aprovada." Provavelmente a frase que mais economiza retrabalho em conversa longa — sem ela, partes fechadas são "melhoradas" de passagem.

Quando existe um teste objetivo, peça o teste em vez de confiar na aparência. A diferença é entregar pelo que parece certo e entregar pelo que foi checado.

• "Abra em 390px de largura e me diga se algo estoura na horizontal."
• "Calcule o contraste do texto #3F444D sobre o fundo #B7C5D1 e me diga o número."
• "Conte quantas imagens existem e quantas têm alt preenchido."
• "Rode o arquivo e me diga se o console acusa erro."

Quanto mais coisa acumula, mais decisões de momentos diferentes se misturam. O sintoma é característico: erro já corrigido reaparece, restrição que estava valendo é esquecida, o ritmo cai.

Quando isso acontece, corrigir mais não resolve — cada correção nova entra no mesmo acúmulo que está causando o problema.

O que resolve é recomeçar com um resumo, não com o histórico. Cinco linhas de estado valem mais que cinquenta mensagens — e vêm sem o ruído das tentativas que deram errado.

PROJETO: LP da Vanessa Carvalho, arquiteta, Campo Grande.
TRAVADO: paleta (#305546 / #567A6B / #B7C5D1 / #FFFCF7 / #3F444D),
         fonte X no título e Y no corpo, CTA único no WhatsApp,
         entrega em arquivo único com CSS e JS inline.
PRONTO:  hero e seção de serviços, aprovadas.
FALTA:   cronograma, prova, conversão, rodapé.
AGORA:   a seção de cronograma, usando os tokens existentes.

Um arquivo de contexto na raiz do projeto — em Claude Code, o CLAUDE.md — carrega sozinho em toda sessão. É a versão permanente do resumo acima, e é mais importante que qualquer skill: a skill descreve como trabalhar em geral, esse arquivo descreve este projeto.

O que vale estar nele: as decisões travadas, o padrão de entrega, o que já está aprovado e não deve ser tocado, e as convenções de nome que você usa.

Chamar a mesma coisa de "hero" hoje, "topo" amanhã e "banner" depois obriga a reinferir a cada pedido — e às vezes a inferência erra. Nomear as seções uma vez e manter deixa cada pedido seguinte mais curto e mais preciso.

Um conjunto que funciona para landing page: hero, prova, serviços, processo, conversão, rodapé. Qualquer conjunto serve, desde que não mude.

Uma skill é um brief permanente: em vez de redigitar as mesmas regras em todo projeto, elas viram um arquivo que carrega sozinho quando o assunto aparece.

O que funciona dentro dela, na ordem de retorno:

1. As invariantes. Arquivo único, CSS e JS inline, nenhum CDN além do Google Fonts, funciona com JavaScript desligado, nada inventado — tudo marcado [PREENCHER]. Objetivo, nunca muda, fácil de escrever.
2. Os mecanismos repetidos. O formulário que monta a mensagem do WhatsApp, o menu que vira sólido ao rolar, o reveal, a facade do vídeo. Colocar o código real desses blocos elimina a reescrita — e reescrita é onde entra variação indesejada.
3. As regras de arquitetura. "Seção sem objeção respondida não entra." "Sem depoimento real, a seção não vai ao ar." Julgamento codificado.

"No padrão do projeto X" transfere mais que três parágrafos de descrição, porque carrega junto todas as microdecisões. Vale manter um projeto seu como referência canônica, citá-lo por nome, e mantê-lo acessível — num repositório, numa pasta, dentro da skill.

É também o que faz seu trabalho ficar reconhecível ao longo do tempo, em vez de cada projeto ser uma reinvenção.

Saber onde a ferramenta é fraca vale mais que saber onde ela é forte — porque é onde você precisa olhar.

Peça uma landing page completa e, se nada impedir, ela virá com depoimentos, números de clientes atendidos, anos de mercado e selos de certificação. Tudo inventado, tudo verossímil, tudo pronto para ir ao ar.

Isso não é detalhe estético — é exposição real. Depoimento falso e número inventado no site de um cliente são publicidade enganosa, e quem publicou responde. Em algumas profissões é mais grave ainda: psicólogo não pode publicar depoimento nem promessa de resultado, e a regra vem do próprio conselho da categoria.

"Não invente nenhum dado. Todo número, depoimento, nome ou
 credencial que eu não tiver fornecido deve aparecer como
 [PREENCHER] no código e ser listado no final como pendência."

Foto. Imagem achada na busca não é livre por estar visível. Apontar direto para o servidor de outro site (hotlink) soma dois problemas: licença e a imagem sumir ou virar marca d'água sem aviso. Para material temporário de aprovação, o caminho seguro é banco com licença livre para uso comercial — Unsplash, Pexels — ou bloco de placeholder desenhado em CSS. Antes de publicar, foto real do cliente.

Fonte. Nem toda fonte bonita pode ser embutida num site comercial. Google Fonts resolve a maior parte sem custo nem dor de cabeça. Fonte paga exige licença de uso web, que é diferente da licença de desktop — e quem instala responde.

Layout. Pedir para reproduzir o site de alguém produz um clone, e clone traz dois problemas de uma vez: exposição jurídica e ausência de identidade. O cliente não quer o site do concorrente com outro logo — ele quer parecer melhor que o concorrente.

No código. A regra da Parte de segurança vale em dobro quando o código é gerado: tudo que está no front-end é público. Se a IA propuser colar uma chave de API no HTML para "facilitar a integração", isso vira credencial exposta no site do seu cliente. Chave de envio de e-mail, token de CRM, senha — nenhuma dessas pode existir no arquivo que vai pro navegador.

No chat. O que você cola no pedido sai do seu computador. Não vale colar senha, chave, token, contrato assinado, dado pessoal de terceiro nem base de clientes. Se precisar trabalhar com uma estrutura de dados, mande o formato com valores fictícios — funciona igual para o que você precisa.

LGPD. Se o site coleta qualquer dado pessoal — formulário, analytics com cookie, pixel de anúncio — existe obrigação de aviso e base legal. A responsabilidade formal é do cliente, mas quem instalou a tag foi você, e é você que vai ser chamado quando der problema. O caminho limpo é não instalar rastreamento sem o cliente pedir e saber, e deixar o ponto marcado no código para ele decidir. Vale lembrar que isto é orientação prática, não parecer jurídico — para caso concreto, advogado.

O cliente não contratou uma ferramenta, contratou você. Se a página tiver um número inventado, um contraste ilegível ou uma foto sem licença, o problema é seu — e a explicação "a IA que escreveu" não existe como defesa, nem comercial nem jurídica.

Na prática isso significa uma coisa simples: nada vai para o cliente sem você ter lido. Não reler porque "estava bom" é o atalho que transforma ganho de produtividade em risco acumulado.

[ ] Nenhum número, depoimento ou credencial inventado
[ ] Todo [PREENCHER] resolvido ou listado como pendência
[ ] Fotos com licença verificada
[ ] Nenhuma chave, token ou senha no código
[ ] Contraste conferido no texto principal
[ ] Testado em 390px de largura
[ ] Links de WhatsApp e âncoras funcionando
[ ] Ctrl+U: nada no fonte que você não queira público

Adicione a seção [NOME] logo depois de [SEÇÃO ANTERIOR].

Ela existe para responder: "[a objeção ou pergunta do
visitante que essa seção resolve]".

Conteúdo: [o que vai dentro].

Use os tokens que já estão no :root — não crie cor, medida
nem tamanho de fonte novo. Mantenha a alternância de fundo
em relação à seção anterior.

Não toque em nenhuma outra parte do arquivo.

As duas últimas linhas são o que diferencia uma edição pontual de uma reescrita do arquivo inteiro.

MANTENHA: [o que está certo — seja específico, não "o resto"].

MUDE: [uma coisa só].
POR QUÊ: [o efeito indesejado que ela está causando].

Não mexa em mais nada.

Se você tem três críticas, mande três comandos. Juntar as três num só impede saber qual mudança causou o quê — e é assim que uma revisão vira vaivém.

Tudo o que esta trilha diz sobre pedir — ação única, mundo concreto, o que não quer, o plano antes do código, uma mudança por vez — virou uma ferramenta que monta o pedido a partir das suas decisões e aponta o que está fraco antes de você mandar.

Ela mora agora na área de trabalho, junto das outras, porque é lá que se usa: o Gerador de comando tem onze tipos — landing page, direções, arquivo de contexto, recomeçar conversa, nova seção, texto da seção, animação, feedback, correção pontual, autocrítica e revisão final — e puxa nome, público, paleta e tipografia do que você já preencheu nas outras ferramentas.