Vibe Coding: Transformando Código em Conversa com IA

O que “Vibe Coding” Significa (Sem o Hype)

“Vibe coding” é uma ideia simples: em vez de construir software escrevendo cada linha você mesmo, você o constrói por meio de uma conversa contínua com uma IA que propõe código, explica trade-offs e itera com você.

Você direciona com intenção (“faça esta página carregar mais rápido”, “adicione login”, “compatibilize com este formato de API”), e a IA responde com mudanças concretas que você pode executar, inspecionar e revisar.

Conversa em vez de especificação

Fluxos tradicionais costumam ser: escrever uma especificação detalhada → dividir em tarefas → implementar → testar → revisar. Isso funciona bem, mas pressupõe que você consegue prever o design certo desde o início e que escrever código é o principal gargalo.

Vibe coding desloca a ênfase para: descrever o objetivo → obter uma implementação inicial → reagir ao que você vê → refinar em pequenos passos. A “spec” não é um documento grande — é um diálogo em evolução pareado com saída funcional.

Por que isso está acontecendo agora

Três forças empurram essa mudança:

• Ferramentas ficaram boas o suficiente: pair programming com IA pode gerar rascunhos críveis, não só trechos.\n- Velocidade importa: times podem explorar opções rapidamente — diferentes padrões de UI, modelos de dados ou tratamento de casos de borda — antes de se comprometer.\n- Acessibilidade melhorou: mais pessoas conseguem prototipar e comunicar intenção de produto sem serem especialistas em programação.

Definindo expectativas

Vibe coding brilha quando você está explorando, prototipando, integrando padrões comuns ou polindo funcionalidades por micro-iterações rápidas. Pode enganar quando você tratar a saída da IA como “correta por padrão”, especialmente em segurança, desempenho e regras de negócio sutis.

A mentalidade útil é: a IA é um colaborador rápido, não uma autoridade. Você ainda é responsável pela clareza, restrições e por decidir o que significa “pronto”.

Da Especificação à Conversa: A Mudança Central

Especificações tradicionais são desenhadas para eliminar ambiguidade antes que alguém escreva código. Elas tentam congelar decisões cedo: campos exatos, estados exatos, casos de borda exatos. Isso pode ser útil — mas também assume que você já sabe o que quer.

Vibe coding inverte a sequência. Em vez de tratar incerteza como falha, você a trata como material para exploração. Você começa com intenção e deixa a conversa revelar as partes faltantes: restrições, trade-offs e momentos de “ah, não pensamos nisso”.

Specs removem ambiguidade; conversas a usam

Uma spec diz: “Aqui está o sistema.” Uma conversa pergunta: “O que o sistema deve fazer quando isso acontece?” Essa abordagem orientada por perguntas facilita descobrir requisitos que nunca apareceriam num documento — como quão rigorosa deve ser a validação, o que as mensagens de erro devem dizer, ou o que fazer quando um email já está em uso.

“Bom o suficiente para testar” vence “perfeito no papel” cedo

Quando a IA pode rascunhar uma implementação em minutos, o objetivo da primeira versão muda. Você não tenta produzir uma planta definitiva. Você tenta produzir algo testável: uma fatia fina que você pode clicar, executar ou simular. O retorno desse protótipo vira os requisitos reais.

A nova unidade de progresso: iterações e feedback

Progresso não é mais “terminamos a especificação.” É “executamos, vimos o comportamento e ajustamos.” A conversa produz código, o código produz evidência, e a evidência guia o próximo prompt.

Exemplo: “Quero um fluxo de cadastro” → passos → código

Em vez de escrever um PRD completo, você pode pedir:

• “Rascunhe um fluxo básico de cadastro com email + senha, validação e mensagens amigáveis.”\n- “Quais são os casos de borda? Faça uma checklist.”\n- “Implemente uma versão mínima que eu possa testar localmente e então sugira melhorias.”

Isso transforma um desejo vago em passos concretos — sem fingir que você já sabia todos os detalhes. O resultado é menos papelada inicial e mais aprendizado fazendo, com humanos guiando decisões a cada iteração.

Novos Papéis: Diretor, Editor e Implementador

Vibe coding não substitui “desenvolvedor” tanto quanto faz o trabalho parecer chapéus distintos que você veste — às vezes na mesma hora. Nomear esses papéis ajuda times a serem intencionais sobre quem decide o quê e evita que a IA vire a decisora silenciosa.

Diretor: define direção, restrições e gosto

O Diretor define o que você está construindo e o que significa “bom”. Não é só features — são limites e preferências:

• Objetivos: qual resultado o usuário deve alcançar
• Restrições: orçamento, metas de desempenho, stack, prazos
• Gosto: estilo, simplicidade, manutenibilidade, acessibilidade

Quando você age como Diretor, não pede à IA a resposta. Pede opções que se encaixem nas suas restrições e então escolhe.

Editor: molda, verifica e mantém coerência

O Editor transforma a saída da IA em um produto coerente. É aqui que o julgamento humano importa mais: consistência, casos de borda, nomeação, clareza, e se o código realmente corresponde à intenção.

Uma mentalidade útil: trate sugestões da IA como um rascunho de um colega júnior rápido. Você ainda precisa checar suposições, perguntar “o que esquecemos?” e garantir que isso se encaixa no resto do sistema.

Implementador: acelera as partes chatas

O papel do Implementador é onde a IA brilha: gerar boilerplate, ligar endpoints, escrever testes, traduzir entre linguagens ou produzir múltiplas abordagens rapidamente.

O maior valor da IA é velocidade e amplitude — propor padrões, preencher lacunas e fazer trabalho repetitivo enquanto você segura o volante.

Propriedade: humanos permanecem responsáveis

Mesmo se a IA escreveu 80% das linhas, humanos são responsáveis pelos resultados: correção, segurança, privacidade e impacto no usuário. Deixe isso explícito no fluxo de trabalho — quem aprova mudanças, quem revisa, quem faz o deploy.

Não deixe a IA virar a autoridade

Para manter a colaboração saudável:

• Peça trade-offs (“Quais são duas abordagens alternativas e seus riscos?”)\n- Solicite incertezas (“Quais suposições você está fazendo?”)\n- Verifique com a realidade (“Quais testes ou checagens provam que isso funciona?”)

O objetivo é uma conversa em que a IA produz possibilidades — e você fornece direção, padrões e julgamento final.

Como o Fluxo de Trabalho Muda: Micro-Iterações em vez de Grandes Planos

Vibe coding desloca a unidade padrão de trabalho de “terminar a feature” para “provar o próximo pequeno passo.” Em vez de escrever um prompt gigante que tenta prever todo caso de borda, você itera em loops curtos: pedir, gerar, testar, ajustar.

Micro-iterações: prompts menores, feedback mais rápido

Uma regra útil é ir de grandes solicitações iniciais para incrementos pequenos e testáveis. Peça uma única função, um único endpoint ou um estado de UI — não o módulo inteiro. Então execute, leia e decida o que mudar.

Isso mantém você próximo da realidade: testes que falham, erros reais de compilação e problemas concretos de UX são melhor guia do que suposições.

“Planejar primeiro, depois codificar” como loop padrão

Micro-iterações funcionam melhor quando você mantém um ritmo:

1. Planeje: defina o próximo incremento e os critérios de sucesso.

2. Codifique: peça à IA para gerar apenas o que corresponde ao plano.

3. Verifique: execute testes, lint e faça uma leitura rápida.

4. Refine: atualize o plano com o que aprendeu.

Se pular a etapa de planejamento, a IA pode produzir código plausível que se desvia da sua intenção.

Faça a IA reformular requisitos (e suposições)

Antes de escrever código, peça que a IA reformule requisitos e suposições com suas próprias palavras. Isso revela lacunas cedo: “Devemos tratar strings vazias como ausentes?” “Isso é síncrono ou assíncrono?” “Qual é o formato de erro?” Você pode corrigir a rota em uma mensagem em vez de descobrir desalinhamentos depois.

Mantenha um changelog leve da conversa

Como decisões acontecem por diálogo, mantenha um changelog leve: o que você mudou, por que mudou e o que deixou para depois. Pode ser uma seção curta na descrição do PR ou um arquivo de notas simples. O retorno é clareza — especialmente quando revisar a feature depois de uma semana ou passar para outra pessoa.

Se você usa uma plataforma de vibe-coding como Koder.ai, recursos como planning mode, snapshots e rollback podem tornar essas micro-iterações mais seguras: explorar rápido, criar checkpoints e desfazer experimentos sem perder ritmo.

Prompting como Pensamento de Produto: Fazer Perguntas Melhores

Vibe coding funciona melhor quando os prompts soam menos como “escreva uma função” e mais como “ajude-me a tomar uma boa decisão de produto.” A habilidade escondida não é uma redação esperta — é ser explícito sobre o que significa sucesso.

Comece com contexto, não instruções

Comece descrevendo a situação onde o código vai viver: objetivos, usuários, restrições e não-objetivos. Isso evita que o modelo preencha espaços com suposições que você não escolheu.

Por exemplo:

• Objetivo: reduzir abandono do checkout ao clarificar custos de frete\n- Usuários: mobile-first, alguns em conexões lentas\n- Restrições: deve caber no design system existente, sem novas tabelas de backend\n- Não-objetivos: redesenhar todo o checkout

Peça opções antes de pedir código

Antes de se comprometer com uma implementação, solicite múltiplas abordagens com prós/contras. Você não está só gerando código — está escolhendo trade-offs (velocidade vs manutenibilidade, precisão vs complexidade, consistência vs novidade).

Um padrão de prompt útil:

“Dê-me 3 abordagens. Para cada: como funciona, benefícios, riscos, o que eu precisaria verificar. Então recomende uma baseada nas minhas restrições.”

Use checklists para forçar completude

IA pode produzir saídas convincentes no caminho feliz. Contra-ataque pedindo que ela mesmo faça uma autoauditoria com um checklist: casos de borda, estados de erro, acessibilidade e desempenho. Isso transforma prompting em QA leve de produto.

MVP primeiro, depois polimento

Peça exemplos mínimos primeiro e então expanda. Comece com uma fatia fina que você pode executar e entender, depois itere: MVP → validação → polimento. Isso mantém você no controle e torna erros mais baratos de detectar cedo.

Controle de Qualidade Quando o Código é Sugerido, Não Redigido

Quando uma IA sugere código, parece menos “escrever” e mais “aceitar ou rejeitar” opções. Essa mudança é exatamente o motivo pelo qual controle de qualidade importa: código sugerido pode ser plausível, rápido e sutilmente errado.

Trate a saída da IA como um rascunho

Código gerado deve ser tratado como um primeiro rascunho de um colega que trabalhou rápido e não executou nada. Assuma que precisa de edições, verificação e alinhamento com suas convenções antes de entrar na base de código.

Use hábitos familiares de revisão de código

Execute sua checklist usual, mesmo que a mudança seja pequena:

• Legibilidade: a intenção está óbvia sem malabarismos mentais?\n- Nomes: variáveis e funções refletem o domínio, não a implementação?\n- Estrutura: lógica dividida em unidades coerentes, ou é um bloco longo?\n- Comentários: esclarecem o “porquê”, não repetem o “o quê”?

Se o código é difícil de ler, é difícil confiar — e mais difícil de manter.

Faça a IA se explicar

Antes de mesclar qualquer coisa, peça uma explicação em linguagem simples do que o código faz, suposições chave e edge cases que pode perder. Se a explicação for vaga ou evitar detalhes, esse é um sinal para desacelerar e simplificar.

“Mostre-me testes” vence “confie em mim”

Peça à IA para propor testes que provem o comportamento, não só a intenção:

• caminho feliz\n- casos de borda e entradas ruins\n- regressões para bugs já corrigidos

Mesmo testes leves forçam clareza. Se você não consegue testá-lo, você não o controla de verdade.

Regra rápida de aceitação

Aceite código sugerido somente quando você puder (1) explicá-lo, (2) executá-lo e (3) verificá-lo com testes ou checagens reproduzíveis. Velocidade é ótima — até que envie incerteza para produção.

Onde o Vibe Coding Falha: Limites e Modos de Falha

Vibe coding brilha quando você explora, prototipa ou itera sobre padrões bem entendidos. Falha quando a IA começa a “ajudar” preenchendo lacunas que você nem sabia que existiam.

Suposições ocultas (a falha mais silenciosa)

Sugestões da IA frequentemente contêm palpites não declarados: qual banco de dados você usa, como auth funciona, o que significa “usuário ativo”, ou qual tratamento de erro é aceitável. Essas suposições podem ser sutis o suficiente para parecerem razoáveis num diff — mas erradas para seu produto.

Um indício prático: se o código introduz novos conceitos que você não mencionou (um cache, uma fila, uma biblioteca específica), trate isso como hipótese, não como resposta.

Saídas convincentemente erradas

Modelos podem inventar APIs, flags ou métodos inteiros que não existem — especialmente com frameworks que evoluem rápido. O tom é persuasivo, o que pode enganar times a publicar ficção.

Formas de detectar rápido:

• Verifique cada chamada desconhecida contra a documentação oficial.\n- Procure por comportamento “mágico” sem configuração de suporte.\n- Pergunte à IA a fonte exata ou versão; se não souber, pare.

“Testes passam” não significa “usuários atendidos”

Uma IA pode otimizar para satisfação de testes enquanto perde necessidades reais: acessibilidade, latência, casos de borda ou regras de negócio. Passar nos testes pode só provar que você testou a coisa errada.

Se estiver escrevendo cada vez mais testes para justificar uma abordagem duvidosa, pare e reformule o resultado em termos de usuário em linguagem simples antes de continuar.

Quando parar de iterar

Parei de pedir ao chat e consulte a docs (ou um especialista humano) quando:

• Você lida com segurança, pagamentos, auth ou privacidade.\n- A correção requer múltiplos “pequenos ajustes” e nada estabiliza.\n- Você não consegue explicar o caminho do código de ponta a ponta após duas rodadas.

Vibe coding é uma conversa rápida, mas algumas decisões exigem uma resposta referenciada — não um palpite fluente.

Segurança, Privacidade e Propriedade Intelectual: Agindo com Responsabilidade

Vibe coding desloca muito pensamento para a janela de chat. Isso é útil — mas também facilita colar coisas que você normalmente não publicaria.

Uma regra simples ajuda: trate cada prompt como se pudesse ser logado, revisado ou vazado. Mesmo que a ferramenta prometa privacidade, seus hábitos devem assumir “compartilhável por acidente”.

O que nunca deve ser enviado a uma IA

Algumas informações são um “não” absoluto em prompts, screenshots ou logs copiados:

• Segredos: chaves de API, tokens, chaves privadas, certificados, links de reset de senha, códigos OAuth, segredos de assinatura de webhooks.\n- Dados pessoais: nomes ligados a identificadores, emails, telefones, endereços, dados de pagamento, documentos de identidade, informações de saúde.\n- Dados de clientes ou internos sensíveis: números de vendas, contratos, roadmaps, relatórios de incidentes com detalhes identificáveis.\n- Código fonte proprietário que você não pode compartilhar fora da organização (incluindo código de clientes).

Se tiver dúvida, assuma que é sensível e remova.

Prompting mais seguro com placeholders e redação

Você ainda pode obter ajuda sem expor dados reais. Substitua valores sensíveis por placeholders consistentes para que o modelo raciocine sobre a estrutura.

Use padrões como:

• API_KEY=REDACTED\n- user_email=\u003cEMAIL\u003e\n- customer_id=\u003cUUID\u003e\n- s3://\u003cBUCKET_NAME\u003e/\u003cPATH\u003e

Ao compartilhar logs, remova headers, query strings e payloads. Ao compartilhar código, remova credenciais e configs de ambiente e mantenha só o trecho mínimo necessário para reproduzir o problema.

IP, licenciamento e atribuição básica

Sugestões de IA podem incluir código que lembra exemplos públicos. Trate qualquer coisa que você não escreveu como potencialmente “emprestada.” Diretrizes práticas:

• Não cole grandes trechos de fontes com copyright nos prompts.\n- Seja cauteloso ao copiar snippets gerados para produção sem revisão — especialmente se parecerem funções de biblioteca ou implementações “perfeitas”.\n- Prefira docs oficiais e sua própria base como fontes de verdade.\n- Se sua equipe exigir, registre a proveniência (ex.: “rascunho assistido por IA”) nos PRs para que revisores apliquem escrutínio extra.

Uma política leve de equipe que funciona

Mantenha-a curta para que as pessoas a sigam:

1. Ferramentas permitidas (e em quais projetos podem ser usadas).\n2. Regras de redação (o que deve ser removido sempre).\n3. Expectativas de revisão (código gerado por IA tem os mesmos testes, checagens de segurança e revisão humana).\n4. Caminho de escalonamento para incerteza (perguntar ao security/legal ou a um responsável designado).

Uma página é suficiente. O objetivo é manter o vibe coding rápido — sem transformar velocidade em risco.

Padrões de Comunicação que Mantêm Humanos no Controle

Vibe coding funciona melhor quando o humano fica no “assento do piloto” e a IA é tratada como um assistente rápido e comunicativo. A diferença raramente é o modelo — são os hábitos de comunicação que previnem deriva, suposições silenciosas e expansão acidental de escopo.

Um objetivo por thread (e declare-o em voz alta)

Trate cada chat ou sessão como um mini-projeto. Comece com um objetivo claro e um limite. Se o objetivo mudar, abra uma nova thread para que o contexto não se confunda.

Por exemplo: “Adicionar validação client-side ao formulário de cadastro — sem mudanças no backend.” Essa frase dá uma condição limpa de sucesso e uma linha de parada.

Pequenos “resumos de decisão” após marcos

Após qualquer passo significativo — escolher uma abordagem, atualizar um componente, mudar uma dependência — escreva um resumo de duas a quatro linhas. Isso fixa a intenção e dificulta que a conversa desvie.

Um resumo simples deve responder:

• O que decidimos\n- Por que decidimos\n- O que faremos a seguir

Sempre peça um resumo final

Antes de mesclar (ou mesmo mudar de tarefa), solicite um recap estruturado. Isso é um mecanismo de controle: força a IA a expor suposições ocultas e te dá um checklist para verificar.

Peça por:

• Arquivos alterados (e por quê)\n- Comandos executados\n- Suposições feitas\n- Riscos / edge cases não tratados

Torne prompts parte do produto entregue

Se uma sugestão de IA influenciou o código, mantenha o “porquê” perto do “o quê.” Armazene prompts e saídas-chave junto aos PRs ou tickets para que revisores entendam a intenção e possam reproduzir o raciocínio depois.

Um template leve que você pode colar na descrição do PR:

Goal:
Scope boundaries:
Key prompts + summaries:
Recap (files/commands/assumptions):
Verification steps:

Esses padrões não te retardam — eles evitam retrabalho ao manter a conversa auditável, revisável e claramente de responsabilidade humana.

Impacto no Aprendizado e na Dinâmica do Time

Vibe coding desloca o aprendizado de “estude primeiro, construa depois” para “construa, depois estude o que acabou de acontecer.” Isso pode ser uma superpotência — ou uma armadilha — dependendo de como os times definem expectativas.

O que juniores ganham (e o que observar)

Para desenvolvedores juniores, o maior ganho é a velocidade de feedback. Em vez de esperar um ciclo de revisão para aprender que uma abordagem está errada, eles podem pedir exemplos, alternativas e explicações em linguagem simples na hora.

Bom uso parece com: gerar um pequeno snippet, perguntar por que funciona, e então reescrevê-lo em suas próprias palavras e código. O risco é pular essa etapa final e tratar sugestões como mágica. Times podem incentivar aprendizado exigindo uma nota curta “o que mudei e por quê” nos PRs.

O que seniores ganham (e como muda mentoria)

Engenheiros seniores ganham mais em boilerplate e busca de opções. IA pode rapidamente scaffolder testes, ligar código glue, ou propor múltiplos designs para comparar. Isso libera seniores para focar em arquitetura, casos de borda e coaching.

Mentoria também fica mais editorial: revisar as perguntas que juniores fizeram, as suposições embutidas nos prompts e os trade-offs selecionados — em vez de só o código final.

Riscos do time: atrofia de habilidade é real

Se pessoas param de ler diffs cuidadosamente porque “o modelo provavelmente acertou”, a qualidade da revisão cai e o entendimento fica raso. Com o tempo, depurar fica mais lento porque menos pessoas conseguem raciocinar pelos princípios.

Uma norma saudável é simples: IA acelera aprendizado, não substitui entendimento. Se alguém não consegue explicar uma mudança, não vai para produção — não importa quão limpo o output pareça.

Medindo o Sucesso: Como é “Bom” na Prática

Vibe coding pode parecer produtivo mesmo quando cria riscos silenciosos: intenção pouco clara, testes rasos ou mudanças que parecem corretas mas não são. Medir sucesso significa escolher sinais que recompensem correção e clareza — não só velocidade.

Comece com critérios de aceitação em linguagem comum

Antes de pedir uma solução à IA, escreva o que “feito” significa em termos cotidianos. Isso mantém a conversa ancorada em resultados em vez de detalhes de implementação.

Exemplos de critérios de aceitação:

• “Quando um usuário reseta a senha, ele recebe exatamente um email em até 60 segundos.”\n- “Se o provedor de pagamento estiver fora, o checkout mostra uma mensagem clara e não cobra o cliente.”

Se você não consegue descrever sucesso sem mencionar classes, frameworks ou funções, provavelmente não está pronto para delegar sugestões de código.

Trate checagens automáticas como placar

Quando o código é sugerido em vez de escrito linha a linha, checagens automáticas são sua primeira verdade. Um fluxo de vibe coding saudável aumenta a porcentagem de mudanças que passam nas checagens na primeira ou segunda micro-iteração.

Checagens comuns:

• Lint/format\n- Testes unitários e de integração\n- Verificações de tipo (quando aplicável)\n- Scans de segurança (dependências, segredos, SAST básico)

Se essas ferramentas faltam, métricas serão majoritariamente vibes — e isso não se sustenta.

Acompanhe resultados, não só produção

Indicadores úteis são visíveis em hábitos do time e estabilidade em produção:

• Menos regressões após releases (e identificação de causa mais rápida)\n- Tempo de ciclo menor de pedido de mudança pequena → PR mesclado\n- PRs mais claros: descrições melhores, critérios de aceitação vinculados e diffs legíveis

Se PRs ficam maiores, mais difíceis de revisar ou com “mistério”, o processo está escorregando.

Adicione regra de “sign-off humano” para mudanças de alto impacto

Defina categorias que sempre exigem aprovação humana explícita: auth, pagamentos, deleção de dados, permissões, configurações de segurança e lógica central de negócio. A IA pode propor; uma pessoa deve confirmar intenção e risco.

“Bom” na prática significa que o time entrega mais rápido e dorme melhor — porque a qualidade é medida continuamente, não assumida.

Um Playbook Prático Inicial para Vibe Coding

Vibe coding funciona melhor quando você o trata como um processo leve de produção, não um chat que “de algum jeito” vira software. O objetivo é manter a conversa concreta: escopo pequeno, critérios claros de sucesso e verificação rápida.

1) Comece pequeno e defina “feito” desde o início

Escolha um projeto que dê para terminar em um ou dois dias: uma pequena ferramenta CLI, um widget interno simples no dashboard, ou um script que limpa um CSV.

Escreva uma definição de feito que inclua resultados observáveis (saídas, casos de erro e limites de desempenho). Exemplo: “Processa 10k linhas em menos de 2 segundos, rejeita linhas malformadas, gera um JSON resumo e inclui 5 testes.”

2) Use um template padrão de prompt (e reaproveite)

Uma estrutura repetível reduz deriva e facilita revisões.

Context:
- What we’re building and why

Constraints:
- Language/framework, style rules, dependencies, security requirements

Plan:
- Step-by-step approach and file changes

Code:
- Provide the implementation

Tests:
- Unit/integration tests + how to run them

Se quiser um guia mais profundo sobre estrutura de prompts, mantenha uma página de referência para o time (ex.: /blog/prompting-for-code).

3) Adicione uma checklist de revisão desenhada para código sugerido por IA

Use isso após cada iteração:

• O código bate com a definição de feito (não só “parece certo”)?\n- Entradas validadas e erros tratados claramente?\n- Chamadas de rede, telemetria ou dependências inesperadas?\n- Existe um teste simples que falharia se o comportamento estiver errado?\n- Um colega consegue explicar a mudança em 60 segundos?

4) Mantenha iterações apertadas

Peça a próxima menor mudança (uma função, um endpoint, um refactor). Após cada passo, rode testes, confira diffs e só então solicite a próxima iteração. Se a mudança crescer, pause e reafirme restrições antes de continuar.

Se a meta é tornar esse fluxo repetível no time, ajuda usar tooling que incorpore guardrails: Koder.ai, por exemplo, pareia construção orientada por chat com um fluxo de planejamento estruturado e recursos de entrega práticos como exportação de código e deploy/hosting — assim a “conversa” permanece conectada a software executável em vez de virar um amontoado de snippets.