Engenharia assistida por IA, não vibe coding: a diferença que importa

Vibe coding, um termo que se espalhou ao longo de 2025, significa descrever o que quer a uma IA, aceitar o que quer que ela produza e iterar por intuição até o resultado parecer certo. É uma forma legítima de explorar uma ideia. É rápido, barato e genuinamente divertido. O que não é, é engenharia, porque nada no ciclo verifica que o software se comporta corretamente, se mantém seguro ou pode ser alterado em segurança no mês seguinte. O resultado é julgado a olho, e o processo não deixa registo do que mudou, porquê, ou se alguém verificou.

A engenharia assistida por IA mantém a velocidade e elimina a adivinhação. A IA continua a escrever o código, mas cada alteração aterra dentro de uma disciplina de entrega: é versionada num branch, verificada contra políticas, exercitada por testes automatizados, analisada e sondada quanto a problemas de segurança, e implementada através de um pipeline controlado com um caminho de rollback. Um humano aprova as alterações que acarretam consequências, e um registo de auditoria documenta que o fez. O prompt é o mesmo. Tudo o que acontece depois do prompt é diferente.

A distinção não é académica. Determina se aquilo que construiu pode guardar dados de clientes, passar uma revisão de segurança, sobreviver à saída do seu autor ou ser entregue a uma segunda equipa. Se a resposta a alguma destas perguntas precisa de ser sim, é o modo de construir, não o modelo que constrói, que o decide.

O termo começou como um elogio, uma forma de nomear como a geração se tinha tornado fácil, e transformou-se num rótulo de aviso quando a primeira vaga de apps construídas com IA encontrou utilizadores reais. Nada no aviso é anti-IA. Os modelos não são o problema; o sistema em falta à volta deles é que é, e o mesmo modelo colocado num ciclo de entrega governado produz software que uma empresa pode defender. É por isso que o argumento aqui é sobre arquitetura de processo, não sobre escolha de modelo, e é por isso que se aplica seja qual for o fornecedor de IA que preferir. Aplica-se também a todas as dimensões: uma startup de duas pessoas pode fazer vibe coding de forma responsável sabendo de que lado da linha está; um banco não se pode dar ao luxo de não saber.

A maioria das equipas encontra este problema no momento da passagem de testemunho. Alguém no marketing, nas operações ou no produto constrói por vibe coding uma ferramenta que funciona suficientemente bem para as pessoas começarem a depender dela. Depois precisa de SSO. Depois guarda algo pessoal. Depois um diretor pergunta quem revê as alterações, e a resposta honesta é ninguém. Nesse ponto, as opções são feias: reconstruí-la como deve ser, adotá-la tal como está e herdar um risco desconhecido, ou matar uma ferramenta que as pessoas já usam.

O custo aparece em três livros de contas. Primeiro, o retrabalho: protótipos que não conseguem graduar-se são reconstruídos do zero, o que significa que o caminho rápido era afinal o caminho lento. Segundo, a exposição de segurança: código gerado sem revisão vai para produção com os padrões de acesso e as dependências que o modelo calhou de escolher, e ninguém sabe dizer o que lá está dentro. Terceiro, os estrangulamentos de revisão: quando a IA multiplica o volume de alterações mas a capacidade de revisão e de testes fica na mesma, ou a entrega abranda para o ritmo antigo ou o escrutínio cai discretamente. Nenhum dos dois é o resultado pelo qual alguém comprou uma ferramenta de IA.

Há também um custo organizacional que raramente chega aos diapositivos: a confiança. A primeira ferramenta vibe-coded que corrompe dados ou expõe um registo torna cada proposta futura construída com IA mais difícil de aprovar. As equipas que estabelecem disciplina cedo mantêm a sua licença para andar depressa. As equipas que a saltam costumam ter direito a um incidente, e depois a uma moratória.

Se lidera a engenharia, a versão mais afiada da dor é a assimetria da culpa. O negócio celebra a velocidade das ferramentas construídas com IA até ao momento em que uma falha, e a falha aterra na engenharia, mesmo quando a engenharia nunca viu a ferramenta. Essa dinâmica faz do caminho governado a jogada de interesse próprio, não apenas a responsável: a única resposta duradoura à construção não sancionada é uma forma sancionada de construir que seja igualmente rápida. As proibições não sobrevivem ao contacto com uma ferramenta que resolve o problema de segunda-feira de manhã de alguém; melhores predefinições, sim.

Um autoteste rápido. Consegue nomear as últimas três alterações à app e quem as aprovou? Se a app se partisse agora mesmo, alguma coisa além de um utilizador o avisaria? Um colega conseguiria reverter a alteração de ontem sem si na sala? Alguma coisa trava automaticamente uma publicação quando um fluxo de início de sessão se parte? Se respondeu não mais do que uma vez, está a fazer vibe coding. Chame-se o que se chamar a sua ferramenta.

Nada disto é um argumento contra prototipar por intuição. A exploração é de onde vêm os bons produtos, e forçar a disciplina completa num ensaio descartável faz perder tempo a toda a gente. O padrão de falha não é prototipar; é os protótipos tornarem-se silenciosamente produção porque ninguém traçou a linha. Decida onde fica a linha antes de a ferramenta a atravessar, e faça da travessia um ato deliberado com uma checklist. Não uma acumulação gradual de utilizadores. Se quiser uma versão estruturada desse autoteste, o scorecard de risco de vibe coding percorre-o pergunta a pergunta.

Corra o mesmo teste também ao nível do portefólio. A maioria das organizações não tem uma app construída com IA; tem dezenas, em estados variados de disciplina, e nenhuma lista. Um inventário com donos nomeados, mesmo uma folha de cálculo tosca, converte um risco desconhecido num risco gerido, e costuma revelar duas ou três ferramentas que se tornaram discretamente críticas enquanto ninguém estava a olhar. Esses são os seus primeiros candidatos ao caminho governado, ordenados por sensibilidade dos dados e número de utilizadores, e não por quem grita mais alto.

O Automo foi construído para que o caminho rápido e o caminho disciplinado sejam o mesmo caminho. Descreve a app em linguagem simples e o Automo gera aplicações reais em React, TypeScript e Supabase que são suas. Mas cada alteração aterra dentro do ciclo de entrega, e não ao lado dele. O Guardrails mapeia o código em áreas de negócio, deteta alterações arriscadas, aplica políticas em linguagem simples, regista a revisão humana e deixa um registo de auditoria por trás de cada merge. O QA executa repetições determinísticas em navegador, testes autorreparáveis, smoke gates antes da publicação e verificações de produção depois dela. O Security executa análise estática, verificação de dependências e sondagens de controlo de acesso, e confirma vulnerabilidades contra a app ao vivo antes de as sinalizar.

O resultado é que um protótipo e uma app de produção não são dois artefactos diferentes no Automo. São o mesmo artefacto com níveis de escrutínio diferentes, com o escrutínio aplicado pela plataforma em vez de por quem se lembra. O código é React, TypeScript e Tailwind padrão, exportável para o seu próprio repositório a qualquer momento, pelo que a disciplina nunca se torna uma jaula. Para equipas que gerem programas de produção sérios, o argumento cabe numa linha: engenharia assistida por IA, não vibe coding. Os programas de desenvolvimento sérios começam em 10.000 USD por ano; uma demonstração é a forma mais rápida de ver o ciclo correr de ponta a ponta.

Uma nota de honestidade: nenhuma plataforma torna a disciplina gratuita. As políticas continuam a ter de ser escritas, as zonas protegidas declaradas, e alguém continua a ser dono das decisões de julgamento sobre alterações sinalizadas. O que uma plataforma muda é a predefinição. No Automo, o caminho indisciplinado é o que exige esforço extra, o oposto de como a maioria das ferramentas funciona. Na prática, é essa inversão que decide se os padrões de uma equipa sobrevivem ao contacto com um prazo.