Se você leu a série “Plugin do Zero ao WP.org com IA”, leu a versão organizada, coerente e bem estruturada da jornada. Esta é a outra versão.
Preciso começar com uma confissão. Mas dessa vez é uma confissão de verdade, não um recurso narrativo.
Os 5 artigos da série foram escritos pela IA. Pelo Claude, especificamente. Eu defini o que contar, revisei cada texto, ajustei o que precisava. Mas a narrativa, a estrutura, a forma como a história é contada — é a perspectiva da IA sobre o processo. E a IA conta bonito. Organiza bem. Faz tudo parecer mais intencional do que foi.
A verdade? Foi bem mais bagunçado.
Não estou dizendo que os artigos mentem. Não mentem. Os fatos estão lá. Mas a forma como são apresentados sugere que eu sabia o que estava fazendo desde o início, que as decisões seguiram uma lógica clara, e que o método nasceu pronto. Não foi assim. E acho que contar como realmente foi é mais útil para quem está pensando em tentar algo parecido.
A lacuna que começou tudo
Lá por agosto de 2025, eu estava montando o Ecossistema FP — meus três sites integrados — e uma das peças era o Brechó da Informática, focado em curadoria de produtos tech com links de afiliados. Eu já era afiliado da Amazon e do Mercado Livre, e tinha acabado de me afiliar à Shopee, que eu queria explorar.
Fui procurar plugins para exibir os produtos de forma profissional no WordPress. E o que encontrei não me atendeu. A maioria era voltada para Amazon, com integração via API. Alguns atendiam o Mercado Livre. Mas Shopee? Nada. E eu queria algo que funcionasse com qualquer marketplace brasileiro, sem depender de API — só link de afiliado, imagem, preço e um card bonito.
Ao mesmo tempo, eu percebia que ia ser só mais um afiliado na multidão. Todo mundo divulgando os mesmos produtos, nos mesmos marketplaces, com os mesmos layouts genéricos. O que me diferenciaria?
Foi aí que pensei: e se eu criasse o plugin que está faltando? Não como programador — como alguém que entende o problema e tem IA disponível para executar. Seria um ativo de autoridade pro Ecossistema, uma prova de conceito, e resolveria meu próprio problema de quebra.
Setembro de 2025: o experimento que ninguém viu
A primeira versão do PAP — que na época nem se chamava PAP — foi um experimento cru. Um único arquivo PHP. Sem documentação nenhuma. Sem nome definido. Sem arquitetura. Eu basicamente abri uma conversa com a IA e disse algo como “quero um plugin WordPress que mostre cards de produtos afiliados com shortcode.”
E a IA entregou. Funcionou. Um card básico apareceu no meu WordPress local.
Aquele momento foi importante, porque me mostrou que a coisa tinha potencial. Que a IA realmente conseguia produzir código funcional para WordPress. Mas também percebi que era só um brinquedo — longe de algo publicável. Arquivei a ideia e voltei a focar no Ecossistema.
O que eu já sabia (e o que não sabia que não sabia)
Aqui preciso dar um contexto que os 5 artigos não dão. Quando comecei o experimento do plugin, eu já não era exatamente um iniciante em trabalhar com IA. Na parte editorial do Ecossistema FP, eu já tinha aprendido bastante.
Já tinha criado projetos no Claude com arquivos de referência. Já configurava instruções de projeto. Já sabia que a IA dá outputs melhores quando recebe contexto estruturado — eu vinha da área de TI, sabia explorar um sistema para tirar melhor proveito. Os textos produzidos para o blog já estavam ficando bons justamente por causa desses arquivos de referência.
Então, para conteúdo editorial, eu já operava num nível razoável. O que eu não estava preparado era para a diferença brutal entre pedir texto e pedir código. Texto com problema de tom ou estrutura é fácil de revisar — você lê e sente. Código com problema de segurança ou arquitetura parece funcional até explodir. E quando explode, você nem entende por quê.
Novembro de 2025: a retomada com propósito
Dois meses depois do experimento, voltei ao plugin. Mas dessa vez com uma motivação estratégica clara: o plugin seria um ativo do Ecossistema. Traria autoridade, diferenciação, tráfego. Não era mais “vou ver se consigo” — era “vou fazer porque faz sentido para o negócio.”
E é aqui que a história real diverge da versão polida dos artigos.
Os artigos sugerem que eu parei, refleti, criei 16 documentos técnicos, e aí implementei a versão final em 6 dias. Como se a documentação tivesse nascido pronta e o método fosse claro desde o início.
Na realidade, a documentação cresceu aos trancos e barrancos. A primeira especificação nasceu do experimento de setembro — eu olhei para aquele arquivo PHP único e tentei descrever o que ele fazia e o que eu queria que fizesse. Era um documento simples, mais um briefing do que uma especificação técnica.
E acho que esse é um ponto importante para quem quer começar: não espere ter documentação perfeita para dar o primeiro passo. Comece com um prompt objetivo, com referências do que quer, e vá refinando conforme aprende. Foi assim que eu comecei — antes de qualquer documento formal.
O nome que não era nome
Nos artigos, o plugin se chama “PAP Afiliados Pro” como se sempre tivesse sido assim. Não foi.
No começo era “Plugin Afiliados Pro.” Às vezes “Produtos Afiliados Pro.” O nome ficou indefinido por semanas. E isso causou um problema real: os prefixos nos nomes de arquivos, funções e variáveis estavam inconsistentes. Cada sessão de IA usava um prefixo diferente porque eu não tinha definido um padrão.
Quando tentei padronizar para publicar no WordPress.org, percebi que “PAP” — três caracteres — era curto demais para os padrões de nomenclatura. Mas eu já tinha trabalhado com esse prefixo por um tempo. Resultado: tive que fazer um reset. Migrar tudo de “pap” para “papafpro” — oito caracteres — em todos os elementos: classes, funções, constantes, CPT, taxonomias, tabelas, ações AJAX, namespace REST, handles de CSS/JS, opções, transients.
Se eu tivesse definido o nome e o prefixo antes de escrever a primeira linha de código, esse reset não teria existido. Lição aprendida da forma mais cara: naming convention não é detalhe, é fundação.
As rejeições (a versão não polida)
Os artigos falam das rejeições do WordPress.org com certa elegância. “Aprendi lições valiosas.” “Cada rejeição me ensinou.” Verdade. Mas a versão sem filtro é um pouco menos nobre.
Na primeira rejeição, recebi a mensagem do revisor e… não li tudo com atenção. Sério. Foquei nos erros que o Plugin Check apontava — os mais visíveis, os mais fáceis de entender — e fui corrigir. Tratei os problemas das mensagens de erro e resubmeti.
Voltou de novo. Segunda rejeição. E aí caiu a ficha: o problema principal que o revisor tinha apontado na primeira vez — naming convention — eu tinha ignorado. Não por arrogância. Por pressa. Por ansiedade de ver o plugin aprovado. Li o que queria ler e ignorei o que parecia “menos urgente.”
Nhééé. Esse erro me custou dias. Porque a correção de naming convention não é pontual — é sistêmica. Tive que migrar o prefixo em todos os elementos do plugin. Tudo.
A lista completa do que corrigi nessa rodada: removi biblioteca externa de clipboard (tinha que usar a do WordPress core), tirei CSS dinâmico inline e migrei para JSON + JS, troquei URLs de exemplo para example.com conforme RFC 2606, migrei o prefixo de “pap” para “papafpro” em absolutamente tudo, corrigi queries SQL removendo o padrão sprintf+esc_sql e usando só $wpdb->prepare, fiz migração completa de internacionalização com strings em inglês e tradução pt_BR, e corrigi o nome do arquivo ZIP.
Sete correções. Algumas eram simples. A do prefixo, sozinha, levou mais tempo que todas as outras juntas.
A documentação que encolheu (e ficou melhor)
Aqui tem outro ponto que os artigos não mostram. A versão polida fala em “16 documentos técnicos” como se fosse uma conquista. E era — na época. Mas depois das rejeições, eu olhei para aquela pilha de documentos e percebi que muitos tinham redundância, inconsistência, ou informação que não era mais relevante.
Decidi rever tudo. Procurei por inconsistências, cortei o que era redundante, consolidei o que podia ser consolidado. O resultado: de ~16 documentos para ~8, mais changelog e estado atual.
Menos documentos, menos linhas, menos para a IA processar em cada sessão. E paradoxalmente, mais clareza. Porque documentação boa não é documentação volumosa — é documentação precisa.
A versão 2.0 do PAP — a que foi efetivamente publicada — nasceu com essa documentação reduzida. E a implementação, do primeiro código do Milestone 1 até a versão publicada, levou praticamente uma semana. Não porque eu fosse mais rápido, mas porque os documentos eram mais limpos.
E foi nessa versão reduzida que o Guardian de Conformidade — aquele sistema de checklist que descrevo no Artigo 4 — nasceu de verdade. As 8 regras de segurança não foram inventadas numa tarde de planejamento. Foram fruto direto da auditoria de documentação, que por sua vez incorporou tudo que os revisores do WordPress.org tinham apontado. Cada rejeição virou regra. Cada correção virou padrão.
O sprint final saiu com essa base. Mas seria ingênuo dizer que a documentação cobriu tudo — não cobriu. Durante a semana de implementação, surgiram ajustes e polimentos que nenhum documento tinha previsto. Porque um projeto dessa natureza é vivo. Evolui por necessidade: feedback de revisores, problemas que só aparecem na prática, decisões que só fazem sentido quando você está no meio da implementação. A documentação é fundação, não camisa de força. E depois da publicação, o projeto continua evoluindo — por feedback da comunidade, por necessidades que o autor identifica, por contextos que mudam. Nenhum documento é definitivo. Os melhores são os que sabem crescer junto com o projeto.
O que os artigos contam como se eu soubesse de antemão
Tem uma coisa que me incomoda levemente nos 5 artigos: eles contam o processo como se eu tivesse planejado cada etapa. “Defini papéis para cada IA.” “Criei contratos técnicos.” “Implementei o Guardian de Conformidade.”
Na realidade, cada uma dessas coisas surgiu porque algo deu errado. Não foi planejamento — foi reação.
Defini papéis para as IAs porque tentar fazer tudo numa ferramenta só não funcionava. Criei documentação porque sem ela, cada sessão de IA produzia código incompatível com a anterior. Criei o Guardian porque o WordPress.org rejeitou meu plugin e eu precisava de um jeito de não repetir os mesmos erros.
Tentativa, erro, aprimoramento. Essa é a sequência real. Não planejamento, execução, sucesso.
E sinceramente? Acho que é assim que funciona para a maioria das pessoas. Você não senta num dia e desenha o método perfeito. Você começa, tropeça, ajusta, e no final olha para trás e vê um método — mas ele foi construído no caminho, não antes dele.
O que eu realmente era quando comecei
Os artigos me apresentam como “profissional com 26 anos de TI que decidiu orquestrar IAs.” É verdade. Mas falta um detalhe: quando comecei o experimento do plugin, eu era basicamente um iniciante em IA generativa.
Sim, eu já usava o Claude para conteúdo editorial. Sim, já tinha projetos configurados. Mas a distância entre “pedir para a IA escrever um artigo” e “pedir para a IA construir um sistema de software” é enorme. É como a diferença entre pedir para alguém traduzir um texto e pedir para construir uma casa. As duas coisas usam linguagem, mas a complexidade é de outra ordem.
Eu fui aprendendo no processo. Cada versão descartada me ensinou algo sobre como interagir com a IA para desenvolvimento. Cada erro me mostrou onde minha instrução tinha sido insuficiente. A documentação estruturada — que nos artigos parece uma decisão brilhante e planejada — nasceu da frustração de ver a IA produzir código inconsistente porque eu não sabia dar contexto direito.
Para quem está no ponto zero
Se você está lendo isso e está mais perto do “eu no início” do que do “eu no final,” aqui vai o que eu genuinamente sugiro:
Comece com um experimento pequeno. Sem documentação, sem arquitetura, sem pretensão. Só para ver se a IA entrega algo que funciona no contexto que você precisa. Se funcionar — mesmo que tosco — você tem algo para trabalhar.
A partir desse experimento, escreva o que ele faz e o que você quer que faça. Isso é sua primeira especificação. Não precisa ser formal. Pode ser um arquivo de texto com bullet points. O importante é que exista.
Use esse documento como referência na próxima sessão de IA. Você vai notar a diferença imediata na qualidade do output. E a partir daí, é iteração: cada problema que aparece vira uma melhoria no documento. Cada sessão fica melhor que a anterior porque o documento fica melhor.
Não tente ter tudo pronto antes de começar. Tente começar e ir documentando o que aprende. O método se constrói no caminho — eu sou prova viva disso.
Por que estou contando isso
Os 5 artigos da série cumprem um papel: mostram que é possível criar software profissional sem programar, usando IA com método. E são artigos bons — honestos, úteis, bem estruturados. Eu os assinei com convicção.
Mas faltava a versão crua. A que mostra que o “método” foi construído quebrando a cara. Que a “documentação estruturada” começou como um arquivo de texto bagunçado. Que eu não li a mensagem de rejeição inteira porque estava com pressa. Que o nome do plugin mudou três vezes antes de virar PAP.
Essa versão é menos elegante. Mas talvez seja mais útil. Porque quem está começando não se identifica com uma narrativa impecável — se identifica com alguém que também estava perdido e foi encontrando o caminho.
O PAP Afiliados Pro está no WordPress.org. É real, funciona, passou na revisão. Mas o caminho até lá teve mais curvas do que os 5 artigos mostram. E tudo bem. Porque é nas curvas que a gente aprende a dirigir.
Este artigo é um complemento da série “Plugin do Zero ao WP.org com IA”. Se você ainda não leu, comece pelo primeiro artigo: Eu não sei programar. Mesmo assim criei e publiquei um plugin no WordPress.org — veja como