Wildberries mostrou como um agente local de AI começou a escrever testes unitários para Android

A Wildberries & Russ publicou uma análise prática de como um tech lead do time Android transformou um LLM local de um brinquedo curioso em um assistente funcional para unit tests. O experimento levou cerca de dois meses: inicialmente a IA cometia erros consistentes e alucinava, mas após reconfigurações começou a produzir testes compiláveis e até mesmo corrigir comentários de revisão de código por conta própria.

Do ceticismo à tarefa

O autor descreve um caminho familiar para muitos desenvolvedores: do entusiasmo inicial com ChatGPT em 2023 até o cansaço do hype e dúvidas sobre se redes neurais realmente trazem ganho de produtividade no desenvolvimento de produtos em larga escala. Após estudar palestras, artigos e casos de uso, ele chegou a uma conclusão mais realista: em bases de código existentes, geralmente não se trata de substituir a equipe, mas de ganhos de eficiência de aproximadamente 10–20%, se a ferramenta estiver adequadamente integrada ao processo.

"A diferença entre um júnior e um sênior no uso de redes neurais é de

3–4 meses."

Nessa perspectiva, o autor escolheu não uma meta abstrata de "implementar IA", mas uma tarefa muito específica e impopular: escrever unit tests para um projeto Android em Kotlin. Uma limitação importante: apenas um LLM local ou um modelo em ambiente corporativo podia ser usado. Devido aos requisitos de segurança, cenários em nuvem foram descartados, onde o código do projeto é indexado e enviado para servidores externos, então a aposta foi feita em ferramentas compatíveis com infraestrutura local.

Por que não funcionou

A primeira tentativa parecia lógica, mas falhou. O desenvolvedor montou um prompt de sistema grande, descreveu o projeto em detalhes, adicionou um arquivo markdown com instruções para o agente e um template de prompt para testes, esperando que o máximo de contexto resultaria em máxima qualidade. Na prática, o modelo local escreveu um teste para um mapper pequeno em cerca de 20 minutos, e produziu não um resultado funcional, mas um conjunto de avisos, erros de importação e código não compilável. Quanto maior a classe, piores as alucinações e pior o modelo entendia quais ferramentas de teste precisavam ser aplicadas. Os principais problemas da primeira iteração foram:

• instruções muito detalhadas sobrecarregavam o modelo e ele ignorava requisitos importantes;
• a saída do Gradle após compilação e execução de testes entupiam o contexto e pioravam as respostas subsequentes;
• executar várias sessões em paralelo não acelerava o trabalho, apenas multiplicava o número de testes quebrados;
• tentar testar ViewModels grandes imediatamente terminava em perda de foco e soluções fictícias.

Refinamento manual desses resultados também não salvava a situação. Corrigir um teste gerado frequentemente levava mais tempo do que escrevê-lo do zero. Por fim, a primeira fase produziu uma conclusão útil mas desagradável: um LLM por si só não se torna um assistente confiável simplesmente porque recebeu um prompt longo e acesso ao código. O que era necessário era uma estrutura diferente de contexto, filtragem de ruído e divisão mais clara do trabalho dentro do sistema de agentes.

O que realmente funcionou

Na segunda iteração, o autor mudou não apenas o modelo, mas a abordagem em si. Ele adicionou RAG com um índice do projeto para acelerar a busca de arquivos relevantes e configurou o processamento da saída do Gradle para que apenas informações úteis entrassem no prompt, não todo o ruído técnico da compilação. Depois disso, sobre o OpenCode foi construída uma estrutura de um agente principal, subagentos e skills separadas.

A ideia é simples: em vez de uma instrução gigante, o modelo recebe regras curtas para cada estágio específico de trabalho. O sistema de geração de testes foi dividido em três papéis: um planejador analisava a classe e coletava todos com casos de teste, um escritor de testes implementava as verificações propriamente ditas, e um revisor verificava compilação, completude de cobertura e conformidade de estilo. Foi apenas após essa decomposição que o modelo produziu pela primeira vez um teste compilável pronto para uso em um mapper pequeno.

O merge request passou em revisão com um comentário de estilo, esse comentário foi adicionado à skill correspondente, e a correção foi executada pelo modelo novamente. Em hardware local, um teste ainda levava cerca de 19 minutos, mas isso já era útil no ritmo real de trabalho: o agente podia escrever testes enquanto o desenvolvedor estava em uma chamada. Depois, após rodar em infraestrutura mais poderosa, o tempo foi reduzido para aproximadamente 5–10 minutos por teste.

O que isto significa

O caso Wildberries demonstra que um agente de IA corporativo começa a entregar valor não após "magicamente" conectar um modelo, mas após configuração de engenharia: com um índice de projeto, filtragem de ruído, papéis e verificação obrigatória de resultados. A substituição completa de desenvolvedores está longe de acontecer, mas tarefas rotineiras como unit tests ou pequenos ajustes já podem ser delegadas à máquina—especialmente onde contenção local e controle de código são importantes.