Recentemente, assisti a um vídeo muito interessante do Raul Cruz, no qual ele documenta o início de um projeto ambicioso: abandonar o WordPress e recriar toda a sua estrutura de vendas e a área de membros utilizando exclusivamente inteligência artificial, em um processo hoje popularmente chamado de vibe coding.
O objetivo declarado era fugir da lentidão, dos problemas de desempenho do WordPress, migrando para a “IA”. No entanto, ao analisar os primeiros minutos e a motivação por trás dessa mudança, percebe-se um conceito que vem se tornando muito comum na comunidade de marketing: a crença de que a Inteligência Artificial é uma substituta do WordPress ou de outra tecnologia web.
A inteligência artificial é um meio de criar código. As estruturas em si continuam a rodar na web e precisam de uma base para funcionar. Comparar WordPress e IA é comparar duas coisas totalmente diferentes.
E, para entender por que essa transição proposta no vídeo é mais arriscada do que parece, precisamos dissecar os problemas reais de performance, a ilusão do conteúdo estático e os perigos do chamado “vibe coding”.
1. A Confusão de Conceitos: Tecnologia Web vs. Ferramenta Gerativa
O primeiro ponto a esclarecer é a natureza das ferramentas envolvidas. O WordPress é um Sistema de Gerenciamento de Conteúdo (CMS) robusto, uma tecnologia web completa que lida com banco de dados, roteamento, autenticação de usuários e gestão de mídia. Possui mais de 20 anos de estrada e maturidade de mercado.
Por outro lado, a Inteligência Artificial (como o Claude Code ou ferramentas no Antigravity) é uma IA generativa. Ela não é uma plataforma de hospedagem ou um CMS; ela gera código. Quando você pede para a IA “clonar” um site, ela extrai o visual e gera código, possivelmente em React, Next.js ou HTML/CSS puro (linguagens de front-end).
Aqui reside o grande problema: a IA te entrega a “casca” (o front-end). Mas e o motor (o back-end)? Muita gente está tendo enormes dores de cabeça por não entender de segurança de dados.
O conceito de “vibe coding” (programar apenas conversando com a IA sem entender os fundamentos do código gerado) costuma resultar em back-ends frágeis, cheios de brechas e sem nenhuma camada de segurança robusta. Abandonar o WordPress significa abandonar um back-end validado ao longo de décadas para construí-lo do zero, muitas vezes às cegas.
2. O Diagnóstico Errado: O Culpado Não é o WordPress
Nos primeiros 10 minutos do vídeo, o autor faz uma auditoria no Google PageSpeed Insights da sua página de vendas atual (feita em WordPress com Elementor), obtendo uma pontuação muito baixa, na casa dos 39 pontos, no mobile. A conclusão imediata foi que o WordPress e o Elementor eram os culpados pela lentidão.
Porém, ao olhar com um olhar clínico para o diagnóstico, fica evidente que o site está cheio de problemas críticos de implementação, e não de limitações da plataforma.
A pontuação de performance está super baixa, começando por um erro básico e fatal: um GIF de 4 megabytes sendo carregado logo na imagem de LCP (Largest Contentful Paint).
Carregar um arquivo tão pesado na primeira dobra do site vai destruir o desempenho de qualquer página, seja ela feita em WordPress, React ou código puro. Além disso, a auditoria revela uma enxurrada de scripts de terceiros (como embeds pesados do YouTube) e, possivelmente, códigos provenientes de um número excessivo de plugins instalados.
Há indícios de falhas na estrutura de cache e até algum código JavaScript em loop que baixa arquivos de forma infinita. Nada disso é responsabilidade do WordPress. É o resultado de uma construção feita sem as devidas práticas de otimização web.
3. O Efeito “Espaguete” do Elementor e as Soluções Nativas
Construtores de páginas visuais como o Elementor são fantásticos para agilidade, mas injetam um excesso de elementos DOM (divs dentro de divs) que tornam a renderização pesada.
Até o Claude Code “apanha” para montar o clone do site devido a esse excesso de elementos. A IA, de forma inteligente, trabalha para remover o que não é estritamente necessário.
Se a busca é por performance entregando HTML rápido, a solução não exige abandonar o WordPress. O editor de sites permite criar interfaces limpas e o ecossistema possui excelentes plugins de cache (como WP Rocket, LiteSpeed, entre outros) que geram versões estáticas em HTML do seu conteúdo dinâmico, entregando velocidades absurdas sem que você perca o seu painel administrativo.
4. A Armadilha do Conteúdo Estático
Isso nos leva a um dos pontos mais cruciais dessa experiência de clonagem com IA. O clone gerado pelo Claude Code resultou em uma aplicação estática maravilhosa. Rápida, limpa e funcional. Mas pense a longo prazo: como esse conteúdo será atualizado?
No WordPress, se você quer mudar o preço de um produto de R$ 497 para R$ 297, ou alterar um parágrafo a qualquer momento, basta entrar no painel administrativo (wp-admin), editar o texto e salvar. Qualquer pessoa da sua equipe de marketing pode fazer isso.
Com o site convertido em um projeto React ou Next.js gerado por IA (sem um CMS por trás), tudo está implementado no código. Para alterar uma simples vírgula, você precisará abrir sua IDE, pedir à IA para alterar o código-fonte, realizar um build da aplicação e fazer o deploy novamente.
Se você não souber programar, ficará refém da IA (e dos custos de tokens) para cada microatualização, ou terá que pedir à IA que construa um painel administrativo completo do zero (o que volta ao problema de segurança do back-end mencionado anteriormente).
5. A Metáfora do Mestre de Obras: IA como Assistente, não como Substituto
No vídeo, é feita uma excelente analogia, comparando o desenvolvedor a um pedreiro, a IA a uma betoneira e a um ajudante. Essa é a visão correta! A IA (a betoneira) nos dá o “concreto” para construirmos muito mais rápido. Ela abstrai o trabalho maçante.
No entanto, o desenvolvedor (ou o criador do projeto) continua sendo o Mestre de Obras. E o que faz um mestre de obras excepcional não é apenas bater a massa rápido, mas também entender onde colocar as vigas de sustentação (arquitetura do projeto) e garantir que a casa não caia (segurança e manutenção).
Da mesma forma que o Raul começou um projeto novo para recriar tudo com IA, ele poderia ter usado essa mesma IA para analisar e resolver os problemas do seu WordPress atual. Hoje existem diversas Agent Skills projetadas especificamente para trabalhar e auditar ambientes WordPress. A IA poderia ter identificado o GIF pesado, otimizado os embeds do YouTube, limpado os loops de JavaScript e configurado uma estrutura de cache eficiente, salvando todo o sistema que ele já possuía.
A Conclusão e os Próximos Passos (O Desafio)
A grande verdade é: nós podemos continuar usando o WordPress como solução sem perder a flexibilidade da IA ou a facilidade de atualização do conteúdo. Com seus 20 anos de história, ele funciona perfeitamente quando as boas práticas são aplicadas.
A Inteligência Artificial não veio para matar o WordPress; veio para nos ajudar a escrever temas melhores para ele, a criar plugins mais seguros e a diagnosticar problemas de performance em segundos.
Para provar esse ponto, decidi embarcar em um desafio prático que servirá como resposta construtiva a esse vídeo. Vou tentar recriar o processo de clonagem do site dele.
Mas, em vez de pedir para a IA criar uma solução em React (que exigirá manutenção complexa e custosa), vou usar a IA para criar um tema WordPress nativo, totalmente limpo e sem a necessidade do Elementor.
Vamos comparar os resultados? Veremos como um WordPress bem feito, desenvolvido com o auxílio da IA como nosso “ajudante de obras”, pode entregar notas máximas de performance, mantendo a facilidade de gestão de conteúdo e a segurança de um back-end sólido.
Fiquem ligados nas próximas postagens, pois vou documentar todo esse processo passo a passo. A verdadeira revolução não é jogar suas ferramentas fora, mas sim usar a IA para extrair o máximo do potencial delas!
Posts Relacionados
Deixe um comentário