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.
Esse é o último artigo da série. Nos quatro anteriores, contei que não sei programar, mostrei como organizei múltiplos AIs como equipe, compartilhei as lições de segurança que aprendi com rejeições, e expliquei o sistema de Guardian de Conformidade que criei para não repetir erros.
Agora quero fazer algo diferente: mostrar os números reais. A timeline completa. As decisões que tomei e por quê. O que custou em tempo e esforço. E o que eu faria diferente se começasse hoje.
Sem filtro, sem romantização. Dados de um projeto real feito por um não-programador com IA.
Os números, de uma vez
Antes de contar a história, os fatos secos:
Duração total: aproximadamente 3 meses de trabalho dedicado, quase integral em muitos dias. Isso inclui aprendizado, versões descartadas, documentação e implementação final.
Versões descartadas: pelo menos 2 versões quase completas foram para o lixo antes da versão final.
Implementação da versão final: 6 dias de desenvolvimento focado, com documentação completa já pronta.
Documentos técnicos criados: 16 contratos cobrindo arquitetura, dados, frontend, segurança, nomenclatura, admin, tracking, estatísticas, release e mais.
Classes PHP: 20 classes no plugin final.
Tabelas no banco de dados: 4 tabelas próprias.
Milestones de desenvolvimento: 8 milestones estruturados na versão final, cada um com blocos de implementação e validação.
Rodadas de revisão no WordPress.org: mais de uma. Cada uma com aprendizados concretos.
Ferramentas de IA utilizadas: 3 principais — Claude Chat para arquitetura, CCW para implementação, ferramentas especializadas para debug pontual.
Custo financeiro em ferramentas: assinatura do Claude Pro. Nenhum investimento adicional em ferramentas, servidores ou serviços pagos.
Esses números contam uma história que vale a pena destrinchar.
Mês 1: Aprendendo o terreno
O primeiro mês foi quase inteiramente de aprendizado. Eu nunca tinha usado GitHub. Não sabia a diferença entre commit e push. Não entendia como o WordPress organiza plugins internamente — hooks, filters, actions, o loop de carregamento. Eu usava WordPress há anos, mas como usuário. Por dentro, era território desconhecido.
Nesse período, fiz o que faço com qualquer tecnologia nova: mergulhei na documentação e fui testando. Só que em vez de testar sozinho, testava com IA. Pedia para o Claude explicar conceitos, depois pedia exemplos práticos, depois tentava montar algo simples. Um plugin que só mostrava uma mensagem no admin. Depois um que salvava dados. Depois um com shortcode.
Cada experimento era pequeno e descartável. Não estava construindo o PAP ainda — estava construindo entendimento.
O erro desse mês: comecei a ficar ansioso para ter algo funcional. A tentação de pular do “aprender” para o “fazer” é forte. E no final do primeiro mês, cedi. Comecei a versão 1 do plugin sem ter documentação nenhuma, só com a empolgação de quem viu que a IA realmente produzia código funcional.
Mês 2: O vale das versões descartadas
Esse foi o mês mais caro em tempo e mais valioso em aprendizado.
A versão 1 chegou a uns 70% de funcionalidade. Os cards renderizavam, o painel admin existia, dava para cadastrar produtos. Mas o código era uma colcha de retalhos. Cada funcionalidade implementada numa sessão diferente de IA, com premissas diferentes, sem padrão de nomenclatura, sem arquitetura de segurança. Funcionava, mas era frágil. Eu sentia que se tocasse em qualquer coisa, tudo podia desmoronar.
Joguei fora e comecei a versão 2. Dessa vez com um pouco mais de planejamento — criei alguns documentos básicos de referência. Melhorou. Chegou a 80%. Mas aí tentei adicionar o Template Builder e percebi que a estrutura de dados não suportava o que eu precisava. O banco estava modelado errado. E quando o banco está errado, não tem refatoração que salve — precisa repensar do zero.
Joguei fora de novo.
Nhééé. Dois meses de trabalho e nada para mostrar. Nesse momento, a maioria das pessoas desiste ou começa a questionar se o projeto faz sentido. Eu também questionei. Mas o problema que eu queria resolver continuava real — exibir produtos afiliados de forma profissional no WordPress. E a cada versão descartada, eu entendia melhor o que o plugin precisava ser.
Foi no final do mês 2 que aconteceu a virada que descrevi no Artigo 1: parei de pedir código e comecei a documentar decisões. Se cada sessão de IA começa do zero, a única forma de manter consistência é ter documentação tão boa que qualquer sessão nova produza código compatível com as anteriores.
Sentei e escrevi os 16 contratos técnicos. Demorou uma semana. Parecia improdutivo — nenhuma linha de código novo nesse período. Mas foi a semana mais importante do projeto inteiro.
Mês 3: Os 6 dias que valeram 3 meses
Com os contratos prontos, a implementação final foi rápida de uma forma que me surpreendeu. O que antes levava semanas de tentativa e erro agora fluía em horas.
Os 8 milestones estavam definidos antes de escrever a primeira linha de código:
O primeiro milestone cobriu a fundação — estrutura de arquivos, classe principal, ativação, desativação, criação de tabelas. O segundo, a camada de dados — CRUD completo de produtos com toda a segurança. O terceiro, o painel admin — listagem, formulários, bulk actions. O quarto, o Template Builder — personalização visual com preview em tempo real. O quinto, o sistema de shortcodes — renderização frontend dos cards. O sexto, tracking de cliques e estatísticas. O sétimo, importação e exportação CSV. O oitavo, testes finais, otimização e preparação para submissão.
Cada milestone tinha seus contratos de referência, seus requisitos de segurança explícitos, e seus critérios de validação. O prompt para cada bloco de implementação seguia o template do Guardian de Conformidade — contexto, documentos, conformidade obrigatória, implementação, validação.
Seis dias. Cada milestone levava entre meio dia e um dia inteiro. O ritmo era intenso mas sustentável porque eu não precisava tomar decisões arquiteturais durante a implementação — todas já estavam tomadas e documentadas. O trabalho era montar o prompt, alimentar o CCW, validar o resultado, ajustar o que precisasse, seguir para o próximo bloco.
Teve momentos de frustração mesmo dentro desses 6 dias — um bug de CSS que só aparecia no Safari, um conflito entre o color picker do WordPress e o JavaScript do Template Builder, uma query de estatísticas que funcionava com 10 produtos mas ficava lenta com 100. Nada disso era problema de arquitetura. Eram problemas pontuais, resolvíveis, que não ameaçavam a base do projeto. E essa é a diferença brutal entre implementar com documentação e implementar no improviso: os problemas que aparecem são pequenos, não estruturais.
O que antes eram meses de idas e vindas viraram menos de uma semana de execução focada. Não porque eu tivesse ficado mais inteligente. Porque o processo tinha ficado mais inteligente.
As decisões que fizeram diferença
Olhando para trás, consigo identificar 5 decisões que foram determinantes para o resultado:
A primeira foi escolher o escopo com rigor. O PAP Afiliados Pro faz cards de produto afiliado para marketplaces brasileiros. Não faz comparação de preços. Não faz integração com APIs. Não faz gestão de links automática. Cada feature que pensei em adicionar passei por um filtro: isso é essencial para a versão 1, ou é desejo? Se era desejo, ia para o roadmap futuro. Esse filtro evitou semanas de escopo inflado.
A segunda foi documentar antes de implementar. Já falei bastante sobre isso, mas vale repetir: se eu pudesse voltar no tempo e dizer uma única frase ao Fernando do mês 1, seria “escreve os contratos antes de pedir código.”
A terceira foi separar papéis entre as IAs. Claude Chat para pensar, CCW para executar. Quando misturei os papéis — pedindo para o Claude Chat implementar ou para o CCW definir arquitetura — o resultado ficou pior nos dois casos. Cada ferramenta tem seu ponto forte.
A quarta foi aceitar que jogar fora faz parte. As versões descartadas não foram desperdício. Foram iterações de aprendizado que informaram a versão final. Se eu tivesse insistido em “consertar” a versão 1, estaria até hoje tentando remendar uma base errada.
A quinta foi tratar segurança como fundação, não como acabamento. Depois da primeira rejeição do WordPress.org, segurança virou o item número 1 de qualquer implementação. Não o último. Não “quando der tempo.” O primeiro.
O que eu faria diferente
Nem tudo foram boas decisões. Se eu fosse começar o projeto do zero hoje, mudaria algumas coisas.
Teria criado os contratos técnicos antes de escrever qualquer código. Teria economizado pelo menos 6 semanas de versões descartadas.
Teria estudado as guidelines do WordPress.org com profundidade logo no início. Não por cima — inteiras. Especialmente a parte de segurança. Metade dos problemas que tive na revisão teriam sido evitados se eu tivesse lido as guidelines com atenção antes de submeter.
Teria investido mais tempo em entender o Plugin Check desde o primeiro milestone. É a ferramenta oficial do WordPress para validar plugins antes de submeter. Não pega tudo, mas pega o básico. Rodar isso desde cedo teria me poupado surpresas.
Não teria tentado fazer tudo sozinho em silêncio. Participar mais cedo dos fóruns de desenvolvimento WordPress, ler reviews de outros plugins, entender os padrões da comunidade — tudo isso teria acelerado meu aprendizado e evitado alguns becos sem saída.
E teria documentado a jornada desde o dia 1, não no final. Essa série de artigos seria muito mais rica se eu tivesse anotações diárias do processo.
Para quem está pensando em começar
Se você leu essa série inteira e está pensando em criar algo com IA — um plugin, uma ferramenta, um produto digital — deixa eu te dizer o que eu gostaria que alguém tivesse me dito antes de começar.
O caminho é mais longo do que os tutoriais prometem. Ninguém faz um plugin profissional em um final de semana com IA. Não se for para publicar de verdade. Mas o caminho é mais curto do que você imagina, se tiver método.
Método supera talento. Eu não tenho talento para programação. Tenho disciplina para documentar, verificar, e persistir. E isso foi suficiente para publicar um plugin no diretório oficial do WordPress.
IA amplifica, não substitui. Se você entende o problema, a IA acelera brutalmente. Se não entende, a IA gera a ilusão de progresso. Saber a diferença é o que separa projetos que vão a algum lugar de projetos que ficam rodando em círculos.
Comece pela documentação, não pelo código. Eu sei que é contra-intuitivo. Eu sei que a tentação é pedir código e ver algo funcionando na tela. Mas cada hora investida em documentação economiza um dia de retrabalho. Isso não é figura de linguagem — é a minha experiência real.
E por último: aceite que vai dar errado. Várias vezes. O que importa não é evitar o erro — é construir um sistema que transforma erro em aprendizado e aprendizado em prevenção. Isso é o Guardian de Conformidade em essência, mas também é, mais amplamente, como qualquer projeto complexo funciona.
O balanço final
Três meses. Dezesseis documentos. Vinte classes. Oito milestones. Mais de uma rodada de revisão. Um plugin publicado no WordPress.org.
Tudo isso feito por alguém que não sabe programar, usando IA como equipe de desenvolvimento e documentação estruturada como cola que mantém tudo junto.
Não vou dizer que foi fácil. Não foi. Não vou dizer que qualquer pessoa consegue. Depende do que você já sabe, do quanto está disposto a aprender, e da honestidade para reconhecer o que não sabe.
Mas se você tem experiência em qualquer área técnica, entende o problema que quer resolver, e está disposto a investir mais tempo em planejamento do que em execução — o caminho existe. Está documentado. E este case prova que funciona.
O PAP Afiliados Pro está disponível gratuitamente no diretório WordPress.org. Não como vitrine de ego — como prova de conceito. De que método e documentação, combinados com IA, podem produzir software profissional que passa no crivo mais exigente do ecossistema WordPress.
Se essa série te ajudou de alguma forma, já valeu o esforço de escrevê-la. E se te inspirou a começar algo, melhor ainda.
Agora sim — é isso.
Essa é a conclusão da série “Plugin do Zero ao WP.org com IA”. Os artigos anteriores estão disponíveis no blog: Artigo 1 | Artigo 2 | Artigo 3 | Artigo 4
Se quiser acompanhar o que vem por aí — o PAP tem um roadmap de evolução com Gutenberg blocks, templates avançados, e muito mais — assine a newsletter ou me siga nas redes.
Navegação da série:
◀ Artigo anterior: Como transformei rejeição em sistema: o Guardian de Conformidade que não deixa erro passar