SENAR adota portões de qualidade no desenvolvimento com IA: como especificações e métricas reduzem erros

Saiu no Habr o quarto artigo da série sobre o SENAR, uma metodologia aberta para desenvolvimento com agentes de IA. Andrey Yumashev descreve como "portões" formais de entrada e saída devem substituir a disciplina pessoal de quem define a tarefa. A proposta é reduzir os erros que só aparecem depois que a tarefa já foi fechada.

Como o SENAR funciona O autor define o SENAR como uma metodologia de

engenharia para trabalhar com agentes de IA no desenvolvimento. Ela nasceu da prática, não da teoria. Segundo Yumashev, em um ano e meio mais de trinta projetos passaram por esse modelo.

Neles, o agente escrevia uma parte cada vez maior do código, enquanto o humano cuidava da definição das tarefas, da aceitação das entregas e da análise de falhas. A ideia central do artigo é simples: o agente não mantém contexto entre execuções, segue a instrução ao pé da letra e tende a otimizar localmente quando a tarefa é descrita de forma descuidada. No ciclo de uma tarefa, o SENAR se apoia em alguns elementos obrigatórios: objetivo formal da tarefa na lógica de produto critérios de aceitação verificáveis um bloco separado de cenários negativos limites das alterações e contexto de arquitetura * métricas de sinalização da qualidade do processo O autor ressalta que a proposta não é substituir testes, linters ou revisão de código.

A lógica é outra: as verificações comuns olham para o código, enquanto os portões olham para a própria tarefa antes do início e para a qualidade da aceitação depois da conclusão. Na implementação prática, o TAUSIK, essas etapas estão embutidas diretamente na ferramenta. Por isso, não dá para pulá-las sem contornar o próprio sistema.

Na visão do autor, é isso que protege a equipe do cansaço de "sexta-feira", quando justamente as tarefas mais simples costumam chegar à produção com defeito.

O que os portões verificam Na entrada, o SENAR usa o portão QG-0.

Ele impede que a tarefa entre em execução enquanto não houver uma especificação mínima: objetivo, critérios de aceitação, cenários negativos, limites das alterações e referência ao contexto de arquitetura. Yumashev contesta a ideia popular de que tarefas pequenas podem ser passadas ao agente "em uma linha". Pela observação dele, são justamente essas tarefas que mais quebram em produção, porque quem as define guarda detalhes importantes na cabeça, mas não os registra no card.

«Quem pulou a etapa não foi o agente, fui eu».

Na saída, entra o QG-2, um portão que bloqueia o fechamento da tarefa até que o resultado seja conferido com o que foi prometido na entrada. O autor destaca três verificações obrigatórias: confirmar cada critério de aceitação por meio de teste, verificação manual ou artefato; registrar todos os ajustes manuais feitos depois do agente; e atualizar a memória do projeto quando a tarefa revelar um novo caso-limite ou uma particularidade de infraestrutura. O objetivo não é criar burocracia. A ideia é evitar que o agente repita os mesmos erros na tarefa seguinte por causa de correções feitas silenciosamente pelo humano.

Métricas e limites

Uma parte do artigo trata das métricas que o SENAR usa como sinais do estado do processo. O FPSR mostra a proporção de tarefas resolvidas na primeira tentativa; o MIR indica com que frequência foi preciso um ajuste manual depois do agente; o DER mede becos sem saída e tempo perdido; e o ERR reflete as tarefas que precisaram ser corrigidas depois de fechadas. Segundo o registro de trabalho do autor, em tarefas de servidor em um domínio conhecido o FPSR subiu de cerca de 40% para 75–80%.

No projeto Sortule, o MIR caiu de 20% para 5–7%, e o ERR recuou de aproximadamente 15% para 6%. Yumashev também descreve com franqueza os limites da metodologia. Os portões ajudam pouco quando o resultado é difícil de formalizar: em tarefas que dependem da "sensação" da interface, do tom do texto ou da intuição de produto.

Eles também não resolvem o trabalho com serviços externos quando a documentação de terceiros contradiz o comportamento real da API. Nesses casos, o processo formal pode manter a estrutura da tarefa, mas não substitui o conhecimento do domínio, a verificação manual de hipóteses e a investigação prévia da integração.

O que isso significa O SENAR se apresenta não como um conjunto de

dicas, mas como um ciclo operacional rígido para o desenvolvimento com IA: sem uma especificação adequada, o agente não começa; sem aceitação confirmada, a tarefa não é fechada. Para equipes que já delegam parte do código a agentes, o recado é claro: o principal risco agora não está só no modelo, mas também na qualidade da definição das tarefas, na memória do projeto e na disciplina do processo.