T-Bank ensinou um agente de IA a escrever testes unitários de iOS com AGENTS.md e SKILL.md

A equipe de desenvolvimento iOS do T-Bank descreveu no Habr como ensinou um agente de LLM a escrever testes unitários no estilo do projeto: com objetos Mock reais, os utilitários corretos e código que compila de primeira. O autor do texto, o desenvolvedor iOS Artem Jitko, conta que o ajuste de prompts não resolveu. O que funcionou foi um sistema de regras baseado nos arquivos AGENTS.md e SKILL.md. O anúncio não traz números, como a porcentagem de testes que compilam ou as horas economizadas; ao que tudo indica, esses dados ficaram no artigo completo.

O que deu errado na primeira tentativa

Os testes costumam ser escritos no fim da tarefa, quando a lógica já está pronta e a motivação é baixa. É um candidato óbvio para delegar a um agente. O T-Bank tentou entregar a tarefa ao ChatLLM e obteve um conjunto típico de defeitos:

• o código não compilava;
• o modelo inventava objetos Mock que não existem no projeto;
• as convenções de arquitetura da equipe eram ignoradas;
• eram usados utilitários de teste diferentes dos que a base de código adota.

Os quatro problemas têm a mesma raiz: o modelo não enxergava o projeto por dentro. Ele sabe como são testes em Swift de modo geral, mas não sabe como se chamam os seus helpers, onde ficam os stubs e qual camada de dependências costuma ser substituída. Por isso, preenche as lacunas com invenções plausíveis. Para código, é o pior cenário: a invenção parece convincente e só quebra na hora de compilar.

Regras no lugar de prompts

A equipe concluiu que a causa era a falta de contexto, e não a fraqueza do modelo, e levou o conhecimento sobre o projeto para arquivos. O AGENTS.md funciona como a instrução geral do agente no repositório: estrutura, convenções e práticas obrigatórias. O SKILL.md descreve uma habilidade específica, neste caso a escrita de testes: a ordem das ações, quais utilitários usar, como nomear os casos e o que conta como resultado pronto. O anúncio não revela como exatamente as regras foram divididas entre os dois arquivos.

A principal mudança está na própria abordagem. Um prompt vive na cabeça de alguém ou em um chat, e o resultado depende de quem o escreveu e de como. Já o arquivo de regras fica no repositório, passa por revisão, tem versionamento e funciona do mesmo jeito para todos os desenvolvedores. Nas palavras do próprio autor, a geração de testes deixa de ser uma solicitação avulsa e vira um processo de engenharia reproduzível.

Principais fatos do anúncio

• Plataforma: iOS, testes unitários.
• Modelo inicial: ChatLLM; o resultado sem contexto foi considerado inutilizável.
• Ferramentas: AGENTS.md e SKILL.md.
• Tese da equipe: boas regras importam mais do que escolher o modelo mais inteligente.
• O anúncio não apresenta métricas de qualidade nem de economia de tempo.

A tese sobre regras e modelo deve ser lida com ressalvas. Trata-se da conclusão de uma única equipe em uma única base de código, ainda sem números publicados. Mas ela está alinhada com o que muita gente observa ao trabalhar com agentes de código: o ganho de qualidade costuma vir da descrição do ambiente e da verificação do resultado, e não da troca por um modelo mais caro.

Como aplicar na sua equipe

Se quiser repetir a abordagem, comece pela análise dos erros, e não pela escrita das regras. Reúna de 10 a 20 testes que o agente gerou mal e classifique as causas: classe inventada, utilitário errado, arquitetura violada. Cada causa recorrente vira uma regra concreta.

No AGENTS.md, coloque o que vale para todo o repositório: estrutura dos módulos, convenções de nomenclatura, proibições. Em uma skill separada, isole o procedimento específico, como a escrita de testes, e inclua um ou dois exemplos de referência tirados do código real. Liste explicitamente os objetos Mock e os utilitários de teste existentes e proíba a criação de novos sem solicitação. É a resposta direta ao principal problema descrito pela equipe.

E feche sempre o ciclo com verificação: faça o agente rodar o build e os testes e corrigir os erros por conta própria. As regras reduzem as invenções, mas o compilador continua sendo o revisor mais confiável. Os arquivos de regras merecem revisão como qualquer código e devem ser atualizados junto com a arquitetura; do contrário, ficam desatualizados rapidamente e passam a atrapalhar.