QA do Yandex com orçamento de 15 000 ₽ por mês entregou checklists e testes automatizados a um agente de IA

Toda equipe de QA tem uma rotina que ninguém gosta de fazer: abrir o ticket, entender o que mudou no PR, rascunhar um checklist, escrever os casos de teste, automatizá-los e, depois, consertar os testes que quebraram no CI. A equipe de testes da página principal do Yandex decidiu passar uma parte significativa desse trabalho a um agente. Ela contou no Habr como o sistema é montado, quanto custa e onde a equipe tropeçou.

Do plugin na IDE ao evento no Tracker

A primeira versão rodava no Roo Code, para VS Code. O engenheiro abria o editor, escolhia um modo e escrevia “monte um checklist para a tarefa”. O agente ia sozinho ao Tracker, lia o PR e entregava o resultado. Funcionava, mas só era usado por quem já sabia automatizar. Os demais teriam de subir o ambiente e conferir os acessos, ou seja, trocar um trabalho manual por outro.

Por isso, o agente passou a ser acionado por eventos. Quando a tarefa muda para o status “Pronto para testar”, o Tracker envia um HTTP POST ao CI, que sobe um contêiner com o agente, e o testador abre o ticket já com o checklist pronto. Há um segundo gatilho: uma palavra-código no comentário, útil para gerar tudo de novo depois que o PR é atualizado. Com os autotestes, o esquema é parecido, mas o agente primeiro pede a confirmação do engenheiro e só então monta o PR. É uma proteção contra spam.

Subagentes em vez de um prompt gigante

A primeira versão era um monolito: um único agente lia a tarefa, analisava o PR, montava e publicava o checklist. Era lento e caro, porque todo o contexto seguia em cada requisição. Agora o processo está dividido em etapas: coleta de contexto, análise do PR, geração e publicação. Entre elas trafega um JSON validável.

O ganho é prático. Cada etapa vê apenas o contexto de que precisa, cada uma tem seus próprios logs e, quando algo cai, só um job é reiniciado, não o pipeline inteiro.

Para os autotestes, três etapas não bastaram. Por motivos de segurança, o agente foi proibido de acessar um navegador real, então os localizadores do primeiro rascunho saíam imprecisos. A solução foi rodar o teste no CI (aqui já não há LLM), entregar o relatório ao agente para que ele mesmo corrija os localizadores e rodar de novo. O resultado foram seis etapas, duas delas execuções comuns, sem modelo.

Houve ainda um detalhe menor que irritava muita gente: o PR é criado por um robô, não por um engenheiro. Para que a pessoa possa ajustar os localizadores de imediato, o login do autor é passado por toda a cadeia e, no final, o robô o adiciona como coautor e dono do branch.

Skills e memory bank

O conhecimento do agente fica em dois lugares, ambos no repositório. O skill é uma instrução passo a passo, como para um júnior: o que fazer, quais templates usar, como verificar o resultado. Por exemplo: o teste com mocks vai em integration, o teste sem mocks vai em e2e, e não inventamos verificações que não estejam no caso de teste. A equipe tem skills separados para coleta de contexto, análise do PR, exportação de casos do TMS, escrita de teste, code review e correção de falhas. Quanto mais estreito o skill, mais barata e estável é a etapa.

O memory bank responde à pergunta “como fazemos as coisas por aqui”: é um conjunto de arquivos Markdown com stack, fixtures, antipadrões e falhas típicas. A regra é simples: só registramos o que for útil em tarefas futuras, sem detalhes de um único ticket e sem duplicatas. O memory bank também consome tokens, então um guia curto e atualizado vale mais do que duzentas páginas de documentos defasados.

Quanto isso custou

Para a equipe de cinco pessoas, foram reservados 15 000 ₽ por mês. Os gastos mês a mês foram: 11 600, 9 300, 14 600 e 15 000 ₽. No quarto mês, o limite foi consumido por completo. Por isso, a equipe calcula o custo de cada etapa separadamente: registra os tokens de entrada e de saída e acompanha para onde o dinheiro vai. A parte final da seção de conclusões do texto original está cortada, então os detalhes sobre o volume de requisições ficam de fora.

O que levar para a sua equipe

O esquema não está preso ao Yandex nem a um modelo específico. Para reproduzi-lo, são necessários um CI com gatilho externo, uma conta de robô e um runtime de agentes. O papel do Tracker pode ser desempenhado por Jira Automation ou Linear Webhooks; o do tasklet, por GitHub Actions ou GitLab CI; e a orquestração pode ficar com Claude Code, OpenAI Agents SDK ou LangGraph.

Cinco regras do artigo: fixar a revisão do código, guardar as instruções junto do código, dividir o trabalho em etapas com JSON, contar tokens por etapa e restringir com rigor os acessos do agente.

As limitações também são apresentadas com franqueza. O agente entrega um rascunho, não uma solução pronta. Cenários complexos, casos de borda e lógica de negócio são verificados por uma pessoa, que também decide se o PR deve ser mergeado. Sem acesso à página real, os testes passam por um ciclo extra de autocorreção. É uma forma barata de preparar a base para o testador, mas não substitui o testador.