Quando Toda Mudança Pequena Tem Blast Radius
A primeira fase do vibe coding parece absurdamente produtiva. Cursor e Claude Code conseguem gerar login, dashboard, settings e push notifications rápido o bastante para que um founder sozinho coloque um MVP no ar em poucos dias.
O problema aparece na segunda ou terceira rodada de mudanças. Um ajuste pequeno em settings quebra o auth. Uma atualização de perfil bagunça as notifications. Os bugs parecem sem relação, mas o código não tem fronteiras impostas, então qualquer parte do app pode afetar qualquer outra.
Essa é a armadilha do vibe coding. Cursor e Claude Code são incríveis em gerar código que funciona. Eles não foram arquitetados para gerar código sustentável. Quando você pede ao Claude uma tela de settings, ele gera uma tela de settings. Ele não gera uma tela de settings que respeita suas fronteiras de service, segue o contrato de tema e valida os próprios inputs. Ele preenche o prompt. Você preenche a lacuna.
Por que o Vibe Coding Quebra em Escala
Quando você tem dez usuários, um edge case quebrado é uma DM pela qual você pode pedir desculpas. Quando tem mil, vira churn. Quando tem dez mil, vira uma indisponibilidade que ameaça a empresa. A mesma codebase que parecia mágica na fase de MVP vira algo assustador na fase de crescimento.
O desenvolvimento tradicional resolve isso com code reviews, ADRs e engenheiros seniores que dizem “não”. Mas, quando você está publicando com Cursor e Claude Code em velocidade 10x, não pode se dar ao luxo de ter um gargalo humano em cada loop de verificação. O gargalo anula o ganho de velocidade. Você precisa de algo mais rápido do que revisão humana, mas tão confiável quanto.
Restrições Declarativas: a Resposta
Guardrails: checagens determinísticas e declarativas que rodam em milissegundos. Elas não se cansam. Não perdem contexto. Não custam tokens. São o sistema imunológico arquitetural da sua app feita com vibe coding:
// These aren't suggestions. They're non-negotiable gates.
// They run on every commit. Human or AI code — doesn't matter.
1. TypeScript strict mode catches interface violations
- noUncheckedIndexedAccess
- exactOptionalPropertyTypes
2. ESLint catches architectural violations
- no className outside primitive seam
- import from barrels, not implementations
3. dependency-cruiser catches boundary violations
- Circular dependencies caught at commit time
- Never reach production
4. Pre-commit hooks run ALL checks before code lands
pnpm run verify → lint, typecheck, depcruise, test
If any check fails, the commit is blocked.
O Custo de Pular os Guardrails
Sem guardrails, código gerado por IA segue uma espiral previsível: gerar rápido, publicar rápido, quebrar rápido, depurar em pânico na produção, perder usuários, perder sono, perder confiança. Já vi times gastarem sprints inteiras consertando código gerado por IA que uma única regra de ESLint teria prevenido. O tempo que eles economizaram com vibe coding na primeira semana foi perdido dez vezes mais na décima.
Com guardrails, o ciclo muda: gerar rápido, validar rápido, publicar com segurança. Cursor e Claude Code continuam escrevendo o código. Os guardrails impõem as fronteiras. Você ganha velocidade de IA com segurança arquitetural.
Como São Guardrails Prontos para Produção
Em uma arquitetura React Native pronta para produção, guardrails fazem parte da fundação:
- TypeScript strict mode desde o primeiro dia, com
noUncheckedIndexedAccesseexactOptionalPropertyTypes - dependency-cruiser impondo fronteiras entre pastas e evitando dependências circulares
- ESLint bloqueando
classNamefora da costura dos primitivos de styling - Hooks de pre-commit rodando a suíte completa de verificação em todo commit
O resultado: código gerado por IA continua dentro dos limites. O Cursor gera componentes, telas e hooks em velocidade máxima. Mas não consegue violar fronteiras de service. Não consegue vazar mecanismos de styling. Não consegue criar dependências circulares. Os guardrails dizem o que é permitido. A IA preenche os espaços.
A Transição sem Atrito
O Autotomy Expo Starter Pack foi construído exatamente para essa transição:
- Interfaces de service definidas com barrel exports
- Composition root para gerenciamento de dependências
- Primitivos semânticos de UI com contrato de tema
- Fronteiras de dependências hard e opcionais
- Gerenciamento centralizado de lifecycle
- Validação de URL nas fronteiras de rota
- Guardrails determinísticos em pre-commit
- O padrão autotomy para refatoração segura
Você não para de fazer vibe coding. Você faz vibe coding em cima de uma fundação que escala. O Cursor gera telas contra o seu contrato de tema. O Claude Code gera features contra as suas interfaces de service. Seus hooks de pre-commit capturam violações de fronteira antes que elas cheguem à produção. Sua app cresce de dez usuários para dez mil sem o colapso arquitetural que mata a maioria dos projetos codados com IA.
Velocidade tem valor. Estrutura é o que torna velocidade sustentável. Se você está publicando um app React Native com Cursor e Claude Code, invista em guardrails antes de precisar deles. Eles são mais baratos do que refatoração e se pagam na primeira vez em que capturam uma breaking change no commit, e não na mão do usuário.