Vibe coding: o que é, onde ajuda e onde vira risco para a empresa

Quem pergunta o que é vibe coding costuma ter ouvido que dá para criar um sistema só conversando com a IA. A definição é simples. Vibe coding é construir software pedindo a uma IA, em linguagem natural, o que se quer, e aceitar o código gerado sem ler nem revisar. Também se escreve junto: vibecoding.

Para uma empresa, isso ajuda a testar ideias depressa. O risco aparece quando o protótipo passa a guardar dados de clientes, a falar com bancos e com o fisco ou a sustentar o trabalho de outras pessoas. Este guia mostra onde fica essa fronteira e o que acrescentar para atravessá-la.

O que é vibe coding

O termo foi cunhado por Andrej Karpathy em fevereiro de 2025. Na descrição dele, reproduzida pelo desenvolvedor Simon Willison, é programar de um jeito em que você “forget that the code even exists”: esquece que o código existe. Karpathy aceitava tudo o que a IA propunha, sem ler as alterações. E dizia que isso não era tão ruim para “throwaway weekend projects”, projetos descartáveis de fim de semana.

Em 6 de novembro de 2025, o Collins Dictionary escolheu vibe coding como palavra do ano. O dicionário o define como “the use of artificial intelligence prompted by natural language to write computer code”. Em português: o uso de IA, comandada por linguagem natural, para escrever código. O Collins registra também o debate sobre se a prática é revolucionária ou imprudente.

A definição do Collins é mais larga, e isso gera confusão. Willison propôs um critério prático. Se a IA escreveu o código e você revisou, testou a fundo e sabe explicar a outra pessoa como ele funciona, “that's not vibe coding, it's software development”. Não é vibe coding, é desenvolvimento de software.

Neste guia, vibe coding é aceitar o código sem entendê-lo. O risco não está na IA, e sim na falta de alguém que saiba o que o código faz.

Vibe coding, no-code, low-code e engenharia com agentes: qual a diferença?

Todas essas abordagens prometem software com menos programação manual. A diferença está em quem usa, no que produzem e em quem mantém o resultado.

Abordagem	Quem usa	O que produz	Quem mantém	Principal risco
Vibe coding	Qualquer pessoa	Código da IA aceito sem revisão	Quem criou, se ainda estiver por perto	Falhas que ninguém sabe localizar
No-code	Equipe de negócio	Telas e fluxos montados numa plataforma, sem programar	O time, nas regras da plataforma	Limites e dependência da plataforma
Low-code	Equipe de negócio com apoio técnico	Aplicações numa plataforma, com um pouco de código	O time ou um parceiro	Os do no-code, mais o código próprio
Desenvolvimento com agentes de IA e revisão humana	Desenvolvedores	Código escrito com agentes, revisado e testado por pessoas	A equipe de desenvolvimento	Revisão apressada de muito código
Engenharia de software tradicional	Desenvolvedores	Código escrito e revisado por pessoas	A equipe de desenvolvimento	Mais tempo até a primeira versão

Modelo ilustrativo.

O próprio Karpathy separa as duas pontas. Num texto de 30 de abril de 2026, escreveu que vibe coding “is about raising the floor for everyone”: eleva o piso do que qualquer pessoa consegue fazer. Já a engenharia com agentes, ou agentic engineering, “is about preserving the quality bar of professional software”. Isto é, preserva o padrão do software profissional.

E completa: “You are not allowed to introduce vulnerabilities because of vibe coding.” Não é permitido introduzir falhas de segurança por causa do vibe coding. O autor do termo não o abandonou. Só o separou do software de produção.

Vibe coding é a mesma coisa que low-code?

Não. No no-code e no low-code, a aplicação é montada numa plataforma, com blocos prontos e alcance previsível. No vibe coding, a IA escreve código novo que ninguém revisa. Para automações internas, uma ferramenta de fluxos pode ser alternativa sem código próprio: veja o texto sobre n8n para empresas.

Onde entram os agentes de programação

Agentes de programação executam tarefas inteiras: alteram arquivos e rodam comandos. Sem revisão, são vibe coding com mais alcance e mais estrago possível. Com revisão, testes e permissões limitadas, são a quarta linha da tabela.

Exemplos de vibe coding: o que as pessoas constroem

Alguns tipos de aplicação que dá para criar assim, e o ponto em que cada um muda de natureza:

• Telas de cadastro e controle: servem a uma pessoa com dados de teste. Com vários usuários, faltam permissões e histórico.
• Calculadoras e simuladores internos: se o número vai para uma proposta, a regra precisa ser testada.
• Páginas simples, como um formulário de inscrição: publicadas, recebem dados de pessoas reais.
• Painéis sobre uma planilha: se viram base de decisão, a origem dos dados precisa ser confiável.
• Scripts que juntam arquivos exportados: se rodam sozinhos, precisam de registro de erros.
• Protótipos de aplicativo: mostram o fluxo, mas não são a versão que chega ao cliente.

O protótipo funciona para quem o criou e muda de natureza quando entram outros usuários, dados de clientes ou integrações.

Onde o vibe coding ajuda a empresa

Usado no lugar certo, o vibe coding encurta a distância entre uma ideia e algo que dá para testar:

• protótipo para discutir requisitos com a operação antes de contratar desenvolvimento;
• validação rápida de uma tela ou de um fluxo com quem vai usar;
• ferramenta interna descartável, de uma pessoa, sem dados de clientes;
• automação pessoal de uma tarefa repetitiva, sem acesso a sistemas críticos.

A regra que recomendamos: vibe coding serve para aprender e validar, não para sustentar a operação.

Onde ele vira risco

O risco não depende de quanto código foi gerado, e sim do que a ferramenta toca. Quatro situações pedem cuidado:

• dados de clientes e dados pessoais;
• integrações fiscais e financeiras, como nota fiscal, bancos e pagamentos;
• vários usuários com permissões diferentes;
• qualquer ferramenta de que outras pessoas passam a depender.

Sobre dados pessoais, a lei é explícita. O art. 46 da LGPD obriga os agentes de tratamento a adotar medidas de segurança, técnicas e administrativas. Elas devem proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas. O § 2º manda observá-las desde a concepção do produto ou do serviço. Isto não é orientação jurídica.

Três levantamentos dão a dimensão do problema.

Levantamento	O que encontrou	Limite
Veracode, 24/03/2026	Com mais de 150 modelos testados, 45% das tarefas geraram código com falhas de segurança conhecidas. A taxa está praticamente estável há dois anos.	Empresa que vende segurança de código; 80 tarefas, em quatro linguagens, analisadas pela ferramenta dela. Não vale para todo código gerado por IA.
Stack Overflow Developer Survey 2025	72,2% disseram que vibe coding não faz parte do seu trabalho profissional. Entre as frustrações com IA, 66% citaram soluções “quase certas, mas não totalmente”, e 45,2% disseram que depurar código gerado por IA leva mais tempo.	Participação voluntária, recrutada sobretudo nos canais do próprio site, segundo a metodologia. Mede percepção.
DORA 2025, do Google Cloud	A IA amplifica o que já existe: fortalece equipes que vão bem e intensifica os problemas das que vão mal. A adoção de IA tem relação positiva com a vazão de entregas e negativa com a estabilidade.	Quase 5.000 profissionais de tecnologia, com respostas autodeclaradas. Publicado pelo Google Cloud.

O DORA também explica o mecanismo. Sem testes automatizados, controle de versões maduro e retorno rápido, mais volume de mudanças gera mais instabilidade. No vibe coding, nada garante que esses controles existam.

Há ainda um caso real. Em julho de 2025, segundo a Fortune, um agente de IA da Replit apagou o banco de dados de produção de um projeto do SaaStr. Foi durante um congelamento de código, que deveria impedir qualquer mudança em produção.

O CEO da Replit, Amjad Masad, chamou o caso de “Unacceptable and should never be possible”: inaceitável, algo que nunca deveria ser possível. A empresa anunciou a separação automática entre bancos de desenvolvimento e de produção. A lição não é sobre uma ferramenta: produção precisa de barreiras que não dependam de a IA obedecer.

A IA deixa o desenvolvimento mais rápido?

Depende, e a medição séria ainda é escassa. Um experimento randomizado do METR, publicado em julho de 2025, trouxe um resultado contraintuitivo.

19%

foi o aumento no tempo que 16 desenvolvedores experientes levaram para concluir 246 tarefas quando podiam usar IA. Antes, esperavam ganhar 24% de velocidade. Depois, acreditavam ter ganho 20%.

A lição não é que a IA atrasa. É que a percepção de ganho engana, até entre especialistas.

Em fevereiro de 2026, o METR publicou uma atualização. Para os desenvolvedores do estudo original que voltaram, a estimativa passou a 18% menos tempo com IA. O intervalo de confiança vai de 38% a menos a 9% a mais, ou seja, inclui ganho e perda. O próprio METR chama esses dados de evidência muito fraca, por efeitos de seleção. De 30% a 50% dos desenvolvedores disseram ter deixado de enviar tarefas que não queriam fazer sem IA.

Já três experimentos de campo reuniram 4.867 desenvolvedores na Microsoft, na Accenture e numa empresa da Fortune 100 não identificada. Com um assistente que sugere complementos de código, as tarefas concluídas aumentaram 26,08%, com erro-padrão de 10,3%. Os ganhos foram maiores entre os menos experientes.

Os limites: completar código não é pedir um aplicativo inteiro, e tarefas concluídas não medem qualidade. O estudo, de junho de 2025, é divulgado pela Microsoft Research.

Juntando tudo, há ganho em alguns contextos e perda em outros. Se a velocidade é o argumento, meça antes e depois na sua empresa, com tarefas reais. O pilar sobre o que os estudos mostram sobre IA nas empresas reúne medições fora do desenvolvimento de software.

Do protótipo à produção: o que precisa ser acrescentado

Um protótipo que provou valor pode virar uma boa especificação. Para virar ferramenta da operação, precisa ganhar o que o vibe coding deixa de fora.

No último item, deixe por escrito quem responde por cada peça. Se houver fornecedor, confira o que o contrato diz sobre a propriedade do código.

Na LinieX, essa é a passagem da Validação, quando testamos com a operação real, para a Evolução. As etapas estão na nossa metodologia, e o tipo de trabalho, em sistemas próprios.

Decidir se o que o time já criou com IA deve ser reforçado, reconstruído ou aposentado é tema para outro texto. Para orçar a versão de produção, veja quanto custa desenvolver um sistema. Se o protótipo nasceu para substituir uma planilha, leia como transformar a planilha em sistema. Se ainda não está claro se vale construir, decida antes entre software sob medida ou SaaS.

Uma política simples de uso para o time

Proibir a IA não resolve, e liberar tudo também não. Uma política curta, pela sensibilidade do dado, é um bom começo. O modelo abaixo é ilustrativo, não uma norma: ajuste-o com quem responde por segurança e LGPD.

Faixa	Quando se aplica	O que é permitido	Quem aprova
Liberado	Uso pessoal, sem dado de cliente nem acesso a sistemas da empresa	Protótipos, simulações e automações pessoais	Ninguém; basta registrar
Com revisão	Dado interno, uso por uma equipe	Ferramentas internas, depois de revisão técnica	O gestor da área e um revisor técnico
Proibido sem arquitetura	Dado pessoal, financeiro ou fiscal, ou integração com outros sistemas	Só protótipo com dados fictícios	A diretoria e o responsável técnico

Modelo ilustrativo.

Três regras completam a política:

• o código fica num repositório da empresa, não na conta pessoal de quem criou;
• um registro simples lista cada ferramenta, quem criou, que dados usa e quem depende dela;
• a ferramenta é reavaliada quando muda de faixa, por exemplo ao ganhar usuários ou dados de clientes.

Perguntas frequentes sobre vibe coding

Em resumo

Vibe coding é ótimo para aprender e validar, e arriscado para operar. Evite quando entram dados pessoais, dinheiro, fisco, vários usuários ou pessoas que dependem da ferramenta. Os estudos não sustentam ganho automático, e a IA amplifica o que a organização já é.

O valor está em saber quando o protótipo precisa de arquitetura, testes e um responsável, e em fazer essa passagem antes que a operação dependa dele.

Fontes

1. Simon Willison. Not all AI-assisted programming is vibe coding (but vibe coding rocks). 2025. Acesso em 19/09/2026. Reproduz a descrição original de Andrej Karpathy, publicada no X em fevereiro de 2025.
2. Collins Dictionary. Collins' Word of the Year 2025: AI meets authenticity as society shifts. 2025. Acesso em 19/09/2026.
3. Andrej Karpathy. Sequoia Ascent 2026 summary. 2026. Acesso em 19/09/2026.
4. Presidência da República. Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais), art. 46. 2018. Acesso em 19/09/2026.
5. Veracode. Spring 2026 GenAI Code Security Update: Despite Claims, AI Models Are Still Failing Security. 2026. Acesso em 19/09/2026. Publicado em 24/03/2026 por empresa que vende segurança de código; 80 tarefas, 4 linguagens, 4 tipos de falha.
6. Stack Overflow. AI, 2025 Stack Overflow Developer Survey. 2025. Acesso em 19/09/2026. Participação voluntária; mede percepção.
7. Stack Overflow. Methodology, 2025 Stack Overflow Developer Survey. 2025. Acesso em 19/09/2026. Coleta de 29/05/2025 a 23/06/2025, com 49.009 respostas analisadas.
8. Google Cloud (Nathen Harvey e Derek DeBellis). Announcing the 2025 DORA Report: State of AI-Assisted Software Development. 2025. Acesso em 19/09/2026. Pesquisa com quase 5.000 profissionais de tecnologia; respostas autodeclaradas.
9. Fortune (Beatrice Nolan). An AI-powered coding tool wiped out a software company's database, then apologized for a 'catastrophic failure on my part'. 2025. Acesso em 19/09/2026. Fonte jornalística; segundo a reportagem, a declaração do CEO da Replit foi publicada no X.
10. METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 2025. Acesso em 19/09/2026. Experimento randomizado com 16 desenvolvedores e 246 tarefas.
11. METR. We are Changing our Developer Productivity Experiment Design. 2026. Acesso em 19/09/2026. Os autores consideram os dados evidência muito fraca por efeitos de seleção.
12. Microsoft Research (Cui, Demirer, Jaffe, Musolff, Peng e Salz). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. 2025. Acesso em 19/09/2026. Mede tarefas concluídas, não qualidade.