Ensinar uma inteligência artificial a programar exige mais do que mostrar exemplos de código. Para formar um agente capaz de investigar um sistema, alterar arquivos, executar testes e corrigir os próprios erros, é preciso colocá-lo diante de tarefas completas — e, principalmente, saber de maneira objetiva se ele resolveu cada uma delas.
Essa última parte é o gargalo. A internet está cheia de software, mas não de exercícios prontos para aprendizado por reforço. Issues e commits ajudam a reconstruir algumas tarefas reais, porém representam apenas uma fração do que existe dentro de um repositório. Grande parte das funcionalidades já foi implementada há anos, sem uma descrição suficientemente detalhada ou um histórico fácil de converter em ambiente de treinamento.
O CodeMidas, apresentado por pesquisadores em setembro de 2026, propõe inverter essa lógica. Em vez de procurar tarefas nos rastros deixados pelo desenvolvimento, o sistema observa o próprio código funcionando e tenta reconstruir o problema que aquele código resolve. A partir disso, agentes formulam especificações, criam testes executáveis e verificam se a tarefa pode ser resolvida de maneira confiável. O resultado apresentado pelos autores é um conjunto de 5.545 tarefas de treinamento produzido usando somente código-fonte como entrada específica.
O ouro escondido dentro dos repositórios
Quando uma equipe desenvolve uma funcionalidade, o resultado final costuma conter muito mais informação do que a documentação que a acompanha. O código revela entradas aceitas, estados internos, exceções, efeitos colaterais e relações com outros componentes. Os testes existentes revelam uma parte do comportamento esperado. A execução do programa mostra detalhes que talvez nunca tenham sido escritos em linguagem natural.
Os métodos tradicionais de criação de tarefas para agentes frequentemente começam por uma issue e pelo commit que a resolveu. A issue descreve o objetivo; o commit fornece uma possível resposta; e os testes ajudam a avaliar a solução. É uma estrutura valiosa, mas limitada. Muitos projetos não mantêm issues detalhadas, acumulam commits confusos ou misturam várias mudanças na mesma revisão. Funcionalidades antigas e estáveis também desaparecem desse radar.
O CodeMidas trata cada implementação existente como uma espécie de fóssil reversível. Se uma função já está presente e pode ser executada, agentes podem explorá-la, observar seu comportamento e produzir uma especificação que permita removê-la ou ocultá-la para outro agente reconstruí-la. Assim, o repositório deixa de ser apenas uma coleção de respostas e passa a servir como matéria-prima para fabricar perguntas.
Essa mudança parece simples, mas amplia radicalmente o universo disponível. Em princípio, qualquer funcionalidade executável pode originar uma tarefa, mesmo quando não existe uma issue correspondente. O valor não está somente no volume: tarefas extraídas de software real carregam dependências, convenções e ambiguidades difíceis de reproduzir em exercícios artificiais.
Uma fábrica de ambientes, não apenas de prompts
Uma tarefa de programação não se torna adequada ao aprendizado por reforço apenas porque possui uma boa descrição. O treinamento precisa de um verificador: um mecanismo capaz de distinguir uma solução funcional de uma resposta convincente, porém errada. Sem isso, o sistema pode recompensar código que parece correto, passa por uma inspeção superficial ou explora falhas do próprio ambiente.
O pipeline do CodeMidas distribui trabalho computacional entre várias etapas. Primeiro, agentes exploram a funcionalidade já implementada para formular uma especificação comportamental. Depois, constroem testes fundamentados na execução do programa original. Em seguida, executam verificações e repetem tentativas de solução para filtrar tarefas frágeis, impossíveis ou fáceis de manipular.
Há uma diferença importante entre pedir a um modelo que invente um teste e ancorar esse teste no comportamento de um programa existente. No segundo caso, a implementação original funciona como referência executável. Ela não garante que todo teste criado seja perfeito, mas oferece um ponto concreto de comparação. O processo pode perguntar: esta entrada é realmente aceita? Esta saída aparece de forma consistente? A tarefa continua solucionável depois que a implementação-alvo é retirada?
O produto final, portanto, não é uma lista de perguntas acompanhadas de respostas textuais. É uma coleção de ambientes nos quais outro agente pode navegar pelo projeto, editar código, executar comandos e receber um sinal verificável de sucesso ou fracasso. Essa estrutura é precisamente o que o aprendizado por reforço precisa para transformar tentativa e erro em atualização do comportamento.
Por que isso importa para agentes de programação
Os melhores agentes atuais ainda sofrem quando saem de problemas bem delimitados e entram em bases de código reais. Eles podem corrigir o arquivo errado, escrever testes que confirmam a própria suposição, ignorar efeitos colaterais ou declarar a tarefa concluída depois de uma validação incompleta. A diversidade do treinamento é decisiva porque essas falhas raramente aparecem em pequenos desafios algorítmicos.
Ao extrair tarefas de funcionalidades implementadas, o CodeMidas pode expor agentes a padrões mais próximos do trabalho cotidiano: compreender uma arquitetura desconhecida, localizar o ponto certo de intervenção, preservar contratos existentes e interpretar o comportamento do sistema. Uma mesma técnica também pode produzir graus diferentes de dificuldade, dependendo de quanto contexto, documentação ou estrutura de testes permanece visível.
Existe ainda um efeito estratégico. Se a criação de ambientes deixa de depender principalmente de trabalho humano e de históricos perfeitamente organizados, equipes podem aumentar o treinamento sem aumentar na mesma proporção o custo de anotação. O recurso escasso passa a ser a capacidade de explorar, executar e validar software em escala.
Isso não elimina o risco de contaminação ou memorização. Se o agente em treinamento já encontrou o mesmo código durante a pré-formação, uma reconstrução pode medir lembrança em vez de competência. Também será necessário separar projetos, versões e famílias de implementação com cuidado. Mesmo assim, a abordagem oferece uma direção mais rica do que simplesmente multiplicar exercícios sintéticos desconectados de sistemas reais.
O impacto para o Brasil e para as empresas
Para o ecossistema brasileiro, a ideia é especialmente relevante porque existe muito software útil fora dos grandes conjuntos internacionais de treinamento. Sistemas fiscais, bibliotecas financeiras, ferramentas de comércio eletrônico, integrações com serviços públicos e aplicações escritas em português carregam requisitos locais que raramente aparecem nos benchmarks mais conhecidos.
Uma empresa poderia, por exemplo, transformar componentes internos autorizados em ambientes privados de treinamento ou avaliação. Em vez de medir um agente apenas por benchmarks públicos, seria possível verificar se ele compreende os padrões de autenticação, observabilidade, testes e tratamento de erros usados pela própria organização. O agente seria avaliado no terreno em que precisará trabalhar.
Para negócios menores, a oportunidade provavelmente aparecerá primeiro na avaliação, não no treinamento de um modelo do zero. Uma fábrica de tarefas derivadas do código interno pode comparar fornecedores, testar atualizações e identificar quais tipos de demanda ainda exigem revisão humana intensa. Isso produz uma métrica mais útil do que perguntar genericamente qual modelo programa melhor.
Há, contudo, questões de segurança e licenciamento. Código proprietário não deve ser enviado indiscriminadamente a serviços externos, e repositórios abertos possuem licenças com obrigações diferentes. Testes gerados também podem revelar regras de negócio ou vulnerabilidades. Antes de adotar a abordagem, empresas precisarão definir isolamento de execução, controle de acesso, rastreabilidade e critérios claros para o uso de cada projeto.
O open source ocupa uma posição dupla nesse cenário. Ele oferece um enorme laboratório de comportamentos executáveis, mas não é um depósito sem dono. Preservar atribuição, respeitar licenças e impedir que benchmarks incentivem cópias literais será parte da engenharia — e não um detalhe jurídico acrescentado no fim.
Quando todo programa vira um professor
O CodeMidas aponta para uma transformação maior: software existente pode ensinar novos sistemas não apenas por meio de seu texto, mas por meio de seu comportamento. O programa executado se torna referência; seus componentes viram problemas; e seus testes ajudam a construir critérios de aprendizagem.
A promessa é poderosa, mas precisa ser lida com cautela. Uma implementação antiga pode conter erros, decisões ruins ou comportamentos que ninguém deseja preservar. Reproduzir fielmente um sistema não significa melhorá-lo. Se a fábrica de tarefas tratar todo comportamento observado como verdade, poderá ensinar agentes a repetir dívidas técnicas com grande eficiência.
O papel humano muda, mas não desaparece. Em vez de escrever manualmente cada exercício, especialistas passam a decidir quais repositórios são apropriados, quais comportamentos merecem ser aprendidos e quais verificadores representam qualidade de verdade. A automação aumenta a escala da escola; não escolhe sozinha o currículo.
Talvez essa seja a contribuição mais interessante do trabalho. Durante anos, tratamos código aberto principalmente como dados para leitura. O CodeMidas sugere enxergá-lo como um conjunto de mundos executáveis, onde agentes podem experimentar consequências e receber correções. Se a proposta amadurecer, a vantagem dos futuros agentes não virá apenas de terem lido mais código, mas de terem praticado em mais sistemas — e aprendido, repetidamente, a provar que o trabalho realmente funciona.