Na vasta e intrincada paisagem do software moderno, as melhorias de desempenho raramente se parecem com novas invenções. Em vez disso, são ajustes sutis em bases de código existentes, onde uma única mudança deve se ajustar perfeitamente a milhares de linhas de lógica estabelecida, regras de compilação rigorosas e interfaces públicas. Encontrar essas melhorias é difícil porque o espaço de mudanças possíveis é enorme, e a maioria das tentativas falha ao compilar ou quebra o sistema. Para navegar nisso, pesquisadores desenvolveram agentes automatizados que podem escrever e testar código. Esses agentes operam como exploradores, mas a estratégia que utilizam para decidir para onde ir a seguir importa imensamente. Algumas estratégias focam inteiramente no melhor caminho único encontrado até o momento, empilhando mudanças sobre ele como um escalador ascendendo uma única crista. Outras tentam muitos caminhos diferentes de uma só vez, mas iniciam cada nova tentativa a partir do início absoluto, descartando qualquer progresso feito em tentativas anteriores. Uma terceira abordagem, conhecida como busca de qualidade-diversidade, tenta manter um mapa de muitos estados de sucesso diferentes, preservando variações que não são necessariamente o "melhor" atual, mas que podem levar a algo melhor mais tarde.

Este artigo apresenta um sistema chamado LORELEY, que aplica essa abordagem de qualidade-diversidade à evolução de repositórios de software inteiros. Os pesquisadores queriam saber se manter um arquivo diverso de estados de código passados e, ocasionalmente, retornar a eles para inspiração, produziria de fato melhores resultados do que simplesmente empilhar mudanças sobre a versão atual mais bem sucedida ou começar do zero a cada vez. Eles testaram isso colocando o sistema LORELEY contra duas estratégias mais simples e tradicionais em um experimento controlado usando a biblioteca de compressão Zstandard, uma peça de software crítica usada para encolher arquivos de dados. O objetivo era ver se a abordagem mais complexa e rica em memória poderia encontrar uma versão final de código superior dentro de um orçamento fixo de tentativas.

O experimento foi rigoroso e cuidadosamente pareado para garantir uma comparação justa. Os pesquisadores executaram três políticas de busca na mesma base de partida congelada do código Zstandard. A primeira política, chamada Sequential Champion, agiu como um escalador implacável: ela pegava a melhor versão encontrada até o momento e pedia ao agente para melhorá-la ainda mais, descartando todos os outros ramos. A segunda, Independent Root, era como um grupo de trilheiros começando do acampamento base a cada vez; cada tentativa começava do código original, ignorando quaisquer melhorias encontradas por outros. A terceira, LORELEY, mantinha um arquivo de muitos estados de código válidos. Quando precisava gerar uma nova ideia, podia escolher uma base deste arquivo e também observar outros estados armazenados para inspiração, esperando que a combinação de um ponto de partida menos óbvio com uma ideia fresca resultasse em um avanço.

O estudo rodou por um orçamento específico de quarenta e oito tentativas, ou "jobs", para cada política. No mundo da codificação automatizada, um job é um ciclo completo onde o sistema escolhe uma versão de código inicial, um agente escreve mudanças em um ambiente isolado, e um testador externo constrói e mede o resultado. Os pesquisadores mediram o desempenho final do melhor código encontrado por cada política usando um conjunto separado de dados que os agentes nunca tinham visto durante sua busca. Este teste de "holdout" garantiu que os resultados fossem melhorias genuínas e não apenas palpites sortudos que funcionavam apenas nos dados de treinamento.

Os resultados mostraram que a estratégia Sequential Champion, que simplesmente continuava construindo sobre a melhor versão, teve o maior desempenho médio e mediano observado após quarenta e oito jobs. O sistema LORELEY, apesar de seu arquivo complexo e capacidade de revisitar ideias antigas, terminou ligeiramente atrás do campeão. A estratégia Independent Root, que nunca lembrava de sucessos passados, teve o pior desempenho. No entanto, os dados não estabeleceram uma vantagem estatística para a abordagem de Qualidade-Diversidade (QD) sobre as duas estratégias de controle; os intervalos de confiança incluíram zero, o que significa que o experimento não pôde confirmar que a QD melhora o desempenho final de hold-out sobre as estratégias mais simples, nem pôde estabelecer equivalência. Embora o LORELEY tenha conseguido manter um conjunto diverso de estados de código em seu arquivo e tenha ocasionalmente amostrado esses estados, esse comportamento não se traduziu em um resultado final estatisticamente superior. O sistema não demonstrou que manter um mapa de muitos caminhos é definitivamente melhor do que focar no caminho único mais eficiente para esta tarefa específica.

Contudo, a história não é inteiramente de fracasso para a abordagem complexa. Os pesquisadores observaram que o sistema LORELEY de fato se envolveu com seu mecanismo pretendido. Ele reteve com sucesso estados de código que não eram os atuais líderes e amostrou esses estados não-campeões posteriormente para usá-los como base ou inspiração. Em quatro de sete execuções de teste, o código vencedor final do sistema LORELEY teve ancestrais em seu histórico que não eram os líderes no momento em que foram adicionados ao arquivo. Isso provou que o sistema podia manter e revisitar "pedras de toque" — ideias intermediárias que podem não ser perfeitas por si só, mas que podem levar a algo novo. No entanto, neste experimento específico com um número limitado de tentativas, essas pedras de toque não ajudaram o sistema a superar a estratégia mais simples e direta de forma estatisticamente significativa.

O artigo também analisou campanhas anteriores, menores, onde o sistema foi usado em diferentes bibliotecas de software, incluindo uma biblioteca Python para manipulação de texto e uma revisão separada da ferramenta de compressão. Nesses casos, o sistema produziu com sucesso melhorias significativas, como um aumento de velocidade de quase sete por cento em uma biblioteca e um ganho de vinte e cinco por cento em outra. Esses sucessos demonstram que o sistema é capaz de encontrar melhorias complexas de múltiplos arquivos quando recebe as condições adequadas. Mas a comparação controlada com as estratégias mais simples mostrou que, pelo menos para a tarefa do Zstandard com um orçamento de quarenta e oito jobs, a complexidade adicional de manter um arquivo diverso não proporcionou uma vantagem estatisticamente estabelecida sobre simplesmente focar na melhor versão atual.

Em última análise, o estudo oferece uma visão matizada da evolução de software automatizada. Confirma que um sistema pode ser projetado para lembrar e reutilizar uma ampla variedade de estados passados, e que pode navegar com sucesso em uma base de código complexa para encontrar melhorias. Mas também sugere que, para certas tarefas e dentro de limites de tempo específicos, a estratégia mais eficaz pode ser a direta: encontre a melhor coisa que você tem e continue tornando-a melhor, em vez de tentar gerenciar um mapa expansivo de possibilidades. Os pesquisadores não descobriram que o método complexo é inútil, mas descobriram que ele não venceu esta corrida específica com significância estatística. Os resultados permanecem específicos para as ferramentas e restrições utilizadas, deixando aberta a questão de se uma busca mais longa ou um tipo diferente de problema poderia eventualmente favorecer a abordagem diversa e rica em memória.