Eu sou a favor do vibe coding. E quero construir mais com ele

Imagina uma pequena produtora tentando organizar os projetos que chegam pelo Instagram, pelo e-mail e pelo WhatsApp. Um cliente pediu um vídeo vertical, outro ainda não enviou as referências, um terceiro está esperando uma revisão. Por enquanto, tudo fica espalhado entre mensagens e planilhas.

A ideia de criar uma ferramenta própria talvez nem entrasse na conversa. Contratar alguém para desenvolver um sistema seria caro. Aprender tudo antes de começar poderia levar meses. Com vibe coding, dá para descrever o problema, montar uma primeira versão e descobrir, enquanto usa, o que realmente faz falta.

É difícil olhar para isso e enxergar apenas um risco. Tem uma possibilidade enorme aí. Pessoas que nunca se imaginaram criando software agora conseguem experimentar uma solução para um problema que conhecem de perto. E quem já programa também pode tirar projetos da gaveta, testar caminhos e gastar menos tempo em partes repetitivas.

Eu sou a favor do vibe coding. Não digo isso como alguém que domina todos os detalhes da engenharia de software. Estou no sexto semestre da faculdade, comecei a daLontano e, no meio disso tudo, fui me aproximando cada vez mais do audiovisual. É justamente por estar construindo projetos e aprendendo ao mesmo tempo que essa mudança me chama atenção.

O que antes parecia distante agora pode começar numa conversa com uma ferramenta. Você explica o que precisa, vê uma tela aparecer, pede ajustes, testa outra ideia. Para quem trabalha por conta própria ou está começando um negócio, essa porta aberta pode fazer muita diferença.

O desenvolvedor Simon Willison escreveu sobre esse potencial sem tratar o vibe coding como uma ameaça à programação. Ele defende que essa forma de experimentar pode ajudar pessoas a criar ferramentas próprias e até despertar o interesse de novos desenvolvedores. Ao mesmo tempo, diferencia esse tipo de exploração do desenvolvimento de software que precisa ser revisado, testado e mantido. No texto dele sobre o assunto, as duas ideias convivem: a empolgação com o que ficou possível e o cuidado com o que vai ser compartilhado com outras pessoas.

A diferença entre testar uma ideia e colocar um serviço no mundo

Voltemos à produtora. Se aquela primeira ferramenta serve para organizar tarefas internas, usa dados inventados e só ajuda a equipe a visualizar o fluxo, ela já pode ser útil mesmo sem virar um produto completo. Talvez resolva uma dor pequena. Talvez revele que a ideia não era tão boa. Talvez seja o começo de algo maior.

Agora imagina que a mesma ferramenta comece a guardar dados de clientes, contratos, pagamentos ou acessos. A situação mudou. Uma falha pode expor informações, permitir que uma pessoa veja o projeto de outra ou gerar uma cobrança inesperada. A pergunta deixa de ser apenas “a tela funciona?” e passa a incluir “quem consegue acessar esses dados?”, “o que acontece quando duas pessoas alteram a mesma coisa?” e “como recupero o sistema se uma mudança quebrar tudo?”.

Esse salto não transforma o vibe coding em algo ruim. Ele muda o cuidado necessário conforme o alcance do projeto. Uma experiência local, feita para aprender, tem um impacto possível diferente de uma aplicação que recebe dados reais e promete um serviço a clientes.

Para mim, segurança faz mais sentido quando entra nessa conversa concreta. A gente não precisa tratar cada protótipo como se estivesse movimentando milhões. Também não dá para presumir que uma aplicação está protegida só porque abre, tem um visual convincente e passou por alguns testes.

Os dados mostram adoção e produtividade, com algumas ressalvas

Na pesquisa de desenvolvedores de 2025 do Stack Overflow, 84% dos respondentes disseram que já usam ou planejam usar IA no desenvolvimento. O mesmo levantamento mostra que 52% percebem um efeito positivo na produtividade. Há um interesse real nessas ferramentas, e muitos profissionais encontram utilidade prática nelas. Os dados completos estão na pesquisa oficial.

A experiência também tem atritos. Nesse mesmo estudo, 66% disseram se frustrar com respostas que ficam “quase certas”, mas ainda exigem ajustes. Isso não apaga os ganhos. Ajuda a descrever o trabalho com mais precisão: a IA pode acelerar partes importantes, enquanto a pessoa ainda precisa perceber quando a resposta falhou ou se encaixa mal no projeto.

O DORA, programa de pesquisa do Google Cloud sobre desempenho de equipes de software, chega a uma conclusão que me parece útil para esse debate. O relatório de 2025 descreve a IA como um amplificador: ela tende a aumentar os efeitos das condições que já existem na equipe e na organização. O relatório completo está disponível no site do DORA.

Num projeto bem organizado, com objetivos compreensíveis e formas de verificar as mudanças, a IA pode ajudar a equipe a avançar. Num projeto cheio de decisões confusas, ela pode fazer mais mudanças circularem antes que alguém perceba que a direção estava errada. O valor da ferramenta também depende do espaço em que ela está sendo usada.

Segurança está ficando mais acessível, mas não desapareceu

Existe outro lado positivo nessa história. A segurança não precisa ficar restrita a profissionais especializados que chegam só no fim do projeto. Ferramentas de análise, documentação e recursos de IA podem ajudar mais pessoas a identificar problemas e aprender a evitá-los.

Uma pesquisa da Microsoft Research com 17 desenvolvedores profissionais avaliou uma ferramenta de IA para detectar e corrigir vulnerabilidades em projetos reais. Os pesquisadores viram potencial, mas também encontraram falsos positivos e sugestões de correção que não se aplicavam bem ao contexto do código. O estudo da Microsoft Research detalha os resultados.

Isso me parece um retrato mais justo do momento: a IA já pode participar da defesa, mas ainda não tira da equipe a responsabilidade de decidir o que fazer com o alerta e de verificar a solução. Não é uma conversa sobre desconfiar de tudo. É sobre dar à ferramenta acesso e autonomia compatíveis com o problema que estamos tentando resolver.

A OWASP, que publica referências de segurança usadas por profissionais da área, inclui orientações específicas para desenvolvimento assistido por IA. Entre elas estão proteger chaves de acesso, verificar dependências sugeridas pela ferramenta e limitar as permissões dadas aos agentes. O guia de desenvolvimento seguro com IA da OWASP reúne essas recomendações.

Na prática, parte disso começa com hábitos simples. Para testar uma ideia, usar dados fictícios evita expor informações de clientes por acidente. Guardar versões do projeto permite voltar atrás quando uma alteração estraga algo. Antes de publicar, vale testar situações que parecem óbvias para quem desenvolveu, como uma pessoa tentando acessar dados de outra conta. E, quando aparecem chaves de API ou senhas, elas não devem ficar expostas no código ou em capturas de tela.

Esses cuidados não acabam com a velocidade do vibe coding. Ajudam a escolher onde essa velocidade pode ser usada com tranquilidade e onde a gente precisa de uma segunda revisão.

Construir mais também pode ensinar mais

Eu também penso na minha formação. A IA pode acelerar uma entrega e, ao mesmo tempo, deixar partes do aprendizado para trás se eu apenas aceitar o que aparece. Mas também posso pedir explicações, comparar soluções, investigar um erro e usar o projeto como ponto de partida para entender algo que ainda não conheço.

Essa diferença depende, em parte, de como eu participo do processo. Se termino uma tarefa sem saber o que a ferramenta alterou, perdi a chance de aprender. Se o projeto me leva a perguntar sobre estrutura, dados, permissões, testes e decisões técnicas, a IA também pode virar uma forma de entrar nesses assuntos por uma necessidade concreta.

É aí que vejo valor no vibe coding. Ele não precisa ocupar o lugar de toda a formação para já ser útil. Pode ajudar alguém a resolver uma necessidade pequena, testar uma hipótese ou criar confiança para continuar estudando. Criar alguma coisa que funciona pode ser o primeiro motivo para querer descobrir como ela funciona.

Eu não quero usar os problemas possíveis para diminuir o que essas ferramentas já conseguem fazer. Também não quero que a empolgação nos faça esquecer que um software afeta pessoas quando começa a guardar dados, receber dinheiro ou tomar decisões por elas.

Hoje, consigo imaginar mais pessoas criando soluções que antes ficariam apenas no caderno ou numa planilha. Para mim, isso já é uma mudança importante. O trabalho agora é aproveitar essa abertura, aprender com ela e reconhecer quando um projeto cresceu o bastante para precisar de mais estrutura e revisão.