Equipe da Avito incorpora ao código o fluxo de trabalho de agentes de IA com dois pontos de aprovação

Você pede a um agente que primeiro obtenha a aprovação do plano, depois escreva o código e o verifique em um ambiente de testes. Uma hora depois, ele entrega um PR pronto, mas pulou a aprovação e, no lugar dos resultados dos testes, apresenta uma explicação confiante de por que tudo deve funcionar. É possível acrescentar mais um aviso ao AGENTS.md. Isso não garante o cumprimento das instruções.

Valeri Pochtariov, da equipe Checks da Avito, que atua no combate a fraudes, descreveu outra abordagem: transferir os requisitos verificáveis das instruções para scripts e hooks. Eles determinam em que etapa a tarefa está, se alterações são permitidas e se o resultado pode ser encaminhado para revisão. A configuração se chama af-checks-context; o autor está ampliando seu uso pessoal para a equipe.

Como um requisito se transforma em um bloqueio

A base do sistema é um repositório git separado com o contexto da equipe: especificações, planos, conhecimento e uma descrição do processo. Os repositórios dos serviços ficam ao lado dele. A sessão do agente começa pelo contexto da equipe para que uma tarefa que envolva vários serviços não fique restrita ao conteúdo de um único projeto.

Em seguida, o trabalho passa por uma sequência de etapas: tarefa, plano, aprovação, implementação, verificação em um ambiente de testes separado, aprovação do resultado e envio do PR para revisão. Um script determina a etapa da tarefa a partir dos artefatos existentes. O modelo não pode simplesmente declarar que uma etapa obrigatória já foi concluída.

Suponha que o agente esteja alterando uma verificação de acesso. Até a aprovação do plano, um hook bloqueia alterações de código no diretório de trabalho da tarefa. Uma pessoa confirma o plano em uma mensagem separada com a chave da tarefa. O hook cria uma marca de curta duração que um comando usa para registrar a aprovação. O agente é proibido de criar essa marca por conta própria.

Após a implementação, é necessário um relatório do ambiente de testes. A verificação confere o veredicto pass e o hash do commit testado. Se o agente fizer outra alteração depois de uma execução bem-sucedida, o relatório anterior deixa de validar a versão atual. Mesmo uma pequena mudança exige evidências atualizadas de verificação.

Onde as primeiras restrições tinham brechas

A parte mais útil do relato é a descrição das verificações que falharam. Um bloqueio inicial aceitava qualquer campo de aprovação não vazio: até o valor false passava. Outro verificava apenas se o caminho do relatório existia, então até um diretório com o nome certo era aceito. Formalmente, a etapa estava concluída; na prática, não havia evidências.

Outro problema surgiu com um bot que distinguia alterações no processo de alterações comuns de conteúdo. Ele lia a lista de caminhos protegidos no próprio PR em análise. Uma alteração podia remover seu próprio diretório da lista e entrar em uma categoria que permitia a integração sem intervenção humana. A correção: buscar as regras na branch de destino e sempre considerar alterações na própria configuração como mudanças no processo.

A verificação por outro agente também não garante que a conclusão esteja correta. Certa vez, o agente revisor encontrou uma contradição entre a especificação e um serviço vizinho. Sua cópia local estava 36 commits atrasada; o comportamento necessário já existia. Agora, esses achados são primeiro conferidos com o origin atualizado. Separar os papéis ajuda, mas ainda é preciso verificar se os dados de origem estão atualizados.

O que incorporar ao seu processo

Você pode começar por uma transição que falha com frequência no seu fluxo de trabalho. Por exemplo, impedir o envio de um PR para revisão sem um relatório bem-sucedido para o commit atual. Depois, teste o próprio bloqueio: o que acontece com um relatório vazio, um tipo de arquivo incorreto, um novo commit ou uma falha ao carregar o script de verificação?

O controle tem um custo de manutenção. O hook de inicialização do autor levava de 14,6 a 18 segundos para executar, com um timeout de 15 segundos, o que às vezes impedia silenciosamente que o contexto chegasse ao agente. Caixas de seleção administrativas alteravam o hash do plano e provocavam novas aprovações. Foi necessário simplificar o sistema, separar as verificações rápidas das lentas e excluir as linhas administrativas do cálculo da versão do plano.

Ainda é cedo para avaliar a dimensão do efeito: o trecho fornecido termina em uma tabela com medições pessoais do autor e não oferece um panorama completo da produtividade da equipe. Mas a técnica de engenharia já está clara. Para cada ação obrigatória, é preciso definir um resultado verificável e bloquear a transição na ausência dele. Depois, garantir que o agente não possa reescrever os critérios usados para aceitar seu próprio trabalho.