A Staff Architect Skill: Projetando Produtos com IA

A maioria dos times usa IA para escrever código mais rápido. Eu uso para não tomar decisões arquiteturais ruins às 23h sob pressão de sprint.

A Staff Architect Skill não é um gerador de documentação. É um parceiro de raciocínio que questiona ativamente antes de deixar você avançar.

O problema

Projetos de produto falham não por falta de código, mas por falta de rigor nas decisões que antecedem o código. Discovery vago gera escopo elástico. Arquitetura apressada gera dívida técnica. ADRs ausentes geram debates circulares sobre decisões já tomadas.

Quem sofre são engenheiros seniores e tech leads trabalhando em produtos novos sem um parceiro de raciocínio estruturado — seja por time pequeno, seja por ausência de cultura de design review.

O problema central: o rigor de um Staff Engineer em decisões de produto e arquitetura não deveria depender de ter um Staff Engineer disponível no seu time.

Por que uma Skill e não uma Rule

Uma Rule seria "sempre use o método de 10 fases" — pesado demais para toda conversa, inclusive aquelas em que você está renomeando uma variável.

Uma Skill é "quando for projetar um produto, ative o Staff Architect" — comportamento sob demanda, com custo de contexto proporcional ao momento em que é realmente necessário.

O método envolve fases sequenciais com gates, questionamento ativo que bloqueia o avanço e decisões separadas por reversibilidade. Isso é comportamento, não contexto passivo.

O que cada fase entrega

Discovery — um problem statement validado com Jobs-to-be-Done, personas identificadas e métricas de sucesso definidas. Não "aumentar engajamento", mas "reduzir o tempo médio de triagem de fornecedor de três dias para quatro horas".

Definition — um PRD com escopo fechado, requisitos funcionais e não funcionais, critérios de aceite mensuráveis. A Skill questiona ativamente: este requisito é do produto ou da solução que você já tem em mente?

Strategic Design — opções arquiteturais analisadas com trade-offs, decisão de build vs. buy vs. open-source, e os primeiros ADRs.

Architecture — diagrama de sistema, modelo de dados, contratos de API, componentes e suas responsabilidades. Toda decisão não óbvia vira um ADR.

Execution — WBS com milestones, estimativas de esforço por fase, dependências críticas, riscos mapeados.

As fases restantes cobrem governança de acesso, SLIs/SLOs e observabilidade, threat model STRIDE, documentação técnica para usuários e operadores, e roadmap de evolução pós-MVP.

As regras de comportamento que fazem funcionar

Ela nunca gera código antes da arquitetura ser aprovada — mesmo diante de "dá pra fazer só essa parte rapidinho?". O atalho de hoje é a dívida de amanhã.

Ela nunca pula fases, mesmo sob pressão. Pule o Discovery e o PRD sairá errado. Pule o PRD e a arquitetura vai resolver o problema errado.

Ela interroga a origem dos requisitos: o problema é real ou é uma solução procurando problema? O requisito veio de evidência ou de opinião?

E separa decisões reversíveis de irreversíveis, aplicando rigor proporcional. Nome de variável é reversível — decida rápido. Modelo de multi-tenancy é irreversível — vale uma tarde de análise.

O que ela não é

Não é um gerador de documento bonito. Qualquer LLM produz um PRD de aparência plausível em trinta segundos. Esta Skill não gera documentos — ela questiona até você ter clareza suficiente para que a documentação seja honesta.

Não é um oráculo de stack. "Qual banco usar?" não é uma pergunta que ela responde por você. Ela apresenta os trade-offs e força você a decidir com base nos seus constraints reais: equipe, escala, budget de operação.

Não é mais rápida que um dev sênior que já conhece o domínio. Ela é útil precisamente quando esse sênior não está disponível, ou quando você precisa de um segundo par de olhos estruturado.

O que saiu disso

Rodar um SaaS de compliance inteiro pelo método produziu dez fases documentadas, doze ADRs cobrindo desde o modelo de multi-tenancy até retenção de dados e observabilidade, um WBS de cerca de 290 horas estimadas, um threat model STRIDE e um plano de evolução pós-MVP — antes de uma linha significativa de código de produção existir.

Essa última parte é o ponto inteiro. Os erros caros foram discutidos no papel, onde custam uma tarde em vez de um trimestre.