Vibe coding: oportunidade ou risco corporativo?

Rener Menezes e Evener Menezes discutem como o desenvolvimento de aplicações com inteligência artificial amplia a capacidade de inovação, mas exige controles proporcionais ao risco antes de chegar à produção.

Criar ficou mais fácil; responder pelo resultado, não

O vibe coding transforma instruções em linguagem natural em aplicações, interfaces, bancos de dados e integrações. A questão central do episódio é se essa redução da barreira técnica representa uma oportunidade ou um novo risco corporativo. Rener Menezes e Evener Menezes não tratam as duas possibilidades como excludentes: a mesma facilidade que permite testar uma ideia com rapidez também permite produzir falhas com rapidez.

Por isso, confiar em uma aplicação não deveria depender apenas de quem escreveu o código. Código produzido por pessoas também contém defeitos; código gerado por inteligência artificial não é inseguro por definição. O que sustenta a confiança são os processos posteriores: arquitetura, testes, tratamento de dados, permissões, monitoramento, continuidade e atribuição de responsabilidade.

Essa distinção se torna mais importante conforme aumenta o impacto. Um painel interno e periférico à operação não deve receber necessariamente o mesmo tratamento de um sistema financeiro, de saúde ou de controle de uma aeronave. A consequência de uma falha determina o rigor necessário. Sistemas críticos exigem análise detalhada e evidências mais fortes, independentemente de o código ter sido escrito por um humano ou por um modelo.

Greenfield facilita o começo, não elimina o futuro

O episódio usa os conceitos de greenfield e brownfield para separar dois contextos. Greenfield é um sistema novo, sem legado ou obrigações de compatibilidade. Brownfield é um ambiente existente, no qual mudanças precisam respeitar código, integrações e comportamentos anteriores. A geração por IA tende a encontrar menos obstáculos no primeiro caso, porque não precisa compreender uma longa história técnica antes de construir.

Rener relata o caso de uma empresa conhecida no setor de tecnologia que desenvolvia dois produtos novos exclusivamente com vibe coding. O relato é apresentado como uma experiência observada, não como prova de que a abordagem serve para qualquer sistema. Os produtos já estavam em uso, mas seu responsável reconhecia uma incerteza: com o tempo, o código novo também acumularia mudanças e se tornaria legado. Nem sequer havia garantia de que as ferramentas atuais continuariam disponíveis.

O exemplo revela uma troca. A organização pode ganhar velocidade agora e aceitar que manutenção, dependência de fornecedor e evolução arquitetural precisarão ser enfrentadas depois. Essa decisão pode ser razoável, mas precisa ser consciente. Começar do zero reduz parte da complexidade; não remove requisitos de segurança, operação nem continuidade.

Protótipo funcional não é produção homologada

Quando alguém do financeiro chega com uma aplicação construída no fim de semana, a iniciativa merece ser reconhecida. Isso não significa incorporar imediatamente a ferramenta à rotina da empresa. Um protótipo demonstra intenção e utilidade; produção exige que o sistema continue funcionando sem depender da máquina, da conta ou da presença de seu criador.

A passagem de experimento para ativo corporativo ocorre quando a solução usa dados reais ou sensíveis, integra-se a outros sistemas, afeta clientes ou dinheiro, passa a sustentar o trabalho de outras pessoas ou precisa permanecer disponível. Nesses casos, a decisão deixa de pertencer a um indivíduo e passa a exigir tratamento institucional.

O episódio cita um caso atribuído à ferramenta Replit em que um agente com acesso à produção apagou um banco de dados. A conversa usa o episódio para defender separação entre desenvolvimento e produção, restrição de acessos e possibilidade de reversão. A conclusão não é que agentes sempre provocarão esse tipo de incidente, mas que permissões amplas tornam real o dano que, em um ambiente isolado, seria apenas um erro de teste.

Dados e integrações também precisam de revisão. Uma aplicação pode parecer correta na interface e ainda falhar na autorização do lado do servidor, armazenar informações sensíveis de forma inadequada ou expor infraestrutura. Criptografia é um dos controles discutidos, mas não deve ser aplicada mecanicamente a tudo: a escolha depende do dado, do contexto e dos impactos operacionais. Conhecer o conceito é necessário para formular requisitos e avaliar as respostas da ferramenta.

Modelos geram código; controles verificam comportamento

Uma pessoa sem experiência em programação dificilmente consegue avaliar sozinha se uma aplicação é segura. Na verdade, o episódio argumenta que essa avaliação não deveria depender de uma única pessoa. Modelos de linguagem são não determinísticos: pequenas mudanças na pergunta podem produzir respostas diferentes. Além disso, podem repetir padrões problemáticos presentes nos códigos usados em seu treinamento ou seguir uma solução conveniente sem cobrir requisitos que não foram solicitados.

Isso cria um limite para pedir que a própria IA gere e valide tudo a partir da mesma premissa. Se uma suposição incorreta orientar tanto o código quanto o teste, os dois podem concordar e ainda assim estar errados. Rener propõe combinar a geração com ferramentas mais determinísticas, como verificações automatizadas e testes de segurança que, diante da mesma entrada, executem o mesmo procedimento.

Essas ferramentas não substituem julgamento técnico, mas produzem evidências repetíveis. Testes funcionais, análise de permissões, validação de integrações e inspeção da arquitetura ajudam a descobrir se a solução atende ao comportamento esperado. O objetivo não precisa ser revisar manualmente cada linha: é construir um processo capaz de detectar falhas relevantes antes que recebam poder real em produção.

O novo papel da TI é governar a produção

Se marketing, jurídico, financeiro e outras áreas conseguem criar software, a TI deixa de ser a única fábrica de aplicações. Isso não elimina seu papel. Na visão discutida, tecnologia continua como guardiã da produção e dos fundamentos técnicos: identidade, acesso, infraestrutura, segurança, arquitetura, implantação e continuidade.

Essa mudança separa autoria de homologação. A área de negócio pode conhecer melhor a dor e experimentar uma resposta rapidamente. Quando a aplicação ganha relevância corporativa, profissionais com maturidade técnica avaliam os controles compatíveis com o risco. Uma ferramenta interna de baixa criticidade pode seguir um caminho leve; uma solução regulada, conectada a dados de usuários ou indispensável à operação exige outro nível de cuidado.

Proibir ferramentas de vibe coding não resolve a questão. Segundo a discussão, a proibição pode deslocar o uso para Shadow AI ou Shadow IT, reduzindo a visibilidade da empresa. A alternativa é oferecer um caminho explícito para experimentar e critérios claros para promover uma solução à produção.

Governança proporcional preserva a inovação

Governança pode prejudicar a inovação quando se reduz a documentos, aprovações e demora sem relação com o risco. A ausência completa de governança, porém, pode comprometer dados, credibilidade, operação e até a continuidade do negócio. O equilíbrio está em tornar o risco visível e aplicar controles proporcionais ao impacto, respeitando também obrigações legais e regulatórias.

A síntese do episódio é direta: democratizar a criação não significa democratizar irrestritamente a produção. Qualquer pessoa pode experimentar e propor soluções; colocar uma aplicação em operação é uma decisão corporativa. O teste prático é observar dados, dependências, integrações, impacto financeiro, clientes e disponibilidade. Quanto maior a consequência de uma falha, maior deve ser a evidência exigida.

O vibe coding é, portanto, oportunidade e risco ao mesmo tempo. Seu valor está na velocidade para transformar conhecimento do negócio em experimentos. Seu limite aparece quando velocidade é confundida com segurança ou quando um protótipo funcional é tratado como sistema pronto. A empresa que define um caminho curto, compreensível e proporcional para sair da ideia e chegar à produção consegue incentivar criação sem abandonar responsabilidade.