Onde termina a IA e começa a engenharia de software

A IA termina onde o código deixa de ser uma demonstração e passa a sustentar dinheiro, dados e usuários reais em produção. Ela gera interface, fluxos padrão e integrações comuns com uma velocidade que a engenharia tradicional não alcança.

O que ela não decide sozinha é como o sistema se comporta sob carga, como os dados de um usuário ficam protegidos de outro, e o que acontece quando algo falha às três da manhã sem ninguém olhando. Este artigo é o nosso manifesto sobre essa fronteira: os doze pontos concretos onde projetos criados com IA costumam quebrar, e o que muda quando esses pontos são levados a sério.

A promessa do Vibe Coding

A promessa é real: descrever um produto em linguagem natural e ver telas, fluxos e integrações aparecerem em minutos, não em semanas. Para quem tem uma ideia e nunca teve acesso a um time de desenvolvimento, isso é uma mudança genuína de possibilidade. Empreendedores, times de produto e até desenvolvedores experientes usam ferramentas como Claude Code, Cursor, Lovable, Replit e Bolt para tirar do papel, em dias, o que antes levava meses. Comparamos os pontos fortes de cada uma no artigo Lovable vs. Cursor vs. Claude Code.

O risco não está na promessa, está na generalização dela. Ver um protótipo funcionando bem em uma demonstração leva à conclusão apressada de que o mesmo protótipo está pronto para receber tráfego real, dados sensíveis e usuários pagantes. Essa distância entre “funciona na demonstração” e “aguenta produção” é o assunto central deste artigo.

O que a IA faz muito bem hoje

Vale reconhecer, com honestidade, onde a IA já entrega valor real e consistente. Ela gera interface de qualidade visual alta a partir de descrições simples. Ela escreve integrações com APIs conhecidas e bem documentadas de forma correta na maioria das vezes. Ela acelera drasticamente tarefas repetitivas como CRUDs, formulários e telas de listagem. Ela ajuda a explorar alternativas de design e de fluxo de usuário rapidamente, o que antes exigia protótipos manuais demorados. E ela reduz a barreira de entrada para quem tem uma ideia mas não tem, sozinho, o conhecimento técnico para implementá-la do zero.

Esses ganhos são reais e não devem ser minimizados. O problema aparece quando se assume que essa competência se estende, automaticamente, para decisões que exigem julgamento sobre riscos, escala e consequências de longo prazo, que é exatamente onde a engenharia de software profissional se torna necessária.

Onde os projetos quebram

Arquitetura. Código gerado rápido tende a misturar camadas: interface, regra de negócio e acesso a dados no mesmo arquivo, sem separação clara. Funciona bem para o primeiro protótipo e vira um obstáculo real na primeira funcionalidade nova que precisa tocar em três lugares diferentes do sistema ao mesmo tempo, aumentando o risco de quebrar algo que já funcionava.

Banco de dados. Modelagem feita sem pensar no volume real de dados e no tipo de consulta que o produto vai fazer no dia a dia gera lentidão que só aparece quando o número de registros cresce, não durante os testes com poucos dados de exemplo. Índices ausentes, chaves estrangeiras mal definidas e ausência de estratégia de migração de esquema são erros comuns que ficam invisíveis até o produto ter uso real.

Autenticação. Login funcionando não significa autenticação segura. Senhas armazenadas de forma inadequada, tokens sem expiração definida e fluxos de recuperação de senha vulneráveis a manipulação são falhas frequentes em sistemas gerados rápido, porque o “login funciona” no teste manual esconde exatamente esse tipo de problema.

Autorização. Diferente de autenticação (quem é o usuário), autorização define o que cada usuário pode fazer. É a falha mais comum em produtos gerados com IA: a interface esconde botões que um usuário “não deveria” ver, mas a API por trás não verifica a permissão, permitindo que qualquer pessoa logada acesse ou altere dados de outra conta apenas manipulando uma chamada direta.

Segurança. Chaves de API expostas no código do front-end, ausência de limite de tentativas em formulários de login, dados sensíveis trafegando sem criptografia adequada. Nenhum desses problemas impede o produto de “funcionar” no dia a dia, o que os torna especialmente perigosos: ficam invisíveis até serem explorados.

Integrações. Integrar um serviço de pagamento, envio de e-mail ou armazenamento de arquivos é fácil no caminho feliz. O que a IA raramente trata bem sozinha é o comportamento quando essas integrações falham: timeout, resposta de erro inesperada, indisponibilidade temporária do serviço externo. Sistemas sem tratamento de falha de integração param completamente quando um serviço terceiro tem uma instabilidade momentânea.

APIs. Ausência de versionamento de API significa que qualquer mudança em um endpoint pode quebrar clientes que já dependem dele, incluindo aplicativos móveis instalados que não atualizam na hora. Documentação inconsistente e formatos de resposta que mudam sem aviso são problemas comuns em APIs geradas sem planejamento de evolução.

Testes. Código gerado rápido raramente vem acompanhado de testes automatizados relevantes. Isso significa que cada nova funcionalidade corre o risco real de quebrar uma funcionalidade anterior sem que ninguém perceba até um usuário reportar o problema, muitas vezes depois de já ter causado dano.

Performance. Consultas que funcionam bem com dez registros de teste podem levar segundos com cem mil registros reais. Sem monitoramento de performance e sem testes de carga antes do lançamento, esse tipo de problema só aparece quando já afeta usuários reais, no pior momento possível: quando o produto está crescendo.

Deploy. Publicar uma atualização sem ambiente de teste separado do de produção, sem plano de rollback e sem verificação automatizada antes de liberar para todos os usuários é um convite a incidentes evitáveis. Deploy feito de forma manual e sem processo é uma das causas mais comuns de indisponibilidade em produtos jovens.

Observabilidade. Sem logs estruturados, sem monitoramento de erros e sem alertas configurados, a primeira notícia de que algo quebrou costuma ser a reclamação de um cliente, não um alerta do próprio sistema. Isso transforma qualquer incidente em uma investigação às cegas, atrasando a correção justamente quando a velocidade de resposta mais importa.

Evolução. Um sistema construído sem preocupação com manutenibilidade fica cada vez mais caro de alterar conforme cresce. Cada funcionalidade nova demora mais para ser adicionada do que a anterior, porque o código foi otimizado para sair rápido na primeira vez, não para ser modificado com segurança meses depois.

Vibe Coding profissional: a definição

Vibe Coding profissional é o uso de IA para acelerar a criação de código combinado com prática de engenharia de software para garantir que esse código aguente produção: arquitetura pensada, banco de dados modelado com cuidado, autenticação e autorização levadas a sério, segurança revisada, testes relevantes, observabilidade configurada e um processo de deploy confiável. Não é IA no lugar de engenharia, é IA acelerando a produção de código com engenharia garantindo que esse código sobreviva ao mundo real.

Essa é a definição que estrutura nossa página sobre Vibe Coding profissional: o ponto de encontro entre a velocidade que a IA entrega e a solidez que só disciplina de engenharia garante, aplicado de forma consistente nos mais de 200 projetos que já entregamos ao longo de mais de 15 anos de experiência.

Como isso muda o mercado de software

O efeito prático dessa mudança é a redução do tempo entre “ideia” e “primeira versão testável”, sem eliminar a necessidade de conhecimento técnico sério, apenas deslocando onde esse conhecimento é mais necessário. Antes, boa parte do tempo de um time técnico ia para escrever código repetitivo. Agora, esse tempo pode ir para as decisões que realmente definem se um produto sobrevive: arquitetura, segurança, modelagem de dados, e a leitura crítica do que a IA gerou antes de ele chegar a produção.

Isso também muda o perfil de quem lidera projetos de software: menos tempo digitando código linha a linha, mais tempo revisando, decidindo e garantindo que o que foi gerado rápido não vire uma dívida técnica cara de pagar depois. Discutimos esse deslocamento de papel em detalhe no artigo sobre se o Vibe Coding substitui programadores: a resposta curta é que ele muda o trabalho, não elimina a necessidade de quem entende engenharia.

Para empresas que já têm um time usando IA para desenvolver e sentem que chegaram perto desses doze pontos sem saber exatamente como resolvê-los, esse é o tipo de apoio que o Vibe Squad oferece: reforço de engenharia focado exatamente nas frentes onde produtos gerados rápido costumam quebrar.

Conclusão

A IA não é o problema, e fingir que ela resolve tudo sozinha também não é a solução. Os doze pontos descritos aqui (arquitetura, banco de dados, autenticação, autorização, segurança, integrações, APIs, testes, performance, deploy, observabilidade e evolução) são onde a experiência de quem já colocou produto em produção faz a diferença entre um protótipo que impressiona por uma tarde e um produto que sustenta um negócio. Vibe Coding profissional é justamente essa combinação: Vibe Coding para criar, engenharia para colocar em produção.