Como um gerente de produto sem background técnico montou dois pilotos em uma semana com Claude e Kiro

Um gerente de produto sem experiência prática de desenvolvimento descreveu um caso em que, em uma semana, montou e lançou dois pilotos de trabalho com a ajuda de Claude, Kiro, Figma Make e servidores MCP. A história é interessante não apenas pelo resultado em si, mas também por como muda a barreira de entrada para o lançamento de primeiras versões de um produto sem uma equipe de engenharia completa.

Do que é feito o stack

Na base do fluxo está a divisão de papéis entre várias ferramentas de IA. Claude Sonnet 4.5 foi usado pelo autor para descoberta: público, pontos de dor, jobs-to-be-done, limitações e valor de negócio eram carregados ali. Na saída obtinham-se análises, conteúdo e prompts para os próximos estágios. Figma Make era responsável pela geração do frontend, e Kiro da Amazon — pela montagem, decisões arquiteturais e deploy. Como infraestrutura, utilizou-se Supabase para banco de dados, GitHub Pages para hospedagem e servidores MCP para contexto e testes.

• Claude Sonnet 4.5 — descoberta, análise, conteúdo e prompt do sistema
• Figma Make — geração do frontend para a versão piloto
• Kiro — montagem do projeto, documentação de soluções e deploy
• Supabase e GitHub Pages — banco de dados e publicação
• Context7 e Playwright via MCP — memória entre sessões e verificações e2e básicas

Esse conjunto é interessante porque não tenta forçar uma ferramenta a fazer tudo de uma vez. O autor distribuiu tarefas de acordo com os pontos fortes de cada serviço e assim reduziu a quantidade de edições manuais. Segundo sua avaliação, apenas na etapa de análise e design foi possível economizar cerca de 40 horas — precisamente porque os artefatos da descoberta passavam para a geração da interface e depois para a montagem com mínimas perdas.

Fluxo passo a passo

O processo começava não com código, mas com a definição do problema. Para cada produto, criava-se um assistente separado no Claude, ao qual se passava todo o contexto: quem é o usuário, que problema o serviço resolve, o que conta como valor e quais limitações não podem ser violadas. Depois disso, os materiais eram transferidos para Figma Make, onde um frontend era gerado sem refinamento manual. No caso, tratava-se de dois projetos: um site pessoal de consultoria em produtos e uma ferramenta ágil gratuita que o autor considera como uma alternativa inicial ao Jira para startups.

O próximo passo era passar o frontend e as análises para Kiro. O autor destaca especialmente essa ferramenta como o centro de todo o pipeline, porque Kiro primeiro formula as soluções por escrito e depois as implementa, sem pular direto para o código. Depois disso, conectavam-se três servidores MCP: Context7 para manter o contexto entre sessões, Supabase MCP para esquema de banco de dados e migrações, Playwright MCP para verificar cenários críticos do usuário.

O estágio final parecia maximamente prático: registro no GitHub e Supabase, criação de banco de dados, deploy no GitHub Pages e instruções para vinculação de domínio.

Onde estão os pontos críticos

O autor formula diretamente a limitação principal: esse fluxo funciona bem para pilotos e MVPs, mas não resolve questões de qualidade no caminho para produção completa. Se o produto for projetado para alta carga, integrações complexas ou suporte de longo prazo, a arquitetura ainda precisa ser revisada por uma pessoa. Isso especialmente se aplica às decisões que Kiro pode tomar automaticamente: o artigo observa que algumas delas parecem questionáveis sem uma revisão técnica básica.

O mesmo se aplica às janelas de contexto: Context7 ajuda a não perder o fio do projeto, mas não faz o problema da memória desaparecer completamente.

"Vibe-coding não é substituição para desenvolvedores."

Outro risco está relacionado aos testes. Playwright MCP, segundo a observação do autor, cobre com segurança o happy path, ou seja cenários básicos, mas não elimina a necessidade de verificar separadamente edge cases. Portanto, o stack descrito parece uma ferramenta para verificação rápida de uma hipótese e um processo previsível para um gerente de produto não técnico; sua fraqueza é a necessidade de trazer um engenheiro em tempo oportuno quando o piloto começa a se transformar em um produto real.

O que isso significa

O caso demonstra uma mudança na economia do lançamento: hoje um gerente de produto ou founder pode montar um piloto de trabalho sem contratar uma equipe e semanas de preparação, se conseguir formular claramente requisitos e montar ferramentas em um fluxo consistente. Mas essa também é a limite da abordagem: a IA acelera o primeiro lançamento, não a disciplina de engenharia, quando um produto começa a crescer.