Fabio Akita passou quase quatro meses num projeto próprio, o nes-to-sms, um recompilador estático de jogos do NES para rodar no Master System, antes de desistir dele. Foram 349 commits em 31 dias ativos ao longo desses quase quatro meses, e 668 testes. O Super Mario Bros. saiu jogável, apoiado numa disassembly completa e pública que a comunidade usa há mais de uma década. Os outros jogos do mesmo lote, sem esse mapa, morriam alguns frames depois do boot.
Ele contou o caso num artigo publicado em 28 de setembro de 2026, “Os Limites das LLMs: Boas em reproduzir o que existe, caras pro que não existe”. A frase que resume o argumento dele: “o modelo conhece profundamente o que o mundo já publicou, e é cego pro que o mundo mantém fechado”. Esse limite é o motivo pelo qual a IA está mudando a relação de quem trabalha com software aberto: dá para ler, adaptar e estender um programa cujo código o modelo já viu. O mesmo mecanismo que ajuda aqui é o que trava adiante, e vale entender os dois lados antes de contar com ele. Isso deixa uma pergunta solta: se a IA é boa em reproduzir o que já existe, por que ela está sendo usada, sobretudo, para criar de novo o que já existe?
O que o modelo já leu
Um dos maiores conjuntos de treino de código aberto, o The Stack v2, reúne 67,53 TB de arquivos de código sem compressão, extraídos do arquivo do Software Heritage (ver a página do dataset). É a parte pública do software: bibliotecas, frameworks e scripts publicados em repositórios abertos, o material que um modelo consegue indexar e reproduzir de memória.
Do outro lado fica o que nunca chega a esse treino. Segundo o relatório Octoverse 2025 do GitHub, 81,5% das contribuições em 2025 aconteceram em repositórios privados. Sistema interno de empresa, código embarcado, o que nunca foi publicado: é exatamente aí que a IA não tem o que reproduzir, porque nunca viu.
Por que isso favorece quem já trabalha com código aberto
Já escrevi aqui sobre o QGC4QGIS: trazer para dentro do QGIS o cálculo de grade de voo fotogramétrico que o QGroundControl já fazia, lendo o código-fonte de um projeto aberto para reimplementar a função em outro. O trabalho andou rápido porque os dois programas são abertos: é o tipo de código que entra no treino.
A lógica do artigo do Akita explica o motivo: ler, adaptar e estender um programa publicado é a tarefa em que a IA reproduz bem o que existe. Assim que um dos dois lados é fechado ou inédito, o modelo perde a referência.
Quem já vive no software livre por hábito sai na frente pelo mesmo motivo. Quando escrevi sobre usar Linux com IA, notei que num sistema livre a solução que aparece primeiro também costuma ser livre: em vez de comprar a licença, você procura o pacote, o script, o plugin. É o mesmo terreno em que a IA lê melhor.
O que os números de 2023 diziam, e o que mudou
Um preprint de fevereiro de 2023, arXiv 2302.06590, mediu o efeito do GitHub Copilot numa tarefa isolada: implementar um servidor HTTP em JavaScript o mais rápido possível. O grupo com acesso ao Copilot terminou 55,8% mais rápido que o grupo de controle. É um número real, mas de uma tarefa curta e bem definida, longe do trabalho de manter um sistema em produção.
O teste que chegou mais perto desse cenário veio depois, e mediu o oposto. Um RCT do METR, publicado em julho de 2025 com dados coletados entre fevereiro e junho daquele ano, acompanhou 16 desenvolvedores experientes resolvendo 246 issues reais nos seus próprios repositórios open source, que já conheciam bem. Com IA (principalmente Cursor Pro com Claude), levaram 19% mais tempo do que sem ela. Antes do experimento, esperavam ficar 24% mais rápidos; depois de sentir a lentidão, ainda achavam que tinham ficado 20% mais rápidos.
O METR atualizou o resultado em fevereiro de 2026. Rodaram um novo experimento a partir de agosto de 2025, com 57 desenvolvedores (10 deles do estudo original), e o desenho teve que mudar: parte considerável recusava participar nas condições originais. Alguns disseram que não quereriam fazer metade do trabalho sem IA mesmo recebendo 50 dólares por hora do estudo; entre 30% e 50% evitavam submeter tarefas que não queriam encarar sem assistência. O próprio METR aponta que esse viés corta a amostra no sentido oposto ao que se imaginaria: os desenvolvedores e tarefas que mais se beneficiariam da IA tendem a ficar de fora do experimento, então a estimativa pode estar subestimando o ganho real. Os números medidos mostram alguma evidência de velocidade a favor da IA: tarefas 18% mais rápidas no grupo original (intervalo de -38% a +9%) e 4% mais rápidas no grupo novo (-15% a +9%), o que o próprio METR chama de “evidência muito fraca” do tamanho real do efeito. A equipe acredita que o ganho de produtividade com IA é hoje maior do que em 2025, mas reconhece que ainda não tem como medir quanto.
O mesmo tipo de salto vale para avaliação de código. O SWE-bench, publicado em outubro de 2023, testa modelos resolvendo 2.294 problemas reais tirados de issues e pull requests de 12 repositórios Python open source populares. Território mapeado, exatamente o tipo de código que entra no treino, o que abre espaço para contaminação: o modelo pode ter visto a correção real durante o treino e reproduzi-la de memória. Por isso este post não cita a pontuação atual do benchmark. O LiveCodeBench, de março de 2024, nasceu como resposta a esse problema: coleta continuamente problemas novos de maratonas de programação (LeetCode, AtCoder, CodeForces) para poder comparar o desempenho em problemas publicados antes e depois do corte de treino de cada modelo.
Onde o modelo trava
A distância entre reproduzir um padrão e raciocinar sobre um problema novo dá para medir. O GSM-Symbolic, da Apple, publicado em outubro de 2024, reescreve os mesmos problemas de matemática de nível escolar trocando só os valores numéricos, e o desempenho de todos os modelos testados cai. Ao acrescentar uma cláusula que parece relevante mas não entra de fato no cálculo, a queda chega a 65% nos melhores modelos disponíveis. Os autores levantam a hipótese: os modelos replicam passos de raciocínio vistos no treino, em vez de raciocinar sobre o problema novo. O GSM1k, da Scale AI, publicado em maio de 2024, chega a um resultado parecido por outro caminho: um benchmark equivalente ao GSM8k mas livre de contaminação de treino, e a queda de precisão chega a 8%, com sinais de overfitting sistemático em praticamente todos os tamanhos de modelo. O ARC-AGI-2 (ver o ARC Prize) segue a mesma linha: tarefas verificadas como fáceis para humanos e projetadas para não ter equivalente no material de treino.
Quando o problema é inédito e ainda assim compensa resolver, a saída vira força bruta, e ela tem preço. A AlphaEvolve, da DeepMind, publicada em maio de 2025 e testada em mais de 50 problemas matemáticos abertos, redescobriu o estado da arte em cerca de 75% deles e melhorou a melhor solução conhecida em 20%. O ARC Prize testou o o3-preview da OpenAI, em dezembro de 2024, no ARC-AGI-1: no modo de baixa eficiência (172 vezes mais computação), o modelo chegou a 87,5% no conjunto semiprivado, a um custo de 4.560 dólares por tarefa, contra 75,7% gastando 26 dólares por tarefa no modo barato. E a OpenAI afirmou, segundo a New Scientist em 8 de setembro de 2026, ter chegado a uma solução para o problema de Navier-Stokes: mil agentes trabalhando 50 horas num problema correlato, depois dez mil agentes por 11 horas para estender o resultado, com um custo estimado de 15 milhões de dólares para repetir o processo sob encomenda.
Resolver um problema inédito sai caro mesmo quando compensa: a força bruta computacional cobra um preço proporcional à novidade. Repetir um aplicativo que já existe em algum lugar sai barato, e é essa diferença de custo que ajuda a explicar a enxurrada de lançamentos que vem a seguir.
A enxurrada de apps novos
Enquanto a IA lê melhor o que já é público, a produção de coisa nova também acelerou, e os dados dos dois lados datam do mesmo período recente.
O relatório Octoverse 2025 do GitHub, publicado em 28 de outubro de 2025, contou 121 milhões de repositórios novos criados naquele ano (é o mesmo relatório dos 81,5% de contribuições em repositórios privados, citado no começo do post). É o retrato de quanto código novo nasce, sem separar o que é ferramenta original do que reescreve algo que já existia em outro repositório.
Do lado dos aplicativos, a Appfigures, citada pela TechCrunch em 18 de abril de 2026, registrou que os lançamentos de apps novos no primeiro trimestre de 2026 cresceram 60% sobre o mesmo trimestre de 2025, somando App Store e Google Play, e 80% considerando só a App Store. A reportagem chama a ligação com IA de hipótese de trabalho, apontando ferramentas como Claude Code e Replit, sem apresentá-la como fato estabelecido.
O outro lado do mesmo fenômeno aparece em quem mantém o que já está aberto. Um preprint de 21 de janeiro de 2026, Vibe Coding Kills Open Source (Koren, Békés, Hinz e Lohmann), constrói um modelo econômico: quando agentes de IA montam software a partir de componentes abertos sem que o usuário final interaja com o projeto de origem, e a manutenção depende desse engajamento, a adoção maior reduz a entrada de novos colaboradores e o compartilhamento, o que empobrece a disponibilidade e a qualidade do próprio ecossistema aberto. É um modelo teórico, num preprint, não uma medição de campo.
Casos concretos de mantenedor sentindo esse peso já apareceram em 2026. Adam Wathan, da Tailwind Labs, comentou em um pull request em 7 de janeiro de 2026 que a empresa demitiu 75% da equipe de engenharia por causa do que chamou de impacto brutal da IA no negócio: o tráfego da documentação caiu cerca de 40% desde o início de 2023, com o Tailwind mais popular do que nunca, e a receita caiu perto de 80%. A documentação é o único canal pelo qual as pessoas conhecem os produtos comerciais da empresa. Daniel Stenberg, mantenedor do curl, anunciou em 26 de janeiro de 2026 o fim do programa de recompensa paga por vulnerabilidade, encerrado em 31 de janeiro daquele ano, citando o volume de relatórios de baixa qualidade gerados por IA. O GitHub mudou o próprio produto em 17 de junho de 2026 para deixar mantenedores limitarem quantos pull requests em aberto um colaborador sem acesso de escrita pode manter ao mesmo tempo.
Não existe uma estatística direta comparando apps novos criados com IA contra contribuição em projeto que já existe: ninguém mediu as duas pontas do mesmo jeito. O que dá para colocar lado a lado é isto: de um lado, mais repositórios e mais apps nascendo; do outro, mantenedores de projetos abertos populares relatando menos engajamento e mais ruído. Na minha leitura, os dois quadros convergem: gerar ficou barato, e contribuir continua exigindo ler o projeto dos outros.
Antes de criar, procurar
A ferramenta que já existe carrega o que um projeto novo ainda não tem: gente usando, casos que já testaram o software em uso real, documentação escrita por quem apanhou dos mesmos problemas, e alguém que assumiu mantê-la. Um aplicativo criado do zero começa sem nada disso, mesmo quando resolve exatamente o mesmo problema.
É também onde a IA rende mais. Como mostram as seções anteriores, o modelo lê bem o que já foi publicado: entender um repositório aberto, achar onde mora a função que interessa e estender ou corrigir o que já roda é a tarefa em que ele acerta com mais frequência. Gerar um clone também sai barato, porque o modelo já viu coisa parecida; o que ele não entrega junto é o histórico de uso, os testes e a pessoa que responde quando algo quebra.
O que sobra depois de publicado é conta de quem publicou. Já escrevi sobre isso na seção “O custo que aparece depois”, do post sobre o QGC4QGIS: escrever ficou barato, manter não. Cada ferramenta nova, adotada ou não, vira mais um projeto que vai precisar acompanhar a próxima versão do sistema em que roda, e ninguém faz isso de graça para sempre.
Antes de abrir um projeto novo, valem três perguntas: essa ferramenta já existe em algum lugar? Onde fica o repositório dela? O que falta nela, de fato, que justifica não usar a que já está pronta? Às vezes a resposta é abrir mesmo assim, porque o que falta é grande demais para um ajuste. Muitas vezes o que falta já está descrito numa issue aberta, esperando alguém disposto a ler o código e resolver.
O que eu fiz dentro do QGIS
Os cinco plugins que mantenho seguem o mesmo padrão: em vez de um site ou aplicativo novo, a funcionalidade entrou dentro do QGIS, sobre o projeto que o usuário já tinha aberto.
GisBR substitui o que antes exigia programar em R ou Python com o pacote geobr, do IPEA, ou navegar manualmente por servidores FTP, WFS e ArcGIS REST atrás de bases oficiais. Fora do QGIS, isso teria virado mais um script de download. Dentro dele, virou 55 algoritmos na Caixa de Ferramentas de Processamento, com cache local, espelho automático no GitHub e suporte a certificado SSL embutido nos principais conectores oficiais brasileiros (post, portfólio).
Desire Lines vem de mapas de fluxo que eu ensinava a montar em SQL direto no QGIS, ou de ferramentas antigas que simplesmente não rodavam mais. Isolado, teria sido outro script para colar numa matriz de origem-destino. Dentro do QGIS, é hoje um plugin aprovado no repositório oficial, que gera as linhas de desejo a partir da matriz sem exigir uma linha de código do usuário (post, portfólio).
SIG-Bus nasceu para acabar com o cruzamento manual entre o GTFS de Belo Horizonte e o CSV de embarques da PBH, que exigia entender os dois formatos e resolver na mão os identificadores de linha que não coincidiam entre si. Isolada, teria sido um script de ETL rodado uma vez por análise. Como plugin, importa o GTFS, valida a integridade dele, cruza a demanda por junção espacial e devolve camadas de horário e de carga por trecho já dentro do projeto (post, portfólio).
Logis ocupa o espaço entre o software proprietário de roteirização, caro demais para prefeitura pequena, e o script de pesquisador, que exige ambiente Python montado. Fora do QGIS teria sido mais um script desse segundo tipo. Dentro dele, virou 25 algoritmos organizados em três módulos, e o módulo de logística urbana reaproveita o mesmo pipeline de malha viária do OpenStreetMap que o GisBR já resolvia, o que poupou a parte mais demorada do trabalho (post, portfólio).
QGC4QGIS, que já apareceu neste post e no texto sobre o ecossistema aberto, substitui o replanejamento manual da grade de voo dentro do QGroundControl. A alternativa isolada era continuar redesenhando o polígono à mão no aplicativo de voo, sobre uma imagem de satélite genérica. Dentro do QGIS, a grade nasce sobre as camadas do projeto que já têm o limite da área, a rede viária e o relevo (portfólio).
Nenhum desses cinco é contribuição ao núcleo do QGIS: são extensões, plugins que só existem porque a plataforma já existe primeiro. Ainda assim contam como cooperação, porque rodam sobre o que o QGIS já resolveu antes (leitura de formato, reprojeção, edição, impressão, a própria Caixa de Ferramentas) e chegam a quem já abriu o programa, sem pedir a instalação de mais nada. O limite é o mesmo que já escrevi antes: para quem nunca abre o QGIS, nenhum desses cinco plugins serve.
O que muda para quem usa e mantém software
O fio que atravessa este post é sempre o mesmo: a IA lê bem o que já é público e faz pouco pela pergunta que nunca teve resposta escrita em lugar nenhum. Isso vale para o código que ela ajuda a estender, para o aplicativo que alguém decide criar do zero em vez de procurar antes, e para os plugins que venho publicando dentro do QGIS em vez de fora dele.
Onde o software é fechado, o problema é inédito ou simplesmente não existe uma resposta já publicada, o trabalho de quem opera o agente muda de natureza. Sobra a parte que o Akita descreve como oráculo: definir contra o que o resultado vai ser conferido, seja um teste automatizado, um cálculo de referência ou uma inspeção manual. E sobra saber reconhecer o momento em que o agente parou de convergir e passou a girar em torno do mesmo erro, revertendo uma tentativa atrás da outra sem sair do lugar, o mesmo julgamento que tratei no post sobre aprender com IA sem piloto automático. Nenhuma das duas coisas se delega ao próprio modelo.
Antes de pedir ao agente que construa alguma coisa, vale perguntar duas coisas na ordem certa: aquilo já existe em algum lugar, e onde dá para contribuir com o que já existe, antes de perguntar como fazer de novo.