The DOCOD Method

Engenharia com agentes precisa de um ciclo, não de uma sequência de prompts.

Agentes podem executar cada vez mais trabalho. O método organiza o que continua precisando ser decidido, coordenado, confirmado e aprendido por quem responde pelo sistema.

Define · Orchestrate · Confirm · Observe · [re]Define

Como ler o ciclo

O método não é um pipeline.

Os cinco movimentos têm ordem lógica, mas software real não percorre uma linha reta.

Uma descoberta em Confirm pode exigir voltar a Define.
Uma ocorrência em produção observada em Observe pode mudar requisitos.
Uma decisão arquitetural pode surgir no meio da execução e exigir impacto antes que o trabalho continue.

O ciclo existe para preservar continuidade enquanto o sistema muda.

O manual

Cada movimento resolve um problema de engenharia diferente.

Define

Decida o que precisa ser verdade.

Define transforma intenção em algo que pode ser construído sem depender de contexto implícito.

Aqui você esclarece o problema, requisitos, restrições, decisões, arquitetura, riscos, contratos e a decomposição necessária para o trabalho começar.

Você está em Define quando precisa responder:

O que estamos tentando mudar?
Para quem?
Quais comportamentos precisam existir?
Quais restrições não podem ser violadas?
Que decisões precisam ser tomadas antes da implementação?
O que será considerado sucesso?

Entradas: Intenção, problema, contexto existente, restrições e conhecimento disponível.
Saídas: Requisitos, decisões, design, contratos, riscos e trabalho suficientemente definido para execução.

Define termina quando

o próximo trabalho pode ser executado sem depender de alguém adivinhar intenção ou reconstruir decisões essenciais.

Não confunda Define com

escrever documentação por escrever. O objetivo não é produzir arquivos. É remover ambiguidade relevante antes que ela vire código.

Orchestrate

Organize quem executa, com qual contexto e dentro de quais limites.

Orchestrate transforma trabalho definido em execução coordenada.

É aqui que entram agentes, pessoas, ferramentas, contexto, ambientes, regras, dependências e sequência de trabalho.

Você está em Orchestrate quando precisa responder:

Quem deve executar esta parte?
Que contexto essa execução precisa receber?
Que regras e limites se aplicam?
O trabalho pode acontecer em paralelo?
Que dependências precisam ser respeitadas?
Onde uma pessoa precisa intervir?

Entradas: Trabalho definido, decisões, contexto e restrições.
Saídas: Execução coordenada com responsabilidades, contexto e fronteiras claras.

Orchestrate termina quando

o trabalho certo está sendo executado pelo participante certo, com o contexto e as restrições necessários.

Não confunda Orchestrate com

“mandar vários agentes trabalharem ao mesmo tempo”. Mais agentes sem coordenação apenas produzem mais divergência mais rápido.

Confirm

Não aceite uma conclusão. Exija razões para aceitá-la.

Confirm estabelece se aquilo que foi produzido realmente satisfaz o que havia sido decidido.

Testes, revisão, critérios de aceite, evidência e gates humanos pertencem aqui.

Você está em Confirm quando precisa responder:

O comportamento esperado realmente existe?
Que evidência sustenta essa conclusão?
Os critérios acordados foram atendidos?
Quem produziu também está confirmando o próprio trabalho?
Existe alguma decisão que ainda exige aprovação humana?
Estamos verificando resultado ou apenas atividade?

Entradas: Resultado da execução, critérios, contratos e decisões relevantes.
Saídas: Evidência, verificações, revisões, aprovações ou rejeições justificadas.

Confirm termina quando

há evidência suficiente para aceitar o resultado, ou informação suficiente para saber por que ele precisa voltar.

Não confunda Confirm com

o agente declarar que terminou. “Done” é uma afirmação. Confirmação exige evidência.

Observe

Produção responde perguntas que o planejamento não consegue responder.

Observe acompanha o sistema quando ele encontra realidade: usuários, tráfego, falhas, custos, comportamento inesperado e consequências das decisões tomadas.

Você está em Observe quando precisa responder:

O sistema está se comportando como esperávamos?
Que falhas só aparecem em operação?
Que custos ou gargalos surgiram?
Que hipóteses estavam erradas?
Há drift entre intenção e comportamento?
O que aprendemos que não sabíamos antes?

Entradas: Sistema em uso e sinais produzidos por sua operação.
Saídas: Evidência operacional, incidentes, métricas, desvios e novos aprendizados.

Observe não termina da mesma maneira

ele alimenta continuamente o próximo movimento quando a realidade exige mudança.

Não confunda Observe com

ter dashboards. Observabilidade sem decisão produz informação, não aprendizado.

[re]Define

Aprendizado só importa quando consegue mudar uma decisão.

[re]Define fecha o ciclo levando o que foi aprendido de volta ao estado do projeto.

Uma mudança não começa apagando o passado. Ela começa entendendo o impacto sobre aquilo que já havia sido decidido, construído e confirmado.

Você está em [re]Define quando precisa responder:

O que aprendemos?
Que decisão anterior isso desafia?
O que precisa mudar?
O que depende dessa mudança?
Que confirmações anteriores deixam de ser suficientes?
Qual passa a ser o novo estado desejado?

Entradas: Evidência de Confirm, sinais de Observe, novas necessidades ou mudanças externas.
Saídas: Decisões revisadas, impacto compreendido e um novo estado de Define.

[re]Define termina quando

a mudança deixa de ser apenas descoberta e passa a existir como nova decisão explícita.

Não confunda [re]Define com

editar uma especificação e seguir em frente. Mudanças upstream têm consequências downstream.

Fora da caixinha

Algumas decisões não pertencem a um único movimento.

Decisões arquiteturais, comparações de alternativas, propostas abertas a comentário, regras do projeto, análise de impacto e aconselhamento técnico podem surgir em diferentes momentos.

Eles são transversais porque registram raciocínio que precisa sobreviver ao movimento em que nasceu.

ADRs, RFCs, trade-offs, análise de impacto, regras e counsel atravessam o ciclo.

Eles surgem quando o problema exige, não porque chegou a vez de uma etapa.

Ensinar o contrário seria ensinar uma versão errada do método, em que tudo precisa caber numa caixa.

Onde um termina e o outro começa

O método não é o runtime.

DOCOD Method: Descreve o trabalho de engenharia: como decidir, coordenar, confirmar, observar e aprender quando agentes participam da construção.
DOCOD Runtime: É uma implementação de referência que torna partes desse modelo executáveis e verificáveis dentro de um projeto.