Vou percorrer o workflow completo usando um exemplo prático. Imagine que estamos construindo um sistema de gerenciamento de alertas para uma operação de mineração (algo que efetivamente já escopi para clientes). O sistema precisa lidar com alertas de sensores de equipamentos, roteá-los por múltiplos canais de notificação (email, push móvel, dashboard), permitir que operadores configurem suas preferências de alerta e manter um histórico consultável para compliance regulatório.
Fase 0: Inicialização da Branch
A engine de workflow cria uma branch de feature dedicada antes de qualquer atividade de agente começar. Todo trabalho subsequente acontece nessa branch, com cada fase completa produzindo um commit. O histórico de controle de versão se torna o registro de estado: a branch representa o ciclo de vida da feature, commits representam fases completas. A engine lida com todas as operações de controle de versão. Agentes nunca interagem com git diretamente; produzem artefatos, e a engine gerencia para onde vão.
Fase 1: Especificação de Requisito
O agente de requisitos recebe a descrição da feature e produz um artefato de especificação estruturada. Valida o documento de visão geral do sistema, consulta o serviço de conhecimento para convenções existentes sobre alertas e notificações, identifica edge cases (o que acontece quando um sensor gera alertas mais rápido do que o sistema consegue processar? qual a política de retenção para histórico de alertas?), e gera critérios de aceite testáveis.
Durante essa fase, o agente consulta o serviço de conhecimento várias vezes. Algumas perguntas recebem respostas da documentação existente ('Qual serviço de entrega de email o projeto usa?' recebe resposta documentada). Outras expõem lacunas ('Alertas devem ser processados sincronamente ou por uma fila?'). Para lacunas, o serviço registra a pergunta e a premissa que o agente usará para continuar. Todas essas interações aparecem como dados estruturados no output da fase.
Avaliação roda: checks determinísticos confirmam que a estrutura do artefato está completa; o agente avaliador confirma que cada critério de aceite é objetivamente testável. Aprovado? A engine comita e avança.
Fase 2: Proposta de Arquitetura
O agente de arquitetura lê o requisito aprovado (incluindo premissas documentadas) e propõe decisões técnicas. Identifica padrões estabelecidos nos registros de arquitetura do projeto. Para cada lacuna, propõe abordagem específica com raciocínio documentado e alternativas consideradas.
Por exemplo: 'Para processamento assíncrono de alertas, propor fila de jobs Redis. Raciocínio: Redis já na stack de infraestrutura para cache; bibliotecas de job queue na linguagem do projeto fornecem retry e dead-letter nativos. Alternativa considerada: serviço de fila gerenciado na cloud. Rejeitado porque introduziria dependência adicional de infraestrutura para uma feature que não requer as características de escala de um serviço gerenciado.'
O avaliador verifica consistência e cobertura arquitetural. Aprovado? Comita e avança.
Fase 3: Decomposição de Tarefas
O agente de tarefas quebra o requisito e arquitetura em cinco a oito pacotes concretos: implementar serviço de processamento de alertas, criar canal de notificação por email, criar canal push, adicionar gerenciamento de preferências, construir API de histórico. Cada pacote especifica arquivos exatos, dependências e critérios de aceite. O avaliador valida o grafo de dependências para completude e ausência de referências circulares.
Fase 4: Implementação
O agente de codificação trabalha nos pacotes em ordem de dependência (ou em paralelo onde o grafo permite). Para cada pacote: escreve código seguindo convenções do projeto, escreve testes, roda linter e suíte de testes. Cada pacote completo produz um commit referenciando o identificador do pacote.
Fase 5: Pull Request
Quando todos os pacotes estão completos e passando, a engine faz push da branch e abre um pull request. Este é o primeiro momento em que um humano entra no workflow. O PR contém tudo: especificação de requisito, proposta de arquitetura com raciocínio, decomposição de tarefas, todo o código e todos os testes. O revisor pode ver exatamente quais premissas os agentes fizeram, quais alternativas foram consideradas e rejeitadas, e como cada linha de código se conecta a um requisito.
O revisor aprova e faz merge, solicita alterações (o agente relevante revisa na mesma branch), ou adiciona comentários em artefatos específicos. Agentes executam autonomamente, mas a decisão de merge é humana.
Este artigo é de O SDLC Agêntico por Carlos Aggio.