Tirando o Máximo do Vibe Coding
Por que Vibe Coding não é suficiente para desenvolver software de qualidade profissional?

O Vibe Coding é uma nova forma de dar vida às nossas ideias e de tirar do papel aquele projeto engavetado há meses. Sem o rigor da engenharia de software tradicional, essa prática traz acessibilidade e convida e empodera pessoas por todo o mundo a CRIAR. Mas como veremos abaixo, há limites onde se pode chegar com essa abordagem e também formas de tirar o máximo dessa experiência.
#Vibe Coding
Esta prática viralizou e ganhou popularidade rapidamente desde janeiro de 2025, quando Andrej Karparthy, ex líder de desenvolvimento de IA na Tesla, publicou este post:
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper
#Super Acessibilidade
Há dois anos seria impensável que uma pessoa sem nenhum expertise técnico pudesse criar uma aplicação do zero, sem ajuda nenhuma, e agora isso é totalmete possível.
Ferramentas agênticas como bolt.new, Lovable e Gemini abriram portas para uma nova forma de prototipagem rápida, diferente de tudo que havia antes. Não é necessário escrever uma única linha de código manualmente!


Isso faz com que novos públicos possam codificar aplicações:
- Crianças, que antes precisavam aprender linguagens de programação básicas ou usar alguma ferramenta low-code
- Profissionais de outras áreas, como educação, saúde, comércio, que antes dependiam de desenvolvedores para criar suas soluções digitais
Já para profissionais de tecnologia, ferramentas como essa, e também IDEs agênticas como Cursor e Windsurf trazem grande autonomia e novos poderes:
- Product Owners, designers, coordenadores, gerentes, todos eles agora tem um nível de autonomia muito maior, não dependendo mais do time de desenvolvimento
- Desenvolvedores especializados em backend agora podem fazer o frontend por conta própria com ajuda de um agente de IA
- Da mesma forma, desenvolvedores especializados em frontend podem agora desenvolver backends por conta própria com auxílio de um agente de IA
Este vídeo foi apresentado por Tom Wolf, do HuggingFace, e exibido na palestra do Andrej Karpathy "Software Is Changing (Again)".

#Diversão e o Fator Sorte
Vibe Coding pode ser extremamente divertido, pois trabalhar com um agente de IA de forma livre envolve um elemento de sorte: quando dá certo, a sensação é a de ganhar um prêmio.
As ferramentas de IA estão tornando a programação mais divertida para mim. É como ter um gênio imprevisível. Eu acordo no meio da noite pensando: 'Ah, é assim que eu deveria ter instruído meu agente!' [...] Estou me divertindo mais programando agora do que nunca.
— Kent Beck, episódio do podcast The Pragmatic Engineer, em tradução livre
Mas observe a linguagem do Kent Keck: um gênio imprevisível. Assim como nas histórias, seu pedido é realizado, mas nem sempre da forma como você imaginou, e muitas vezes com consequências indesejadas.
#Perdendo no Jogo da Sorte
O maior problema enfrentado em sessões de Vibe Coding é que, em algum momento, as coisas vão começar a dar errado.
A natureza não-determinística dos agentes baseados em LLMs (Large Language Models) é a fonte dessa variação nos resultados e na confiabilidade das ferramentas, mas não é o único fator que introduz elemento de sorte.
Outros elementos importantes que introduzem variação são:
- Prompt informado
- Contexto informado (ou não informado)
- Modelo escolhido (LLM)
- Estrutura do projeto
Vamos agora explorar as formas como esses elementos introduzem incerteza no processo.
#Prompts Imprecisos ou Incompletos
Um prompt muito simplista tem dois efeitos imediatos: ao mesmo tempo em que dá muita liberdade ao agente, esse prompt deixa o agente no escuro.
Ao contrário do que se pode imaginar numa análise rasa, excesso de liberdade impede bons resultados, ao invés de potencializá-los. Para ilustrar, vamos ver alguns exemplos:
- É a restrição do prazo que faz com que muitos projetos sejam entregues: ausência de prazo atrasa projetos indefinidamente.
- Times pequenos performam melhor do que time muitos grandes: times grandes demais introduzem muito ruído de comunicação e burocracia administrativa. Este é o motivo da famosa regra de ouro do Jeff Bezos para tamanho de squads: "Two-pizza Team".
- Todos os jogos são baseados em regras: são as restrições que essas regras impõem que tornam o jogo possível.
Em outras palavras, são prompts detalhados e bem descritos, livres de ambiguidades, com requisitos claros e bem elaborados que possibilitam ao agente fazer o que pedimos, da forma como esperamos, com resultados eficazes.
Ou seja, prompts de alta qualidade são indispensáveis para atingir bons resultados. Algumas características desses prompts são:
- Definição clara dos requisitos funcionais e não funcionais
- Objetivos claros
- Linguagem livre de ambiguidades
- Regras a seguir, como guidelines do time, projeto ou da empresa, deixando claro o que pode e o que não pode fazer
#Contexto Informado (ou Omitido)
Da mesma forma que o prompt pobre, um contexto pobre permitirá ao agente trabalhar contra nossas expectativas e desejos.
Mesmo quando estamos criando um projeto do zero, é importante definir contexto para o agente. Este contexto pode ser informado de várias formas:
- Detalhes relevantes no prompt sobre a realidade da empresa, sobre o usuário que vai usar
- Imagens anexadas ao prompt fornecem referências visuais valiosas. O bolt.new, por exemplo, permite anexar designs do Figma para respeitar fielmente designs pré-existentes.
- Links da documentação de bibliotecas e frameworks ajudam o agente a implementar de forma mais correta
- Documentações do projeto, da empresa, guidelines, exemplos: tudo isso pode gerar ajudar a colocar o agente na mesma página que nós e alinhar expectativa.
Outra forma de adicionar contexto extra, ou permitir que o agente colete mais contexto sob demanda, a medida que for necessário, é disponibilizar ferramentas para o agente através de servidores MCP. O protocolo MCP (Model Context Protocol) vem ganhando adoção de forma explosiva desde março de 2025, quando foi lançado pela Anthropic.
Ferramentas de codificação agêntica como Cursor, Windsurf, GitHub Copilot e Claude suportam este recurso, e os agentes podem tirar vantagem delas para enriquecer dinamicamente o contexto.
Alguns servidores MCP poderosos para enriquecer contexto são:
- Context7, para buscar exemplos de implementação atualizados para qualquer biblioteca ou frameworks
- Perplexity, para busca mais profundas que exigem pesquisa para suportar tomada de decisão
- Pupeteer ou Playwright, permitem ao agente testar visualmente a aplicação, abrindo o navegador, tirando screenshots, lendo o console, etc
Ou seja, um contexto bem definido pode ser a diferença entre um resultado ruim, de baixa qualidade ou até mesmo inválido, e um resultado de alta qualidade.
#Escolha do Modelo Errado
Outro fator que pode influenciar muito os resultados e a experiência de desenvolvimento com vibe coding é a escolha do modelo (LLM) utilizada.
Enquanto ferramentas de Vibe Coding de alto nível como o bolt.new e o Lovable tomam para si a escolha dos modelos, outras ferramentas como o Cursor e o Windsurf dão ao usuário o poder de escolher o modelo.

Sempre temos opção de ligar o modo "Auto" e delegar a escolha para a ferramenta. Mas em muitos casos o modelo selecionado pode ser um modelo mais simples, mais barato ou mais antigo. Estes modelos podem ser eficientes e adequados para tarefas simples, mas não para a tarefa em mãos.
Cada modelo apresenta capacidades, fraquezas e fortalezas próprias, que podem fazer toda a diferença no resultado de uma implementação. Veja alguns exemplos:
- Modelos mais antigos, como o GPT-4, da OpenAI, foram treinados para tarefas de programação baseadas em campeonatos, mas não são muito bons em tarefas reais de desenvolvimento do dia a dia.
- O Claude 3.7 Sonnet, da Anthropic, foi treinado especificamente para tarefas de programação do mundo real, e por isso é um dos modelos mais usados para programação, mas ele não é tão bom em seguir instruções à risca: ele frequentemente toma liberadades e muitas vezes esquece ou ignora requisitos.
- O Claude 4 Sonnet e o GPT 4.1 foram treinados para seguir mais à risca as instruções do prompt.
- Modelos de raciocío, como o Claude 4 Sonnet Thinking e o Gemini 2.5 Pro, do Google, podem pensar antes de responder ou tomar ações, trazendo melhores resultados.
- Modelos mais antigos como Grok 3 não suportam muito bem o uso de ferramentas, como servidores MCP.
- O modelo da Claude 4 Opus é um modelo de raciocínio muito poderoso para planejamento, mas também é extremamente caro de ser usado. Ele é muito útil para resolução de problemas complexos, mas inviável financeiramente para a maioria das tarefas do dia a dia.
Ao mesmo tempo, durante o treinamento, as LLMs desenvolvem um tipo de personalidade, que pode influenciar o resultado, e a reação dos agentes frente a problemas.
O Claude 3.7 e o Claude 4, por exemplo, tem tendência de ficar desesperado e começar a cometer erros.


Os modelos também podem apresentar humor,como pode ser visto na próxima imagem.

Resumindo, conhecer os modelos disponíveis nos permite escolher o melhor modelo para cada tarefa.
#The Big Three
Esses três elementos precisam estar bem alinhados para obtermos o mínimo de sucesso em qualquer desenvolvimento usando agentes.

#Do Vibe Coding ao Augmented Coding
Apesar de empolgante e divertido, Vibe Coding não é nem de longe receita para sucesso. Especialmente em projetos de longa duração, como é o caso da maioria dos projetos reais.
É só uma questão de tempo até as coisas começarem a dar errado.

Abaixo, vemos outro exemplo que é uma consequência natural do Vibe Coding, algo que podemos chamar de inchaço desenfreado.
Vibe coding and its consequences
Para evitar este tipo de armadilha, precisamos recorrer a práticas mais robustas de engenharia de software. É aí que entra o Augmented Coding.
#Augmented Coding
Augmented Coding vai muito além do Vibe Coding, aplicando práticas bem estabelecidas de engenharia de software para garantir bons resultados.
Alguns exemplos de práticas de engenharia de software que podem ser empregadas:
- Planejamento de arquitetura
- Técnicas de desenvolvimento como TDD (_Test-Driven Development) assistido por IA
- Refatoração periódica para elevar a qualidade, removendo código ao invés de sempre adicionar mais, que é a tendência das LLMs atuais
- Aplicação de design patterns
- Testes automatizados: análise estática (linters, segurança), testes de unidade, testes de integração, end-to-end, testes de carga
- Bons pipelines de CI/CD (Continuous Integration/Continuous Delivery)
- Bons processos de revisão de código
- Documentação técnica
- Outros
Trata-se de utilizar os agentes de IA para aumentar nossas capacidades e produzir mais e melhor, conferindo ao desenvolvedor superpoderes, mas com responsabilidade, sem nunca perder de vista a importânica da manutenção da qualidade do software.