Vibecoding vs WordPress: quando sites gerados por IA falham

Antes de decidir se isto é um problema para o WordPress, convém sermos precisos quanto ao termo, porque está a espalhar-se depressa e significa coisas diferentes para pessoas diferentes.

Convém também deixar uma ressalva quanto ao próprio número. Conjuntos de dados diferentes contam histórias diferentes. A W3Techs mostra a queda e o crescimento da categoria sem CMS detetável, mas é uma única medição assente num método próprio de deteção. Outras fontes põem a tónica noutros pontos. Não muda a direção, porque a direção é confirmada por várias observações independentes, mas quem atira com um só número como se fosse prova está a simplificar. O que nos interessa aqui não é a percentagem exata, é o fenómeno: parte do mercado está mesmo a afastar-se dos CMS prontos em direção a sites gerados a partir de uma instrução.

#O que é o vibecoding

O vibecoding consiste em construir uma aplicação descrevendo-a a um modelo de linguagem e aceitando o que quer que ele produza, sem ler o código linha a linha. As ferramentas são o Lovable, o Bolt.new, o v0 da Vercel, o Replit Agent e o Base44. Escreve “faz uma loja com login e pagamentos” e recebe um frontend a funcionar, uma base de dados (normalmente Supabase) e o deploy em poucos minutos.

Para um protótipo, uma ferramenta interna ou uma página de campanha que só precisa de viver uma semana, isto é genuinamente bom. Usamos exatamente assim as nossas maquetes, para mostrar uma direção ao cliente antes de alguém escrever código de produção. O problema só começa quando esse resultado vai para produção como alicerce de um negócio.

#Vibe coding vs. agentic coding em 2026

Por baixo do “deixa a IA escrever” cabem hoje duas coisas diferentes, e a distinção conta antes de decidir o que tem à frente. As ferramentas prompt-to-app (Lovable, Bolt.new, v0, Replit Agent, Base44) geram uma aplicação inteira a funcionar a partir de uma frase e escondem o código. O agentic coding é a vaga que se impôs em 2026: agentes de programação que trabalham dentro de um repositório a sério (Cursor, Claude Code e os novos IDE agênticos Google Antigravity e AWS Kiro), movidos por modelos de fronteira como o Gemini 3, que editam ficheiros, correm testes e abrem pull requests como faria um programador.

As ferramentas agênticas produzem código bastante mais fácil de manter do que a geração prompt-to-app, porque operam sobre uma base de código real com controlo de versões e não sobre uma pré-visualização selada. É uma melhoria genuína, e é por isso que o interesse de pesquisa à volta delas está a subir. É também aqui que se instala o mal-entendido: gerar melhor código não é o mesmo que responder por ele. Um IDE agêntico continua a meter uma chave do Supabase no bundle, continua a deixar uma rota de administração sem autenticação, continua a renderizar um catálogo apenas no cliente se ninguém lhe disser o contrário, porque o modelo otimiza para “a funcionalidade corre quando a testo”, não para “isto aguenta tráfego real, uma auditoria e as regras de acessibilidade da UE”. A ferramenta subiu um degrau. A distância entre uma demonstração que funciona e um sistema em produção pelo qual alguém responde não se mexeu. Seja qual for a ferramenta que o construiu, as perguntas do resto deste texto continuam as mesmas.

#Erros comuns em sites feitos com IA

Isto não é uma defesa automática do WordPress. É a lista do que aparece de facto quando alguém chega com o clássico “funcionava, e agora deixou de funcionar”:

• Chaves no bundle. O modelo mete uma chave service_role do Supabase em código que vai para o browser. Qualquer pessoa com as ferramentas de programador do navegador consegue lê-la. Ao longo de 2025, chaves expostas em aplicações feitas no Lovable e bases Supabase sem o Row Level Security ativo deixaram tabelas inteiras de utilizadores a descoberto.
• Endpoints sem autenticação. A instrução “faz um painel de administração” gera o painel, mas a rota /api/admin nunca verifica quem está a bater à porta. Parece que funciona porque o autor testa a coisa com a própria sessão iniciada.
• Sem validação nem limites. Um formulário de contacto sem rate limiting e sem sanitização torna-se uma porta aberta ao envio de spam e a tentativas de injeção.
• Invisível na pesquisa. Conteúdo renderizado apenas no cliente, sem renderização no servidor, é uma página vazia para o Googlebot. Um catálogo de produtos que não existe no HTML não entra no índice.
• Zero caminho de manutenção. Sem migrações de base de dados, sem backups, sem versionamento, sem pipeline. A primeira alteração a sério implica reescrever de raiz, porque ninguém, incluindo quem escreveu a instrução, sabe por que razão aquilo foi construído daquela maneira.
• Entrega de email à mercê do fornecedor. O formulário gerado envia as mensagens por um fornecedor gratuito sem SPF, DKIM nem DMARC. As confirmações de encomenda vão parar ao spam, e o dono só descobre pelos clientes, nunca pelo painel.
• Acessibilidade ignorada. Contraste, foco, navegação por teclado, etiquetas dos campos. O modelo gera um ecrã bonito, não uma interface acessível. Na União Europeia, com as exigências do European Accessibility Act, isto não é cosmética, é risco legal.
• Dependência de uma só plataforma. O código fica soldado a um host de preview concreto e a uma base de dados concreta. Sair desse ecossistema, quando as faturas começam a subir com o tráfego, significa uma migração para a qual ninguém se preparou.

Dois casos concretos dos últimos meses. Uma startup de Lisboa montou o painel de cliente no Bolt.new e lançou numa semana. Duas semanas depois, os utilizadores viam e editavam dados de contas alheias, porque a chave anon do Supabase estava no código e o Row Level Security nunca tinha sido ativado. Noutro caso, uma loja online do Porto foi levantada em v0. Bonita, rápida, e ao fim de três meses com tráfego zero vindo do Google, porque o catálogo inteiro só renderizava no browser. Os dois sites pareciam impecáveis no dia de lançamento. É essa a armadilha do vibecoding: a demonstração é perfeita, e a fatura chega mais tarde.

#Porque o Google e a IA não veem sites renderizados em JavaScript

Há aqui uma ironia. O vibecoding é um produto da era da IA, e os sites que produz são muitas vezes invisíveis precisamente para a IA. Se o conteúdo só aparece depois de o script correr no browser, não o veem nem o Googlebot nem os motores de resposta que alimentam as AI Overviews e funcionalidades semelhantes. Um modelo que resume a web lê HTML, não renderiza aplicações. Se o catálogo não está no HTML, não entra na resposta.

É uma dupla perda. O site perde tráfego dos resultados clássicos e ao mesmo tempo fica de fora do novo canal onde cada vez mais começa o percurso de compra. A loja do Porto que referimos acima é o exemplo típico: não só ficou fora do índice do Google como nunca chegou a existir para qualquer motor de resposta, porque o catálogo nunca esteve no HTML que uma máquina lê. A visibilidade nas funcionalidades generativas mede-se, é assunto que tratamos à parte, mas primeiro o conteúdo tem de existir no código que a máquina consegue ler. Um site construído apenas do lado do cliente nem sequer passa esse limiar.

#Porque o código gerado por IA é difícil de manter

O problema não acaba nas falhas isoladas. Está na estrutura. O modelo otimiza para que o ecrã funcione agora, não para que alguém desenvolva o código daqui a seis meses. Na prática, isto traduz-se em alguns padrões recorrentes: a mesma lógica copiada em cinco sítios em vez de isolada uma vez, ausência de separação em camadas, ausência de testes que avisem quando uma alteração parte alguma coisa, e dependências escolhidas pela moda e não pela estabilidade.

Cada uma destas coisas, isolada, até se engole. Juntas, produzem um código em que uma pequena alteração consegue partir algo distante, e ninguém dá por isso até o cliente telefonar. Manter um site não é ir acrescentando funcionalidades. É ter a certeza de que acrescentar uma funcionalidade não deita nada abaixo. O código gerado não dá essa certeza, porque ninguém o desenhou a pensar na mudança.

#Como reconhecer um site feito por vibecoding

Não é preciso ter acesso ao código. Bastam alguns sinais:

• Ver o código-fonte (Ctrl+U) mostra um <body> quase vazio e um único ficheiro grande de JavaScript. O conteúdo só aparece depois de o script carregar.
• Desligar o JavaScript deixa uma página em branco em vez de texto.
• No Google, o site não tem páginas para além da inicial, mesmo que no browser se vejam várias.
• Sem página de login no domínio próprio, ou um painel apoiado por inteiro num serviço externo sem permissões configuradas.
• Os cabeçalhos de resposta apontam para alojamento de preview (Vercel, Netlify) sem uma camada de aplicação própria.

Nenhum destes pontos isolado é uma sentença. Juntos, desenham um site que saiu de uma instrução e nunca teve alicerces.

#Vibecoding ou WordPress para um site em produção

A tabela não diz que o vibecoding é mau. Diz para que serve cada ferramenta. Para testar uma ideia num fim de semana, o vibecoding ganha sem discussão. Para um site que tem de faturar daqui a um ano, ganham os alicerces.

#O que uma auditoria a um site feito por IA verifica de facto

Quando um site destes chega até nós, não começamos por reescrever. Começamos pelo diagnóstico, porque o “funcionava, e agora deixou de funcionar” costuma ter várias camadas. A ordem é quase sempre a mesma:

1. Segurança primeiro. Se há chaves no código carregado para o browser que lá não deviam estar. Se a base de dados tem regras de acesso ativas. Se os endpoints verificam permissões. É isto que decide se o site pode sequer ficar em linha com segurança durante a reparação.
2. Renderização e índice. Se o conteúdo está no HTML ou só no JavaScript. Quantas páginas o Google vê de facto. Se há redirecionamentos, canónicos e mapa do site. É isto que responde à razão por que o tráfego orgânico não aparece.
3. Dados e continuidade. Onde estão os dados, se há cópias, se é possível exportá-los. Sem isto, qualquer decisão seguinte é arriscada.
4. Decisão: salvar ou reescrever. Só agora. Às vezes basta acrescentar a camada que faltou. Às vezes sai mais barato e mais seguro passar o conteúdo para um alicerce que se consiga manter. A auditoria diz qual dos caminhos é mais barato à escala de um ano, e não apenas nesta semana.

O essencial é que isto não é trabalho para mais uma instrução. Uma instrução não lê código alheio com a responsabilidade pelas consequências. Um engenheiro lê.

#O vibecoding vai substituir o WordPress?

A quota está a cair porque a base do mercado, os sites simples que antigamente se faziam em WordPress “por defeito”, está mesmo a migrar para a IA. E ainda bem. Era a parte menos rentável e mais descartável do mercado. O WordPress está a perder o trabalho com que, de qualquer forma, ninguém ganhava dinheiro.

O que fica é o resto: lojas WooCommerce com faturação real, sites multilingues com hreflang correto, projetos sujeitos ao RGPD, trabalho pensado para durar cinco anos e sobreviver a uma dúzia de atualizações. O vibecoding não chega lá, porque lá a tarefa não é gerar um ecrã. É um alicerce: segurança, desempenho que se mede em Core Web Vitals, manutenção e responsabilidade pelo que acontece às duas da manhã no pico da Black Friday.

O WordPress não ganha por estar na moda. Ganha por ter duas décadas de ecossistema, um caminho de manutenção previsível e uma pessoa que sabe por que razão algo foi construído daquela maneira.

#Quando não usar WordPress

Para sermos justos: nem todo o projeto é WordPress. Se está a construir uma aplicação em tempo real, um produto assente por inteiro numa única interface de programação, um painel com lógica pesada do lado do cliente, ou algo que por natureza é uma aplicação e não um site de conteúdo, há outras ferramentas que serão melhores. O WordPress conduz muito bem conteúdo, loja, integrações e visibilidade na pesquisa. Não é um martelo universal, e tratá-lo como tal acaba tão mal como pôr uma loja em cima de um protótipo vibecodado.

A diferença é que a escolha entre o WordPress, uma aplicação dedicada ou outra coisa qualquer é uma decisão de arquitetura que alguém toma de forma consciente, conhecendo as consequências. O vibecoding não toma essa decisão. Gera o que estatisticamente encaixa na instrução e deixa as consequências para depois.

#Quem responde quando um site feito por IA falha

Esta pergunta costuma surgir tarde de mais, porque só surge quando algo já correu mal. Uma instrução não tem escala de serviço. O modelo não devolve a chamada quando ao sábado à noite a loja deixa de aceitar pagamentos. O site gerado não tem um responsável técnico que conheça a sua história e saiba onde procurar.

Um alicerce não é só código. É alguém que assume a responsabilidade pelas consequências. Numa era em que cada vez mais coisas se conseguem gerar, é justamente a responsabilidade que se torna um bem escasso. Não se trata de não usar IA. Nós próprios usamo-la todos os dias. Trata-se de pôr, entre o ecrã gerado e o negócio a funcionar, uma pessoa que percebe a diferença e responde pelo que vai para produção.

#Quem revê o código de um site antes da entrega

Vale a pena olhar para o lado de quem recebe o trabalho, porque em Portugal esse lado tem duas formas muito diferentes e nenhuma delas costuma abrir o código.

A primeira é o mercado interno. Uma boa parte do trabalho em WordPress sai de estúdios pequenos e de profissionais a trabalhar sozinhos, e a entrega ao cliente resume-se a uma frase: “os acessos”. O acesso ao wp-admin e o acesso ao painel do alojamento, quase sempre um cPanel de um revendedor nacional. Não há repositório, não há ambiente de testes, não há um segundo par de olhos. O cliente confirma que o site abre e que o formulário chega ao email, e o projeto fica fechado.

A segunda forma é o trabalho feito para fora. Muita da capacidade técnica portuguesa está alocada a agências e produtos estrangeiros em regime nearshore, e aí existe revisão, mas ela vive noutro sítio. Quem revê está do lado do cliente lá fora e revê aquilo que lhe interessa: se o que foi entregue cumpre a especificação, se passa nos testes, se entra no sprint seguinte. É um filtro a sério. Também é um filtro que raramente pergunta como é que aquilo foi escrito, desde que o resultado se comporte.

Entre estes dois mundos há uma consequência prática desconfortável. Quem tem o hábito de rever código no país exerce esse hábito ao serviço de terceiros, e o cliente português de dimensão média fica com a versão sem revisão nenhuma. Não por falta de competência disponível, mas por essa competência estar noutro contrato, com outra moeda e outro fuso.

O vibecoding encaixa nesta geometria sem qualquer resistência. Para fora, entrega uma coisa que passa nos critérios visíveis de quem revê à distância. Para dentro, entrega um site bonito a quem nunca teve por hábito pedir mais do que os acessos. Em qualquer dos casos, a pergunta sobre quem responde pelo que está no servidor continua sem destinatário, e só aparece no dia em que alguma coisa deixa de funcionar.

#Quando basta o vibecoding e quando contratar um programador

Sem rodeios: para um protótipo, um MVP, uma ferramenta interna ou uma página de campanha, faça vibecoding à vontade. Rápido, barato, suficiente. Para uma loja, um site institucional, ou qualquer coisa que tenha de faturar e continuar a existir daqui a um ano, é preciso um alicerce, não um ecrã gerado.

Fica ainda a pergunta do custo, a que surge com mais frequência: se a IA fez isto num dia, a reparação devia ser barata. Nem sempre. O esforço depende da profundidade dos problemas. Se falta apenas a camada de segurança e uma renderização correta, e o conteúdo e os dados se conseguem transferir, o trabalho é limitado e previsível. Se o alicerce não existe de todo e o site já juntou clientes, dados e posições no Google, então migrar tudo isso sem perdas é um projeto maior do que construir de novo em terreno limpo. Por isso a auditoria começa pelo diagnóstico, e o orçamento é sempre individual: só depois de verificar o que há para salvar é possível dizer com rigor qual dos caminhos sai mais barato à escala de um ano.

Se já tem um site construído por IA e algo está a começar a falhar, desde fugas de dados a perda de tráfego até ao “não conseguimos evoluir isto”, costuma ter solução, mas não com mais uma instrução. Recuperamos sites feitos por IA: auditoria de segurança, SEO de raiz e uma decisão sobre o que reescrever e o que aproveitar. O trabalho é feito por um desenvolvedor que lê o código que ninguém tinha lido antes.