A Parte 1 deste playbook estabeleceu o paradigma: Agente = Modelo + Harness, os 8 pilares de um Harness de produção, o método R.P.I., a arquitetura de contexto em 3 camadas e a escala de maturidade L0, L4. Conceito coberto. Mas conceito sem ferramenta tática vira slide de keynote. Esta Parte 2 entrega o que ficou de fora: as ferramentas analíticas e operacionais que permitem aplicar o paradigma sem improviso.
Cinco peças que separam um time que entende o discurso de um time que executa: (1) o pipeline de refatoração guiada por IA em 4 estágios, (2) a análise de acoplamento tridimensional de Khononov (Força, Distância, Volatilidade), o framework matemático para decidir limites modulares, (3) o caso Velora como contraponto ao PayPal: workflow AI-First aplicado a equipes enxutas em vez de operação enterprise, (4) o Blueprint do Desenvolvedor IA-Nativo como stack vertical de quatro camadas, e (5) a costura com o Framework de Adoção Corporativa em 7 fases que já documentamos em post próprio. Tudo o que faltava para fechar o ciclo.
Pipeline de Refatoração Guiada por IA: os 4 estágios
Refatorar codebase legado com IA é o caso onde Vibe Coding falha mais espetacularmente. Você pede "refatore esse módulo", o agente reescreve metade do sistema com arquitetura inventada, apaga testes, quebra dependências invisíveis e te entrega um PR que ninguém vai conseguir revisar. O playbook AI-Native trata refatoração como pipeline em quatro estágios estritamente sequenciais, cada um com saída auditável.
Estágio 1, Detecção de Anomalias
Mapeamento de code smells e desvios estruturais via IA. Antes de tocar em uma linha, você usa o agente para diagnosticar: onde estão as duplicações reais (não só as que aparecem no linter), quais classes acumulam responsabilidade demais, quais módulos têm acoplamento cíclico, onde a hierarquia foge da convenção do resto do repositório. Saída: relatório em Markdown listando anomalias com referência a arquivo e linha. Esse relatório é o input do próximo estágio, não input direto de execução.
Estágio 2, Padronização
Resolução de duplicações com o objetivo dual de melhorar o código e reduzir consumo de tokens futuros. Código padronizado é mais barato pro agente processar, não é só estética, é economia de janela de contexto em cada task subsequente. Você aplica os fixes em ordem de impacto: as três ou quatro duplicações que aparecem em mais lugares primeiro, porque cada uma delas vai gerar economia composta nas próximas execuções do agente. Saída: PR pequeno e cirúrgico por padronização, com Test Gate associado.
Estágio 3, Consolidação (DDD)
Achatamento da hierarquia e isolamento lógico em Domain Services puros. Aqui você sai do nível de "limpeza" e entra no nível de "reformulação de limites". É o estágio mais arriscado e o que mais se beneficia de Spec-Driven Development: você escreve o Design Doc do novo limite, gera Task List de migração, e só então o agente executa task por task. Nunca consolide sem Spec aprovada, esse é o estágio onde "Destruição de Escopo" acontece com mais frequência.
Estágio 4, Atualização Dinâmica
Registro manual e cirúrgico dos novos padrões arquiteturais no Agents.md. Isso é o que fecha o loop: o aprendizado da refatoração vira regra global do repositório. Próxima vez que alguém pedir uma feature similar, o agente já sai do limite arquitetural correto. Sem o Estágio 4, você refatorou o código uma vez, mas o conhecimento ficou na cabeça da pessoa que pediu a refatoração, e o próximo agente vai cair no mesmo buraco.
Alerta de segurança crítico: nunca peça para a IA gerar seu arquivo Agents.md do zero a partir do código refatorado. Ela vai incluir informações irrelevantes que consumirão sua janela de contexto para sempre. A regra é inegociável: curadoria manual no Estágio 4. O agente sugere, você decide o que entra.
Análise de Acoplamento Tridimensional: o framework Khononov
Esse é o framework matemático que falta na maioria das conversas sobre "módulo bem desenhado". Vlad Khononov propõe que acoplamento entre dois módulos não é uma dimensão única, é um vetor de três: Força, Distância e Volatilidade. Cada um responde uma pergunta diferente, e a interação entre as três é o que define se o acoplamento é estruturalmente seguro ou um gargalo mortal aguardando o próximo deploy.
Força, o que é compartilhado?
Compartilhar uma entidade de domínio gera alto risco. Se Módulo A e Módulo B compartilham a mesma classe Pedido com lógica de negócio dentro, qualquer mudança em Pedido ricocheteia. Compartilhar um contrato de API ou uma fila é estruturalmente seguro: a fronteira é explícita, as mudanças são versionadas, os contratos são auditáveis. Força alta = quanto da semântica interna está acoplada; força baixa = só a interface está acoplada.
Distância, onde eles vivem?
Se o acoplamento for forte e os módulos viverem em repositórios distantes (microserviços separados, times diferentes, ciclos de release independentes), o sistema sofrerá quebras constantes. O custo de manter dois repositórios em sincronia com lógica fortemente acoplada é exponencial. Distância alta exige acoplamento baixo; acoplamento alto exige distância baixa. Violar essa regra é a fonte clássica de "toda vez que deploy o serviço A, o serviço B cai".
Volatilidade, com que frequência muda?
Componentes centrais de negócio que são altamente acoplados E mudam com frequência criam gargalos mortais. É a combinação que destrói velocidade: o time fica refém de coordenar mudanças entre módulos que evoluem juntos mas vivem separados, e cada release vira uma negociação. Se o módulo muda toda semana, o acoplamento com ele precisa ser fraco; se o acoplamento é forte, ele precisa mudar pouco.
Topologia segura vs. perigosa
Aplicando os três vetores à clássica decomposição DDD (Core Domain, Supporting, Generic):
- Core Domain ↔ Generic: Safe API Boundaries. Comunicação via contrato bem definido, baixa força, alta distância tolerada.
- Supporting → Generic: Safe API Boundaries. Mesma lógica.
- Core Domain ↔ Supporting: ⚠ Dangerous High Coupling. Aqui é onde o sistema quebra. Força alta (compartilham entidades), distância variável, volatilidade típica (negócio muda). Resultado: gargalo permanente.
Ação tática: utilize Agent Skills de Modular Decomposition para calcular limites matematicamente seguros baseados nos três vetores. O agente pode analisar a codebase, classificar cada módulo nas três dimensões e propor limites, desde que você forneça o critério como Skill estruturada, não como prompt aberto.
Para o tratamento completo desse framework com exemplos e ferramentas de análise, vale o post dedicado da Steply: Coupling Tridimensional de Khononov: Strength, Distance, Volatility. Este resumo serve como ponte: o Khononov é o critério matemático que sustenta a decisão de "Monolito Modular vs. Microserviços" que defendemos na Parte 1.
Caso Velora: workflow AI-First em equipes enxutas
Na Parte 1 usamos o PayPal como caso enterprise: 24.000 funcionários, trilhões de transações, $2k/mês em tokens por power user, dual-review em 90% do código. Esse é o cenário de quem opera em escala extrema. Mas a maioria dos times que lê este playbook não opera assim. Opera como Velora: equipes de 1 a 2 devs cobrindo o ciclo completo do projeto, com ambição de entrega contínua mas restrição real de pessoas. O caso Velora prova que o paradigma AI-Native escala para baixo tão bem quanto escala para cima.
O gargalo ágil que o workflow AI-Native dissolve
O dashboard tradicional: Backlog → Refinement → Sprint → QA → Review → Staging → Prod. Sete colunas, cada uma com fila, cada fila com latência. O tempo se acumula entre etapas, não no trabalho, na transição. Story passa três dias em Refinement esperando, dois dias em QA esperando review, um dia em Staging esperando aprovação. Soma da espera vence soma da execução em quase todo time pequeno.
O fluxo AI-Native da Velora
Quatro estações, sem filas:
- Protótipo (Cursor). O dev valida a hipótese rapidamente no editor com IA. Não é mais "escrever spec antes de validar tecnicamente", é validar a viabilidade técnica em horas, e só então escrever a spec do que vai pra produção.
- PRD Gerado. A IA transforma o protótipo + contexto de produto em PRD estruturado. Documentação não é overhead, é subproduto.
- Linear Slices. Tickets viram Slices, pacotes robustos otimizados para consumo por agentes, com contexto suficiente para execução autônoma. Não é "história de usuário" pra humano; é especificação determinística pra máquina.
- Produção. Bots internos fazem merge automático de PRs de baixo risco se os Sensores (linter, testes, Test Gates) passarem. Aprovação humana fica reservada para mudanças de alto impacto.
Três consequências operacionais:
- Equipes enxutas. Apenas 1 a 2 devs cuidando do ciclo completo do projeto. O time não cresce para absorver mais demanda, o Harness absorve.
- Fim das Stories. Tickets viram "Slices" robustos otimizados para consumo por agentes. A escrita do ticket vira parte da engenharia, não da gerência.
- Aprovação autônoma. Bots internos fazem merge automático de PRs de baixo risco se os Sensores passarem. Dev humano se reserva para o que realmente exige julgamento.
A diferença entre PayPal e Velora não é o paradigma, é a escala da governança ao redor dele. Os 8 pilares do Harness valem para os dois. O custo de implementação é o que muda, e ele escala favoravelmente para times pequenos: menos pessoas para alinhar, menos políticas para versionar, menos compliance para auditar. Time enxuto com Harness disciplinado supera time grande com Vibe Coding institucionalizado.
O Blueprint do Desenvolvedor IA-Nativo: stack de quatro camadas
Se você fosse desenhar a stack vertical do dev IA-Nativo, do mais conceitual ao mais operacional, ela teria exatamente quatro camadas. Cada uma só funciona se a de baixo estiver estabilizada. Pular camada é a forma mais comum de adoção falhar em silêncio.
┌─────────────────────────────────────────────────────────────┐
│ 4. Governança: Code Reviews + Marketplaces Auditados │
├─────────────────────────────────────────────────────────────┤
│ 3. Fluxo Paralelo: Spec-Driven Development + Git Worktrees │
├─────────────────────────────────────────────────────────────┤
│ 2. Forte Convenção: Padrões nativos diretos (flat) │
├─────────────────────────────────────────────────────────────┤
│ 1. Monolitos Modulares: contexto unificado + alta vis. │
└─────────────────────────────────────────────────────────────┘
↓
O Harness Operacional
Camada 1, Monolitos Modulares
Contexto unificado e alta visibilidade. Sem isso, o agente fica cego para o domínio do problema. Não importa quão sofisticadas sejam as camadas acima, se a 1 está fragmentada em microserviços por moda, o agente não vê o suficiente para tomar decisões boas.
Camada 2, Forte Convenção
Padrões nativos diretos, estruturas flat sempre que possível. Se sua stack é Rails ou Go, você herda convenção da comunidade. Se é JS ou Python, você precisa fabricar convenção dentro do repositório, e essa convenção precisa ser rígida, documentada e auditada via linter, não via boa vontade.
Camada 3, Fluxo Paralelo
Spec-Driven Development + Git Worktrees. É aqui que a Parte 1 deste playbook mora: o método R.P.I., o ciclo de criação de Specs, o paralelismo via worktrees. Camada 3 é onde o trabalho diário acontece. Sem as duas de baixo, ela não escala, você fica refazendo a mesma decisão arquitetural a cada Spec porque a convenção é frouxa.
Camada 4, Governança
Code Reviews automatizados via sub-agents, marketplaces auditados internamente, Skills curadas, MCPs verificados. Camada 4 só faz sentido em organizações maduras, é onde "AI-Native" vira "AI-Operations". Times pequenos podem ficar três anos só com as três primeiras camadas e estar perfeitamente bem.
A leitura essencial: menos abstração humana gera mais contexto para a máquina. A complexidade não desaparece, ela se move da arquitetura do código para a curadoria tática do Harness. Construir Harness é arquitetar duas vezes: uma vez o sistema, outra vez o ambiente que constrói o sistema.
Costura com o Framework de Adoção em 7 fases
Tudo o que está acima, Harness, R.P.I., 8 pilares, pipeline de refatoração, Khononov, Blueprint, é tecnologia. Tecnologia sem método de adoção corporativa amplifica caos em vez de gerar produtividade. A Steply já documentou esse método de adoção em post próprio: o Framework de 7 Fases em 3 Movimentos (Fundação: Diagnóstico, AI Enablers, Piloto. Estrutura: Gargalos, Adoção Progressiva. Sustentação: Governança, Escala).
A ponte é direta. Se o post de 7 fases responde "como adotar IA na empresa sem virar caos amplificado", este playbook em duas partes responde "o que exatamente o time precisa construir e dominar tecnicamente em cada fase". As duas leituras se complementam:
- Fundação (Fases 1-3) exige Diagnóstico + AI Enablers + Piloto. O playbook técnico que sustenta essa fase: 4 erros do Vibe Coding (para diagnóstico de maturidade), as 3 camadas de contexto (para AI Enablers), método R.P.I. (para piloto).
- Estrutura (Fases 4-5) exige Mapeamento de Gargalos + Adoção Progressiva. O playbook técnico: 8 pilares do Harness (estrutura do que adotar), Git Worktrees (paralelismo de adoção), Code Review agêntico (qualidade durante adoção).
- Sustentação (Fases 6-7) exige Governança + Escala. O playbook técnico: Marketplace de Skills auditadas, MCPs como gateway, monitoramento de Convention Drift, Blueprint de 4 camadas operacionalizado.
Sem o Framework de 7 fases, este playbook técnico é arma sem manual. Sem este playbook técnico, o Framework de 7 fases é processo sem músculo. Os dois juntos são a oferta completa de adoção AI-Native que a Steply consolida.
Reframe final: três checagens antes de fechar o ciclo
Pergunta 1: Seu repositório passa no teste de Acoplamento Tridimensional? Pegue três pares de módulos que mais geram bug em produção. Classifique cada par nos eixos Força, Distância, Volatilidade. Se algum par está "Força Alta + Distância Alta + Volatilidade Alta", você não tem um problema de produtividade, tem um problema de topologia. Nenhum Harness compensa isso.
Pergunta 2: Você refatora seguindo o pipeline em 4 estágios ou ainda joga "refatore esse módulo" no agente e reza? Se a resposta é a segunda, está no Nível 1 de maturidade independentemente do que mais você implementou. Pipeline disciplinado é o que separa refatoração assistida de demolição assistida.
Pergunta 3: Suas quatro camadas do Blueprint estão estabilizadas em ordem? Camada 4 (Governança) sem Camada 1 (Monolito Modular) é teatro de processo. Camada 3 (Fluxo Paralelo) sem Camada 2 (Forte Convenção) é caos paralelizado. Estabilize de baixo para cima.
Se as três respostas forem honestas, você terá um mapa concreto do que falta. Não é "mais um modelo". Não é "melhor prompt". É infraestrutura. Você não escreve mais código, você gera código. E o que gera código é o Harness, não o LLM.
