Quando o trabalho de um agente de IA está pronto?

Um agente abre um pull request em vinte minutos. Uma pessoa leva uma hora para revisá-lo direito. Ponha cinco agentes em cinco demandas e o gargalo deixa de ser escrever o código — passa a ser a mesa do revisor. Paralelismo que para ali só muda a fila de lugar.

O DOP é uma plataforma que estou construindo em que um desenvolvedor e um agente conduzem uma demanda de ponta a ponta. Duas das suas decisões de arquitetura respondem à pergunta do título, e a resposta é a mesma nas duas: sem verde, sem PR — e o verde tem de ser conquistado com honestidade.

O caminho da especificação até a main

Quatro regras antes de chamar alguém

A aceitação é executável. Toda demanda carrega critérios que uma máquina consegue verificar — suítes de teste, checagens derivadas da especificação. Um critério que não executa não é critério; é um desejo, e desejos são o que o revisor acaba conferindo na mão.

O agente itera até o verde. Nenhum PR abre com a aceitação falhando. Quando uma falha persiste, ela vira um bloqueio com uma pergunta para o humano, na caixa de atenção. Um PR quebrado nunca é o jeito de pedir ajuda.

Um crítico revisa antes do humano. Uma instância independente, com contexto limpo e sem o histórico de ter escrito o código, recebe diff, especificação e evidência e emite um veredito. É a primeira defesa contra o carimbo automático — o revisor que já leu quatro PRs verdes hoje e vai aprovar o quinto na confiança.

O PR carrega a sua evidência. Resultados da aceitação, execuções de teste, o veredito do crítico, links para o rastro. O humano revisa a exceção, não a regra.

Por que o teste não pode rodar onde o agente trabalha

O agente trabalha num sandbox: sua própria microVM, sua própria árvore de trabalho, tudo o que instalou pelo caminho. O lugar óbvio para rodar os testes é ali mesmo. O DOP recusa, e a recusa está escrita no domínio: uma execução de verificação precisa nomear o commit em que rodou, porque evidência que não diz sobre qual código rodou não é evidência.

Um teste dentro do sandbox roda contra uma árvore suja — que não é commit nenhum. Por isso a verificação acontece num runner: um ambiente efêmero que parte do zero, puxa o commit, constrói a aplicação a partir do fonte e a sobe. Nenhuma imagem do projeto é construída, publicada ou implantada — a parte lenta nunca foi o build, e sim a viagem build → push → pull em volta de um registry. Dependências como um banco de dados são puxadas como imagens publicadas. Quando a execução termina, o runner morre.

O ganho é honestidade por construção: o verde fala de um commit porque rodou num ambiente construído a partir daquele commit — o mesmo que vai ser mesclado.

Quem responde a qual pergunta

Depois do verde: a fila

Três demandas rodam em paralelo e cada uma abre um PR verde — cada um testado contra a main do momento em que a branch nasceu. O primeiro merge invalida os outros dois. Na melhor hipótese, um conflito de texto; na pior, uma quebra semântica silenciosa, em que um PR remove a checagem que o outro presumia. O CI do PR não enxerga isso. A produção enxerga.

Então um PR verde não é mesclado; ele entra numa fila por repositório. A fila reaplica cada PR sobre a main atual, reexecuta a verificação e mescla um por vez. Um conflito é tarefa do agente da demanda primeiro; só uma resolução que falhou chega ao humano, com o contexto do conflito anexado. E o orquestrador do projeto observa quais demandas ativas tocam os mesmos arquivos, para que a sobreposição seja sinalizada antes do PR, não depois.

O que isso compra

O DOP está em construção; isto são decisões, e é mais barato discutir com decisões do que com código. As duas em que este artigo se apoia são públicas: ADR-0007, sem verde, sem PR e ADR-0030, a verificação constrói a partir do fonte.