O Iceberg do Vibe Coding: O Que Ninguém Te Conta Antes de Ir para Produção

Definição: Executar a mesma operação N vezes produz sempre o mesmo resultado da primeira execução.

O exemplo clássico: apertar o botão do elevador 50 vezes não faz ele chegar mais rápido. Se você deletar um usuário do banco, deletá-lo mais 49 vezes não vai gerar erro diferente — ele simplesmente não existe mais.

Na prática, seu sistema provavelmente está repetindo ações que só deveriam acontecer uma vez. Um endpoint bem construído pode ser chamado múltiplas vezes sem efeitos colaterais inesperados.

DELETE /users/42 → usuário deletado
DELETE /users/42 → retorna 404, sem crash, sem inconsistência

Definição: Detectar e ignorar requisições duplicadas para não processar a mesma coisa duas vezes.

Imagine um botão de pagamento. O usuário clica uma vez, o app demora para responder, ele clica mais duas vezes. Sem deduplicação, você gerou três cobranças. Isso acontece até em grandes e-commerces.

• No backend: usar um idempotency_key único por transação. Se a requisição chegar de novo com a mesma chave, ignorar.
• No frontend: desabilitar o botão assim que a primeira requisição for disparada, reabilitando apenas quando a resposta chegar.

Definição: Guardar o resultado de uma operação cara para reutilizá-lo sem refazer o trabalho.

O Google não varre a internet inteira a cada busca. Grande parte dos resultados já está em cache. O mesmo princípio se aplica à sua aplicação.

Se vários usuários fazem a mesma query pesada no banco de dados a cada segundo, você está jogando recursos fora. Com cache (Redis é a ferramenta mais comum para isso), você processa uma vez e serve o resultado salvo para as próximas requisições.

No contexto de IA, o prompt caching da Anthropic evita reprocessar um system prompt gigantesco a cada mensagem enviada ao agente — o que reduz latência e custo.

Quando usar: queries frequentes, resultados que não mudam a todo momento, respostas de APIs externas que você não controla.

Definição: Limitar quantas requisições alguém pode fazer em um período de tempo.

Sem rate limit, qualquer usuário mal-intencionado (ou até um loop acidental no código) pode bombardear sua API com milhares de requisições por segundo, derrubando o servidor.

A lógica é simples: sua portaria deixa entrar no máximo 10 pessoas por minuto no elevador. Chegou a 11ª? Espera o próximo ciclo.

HTTP 429 Too Many Requests
Retry-After: 60

Você define os limites conforme a necessidade da sua aplicação. 100 requisições por minuto por usuário é um ponto de partida razoável para muitos casos.

Definição: Ou tudo é executado com sucesso, ou nada é executado. Sem estado intermediário.

O exemplo mais didático é uma transferência bancária: debitar da sua conta E creditar na do destinatário. Se o crédito falhar depois do débito, o sistema deve fazer rollback — o dinheiro volta para a sua conta. Não existe dinheiro no limbo.

APIs falham. Não existe sistema com 100% de uptime — nem o WhatsApp, nem o Google. Se você não tratar suas operações como atômicas, em algum momento vai executar meia ação no seu sistema, gerando inconsistência de dados difícil de rastrear e corrigir depois.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- ou ROLLBACK em caso de erro

Definição: Tentar novamente após falha, esperando intervalos progressivamente maiores entre tentativas.

Se uma API falhou, você tenta de novo — mas não infinitamente e sem pausa. Se você ficar batendo na API a cada milissegundo sem esperar, você está fazendo um DDoS na sua própria infraestrutura.

O padrão correto é o backoff exponencial:

• Tentativa 1: falhou → espera 1 segundo
• Tentativa 2: falhou → espera 2 segundos
• Tentativa 3: falhou → espera 4 segundos
• Tentativa 4: falhou → espera 8 segundos

Existe um limite máximo de tentativas, após o qual você registra o erro e notifica.

Definição: Dois processos disputando o mesmo recurso ao mesmo tempo, gerando resultado inconsistente.

Imagine um sistema de venda de ingressos. Resta 1 ingresso. Dois usuários clicam "Comprar" ao mesmo tempo. Sem o tratamento adequado, ambos recebem confirmação de compra — e você vendeu o mesmo ingresso duas vezes.

Em auditorias de segurança de sistemas construídos com Vibe Coding puro, race conditions aparecem em 99% dos casos.

SELECT * FROM tickets WHERE id = 1 FOR UPDATE;
-- agora só você tem acesso a esse registro
-- outros processos esperam

Definição: Trazer dados em pedaços pequenos em vez de carregar tudo de uma vez.

O Google não exibe 10 milhões de resultados em uma única página. Ele pagina. Sua aplicação deve fazer o mesmo.

Se você tem uma tabela de logs com 100 milhões de registros e faz SELECT * FROM logs, você vai travar o banco, estourar a memória do servidor e deixar o usuário esperando para sempre.

GET /logs?page=1&limit=15
GET /logs?page=2&limit=15

Mesmo com poucos dados, uma arquitetura sem paginação pode mostrar problemas de performance se as queries forem mal construídas.

Definição: Validar e limpar todo input do usuário antes de usar. Nunca confiar em dado externo.

A IA gera código que funciona. Ela não necessariamente gera código seguro. Rotas sem autenticação, senhas em texto plano, cookies sem criptografia — tudo isso passa despercebido se você não rodar auditorias de segurança explicitamente.

Um campo de telefone que aceita texto em vez de só números parece inofensivo, mas abre espaço para SQL Injection se não for sanitizado:

Campo telefone recebe: DROP TABLE users;

• Validar tipo, tamanho e formato de todos os campos
• Sanitizar HTML para evitar XSS
• Nunca inserir input de usuário diretamente em queries SQL — use prepared statements
• Rodar múltiplas auditorias de segurança antes do deploy

Definição: Conseguir enxergar o que está acontecendo no sistema através de logs, métricas e traces.

Se você não tem monitoramento, está cego. Um erro em produção às 3 da manhã, sem logs, sem alertas — você só vai descobrir quando o cliente reclamar.

• Logs: registrar erros com contexto suficiente para diagnóstico (Sentry, Datadog)
• Métricas: acompanhar uso de CPU, memória, tempo de resposta (Grafana, New Relic)
• Traces: entender onde exatamente uma requisição travou e por quê

Para aplicações com agentes de IA, ferramentas como LangSmith permitem monitorar o que os agentes estão respondendo e como estão se comportando.

Com o trace você vê onde travou, por quê, e sabe exatamente qual linha de código está gerando o problema. Sem isso, seu tempo em produção está contado.