PMs devem construir entendimento de engenharia com IA

A tese: PMs não precisam programar, mas precisam entender engenharia com IA

Paweł Huryn, no Product Compass, dá continuidade à série "Product Engineering for PMs", inspirada em relatório da Gartner. Sua posição é que os papéis de PM e engenharia estão se aproximando: você não precisa codar, mas um PM com compreensão de engenharia construída com IA tem um perfil muito mais forte. O artigo é um guia prático, passo a passo, que leva o AskOne - alternativa ao Slido para perguntas e enquetes - de protótipo a produção sem escrever código.

Ciclo de vida leve de software com IA

O autor admite que simplificou o ciclo de desenvolvimento com IA: os prompts do template foram refinados em brainstorming com o Claude, não escritos de primeira. Ele recomenda contra processos pesados com cerimônias e artefatos, como o playbook de SDLC nativo de IA da Anthropic, destinado a empresas que não conseguem ser mais ágeis. Segundo ele, paradoxalmente, a própria Anthropic não trabalha assim: migrou de documentos de design para discussões de PR e protótipos, valida com usuários internos e permite que pods escolham seus rituais de planejamento.

O fluxo sugerido tem quatro etapas: (1) ideia - descobrir e prototipar com o Claude; (2) ideia refinada - problema, usuários, restrições e decisões de UX, registrada em markdown; (3) plano - o agente inspeciona o código e cria o plano de implementação; (4) construção - a IA implementa e roda testes de unidade, mas ainda não avalia de forma confiável mecanismos dinâmicos ou microinterações, então o PM deve verificar os cenários principais com os próprios olhos.

Modificador de papéis e cobrança por organizações

Para adicionar moderadores, o AskOne migrou a cobrança de usuários para organizações no Clerk: desativar a cobrança de usuários exigiu cancelar assinaturas ativas, definir planos Free (1 sala ativa, 100 participantes) e Premium (10 salas, 1.000 participantes) com chaves de funcionalidade (rooms_10, participants_1000) - em vez de fixar planos no código, as capacidades são liberadas por funcionalidades - e renomear o papel Member para Moderator (org:moderator). O agente então recebeu um prompt para implementar salas moderadas: perguntas ficam retidas até o host aprovar, rejeitar ou banir o participante (bloqueio por cookie; sem cookies, o usuário anônimo não pode perguntar). O Claude questionou o caso de usuário único sem moderador, e a decisão foi moderar por padrão com sinalizável na interface. Também foi pedido um landing page com pesquisa de concorrentes, tabela de preços do Clerk, documentos legais e metadados públicos.

Levando à produção

GitHub: criação de um branch de produção (askone-prod) a partir do branch de desenvolvimento. O autor testou esta etapa com o Codex, que funcionou de imediato, lendo AGENTS.md e as skills de Clerk e Supabase; só precisou autenticar um servidor MCP do Supabase separado.
Supabase: em vez de branches (que exigem plano pago), criou um projeto novo sincronizado com o branch de produção via GitHub. Mudanças de código e de banco viajam juntas por scripts de migração; os dados, não - a estrutura foi copiada sem linhas.
Netlify: o projeto da Parte 1 virou produção, apontando para o branch askone-prod, com as chaves do Supabase substituídas nas variáveis de ambiente e um novo deploy.
Domínio: comprou askone.org no GoDaddy, apontou os servidores DNS para o Netlify (a tentativa com CNAME não propagou a tempo) e o Netlify fornece certificado SSL automático. A variável APP_URL foi ajustada.
Clerk: clonagem da instância de desenvolvimento para produção, com novas chaves configuradas no Netlify e registros DNS adicionados.
Analytics: Microsoft Clarity, gratuito e sem cookies - sem banner de consentimento, com perda do rastreamento de usuários recorrentes - injetado por prompt do agente.
Google Auth: em produção, as credenciais compartilhadas do Clerk não servem; o processo envolve criar OAuth client no Google Cloud Console, verificar a marca (via Google Search Console, com registro TXT no DNS) e configurar o SSO no Clerk.

Conclusão e próximos passos

O resultado é um app SaaS multi-tenant em produção com banco, usuários, domínio e autenticação reais - sem que nenhum arquivo de código tenha sido aberto. Nos próximos passos, o autor planeja cobrir movimentação de mudanças entre ambientes, pagamentos reais com Stripe, limites por aplicação, Cloudflare como firewall, testes mais detalhados e um checklist de segurança e eficiência.