Vibecoding vs WordPress

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 e a vaga de ferramentas de 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.

#Onde os sites feitos por vibecoding falham

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.

#Invisível para o Google e também para a IA

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 é 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 vs WordPress 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ê.

#Porque este não é o fim do 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 o WordPress também não é a resposta

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 algo corre mal

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.

#Quando o vibecoding faz sentido, e quando ligar a um sénior

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.