Os 4 pilares do Vibe Coding destrinchados pra não-dev: vibes, specs, skills, agents

Vibe Coding tem quatro pilares: Vibes (o briefing que vc dá pra IA), Specs (a especificação do que vc quer construir), Skills (comportamentos reutilizáveis) e Agents (subagentes especializados). Sem entender os quatro, vc vai ficar no ciclo de “gerei, não funcionou, joguei fora”.

Eu ensino Vibe Coding no G4 Educação há alguns meses e o padrão de quem trava é sempre o mesmo. A pessoa abre o ChatGPT ou o Claude, manda uma mensagem tipo “cria um sistema de onboarding pra mim” e recebe algo genérico demais pra usar. Aí conclui que IA não funciona pra isso. Não é que não funciona. É que tá faltando estrutura.

Por que Vibe Coding fracassa sem estrutura (o erro do iniciante)?

O erro mais comum é tratar a IA como se ela fosse um funcionário que já sabe tudo sobre a sua empresa, o seu cliente, as suas restrições. Ela não sabe. Você precisa criar o contexto antes de pedir o resultado.

O segundo erro é pular direto pra implementação sem especificar o que vc quer. Tipo pedir pra um arquiteto construir uma casa sem planta. Ele até constrói, mas provavelmente não é o que vc queria.

O terceiro erro é não documentar o que funcionou. Cada vez que vc explica do zero é retrabalho. E no Vibe Coding, retrabalho acumulado mata a produtividade que a ferramenta devia gerar.

Os quatro pilares resolvem exatamente esses três problemas. Vamos um por um.

Pilar 1: Vibes: o briefing que muda tudo

Vibes não é o estilo da resposta. Vibes é o conjunto de contexto que vc dá pra IA antes de fazer qualquer pedido. É o briefing.

Um bom briefing tem quatro partes. Primeira: persona, quem você é e o que você faz. “Sou Eric, CEO da Expert Integrado, empresa de software e educação em IA pra PMEs.” Segunda: objetivo, o que você quer construir e por quê. “Quero automatizar o onboarding de novos clientes pra reduzir o tempo da equipe de CS.” Terceira: constraints, o que não pode ter. “Não pode depender de Zapier, não pode custar mais de R$ 200/mês, precisa funcionar com WhatsApp.” Quarta: exemplos, o que vc acha bom. Manda um print, um link, descreve um sistema parecido que vc usa.

Quando eu começo uma sessão no Claude Code com esse bloco de contexto, a qualidade do output é outra. O modelo sabe quem é o cliente, qual o tamanho da empresa, quais as restrições técnicas. A resposta deixa de ser genérica e vira algo que eu consigo usar no dia seguinte.

Na prática, eu guardo as Vibes em arquivos .md dentro do projeto. O Claude Code lê automaticamente o CLAUDE.md na raiz de cada repositório. Então eu coloco lá: quem somos, o que esse projeto faz, quais as regras que nunca podem ser quebradas. Isso funciona como memória persistente entre sessões.

A regra prática: se vc abrir uma conversa nova e a IA não saber nada sobre você, você esqueceu as Vibes.

Pilar 2: Specs: como escrever uma especificação que a IA entende

Spec é a especificação funcional em linguagem natural. É o documento que descreve o que o sistema faz antes de escrever uma linha de código.

Muita gente pula essa etapa. O resultado é o clássico “funciona, mas não é bem isso”. Vc fica em loop de “muda aqui, muda lá, agora quebrou outra coisa” e no final reescreveu tudo três vezes.

Uma boa Spec tem: o que o sistema faz (em uma frase), quais as entradas (o que entra), quais as saídas (o que sai), os estados possíveis (o que pode dar errado), e as regras de negócio (o que nunca pode acontecer). Não precisa de linguagem técnica. Precisa ser específico.

Exemplo real: quando a gente construiu o módulo de tarefas do Expert Brain, a Spec dizia: “O sistema recebe uma tarefa em texto livre, extrai data, prioridade e contexto, salva no banco e retorna confirmação. Se não tiver data, salva sem prazo. Se o usuário enviar via WhatsApp, o formato de confirmação precisa ser texto simples, sem markdown.” Esse parágrafo economizou pelo menos duas horas de retrabalho.

O Claude Code lê a Spec antes de escrever. Vc pode colocar num arquivo spec.md no projeto, ou mandar inline no início da conversa. O que não pode é improvisar a especificação enquanto o código já está sendo escrito.

Faz sentido? Spec é o mapa antes da viagem. Sem ela, vc chega num lugar que não era o destino.

Pilar 3: Skills: transformando o que funciona em hábito replicável

Skills são pedaços reutilizáveis de comportamento. Pense como macros, só que pra raciocínio e processo, não só pra clique de botão.

No Claude Code, uma Skill é um arquivo .md que descreve um fluxo: quando executar, quais passos, o que verificar antes de terminar. Quando vc digita /triagem-matinal, o Claude sabe exatamente o que fazer: abre os emails, filtra pelo critério definido, cria um resumo no formato que vc pediu, propõe as respostas prioritárias.

Eu tenho hoje mais de 40 Skills ativas. Algumas que uso todo dia: triagem-matinal (processa emails e WhatsApp da manhã), onboarding-cliente-ganho (dispara o fluxo completo quando fecha um contrato), pos-reuniao-acoes (extrai ações de uma transcrição de chamada), briefing-pre-call (prepara contexto antes de reunião com lead).

O ponto central de Skills é esse: quando vc faz algo que funcionou bem, você documenta e transforma em Skill. Da próxima vez, não precisa explicar de novo. Vc invoca e executa.

Para quem está começando, a recomendação é: toda vez que vc escrever um prompt que funcionou muito bem, salva num arquivo .md. Com três campos básicos: o que essa Skill faz, quando usar, e os passos. Com o tempo, vc constrói um arsenal que ninguém mais tem, porque foi construído a partir do que funciona pra você especificamente.

Pilar 4: Agents: quando delegar pro subagente

Agents são subagentes especializados que executam partes do trabalho em paralelo, cada um com contexto, persona, ferramentas e objetivo próprios.

A diferença entre usar um LLM genérico e um Agent é exatamente essa: o Agent já carrega todo o contexto do domínio dele antes de começar. Não precisa de briefing toda vez. Ele sabe quem é, o que pode fazer, e como deve responder.

Na Expert Integrado, a gente tem três Agents principais em uso hoje: o exp-sdr (qualifica leads, busca informações da empresa, prepara o pitch inicial), o exp-cro (analisa páginas e copy, sugere otimizações baseadas em dados de conversão), e o exp-cs (acompanha clientes ativos, identifica risco de churn, propõe próximos passos).

Cada um tem um arquivo de definição com: persona detalhada, objetivo principal, ferramentas disponíveis (quais MCPs pode usar), e regras de comportamento. O exp-sdr, por exemplo, sabe que nunca deve criar uma atividade no Pipedrive antes de confirmar os dados com o Eric. Essa regra está no arquivo de definição dele.

O gatilho pra criar um Agent é quando vc percebe que um determinado conjunto de tarefas: (1) se repete com frequência, (2) tem contexto específico demais pra um prompt genérico, e (3) poderia rodar em paralelo com outras coisas. Se as três condições estão presentes, vale o investimento de criar o Agent.

Um erro comum é criar Agent pra tudo. Agent que faz de tudo não é especialista em nada. O exp-sdr não mexe em CS. O exp-cs não qualifica lead. Especialização é o que torna o Agent útil.

A sequência que Eric usa no dia a dia

Não é uma sequência linear. É mais parecida com construção: vc começa por onde precisa e os outros pilares entram quando fazem sentido.

Na prática, funciona assim: qualquer novo projeto começa com Vibes. Eu paro cinco minutos e escrevo o contexto: quem sou eu nesse projeto, o que quero construir, o que não pode ter. Isso vai pro CLAUDE.md do repositório.

Quando vou construir algo funcional, paro de novo e escrevo a Spec antes de começar. Não em formato técnico. Em texto corrido, como eu explicaria pra um funcionário novo. Esse arquivo fica em spec.md na raiz do projeto.

Quando um processo funciona bem pela primeira vez, eu o documento como Skill. Não deixo pra depois. A chance de documentar depois é próxima de zero se vc não fizer no momento.

Quando uma Skill cresce em complexidade ou precisa de ferramentas específicas, ela vira candidata a Agent. A decisão de promover é baseada em frequência de uso e especificidade de contexto.

No dia a dia, começo com /triagem-matinal (Skill) que usa o exp-sdr (Agent) pra pré-qualificar leads que chegaram. Quando tem reunião, uso /briefing-pre-call (Skill) que puxa informações do Pipedrive e do Expert Brain automaticamente. Depois da reunião, /pos-reuniao-acoes (Skill) extrai as ações e cria os cards no ClickUp.

É tudo construído em cima dos quatro pilares. Vibes define o contexto. Specs evita retrabalho. Skills acelera o que já funcionou. Agents delega o que tem escala.

Quando Vibe Coding não é a resposta certa?

Tem casos em que a estrutura dos quatro pilares não se aplica bem. Vale ser honesto sobre isso.

Vibe Coding funciona mal quando: (1) o problema precisa de infraestrutura complexa que exige arquiteto de software de verdade, tipo um sistema de pagamentos com compliance regulatório, (2) a Spec é impossível de escrever porque o próprio usuário não sabe o que quer, nesses casos o problema não é técnico, é estratégico, (3) o time não tem ninguém disposto a aprender os fundamentos mínimos, Vibe Coding não é “clica e gera”, precisa de quem entenda o que está sendo construído.

Também não substitui um desenvolvedor sênior quando vc está em escala, com produto em produção e com clientes pagando. Nesses casos, Vibe Coding é ferramenta de apoio, não substituta.

Para empresários que estão validando uma ideia, construindo uma automação interna, ou criando um MVE (Mínimo Produto Executável), os quatro pilares são suficientes pra ir longe. Foi assim que a gente construiu boa parte das ferramentas internas da Expert Integrado.

---

FAQ

O que é Vibe Coding, em resumo?

Vibe Coding é um método pra não-desenvolvedores construírem sistemas funcionais com ajuda de IAs como Claude Code e ChatGPT. A diferença do “jogar um prompt e torcer” é que tem estrutura: você define o contexto (Vibes), especifica o que quer construir (Specs), reutiliza o que funciona (Skills) e delega tarefas repetitivas a subagentes especializados (Agents). O resultado é produtividade real, não só experimentação.

Preciso saber programar pra usar Vibe Coding?

Não precisa saber programar. Precisa entender o que vc quer construir, ser específico ao descrever, e ter paciência pra iterar. Quem tem alguma noção de lógica vai andar mais rápido, mas não é pré-requisito. A curva de aprendizado é sobre comunicação com IA, não sobre sintaxe de código.

Qual ferramenta eu uso pra começar com Vibe Coding?

Claude Code é o que eu uso e recomendo pra começar. Tem suporte nativo a Skills, lê arquivos de contexto automaticamente, e o modelo subjacente (Claude Sonnet) é hoje o melhor pra tarefas de desenvolvimento. ChatGPT com modo Canvas funciona pra quem já é assinante. O importante é escolher uma e aprofundar, não testar cinco ao mesmo tempo.

Quanto tempo leva pra ter a primeira automação funcionando?

Com os quatro pilares aplicados, a maioria das pessoas que oriento no G4 tem a primeira automação interna funcionando em uma semana. Não oito horas de estudo, mas uma semana de aplicar no próprio contexto, errar, ajustar. O maior gargalo costuma ser a Spec: vc demora mais pra escrever o que quer do que a IA demora pra construir.

Skills e Agents são a mesma coisa?

Não. Skill é um fluxo de comportamento documentado que vc invoca quando precisa. Ela roda dentro de uma sessão, no contexto atual. Agent é um subagente com identidade própria, ferramentas específicas e contexto persistente. A Skill executa um processo. O Agent é uma entidade especializada que pode usar várias Skills.

Posso usar Vibe Coding pra automatizar processos que envolvem outras pessoas (equipe, clientes)?

Sim, e esse é exatamente o caso mais valioso. O exp-cs da Expert Integrado, por exemplo, trabalha com dados de clientes reais e sugere próximos passos pra equipe de CS. O que muda é o cuidado com dados sensíveis e a clareza sobre o que o Agent pode fazer sem aprovação humana. Agents que envolvem terceiros precisam de regras de comportamento bem definidas no arquivo de definição.

---

Esses quatro pilares são o que separa quem usa Vibe Coding de forma consistente de quem tentou uma vez e desistiu. Bora testar?