Este artigo faz parte da série “Plugin do Zero ao WP.org com IA”, onde documento a jornada real de criação do PAP Afiliados Pro — com acertos, erros e aprendizados.
Preciso começar com uma confissão que talvez devesse ser constrangedora, mas que na verdade é o ponto central de tudo o que vou contar aqui: eu não sei programar. Nunca soube. Em 26 anos trabalhando com tecnologia — infraestrutura, redes, segurança, consultoria — nunca escrevi um sistema, nunca mantive um repositório de código, nunca abri um terminal para fazer deploy de coisa nenhuma.
E mesmo assim, em fevereiro de 2026, eu publiquei um plugin profissional no diretório oficial do WordPress.org. Com 20 classes PHP, banco de dados próprio, painel administrativo completo, sistema de tracking LGPD-compliant e aprovação dos revisores do WordPress — que são voluntários exigentes e não têm nenhuma obrigação de ser gentis com o seu código.
Não estou contando isso para impressionar. Estou contando porque, se você trabalha com tecnologia e já teve aquela ideia de ferramenta que resolveria um problema real, mas travou no “mas eu não sei programar” — esse artigo é para você.
Mas o que me deu na cabeça de criar um plugin?
Eu trabalho com marketing de afiliados. Faço curadoria de produtos tecnológicos, publico análises no meu site e uso links de afiliados de marketplaces brasileiros — Amazon, Mercado Livre, Shopee, Magazine Luiza. Quem trabalha com isso sabe: exibir esses produtos de forma profissional no WordPress é uma dor.
As opções que existiam não me atendiam. Plugins gringos que não entendem o mercado brasileiro. Soluções genéricas que exigem gambiarras para funcionar com os marketplaces daqui. Blocos do Gutenberg que geram cards feios e sem personalização. Ou então plugins premium caros que fazem 500 coisas quando eu precisava de 5, e fazem essas 5 de forma mediana.
Eu queria algo simples: cadastrar um produto afiliado, definir marketplace, preço, link, imagem, e exibir um card profissional no post com um shortcode. Com personalização visual, tracking de cliques, e que funcionasse bem no celular. Era isso.
Olha só — passei meses procurando essa ferramenta e não achei. Em determinado momento, parei e pensei: será que o problema não é achar, é criar? E foi aí que a coisa ficou interessante.
O conceito que mudou tudo: arquiteto, não programador
Eu tenho um MBA em Marketing Digital e 26 anos de bagagem técnica. Eu entendo arquitetura de sistemas. Entendo banco de dados, fluxo de dados, segurança, lógica de negócio. O que eu não sei é a sintaxe — o “como escrever” o código. E curiosamente, isso nunca me fez falta. Nunca me pareceu um impedimento. Lá no começo da carreira até iniciei um curso de Lógica de Programação no Senac, mas rapidamente percebi que me identificava com infraestrutura, não com desenvolvimento. Segui por esse caminho e construí 26 anos de carreira sem precisar escrever uma linha de código.
Quando comecei a trabalhar com inteligência artificial de forma mais séria, percebi uma coisa: a IA sabe a sintaxe. A IA escreve PHP, JavaScript, CSS sem pestanejar. O que a IA não sabe, pelo menos não sozinha, é tomar decisões de arquitetura, definir prioridades, entender o contexto do negócio, fazer trade-offs entre o ideal e o viável.
E sabe quem sabe fazer isso? Quem tem experiência.
A analogia que uso é a do arquiteto e o pedreiro. O arquiteto desenha a planta, define os materiais, calcula a estrutura. Ele não levanta a parede — mas sem ele, a parede cai. O pedreiro executa com maestria, e bom pedreiro vale ouro — qualquer um que já fez reforma sabe disso. Mas o melhor pedreiro do mundo precisa de um projeto para entregar algo que vai além do funcional. Nem sempre isso acontece, não é mesmo? Aqui no Brasil tem obra que sobe sem engenheiro, sem arquiteto, tudo de cabeça. Às vezes funciona. Às vezes vira problema. Com software é a mesma coisa.
No meu caso, eu sou o arquiteto. A IA é a equipe de execução. Eu defino o que precisa ser feito, por que, em que ordem, com quais restrições. A IA traduz isso em código funcional.
Quando essa ficha caiu, percebi que o meu impedimento não era técnico. Era conceitual. Eu estava olhando para o problema errado.
Os 3 meses que mudaram minha perspectiva
Preciso ser honesto aqui: não foi um final de semana. Não foi um “hackathon de IA”. Foram 3 meses de trabalho dedicado — quase integral em muitos dias.
Eu comecei do zero absoluto. Literalmente. Nunca tinha usado GitHub. Não sabia o que era um commit, um branch, um pull request. Tinha o Local WP instalado por conta do desenvolvimento de sites WordPress — mas isso era só para rodar temas e testar plugins, nada a ver com ambiente de desenvolvimento de verdade, com versionamento, debug, linting. Não sabia como funciona o sistema de plugins do WordPress por dentro — eu só usava plugins, nunca tinha olhado a estrutura de um.
O primeiro mês foi basicamente aprender o terreno. Entender como o WordPress organiza plugins, o que são hooks e filters, como funciona o painel admin, o que o diretório WordPress.org exige para aprovar um plugin. Tudo isso com auxílio de IA, mas a decisão de o que aprender e em que ordem era minha.
Não vou romantizar: foi frustrante em vários momentos. Eu chegava a 70% de uma versão funcional e percebia que a base estava errada. Que eu tinha deixado a IA resolver problemas de forma isolada, sem uma visão do todo. O código funcionava, mas era uma colcha de retalhos — cada pedaço feito numa conversa diferente, sem consciência do que veio antes.
Joguei fora pelo menos duas versões quase completas. E não foi por problema de código — foi por problema de arquitetura. Que era, teoricamente, a minha responsabilidade.
Nhééé. Doeu. Mas foi o aprendizado mais valioso de todo o processo.
A virada: quando parei de pedir código e comecei a documentar decisões
Lá pelo segundo mês, depois de descartar mais uma versão, eu parei e refleti sobre o que estava dando errado. E a resposta era simples, daquelas que a gente não quer enxergar: eu estava tratando a IA como um programador freelancer que recebe demandas soltas. “Faz isso aqui.” “Agora ajusta aquilo.” “Adiciona essa feature.” Sem contexto. Sem arquitetura. Sem documentação.
Foi aí que pensei: se eu estivesse liderando uma equipe real de desenvolvedores, o que eu faria diferente? A resposta era óbvia — eu documentaria tudo. Especificação técnica. Contrato de dados. Padrões de nomenclatura. Requisitos de segurança. Fluxo de cada funcionalidade.
E foi exatamente o que fiz. Comecei a criar documentos técnicos — eu chamo de “contratos” — para cada aspecto do plugin. Um contrato para a camada de dados: quais tabelas, quais campos, quais tipos, quais índices. Um contrato para o frontend: como os cards são renderizados, quais variáveis estão disponíveis, como funciona o sistema de templates. Um contrato para segurança: quais validações são obrigatórias, como sanitizar inputs, como escapar outputs.
No total, foram 16 documentos técnicos. Dezesseis. Para um plugin que, visto de fora, “só mostra cards de produto”.
Parece exagero? Na minha experiência, foi exatamente o oposto. Esses documentos se tornaram a memória do projeto. Quando eu iniciava uma nova conversa com a IA — porque cada sessão começa do zero, sem memória das anteriores — eu alimentava com os contratos relevantes. A IA não precisava adivinhar o contexto. Sabia quais prefixos usar, quais padrões seguir, quais restrições respeitar.
O resultado foi que a versão final — a que foi de fato submetida e aprovada — levou 6 dias de desenvolvimento focado. Seis dias. Porque os 2 meses e meio anteriores tinham construído algo mais valioso que código: um sistema de decisões documentadas.
O que o plugin faz (sem marketing, só fatos)
O PAP Afiliados Pro é um plugin gratuito para WordPress voltado ao mercado brasileiro de afiliados. O que ele entrega, na prática:
Você cadastra produtos afiliados com nome, descrição, preço, link de afiliado, imagem e marketplace. O plugin gera cards profissionais que você insere em qualquer post ou página via shortcode. Tem um Template Builder visual que permite personalizar cores, bordas, espaçamentos — tudo com preview em tempo real, sem tocar em código. Suporta grid e lista, funciona bem no celular, e rastreia cliques com conformidade LGPD.
Tem painel de estatísticas com gráficos, importação e exportação por CSV, sistema de tags para organizar produtos, presets de template para reuso rápido. E tudo isso com as validações de segurança que o WordPress.org exige — nonces, capabilities, sanitização, escaping, SQL preparado.
Não é o plugin mais sofisticado do mundo. Mas faz o que promete, faz bem, e passou no crivo dos revisores do WordPress.org. Para quem não é programador, isso é mais do que eu imaginava ser possível quando comecei.
O WordPress.org não é gentil — e não deveria ser
Ah, sobre essa parte da aprovação. Eu preciso falar sobre isso porque é central para a história: ter o plugin aceito no diretório WordPress.org não é só dar upload de um ZIP. Existe um processo de revisão manual onde voluntários analisam seu código linha por linha.
Eles procuram vulnerabilidades de segurança. Verificam se você sanitiza todos os inputs. Se escapa todos os outputs. Se usa nonces em cada formulário e requisição AJAX. Se suas queries SQL são preparadas corretamente. Se seus prefixos estão padronizados. Se suas strings estão prontas para tradução. E se qualquer uma dessas coisas estiver errada, o plugin volta com uma lista de correções obrigatórias.
O meu plugin voltou. Mais de uma vez.
Não vou entrar nos detalhes aqui — o Artigo 3 dessa série é dedicado inteiramente a isso. Mas preciso dizer: cada rejeição me ensinou mais do que qualquer tutorial. Porque o revisor não te diz “faça assim”. Ele te diz “isso aqui está inseguro” e espera que você descubra como resolver.
E foi justamente a documentação estruturada que me salvou nesses momentos. Quando o revisor apontava um problema de segurança, eu conseguia mapear para o contrato técnico correspondente, identificar a falha, e gerar uma correção consistente em todo o projeto — não só no ponto que o revisor indicou.
Para quem isso serve, de verdade
Eu sei o que você pode estar pensando: “Tá, Fernando, mas você tem 26 anos de TI. Isso não é exatamente ‘não saber programar’.” E é justo. A minha bagagem técnica me deu vocabulário para conversar com a IA em termos de arquitetura. Eu sabia o que era uma tabela relacional, um endpoint, uma validação de input — mesmo sem nunca ter implementado nada disso.
Mas o ponto que quero deixar claro é outro: o que fez esse projeto funcionar não foi conhecimento de programação. Foi método. Documentação. Capacidade de articular problemas complexos em partes gerenciáveis. E essas são habilidades que qualquer profissional experiente tem, em qualquer área.
Se você é designer e entende UX, pode arquitetar uma interface complexa e usar IA para implementar. Se você é analista de dados e entende modelagem, pode projetar um sistema de dados e usar IA para codificar. Se você é gestor de projetos e entende fluxos e dependências, pode liderar um desenvolvimento com IA de forma estruturada.
O que não funciona — e eu aprendi isso da pior forma possível — é chegar na IA e dizer “me faz um plugin que faz isso, isso e aquilo”. A pessoa quer algo robusto com um prompt de uma frase. Sem contexto, sem especificação, sem documentação. Aí sim, o resultado é código que funciona por acidente e quebra por design.
O que vem por aí
Esse é o primeiro artigo de uma série de cinco onde vou documentar o processo inteiro. Não como tutorial — como case real. Com as decisões que deram certo, as que deram errado, os números concretos, e os aprendizados que não estão em nenhum curso de “como usar IA para programar”.
No próximo artigo, vou mostrar como organizei a orquestração de múltiplos AIs — sim, mais de um — para trabalhar de forma coordenada no mesmo projeto. Como defini papéis diferentes para cada ferramenta e por que isso foi essencial.
Se você chegou até aqui e se identificou com alguma parte dessa história, acompanhe a série. E se quiser ver o resultado, o PAP Afiliados Pro está disponível gratuitamente no diretório WordPress.org.
Não porque seja perfeito. Mas porque é real. E porque prova que o caminho entre “eu tenho uma ideia” e “eu tenho um produto publicado” pode ser mais curto do que parece — desde que você pare de tentar ser o programador e comece a ser o arquiteto.
Próximo artigo da série: Como organizei múltiplos AIs para desenvolver software profissional sem escrever código
Navegação da série:
▶ Próximo artigo: Como organizei múltiplos AIs para desenvolver software profissional sem escrever código