O assunto já rendeu bastante alarme. Busque "vibe coding" em português e você encontra meia dúzia de artigos sérios explicando os riscos — shadow IT, vulnerabilidade, código sem dono, dado colado no prompt. Estão corretos, e vale lê-los.
O que nenhum deles entrega é a decisão que o gestor precisa tomar na segunda-feira: liberar para quem, para quê, e com que checagem. Porque proibir não é uma opção realista — a prática já está dentro da empresa, com ou sem política.
O que é vibe coding?
É o modo de programar em que a pessoa descreve o resultado desejado em linguagem natural e a IA produz o código. O humano deixa de digitar a solução e passa a dirigir: pede, avalia o que voltou, corrige o pedido, repete.
A diferença em relação a autocompletar inteligente é de escala e de postura. No autocompletar, a pessoa escreve e a ferramenta sugere o fim da linha. No vibe coding, a pessoa descreve a funcionalidade inteira e frequentemente não lê linha por linha o que voltou — e é exatamente aí que mora o risco.
Qual a diferença entre vibe coding e no-code?
São caminhos opostos para o mesmo desejo de fazer software sem escrever software.
| No-code | Vibe coding | |
|---|---|---|
| O que se produz | Uma configuração dentro da plataforma | Código-fonte de verdade |
| Onde roda | Só na plataforma que criou | Em qualquer lugar que rode aquela linguagem |
| Limite principal | O que a plataforma permite fazer | O que a pessoa consegue avaliar |
| Risco típico | Ficar preso ao fornecedor | Código que ninguém entende nem revisou |
| Custo de sair | Alto: refazer do zero em outro lugar | Baixo: o código é seu |
Comparativo elaborado pela Alliance Comunicação com base nas duas práticas.
A troca é clara: no-code protege de erro técnico e prende ao fornecedor; vibe coding entrega liberdade e transfere para a empresa a responsabilidade de avaliar o que foi produzido.
Quantos desenvolvedores realmente usam IA?
A leitura mais importante desses números não é a adoção — é a distância entre uso e confiança. Quem programa todo dia usa a ferramenta e não acredita plenamente nela. Isso não é contradição: é a descrição correta de uma ferramenta útil que exige supervisão.
E o "quase certo, mas não" é a categoria de erro mais cara que existe em software. Código obviamente errado quebra na primeira execução e é corrigido em minutos. Código plausível passa pelo teste superficial e falha depois, em produção, num caso que ninguém previu.
O código gerado por IA é seguro?
Depende inteiramente da revisão. Sem ela, a medição disponível não é animadora.
Vale entender por que isso acontece, porque explica também como mitigar. O modelo otimiza para produzir código que funcione e que se pareça com o que ele viu — não para produzir código que resista a uso hostil. Segurança é uma propriedade que quase nunca aparece no pedido, e o que não é pedido não é entregue.
Os padrões recorrentes são conhecidos: credencial escrita direto no código em vez de variável de ambiente, consulta a banco montada por concatenação de texto, validação de entrada ausente e controle de acesso presumido em vez de verificado.
Onde o vibe coding cabe e onde não cabe?
Aqui está a decisão prática. O critério não é a linguagem, nem o tamanho da tarefa, nem a senioridade de quem pediu. É a consequência do erro.
1. Descartável: liberado
Protótipo para validar uma ideia, script que roda uma vez, prova de conceito com dado fictício, automação pessoal. O código morre em dias e não toca nada real. Exigir processo aqui é queimar a maior vantagem da ferramenta, que é velocidade de exploração.
2. Interno: com revisão e dono
Ferramenta que uma equipe passa a usar na rotina — painel, importador, integração pequena. A regra mínima é ter um responsável nomeado e uma revisão por alguém que entenda o código. O risco aqui raramente é segurança: é a ferramenta virar dependência sem manutenção.
3. Produção: com processo formal
Qualquer coisa que o cliente use ou que a operação dependa. Revisão de código obrigatória, teste automatizado e varredura de segredos antes de publicar. A origem do código deixa de importar: ele passa pelo mesmo funil de sempre.
4. Dado pessoal ou dinheiro: com trava
Cadastro de cliente, pagamento, saúde, contrato. Aqui não basta revisar: é preciso que quem revisa seja quem responde formalmente pelo sistema. E é aqui que o dado colado no prompt vira problema de LGPD antes de virar problema técnico.
Como revisar código escrito por IA?
A revisão de código gerado por IA é diferente da revisão de código humano, porque os erros são de natureza distinta. Humano erra por descuido em pontos difíceis; modelo erra com confiança em pontos fáceis.
- Comece pelo que o código faz com entrada inesperada — vazia, gigante, com caractere estranho, negativa.
- Procure segredo escrito no código: chave, senha, token, endereço de banco.
- Confira se o controle de acesso foi verificado ou presumido — é a falha mais silenciosa.
- Verifique as dependências importadas: existem, são mantidas, e a versão é a atual?
- Rode a suíte de testes e pergunte se ela cobre o caminho de erro, não só o caminho feliz.
- Peça a quem submeteu que explique o trecho mais complexo. Se não conseguir, o código ainda não tem dono.
O último item é o mais barato e o mais eficaz. Ele não testa o código: testa se existe alguém capaz de mantê-lo daqui a seis meses.
Quais os erros mais comuns na adoção?
- Proibir sem oferecer alternativa. A proibição empurra o uso para ferramentas pessoais, fora de qualquer controle.
- Liberar tudo igual. A mesma regra para protótipo e para sistema de pagamento é regra que ninguém segue.
- Medir produtividade por linhas entregues. O gargalo mudou para a revisão; medir a escrita premia exatamente o que não é escasso.
- Ignorar a licença do que foi gerado. Código sugerido a partir de repositórios públicos pode carregar obrigação de licença.
- Não registrar o que foi gerado por IA. Sem essa marca, a auditoria futura não sabe onde olhar primeiro.
O que muda por tipo de empresa?
A régua de quatro níveis vale para todo mundo, mas o ponto de tensão é diferente conforme a estrutura de tecnologia que a empresa tem.
| Situação da empresa | Onde o risco aparece primeiro | Primeira providência |
|---|---|---|
| Sem equipe própria de TI | Ferramenta interna vira dependência sem manutenção | Nomear dono e registrar a origem do código |
| Equipe pequena, sem processo formal | Código em produção sem revisão de segundo par | Revisão obrigatória antes de publicar |
| Equipe com processo maduro | Volume de revisão cresce e vira gargalo | Automatizar varredura de segredo e dependência |
| Setor regulado | Dado sensível colado em prompt de ferramenta pessoal | Ferramenta corporativa e bloqueio técnico |
Quadro elaborado pela Alliance Comunicação a partir de projetos de desenvolvimento assistido por IA.
Repare que em nenhuma das linhas a providência é proibir. A proibição pura tem um efeito documentado e previsível: move a prática para o computador pessoal, onde não há registro, contrato nem revisão — trocando um risco visível por um invisível.
Como medir se está dando certo?
Velocidade de entrega isolada engana, porque a dívida aparece depois. Quatro indicadores dão o quadro real.
- Tempo até a revisão aprovar. Se subiu muito, a IA está transferindo trabalho, não eliminando.
- Taxa de retrabalho em 30 dias. Quanto do que foi entregue precisou ser refeito no mês seguinte.
- Incidentes por origem do código. Só é possível medir se a origem for registrada.
- Cobertura de teste do que foi gerado. Costuma ser menor que a do código escrito à mão, e é o sinal mais precoce de dívida.
Se os quatro estiverem estáveis e a entrega acelerou, a adoção está funcionando. Se a entrega acelerou e o retrabalho subiu, a empresa antecipou o prazo e adiou o custo.
Por onde começar hoje?
Escreva uma página com a régua de quatro níveis adaptada aos sistemas que a sua empresa tem, nomeando exemplos concretos em cada nível. Regra abstrata não é seguida; regra com o nome do sistema ao lado, sim.
Depois defina duas coisas: qual ferramenta é a oficial — com contrato que impeça o uso dos dados para treino — e o que nunca pode ser colado num prompt. Essas duas decisões cobrem a maior parte do risco real.
Na Alliance, o desenvolvimento assistido por IA trabalha com essa régua desde o primeiro dia de projeto, e com registro da origem do código. Se a preocupação maior é a exposição do dado, vale ler o que reunimos sobre onde as empresas brasileiras estão na curva de adoção de IA. E se a dúvida é por qual frente começar, o diagnóstico gratuito ajuda a priorizar.