Guardrails no vibe coding: o que proibir na primeira entrega

O plano da primeira tela do Fumava proibia gradiente, emoji, tela de tutorial e biblioteca nova. Mesmo assim veio fundo texturizado, e Martin teve que olhar e dizer não.\n\nGuardrails são as proibições que você escreve no prompt antes de pedir ao agente que execute. Elas existem para roubar do agente a possibilidade de escolher pelo caminho mais bonito, mais complexo ou mais arriscado, quando o que você precisa agora é simples, seguro e rápido.\n\nMartin começou o Fumava com essas guardrails bem definidas: nada de gradiente na primeira tela, porque gradiente custa performance. Nada de emoji, nada de tutorial, nada de biblioteca nova. Tudo que reduzisse o escopo.\n\n## A regra escrita não vira regra executada sozinha\n\nO agente leu o prompt, entendeu o que devia fazer, e entregou uma tela. Martin olhou e percebeu que tinha fundo texturizado, uma coisa que não estava explicitamente proibida.\n\nUm fundo texturizado é basicamente o avó de um gradiente: começa simples e fica complexo se você deixar. Martin viu o padrão começar e parou:\n\n> Aí eu fui conversando com o agente: \"Olha, isso aqui ficou muito complexo pra primeira tela. Vamos simplificar.\"\n\nEle não tinha escrito \"nada de texturas\" no prompt. Percebeu só de olhar. E com essa observação em voz alta, ele adicionou um guardrail novo à conversa que não estava no prompt escrito.\n\n## As guardrails devem cobrir a intenção, não só a letra\n\nO que Martin estava proibindo não era um efeito específico, era a ideia de complexidade onde tinha que ter simplicidade. Gradiente, emoji, tutorial, biblioteca, textura — tudo aquilo virava mais peso na primeira entrega.\n\nA regra genérica por baixo dessas proibições é: máxima simplicidade na primeira tela. Com ela escrita só dessa forma, o agente teria tido espaço para criatividade e teria chegado com texturas. Com o guardrail genérico seguido de exemplos específicos, o agente consegue replicar o padrão também para coisas que Martin não listou.\n\nEssa prática aparece também em prova de que a tarefa foi feita no vibe coding, onde Martin reescreve o critério depois de ver o artefato, e em criação de conta de desenvolvedor Google Play, onde ele avalia o caminho depois de tentar e volta por outro mais rápido. Está também em vibe coding para começar do zero sem ideia, em vibe coding para copiar onboarding de concorrente, em estimativa no vibe coding, e em como usar vibe coding para planejar antes de delegar, onde Martin travou o paralelismo para fechar o escopo primeiro.\n\n## Guardrails não é censura, é economia\n\nMartin não estava pedindo ao agente que respeitasse limites por limites. Estava pedindo foco. Uma primeira tela que roda rápido é a prova de que o app funciona, e é isso que vai dar moral para pedir segundo, terceiro. Se a primeira tela sair pesada por causa de textura, gradiente ou coisa que o agente achou que ia ficar bacana, vai dar trabalho depois desfazer.\n\nAs guardrails economizam ida e volta. É assim que o vibe coding funciona na prática. Elas dizem ao agente: \"Aqui nós queremos A, não B\", e eliminam uma classe de riscos que você teria que revisar depois de cada entrega.\n\nNa vida real de quem faz vibe coding, as guardrails mais úteis são as que você escreve antes de começar, e as que você aprende a adicionar olhando a primeira entrega. Martin fez as duas.\n\nDá para assistir à live e ver o construtor em ação, revendo cada tela, falando o guardrail em voz alta quando o agente o cruza, e voltando a pedir a mesma tela com a regra revisada."