SENAR introduce portais de qualidade para desenvolvimento de IA: como especificações e métricas reduzem erros

Um quarto artigo da série SENAR foi publicado no Habr — uma metodologia aberta para desenvolvimento com agentes de IA. Andrey Yumashev descreve como "portais" formais de entrada e saída devem substituir a disciplina pessoal de quem define as tarefas e reduzir o número de erros que surgem apenas depois que uma tarefa é fechada.

Como o SENAR Funciona

SENAR é o que o autor chama de metodologia de engenharia para trabalhar com agentes de IA no desenvolvimento. Ela surgiu não da teoria, mas da prática: segundo Yumashev, ao longo de um ano e meio, mais de trinta projetos passaram por esse regime, onde o código era cada vez mais escrito por um agente, enquanto humanos cuidavam da especificação, aceitação e análise de falhas. A ideia principal do artigo é simples: um agente não mantém contexto entre execuções, segue literalmente a formulação e otimiza facilmente de forma local se uma tarefa é descrita negligentemente.

Dentro de uma única tarefa, SENAR se baseia em vários elementos obrigatórios:

• objetivo formal da tarefa em lógica de produto
• critérios de aceitação verificáveis
• um bloco separado de cenários negativos
• limites de mudanças e contexto arquitetônico
• métricas de sinal para qualidade do processo

O autor enfatiza que isso não é uma tentativa de substituir testes, linters ou revisão de código. A lógica é diferente: verificações normais examinam o código, enquanto portais examinam a tarefa em si antes do início e a qualidade de sua aceitação após a conclusão. Na implementação prática do TAUSIK, essas etapas são construídas diretamente na ferramenta, então não podem ser puladas sem contornar o próprio sistema. Isso, segundo o pensamento do autor, protege a equipe do cansaço de "sexta-feira", quando as menores tarefas mais frequentemente passam para produção com defeitos.

O Que os Portais Verificam

Na entrada, SENAR usa o portal QG-0. Ele não permite que uma tarefa comece o trabalho até que tenha uma especificação mínima: um objetivo, critérios de aceitação, cenários negativos, limites de mudanças e um link para contexto arquitetônico. Yumashev argumenta separadamente contra a suposição popular de que pequenas tarefas podem ser entregues a um agente "em uma linha". Precisamente essas tarefas, segundo sua observação, mais frequentemente quebram em produção, porque quem define a tarefa mantém detalhes importantes em sua cabeça, mas não os fixa no ticket.

"A etapa foi pulada não pelo agente, mas por mim."

Na saída, funciona o QG-2 — um portal que bloqueia o fechamento da tarefa até que o resultado seja verificado contra as promessas feitas na entrada. No artigo, o autor destaca três verificações obrigatórias: confirmação de cada critério de aceitação por teste, verificação manual ou artefato; fixação de todas as correções manuais após o trabalho do agente; atualização da memória do projeto se a tarefa descobrir um novo caso extremo ou peculiaridade de infraestrutura. Tal modo é necessário não pelo bem da burocracia, mas para que o agente na próxima tarefa não repita os mesmos erros devido a correções silenciosas feitas por um humano.

Métricas e Limites

Uma seção separada do artigo é dedicada às métricas que SENAR usa como sinais do estado do processo. FPSR mostra a proporção de tarefas resolvidas na primeira tentativa; MIR — com que frequência correção manual foi necessária após o agente; DER mede ramos sem saída e perdas de tempo; ERR reflete tarefas que tiveram que ser corrigidas apenas após o fechamento.

Segundo o registro de trabalho do autor, em tarefas de servidor em um domínio familiar, FPSR cresceu aproximadamente de 40% para 75–80%; MIR no projeto Sortule diminuiu de 20% para 5–7%, e ERR caiu para aproximadamente 6% a partir de 15%. Ao mesmo tempo, Yumashev descreve honestamente os limites da metodologia. Os portais ajudam pouco onde o resultado é difícil de formalizar: em tarefas sobre "sensação" de interface, tom de texto ou intuição de produto.

Eles também não ajudam ao trabalhar com serviços externos, se a documentação de terceiros contradiz o comportamento real da API. Em tais casos, o processo formal pode manter a estrutura da tarefa, mas não substitui o conhecimento de domínio, testes manuais de hipóteses e pesquisa preliminar de integração.

O Que Isso Significa

SENAR é formalizado não como um conjunto de recomendações, mas como um loop operacional rígido para desenvolvimento de IA: sem uma especificação adequada, o agente não inicia; sem aceitação confirmada, a tarefa não fecha. Para equipes que já estão entregando código aos agentes, este é um sinal forte: o risco principal agora não está apenas no modelo, mas na qualidade da especificação de tarefa, memória do projeto e disciplina do processo.