logo
ia

O teu projeto foi vibe coded? Eis o que encontro quando pego no código

7 min de leitura
O teu projeto foi vibe coded? Eis o que encontro quando pego no código

"Funciona no meu ecrã"

A cena repete-se cada vez mais. Alguém contacta-me com um projeto web ou uma aplicação SaaS. O protótipo existe, a interface está impecável, e a pessoa está orgulhosa de me mostrar o que construiu. "Fiz tudo com IA, sem escrever uma linha de código." Depois acrescenta: "Mas há alguns bugs."

Esses "alguns bugs" são, regra geral, a parte visível do iceberg.

Desde o início de 2025, retomei vários projetos que tinham sido inteiramente gerados por IA. Não por programadores que usam IA como acelerador (isso faz parte do meu dia a dia, e é muito diferente), mas por pessoas não técnicas que usaram Claude, Cursor, Bolt ou outras ferramentas para construir o seu produto de A a Z. O famoso vibe coding.

Não estou aqui para criticar esta abordagem. A acessibilidade da criação de software é uma revolução. Mas há uma realidade que ninguém conta: o que acontece quando o protótipo tem de se tornar um produto a sério.


O padrão que encontro sempre

Cada projeto é diferente, mas os problemas de fundo são surpreendentemente semelhantes. Não é uma questão de linguagem ou de framework. É uma questão de fundações.

Sem base técnica sólida

Quando um programador experiente arranca um projeto, começa por definir a arquitetura. A estrutura de pastas, a tipagem dos dados, as convenções de nomenclatura, a gestão de erros, as variáveis de ambiente, a configuração do linting e da formatação. Não é código "útil" no sentido funcional, mas é o que faz o projeto aguentar-se ao longo do tempo.

Um projeto vibe coded, por outro lado, arranca diretamente para o funcional. A IA gera o que lhe pedem: um formulário, uma página, uma ligação a uma API. Funciona. Mas não há esqueleto por baixo. Sem tipos partilhados entre o front e o back. Sem validação do lado do servidor. Sem gestão centralizada de erros. Cada feature é uma ilha, ligada às outras por fios invisíveis que partem assim que se toca em alguma coisa.

A base de dados é, muitas vezes, o caos

Este é provavelmente o problema mais grave e mais frequente. A base de dados é o coração de qualquer projeto, e é aí que encontro os estragos mais importantes.

Sem migrações versionadas, por isso impossível saber como o schema evoluiu. Relações entre tabelas que não estão corretamente definidas, ou que são geridas do lado da aplicação em vez do lado da base de dados. Campos duplicados porque a IA criou uma nova coluna em vez de reutilizar a que já existia. Dados sensíveis armazenados em texto simples. E por vezes, o mais traiçoeiro: funciona em local, porque a IA contornou as restrições de integridade em vez de as respeitar.

No dia em que fazes deploy em produção com utilizadores reais, tudo desmorona.

Segurança? Que segurança?

Este é o ponto que mais me faz ranger os dentes. Em praticamente todos os projetos vibe coded que retomei, a segurança era, na melhor das hipóteses, parcial, na pior, inexistente.

Vi APIs sem qualquer autenticação. Tokens armazenados no localStorage sem expiração. Queries SQL construídas por concatenação de strings. Formulários sem proteção CSRF. Uploads de ficheiros sem validação de tipo nem de tamanho. Chaves de API escritas diretamente no código fonte, enviadas para o GitHub em público.

O problema é que a IA gera código que funciona. Responde ao pedido: "faz-me um login". E faz um login. Mas não pensa espontaneamente em tudo o que rodeia esse login: a gestão de sessões, o rate limiting, o hashing das passwords, a proteção contra injeções. São reflexos que um programador interiorizou ao longo de anos de prática. A IA faz o que lhe pedem. Nem mais, nem menos.

Código que funciona, mas impossível de manter

Imaginemos que passas por todos os problemas anteriores. A tua aplicação funciona, está em produção, há pessoas a usá-la. Ótimo. Agora queres adicionar uma feature. Ou corrigir um bug. Ou alterar o comportamento de um componente.

E aí deparas-te com um muro.

O código gerado por IA tem uma característica muito particular: é frequentemente localmente correto mas globalmente incoerente. Cada ficheiro, analisado individualmente, parece limpo. Mas o conjunto não segue nenhuma lógica de arquitetura. O mesmo padrão está implementado de três formas diferentes em três ficheiros diferentes. Funções utilitárias são duplicadas em vez de partilhadas. As dependências entre os módulos formam um esparguete impossível de desemaranhar.

Resultado: por cada hora passada a adicionar uma feature, passas três a perceber o que já existe e a tentar não partir nada.


Porque é que isto acontece (e a culpa não é da IA)

Quero ser muito claro quanto a isto: o problema não é a IA. A IA é uma ferramenta extraordinária. Uso-a todos os dias no meu trabalho e transformou a minha produtividade.

O problema é a ausência de supervisão técnica.

Quando trabalho com o Claude Code, sei o que lhe pedir, sei avaliar o que produz, e sei quando está a ir pelo caminho errado. Não porque sou melhor do que a IA, mas porque tenho o contexto de negócio e a experiência para julgar se o código é bom, manutenível e seguro.

Uma pessoa não técnica que faz vibe coding é como alguém que usa um GPS sem conhecer as estradas. Enquanto o GPS funciona, tudo bem. No dia em que propõe um itinerário absurdo, não te apercebes. Segues. E acabas num beco sem saída.


Reparar ou recomeçar? A pergunta que dói

Esta é a primeira pergunta que me fazem as pessoas que me contactam. "Conseguimos salvar o que existe?"

A resposta honesta: depende, mas muitas vezes recomeçar é mais rápido.

Não porque o código é "mau" no sentido estético do termo. Mas porque o tempo necessário para compreender a lógica implícita, identificar os efeitos colaterais, corrigir as falhas de segurança, reestruturar a base de dados e tornar o código manutenível ultrapassa frequentemente o tempo que seria preciso para reconstruir de forma limpa a partir do zero.

E sobretudo: quando reconstróis, partes de fundações sólidas. O protótipo vibe coded não se perde. Serve como especificação funcional. É um rascunho interativo que mostra o que o produto deve fazer. Isso é valioso. Mas não é o produto final.


O que isto significa para ti

Se estás a construir um projeto com IA e não tens formação técnica, não faz mal. Mas é preciso ter consciência disso.

O vibe coding é genial para validar uma ideia. Queres ver se o teu conceito faz sentido? Queres testar um percurso de utilizador? Queres mostrar um protótipo a investidores ou a primeiros utilizadores? Avança. A IA vai permitir-te ir rápido e testar hipóteses sem investir dezenas de milhares de francos.

Mas o momento em que queres passar do protótipo ao produto é o momento em que precisas de alguém que perceba o que se passa debaixo do capô. Não para deitar tudo fora e recomeçar do zero (mesmo que por vezes seja a melhor opção), mas para fazer um diagnóstico honesto sobre o que aguenta e o que não aguenta.


Uma auditoria demora quanto tempo?

Em poucas horas, consigo dizer-te em que ponto está o teu projeto. O que funciona, o que é frágil, o que é perigoso. Não um relatório de 50 páginas, mas um diagnóstico concreto com prioridades claras: o que é preciso corrigir agora, o que se pode manter, e o que vale mais a pena reconstruir.

Se tens um projeto que foi vibe coded e te perguntas se é viável para o futuro, falamos. Sem jargão, sem julgamentos, apenas um olhar profissional sobre o que existe.

Porque o pior cenário não é ter feito vibe coding. É continuar a construir sobre fundações que não aguentam.

Envoyer un email
Toni Dias

Toni Dias

Engenheiro de software e parceiro técnico — AsuOs

Pronto para transformar o seu negócio digital?

Toni Dias apoia-o na sua estratégia digital com soluções à medida.