Uma empresa recebe uma proposta de desenvolvimento mais barata porque boa parte do código será produzida por inteligência artificial. A possibilidade parece atraente, mas a resposta curta é: o vibecoding pode reduzir o custo de desenvolvimento de software em partes específicas do projeto, não garantir uma economia fixa nem transformar código gerado rapidamente em solução pronta. O resultado depende do escopo, da qualidade dos requisitos, da complexidade técnica, da maturidade da equipe e do nível de supervisão profissional.
A diferença decisiva está no que acontece depois da geração. Se a IA acelera protótipos, tarefas repetitivas ou alterações bem delimitadas, pode reduzir esforço em uma etapa. Se passa a decidir arquitetura, segurança, regras de negócio e evolução do sistema sem revisão, a economia inicial pode reaparecer como retrabalho, vulnerabilidade, indisponibilidade e dependência técnica. Por isso, avaliar vibecoding no desenvolvimento de software exige olhar para o custo total de propriedade, não apenas para o preço da primeira entrega.
Vibecoding não é sinônimo de desenvolvimento assistido por IA
Vibecoding é um uso corrente para descrever a criação, alteração e depuração de software a partir de instruções em linguagem natural, com forte participação de ferramentas de IA e, em alguns casos, pouca compreensão direta do código produzido. O termo ainda não representa uma norma técnica formal. Ele descreve mais uma forma de trabalhar do que uma tecnologia específica.
No desenvolvimento de software assistido por IA, o profissional também usa modelos para pesquisar, sugerir código, escrever testes, explicar erros ou preparar documentação. A diferença está na responsabilidade: ele continua compreendendo o problema, definindo limites, escolhendo a arquitetura, validando o comportamento e decidindo o que pode chegar à produção. A ferramenta pode participar da implementação; não deve receber automaticamente a autoridade sobre o sistema.
A economia acontece em pontos específicos da arquitetura
A IA tende a ser mais útil quando existe uma tarefa delimitada e um critério claro de verificação. Em termos práticos, ela pode preparar um protótipo para testar uma hipótese, sugerir estruturas repetitivas, converter dados, criar testes iniciais, resumir documentação técnica, investigar uma mensagem de erro ou propor uma pequena alteração em uma base já conhecida. Nesses casos, o possível benefício não está na quantidade de linhas produzidas, mas na redução do esforço em uma etapa que ainda será conferida.
Um cenário hipotético ajuda a separar as coisas: uma empresa pode usar IA para montar uma primeira versão de uma tela interna e descobrir se o fluxo atende à operação antes de financiar uma solução completa. Isso pode diminuir o custo de aprendizado. O exemplo não prova uma porcentagem de economia e não elimina o trabalho posterior de estruturar dados, permissões, autenticação, tratamento de erros, testes e manutenção.
A pergunta profissional é: qual parte ficou mais barata sem aumentar o risco? Uma resposta séria identifica a etapa economizada, o critério de aceitação, o tempo de revisão e o impacto caso a implementação precise ser descartada. Se a proposta fala apenas em velocidade de geração, mas não explica como a solução será validada e sustentada, o cálculo está incompleto.
O limite prático: o que não deve ser delegado ao modelo
Arquitetura define como o sistema será dividido, onde os dados circularão, quais componentes dependerão uns dos outros e como a solução poderá crescer. Regras de negócio determinam o que a empresa aceita, rejeita, cobra, registra ou comunica. Segurança envolve permissões, exposição de dados, credenciais, auditoria e resposta a incidentes. Essas decisões dependem de contexto operacional e responsabilidade, não apenas de padrões encontrados em exemplos de código.
Também não é prudente delegar ao modelo, sem supervisão, o tratamento de dados sensíveis, pagamentos, integrações críticas, exigências regulatórias, observabilidade ou decisões de evolução. Uma sugestão tecnicamente plausível pode estar errada para aquela operação. O código pode executar sem erro e ainda representar uma regra comercial incorreta, registrar informação demais ou criar uma dependência difícil de substituir.
IA escreve código. O desenvolvedor decide qual código deve existir.
Erros baratos de gerar e caros de sustentar
O risco não está apenas em a IA produzir uma linha incorreta. Uma solução pode acumular dependências desnecessárias, duplicação de lógica, validações incompletas, testes frágeis e documentação que não explica as decisões importantes. Também pode incluir credenciais em locais inadequados ou conceder permissões mais amplas do que o necessário. Cada problema parece pequeno enquanto o sistema é novo, mas pode dificultar correções, auditorias e mudanças futuras.
Há ainda um risco de dependência técnica: quando somente a ferramenta ou a pessoa que a utilizou consegue explicar como o sistema funciona. Nesse cenário, a empresa perde capacidade de avaliar uma alteração, trocar de fornecedor ou responder a um incidente. A velocidade inicial deixa de ser economia quando a continuidade da operação depende de conhecimento que não foi documentado nem revisado.
Até 90%: como analisar uma promessa sem comprar uma ilusão
A afirmação de que o vibecoding pode reduzir custos em até 90% deve ser tratada como uma estimativa atribuída a terceiros, não como resultado garantido. Não há, nas evidências fornecidas para este artigo, estudo que sustente uma economia universal desse tamanho. O número pode estar relacionado a uma tarefa muito específica, a um protótipo, a um recorte do trabalho de programação ou a uma comparação que não inclui revisão, testes e manutenção.
Há pelo menos três medidas diferentes: economia na escrita de código, redução do esforço total de desenvolvimento e redução do custo de propriedade ao longo da operação. A primeira pode ser expressiva em tarefas repetitivas. A segunda depende de análise, arquitetura, validação e implantação. A terceira inclui correções, atualizações, incidentes, documentação, contratação de profissionais e capacidade de evoluir o sistema. Confundir essas medidas produz uma proposta atraente, mas tecnicamente frágil.
Antes de aceitar uma porcentagem, peça as premissas: qual escopo foi comparado, que tipo de projeto foi considerado, quem fará a revisão, quais testes existem, quais ferramentas serão usadas e o que acontece quando a IA produzir uma resposta incorreta. A estimativa também deve ser confrontada com o custo de corrigir uma decisão arquitetural ruim depois que dados e usuários já estiverem dentro do sistema.
Governança mínima para usar IA sem perder o controle
Governança, neste contexto, não precisa significar um processo pesado. Significa tornar visíveis as decisões e definir quem pode aprovar uma mudança. O projeto deve manter controle de versões, revisão por outra pessoa quando o risco justificar, testes automatizados e manuais, proteção de dados enviados às ferramentas, documentação das escolhas relevantes e critérios claros para publicação.
Em sistemas que sustentam uma operação, a integração contínua e a entrega contínua podem ajudar a executar verificações antes da publicação. Ainda assim, automatizar o processo não elimina a responsabilidade humana. É preciso saber quais testes existem, quais cenários não estão cobertos, como observar o comportamento em produção e como reverter uma alteração que cause impacto.
A governança também deve prever a manutenção. Ferramentas, modelos e bibliotecas podem mudar. Por isso, a empresa precisa conservar o acesso aos repositórios e ambientes, registrar dependências, proteger credenciais e garantir que outra pessoa consiga compreender e corrigir o sistema. Esse cuidado transforma a IA em instrumento de produtividade, em vez de criar uma nova camada de dependência.
O teste de quatro perguntas antes de aprovar o projeto
Uma proposta baseada em código gerado por IA precisa responder a quatro perguntas simples para o decisor. Elas não substituem uma análise técnica, mas revelam se existe responsabilidade definida ou apenas entusiasmo com a ferramenta.
- Quem define a arquitetura, os limites do escopo e as decisões que não serão delegadas ao modelo?
- Como cada alteração será revisada e quem poderá rejeitar código que funciona, mas não atende à operação?
- Quais testes automatizados e manuais demonstrarão que regras, integrações, permissões e cenários de erro estão corretos?
- Quem documentará, monitorará e manterá o sistema depois da entrega, inclusive quando a ferramenta de IA mudar?
Comparação: onde cada abordagem faz sentido
A comparação abaixo é um modelo analítico para apoiar uma decisão de arquitetura, não o resultado de um estudo de caso. O ponto central é que velocidade inicial, qualidade verificável e custo de propriedade são critérios diferentes.
| Critério | Código gerado sem supervisão | IA usada com supervisão profissional | Desenvolvimento sem uso de IA |
|---|---|---|---|
| Velocidade inicial | Pode parecer alta, mas não indica conclusão do projeto | Pode aumentar em tarefas delimitadas e verificáveis | Depende da competência e do processo da equipe |
| Qualidade verificável | Incerta; depende de revisão posterior | Avaliada por testes, revisão e critérios de aceite | Depende da competência e do processo da equipe |
| Custo de propriedade | Pode crescer com retrabalho, falhas e dependência técnica | Mais previsível quando há documentação, controle e manutenção | Também exige arquitetura, testes, segurança e continuidade |
A decisão final não é usar ou proibir vibecoding
A escolha mais responsável costuma ser proporcional ao risco. Protótipos, pesquisas técnicas e tarefas repetitivas podem permitir maior liberdade, desde que o resultado seja descartável ou verificável. À medida que entram pagamentos, dados sensíveis, regras regulatórias, integrações críticas ou processos essenciais, aumentam as exigências de revisão, testes, segurança, documentação e continuidade.
O papel de Nélio pode ser compreender o problema, definir a arquitetura, separar o que pode ser acelerado pela IA e acompanhar a evolução da solução. O objetivo não é proibir uma ferramenta nem prometer uma porcentagem de economia. É decidir onde ela reduz esforço sem transferir para o modelo a responsabilidade por contexto, segurança, regras de negócio e operação.
Fontes consultadas
- Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
- About GitHub Copilot code review
- Responsible use of GitHub Copilot Chat in GitHub
- Application card: GitHub Copilot inline suggestions
- Vibe Coding Explained: Tools and Guides
- What is Vibe Coding?