DAG: Desenvolvimento Autônomo Governado
No uso comum de IA, o desenvolvedor conduz cada passo e a IA sugere. No DAG é o contrário: o agente faz a tarefa inteira — da especificação ao código revisado, publicado e testado — e as pessoas decidem nos gates.
O que é o DAG
O DAG é o harness que o Alexander Brito construiu e usa em produção: autonomia para os agentes, governança nos gates, decisão com as pessoas.
Autonomia sem gate é dívida técnica em velocidade industrial. O que torna o DAG replicável não são os agentes — é o conjunto de gates que decide o que avança.
Veja o DAG funcionando
Uma tarefa atravessando o fluxo inteiro, dos agentes aos gates em que as pessoas decidem.
Uma tarefa, do início ao fim, sem ninguém conduzir cada passo
Dois gates humanos nas pontas; entre eles, o agente executa e os gates automáticos decidem o que avança.
- 01
Gate de entrada
Alguém do time prioriza a tarefa e diz "pode ir". O agente não escolhe o que fazer.
Pessoa decide - 02
Especificação
O agente escreve a spec com critério de aceite executável, antes de qualquer linha de código.
Agente executa - 03
Código
Implementação num ambiente isolado por tarefa, com lint, build e testes rodando a cada passo.
Agente executa - 04
4 revisões independentes
Quem implementa não verifica. Quatro revisões separadas, uma delas feita por um modelo de outro fornecedor.
Agente executa - 05
Deploy
Merge e publicação no ambiente de desenvolvimento só com todos os gates automáticos verdes.
Agente executa - 06
Testes Playwright
Testes ponta a ponta no ambiente real. Se algo reprova, o próprio DAG faz o revert automaticamente.
Agente executa - 07
Gate de homologação
A pessoa recebe a entrega pronta, com a prova de cada item, e decide se aceita.
Pessoa decide
Os agentes executam. Você decide nos gates. Entre um gate humano e outro, cada passo só avança se os gates automáticos estiverem verdes.
Seis gates automáticos entre o “pode ir” e o aceite
Nenhum depende da boa vontade do agente: todos são verificações executáveis, com critério de aprovação explícito.
- Gate 1
Verificação única
Lint, build e testes num comando só, igual para agente e para gente. Vermelho não passa.
- Gate 2
Critério de aceite executável
O "pronto" é definido na spec como algo que roda, não como opinião.
- Gate 3
Cobertura item a item
Cada item do escopo precisa de prova. Entrega parcial com teste verde não conta como entregue.
- Gate 4
Régua de severidade
Achados críticos ou altos em qualquer revisão seguram o merge até serem resolvidos.
- Gate 5
Verificação independente
Revisores separados de quem implementou, incluindo um modelo de outro fornecedor.
- Gate 6
Revert automático
Se os testes ponta a ponta reprovam depois do deploy, a mudança é desfeita sozinha.
O que o DAG faz que um agente sozinho não faz
O agente não escolhe a tarefa
A fila é determinística e vem do tracker do time. Prioridade é decisão humana.
Quem implementa não verifica
Quatro revisões independentes, uma delas por um modelo de outro fornecedor, para não repetir os mesmos pontos cegos.
Prova de entrega, não só teste verde
Critério de aceite executável e cobertura do escopo item a item antes do merge.
Guardas em código, não em prompt
Bloqueios automáticos de comandos destrutivos, vazamento de credenciais e logins interativos.
Cada gate tem um incidente atrás
As regras nascem de falhas reais e são revistas a cada ciclo. O harness aprende com o uso.
Executores intercambiáveis
Funciona com diferentes ferramentas e fornecedores de IA, com troca automática quando um deles falha.
Em produção no CRM Renke
Números do tracker do cliente, comparando uma janela antes e outra depois do DAG em escala.
Frente principal do CRM
Horas estimadas entregues por mês
Ciclo mediano por tarefa
Tarefas entregues por mês*
Desenvolvedor de outra vertical, após ~10 dias de DAG
Ciclo mediano por tarefa
Tarefas entregues por mês*
* O DAG divide o trabalho em subtarefas, o que infla a contagem de tarefas. Por isso lideramos com horas estimadas (soma das estimativas das tarefas entregues) e ciclo mediano. Janelas da frente principal: antes = jan e abr–jun/2026; depois = ago–set/2026. Outra vertical: antes = jan–ago/2026; depois = set/2026, com cerca de 10 dias de DAG — sinal forte, mas ainda cedo.
Ler o case completoO que muda para o time — e o que você recebe
O papel do time sai de digitar e revisar código linha a linha para definir critério, priorizar e homologar. A implantação é conduzida junto com vocês, no seu ambiente.
A implantação entrega
- DAG instalado e configurado no seu repositório, tracker e pipeline
- Régua de severidade e gates adaptados ao domínio do seu produto
- Linha de base de métricas e painel de acompanhamento antes/depois
- Playbook de operação e treinamento do time nos gates humanos
- Piloto medido em um fluxo real, com relatório de resultados
Pré-requisitos
- Repositório versionado (Git) e um fluxo de pull requests
- Tracker de tarefas em uso pelo time
- Build e testes que rodam de forma automatizada (ou disposição para criar)
- Um ambiente de desenvolvimento ou homologação separado da produção
Falta algum? O diagnóstico mostra o caminho mais curto para chegar lá.
Descubra em 30 minutos onde o DAG destrava o seu time
Uma conversa objetiva sobre o seu fluxo de desenvolvimento atual, onde os gates fazem diferença e qual seria o primeiro piloto. Gratuita e sem compromisso.