Orquestração sustentável de agentes
Instalo o fluxo Research → Plan → Implement no repositório, com papéis humanos claros, specs versionadas e governança, para que agentes acelerem sem substituir decisão arquitetural. Em 90 dias, com o efeito medido em DORA e adoção.
Método publicado em artigo próprio sobre Spec-Driven Development em mobile.
Para quem é
- Empresas com squad mobile ativo em execução, que já adotaram ou estão prestes a adotar agentes no desenvolvimento
- Times com dor mensurável em lead time, regressão ou retrabalho, e patrocinador com autoridade sobre a jornada piloto
- Lideranças que precisam responder qual foi o ganho real de produtividade, com número em vez de percepção
Sintomas
Se você reconhece três ou mais destes, a oferta provavelmente se aplica.
- O time gera muito mais código do que antes, mas o lead time até produção não melhorou na mesma proporção, ou piorou
- Code review virou gargalo: ninguém consegue avaliar com segurança um PR grande escrito por agente
- Decisões arquiteturais são tomadas dentro de uma sessão de chat e não sobrevivem à semana seguinte
- Módulos parecidos foram implementados de três jeitos diferentes, cada um sugerido pela IA em um momento distinto
- Aumentou o retrabalho pós-merge e as regressões em jornadas que estavam estáveis
O que você recebe
- Termo de abertura com hipótese, métricas e matriz de responsabilidade
- Linha de base medida nas três camadas de métricas
- Modelo de orquestração e papéis: o que é do agente e o que é do humano
- Templates de spec e ADR instalados no repositório
- Playbook de revisão e critérios de aceite
- Design reviews e office hours ao longo do piloto
- Relatório de evidências com o delta contra a linha de base
Fases
Abertura
Escolha da jornada piloto, hipótese declarada e matriz de responsabilidade entre consultoria, squad e patrocinador
Linha de base
Medição das três camadas antes de qualquer mudança, porque é contra este número que tudo será comparado
Instalação
Specs, ADRs, templates e checklist de PR entram no repositório, com o tech lead conduzindo
Evidência
Medição do delta, consolidação e apresentação do que mudou e do que não mudou
O que não está incluído
- Implementar features, porque quem codifica é o squad do cliente
- Abrir PR, operar release ou pipeline de produção
- Assumir backlog, papel de PO ou priorização de sprint
- Decidir arquitetura no lugar do cliente, porque a decisão final é dele
- Plantão, suporte a incidente ou on-call
- Substituir squad, renegociar contrato de fornecedor ou avaliar pessoas
Como meço sucesso
Combinado antes de começar, não descoberto no fim.
- Change fail rate e retrabalho medidos contra a linha de base, não contra percepção
- Ao menos 60% dos PRs da jornada piloto entram com spec ou ADR associado
- Aderência ao checklist de revisão acima de 80%
- O tech lead do cliente conduz o fluxo sem o consultor na sala, e é esse o critério de saída
Perguntas frequentes
Por que 90 dias e não um workshop?
Porque o que se mede em três meses é hábito, não entusiasmo. Um workshop muda o discurso da semana seguinte. O piloto mostra se o jeito de trabalhar mudou quando ninguém está olhando.
Você codifica junto com o time?
Não. Esta oferta cabe em 8 horas semanais exatamente porque o consultor não entra na linha de execução. Pedido para só ajudar nesse PR muda a natureza do contrato e é tratado como escopo novo.
E se não tivermos histórico para a linha de base?
A linha de base é levantada na semana 2 com o que existir, e a janela fica declarada. Sem linha de base não há prova, e sem prova o piloto vira opinião.
Próximo passo
Uma conversa de 30 minutos para delimitar o escopo. Ao fim dela dá para dizer se esta oferta se aplica e, se não se aplicar, qual das outras se aplica. Isso também é resultado.