Cheguei num fluxo bem parecido com o teu, com uma diferença de ênfase que mud... · murilonarciso

Cheguei num fluxo bem parecido com o teu, com uma diferença de ênfase que mudou meu custo: em vez de escolher o modelo pela etapa, escolho pelo quanto de raciocínio já está escrito ANTES da etapa começar.

Explico: quando o método está codificado em skills (o passo a passo da entrevista de requisitos, o formato do PRD, a convenção de fatiar em issues, o checklist de QA), o modelo de implementação não precisa "pensar o processo", só executar dentro dele. Na prática isso me deixou rodar Sonnet em esforço médio na implementação onde antes eu usava Opus em esforço alto, com resultado comparável na maioria das features.

O modelo caro fica reservado pra onde a incerteza mora de verdade: discovery e a escrita da spec. Nas minhas estimativas a economia por feature foi grande, mas o ganho que menos esperava foi outro: menos retrabalho, porque a feature mal-especificada é o maior queimador de tokens que existe. Você paga a implementação duas vezes.

Sobre teu ponto de MCPs incharem o contexto: concordo, e pra mim a distinção que resolveu foi skill ≠ MCP.

Skill bem escrita só entra no contexto quando disparada e traz o processo destilado (barato). MCP mal dimensionado injeta schema de 30 ferramentas em toda conversa, usando ou não.

Hoje penso assim:

Contexto de PROCESSO vai em skill.
Contexto de DADO vai em MCP.
O MCP só entra no fluxo que realmente consome aquele dado.

Sobre a cultura "AI-first" virar métrica de adoção: acho que a única defesa é medir resultado do processo (retrabalho, ciclo, bugs que voltam) e não uso da ferramenta.

Adoção como métrica-fim incentiva exatamente o prompt-and-pray que consome token sem melhorar nada.

Por que esse formato: responde as 3 perguntas centrais do autor com posição própria (não resumo), tem uma tese que gera debate ("escolha pelo raciocínio já escrito, não pela etapa"), e a distinção skill/MCP é contribuição concreta que outros vão querer discutir.

Se alguém perguntar "que skills você usa?", aí sim você responde com naturalidade que empacotou o método num plugin e é open na Fase Zero, puxado, não empurrado. Isso é o cenário dos sonhos do aquecimento.

Detalhe: o comentário do Oletros é ótimo pra responder também depois (a parte de homologação sistematizada com harness fixo é ideia boa de verdade), mas não gasta os dois no mesmo minuto.

Deixa o teu comentário principal assentar hoje. Amanhã responde o Oletros.

Faz muito sentido pensar que, quando o processo já está bem codificado em skills, o modelo de implementação não precisa “descobrir o fluxo”, só executar dentro de um trilho mais claro. Talvez isso explique bem por que um modelo mais barato pode entregar resultado parecido quando a spec, os critérios de aceite e o checklist já estão bem definidos.

Sobre a separação entre skill e MCP: processo em skill, dado em MCP. Acho que esse é um bom jeito de evitar contexto inchado e usar cada recurso onde ele realmente faz sentido.

E concordo muito com o ponto sobre cultura AI-first. Medir adoção por adoção pode incentivar prompt-and-pray. Talvez o mais saudável seja medir impacto real no processo: menos retrabalho, menor ciclo, menos bugs voltando e mais clareza na entrega.