Os Limites das LLMs: Boas em reproduzir o que existe. Caras pro que não existe

Papo reto: todo mundo já viu LLM vomitar CRUD de olhos fechados. Formulário, relatório, endpoint, teste unitário, sai bonito e sai rápido. Aí a galera conclui que programador acabou. Eu uso isso pra tudo há quase dois anos, publiquei dezenas de projetos com elas, e a minha leitura é outra.

Se eu tivesse dançando, a gente encerrava no gancho e ia embora mentindo. O que elas fazem de melhor é reproduzir o que já existe. Isso cobre uma fatia gigante do trabalho corporativo, não se engane. Mas tem uma fronteira que elas não cruzam com facilidade, e eu passei os últimos meses esbarrando nela de propósito. Se LLM é tão boa em código, os provedores têm muito a agradecer às décadas de open source, que publicou tudo de graça. Sem esse patrimônio, não existiria Copilot, Cursor, Claude Code, nada disso.

Tem, e eu ponho na mesa. O argumento é especulativo, baseado em observação e nos dados públicos. Ninguém fora dos laboratórios sabe exatamente como cada provedor treina o próprio modelo, e isso muda de casa pra casa e de versão pra versão. O que vale hoje pode não valer na próxima geração. Leva com um grão de sal. Agora o ponto cego, que é onde a conversa pesa.

Todo LLM foi treinado no que é público. A internet pública inteira, e no caso de código, o GitHub público. O dataset canônico de código aberto, o The Stack v2 da BigCode, é explícito: deriva do Software Heritage, o arquivo de todo o código-fonte publicamente disponível. São dezenas de terabytes, bilhões de arquivos únicos, mais de cem milhões de repositórios. Gigantesco. E todo público.

Olha o outro lado. O Octoverse de 2025, relatório oficial do GitHub, diz que mais de oitenta por cento das contribuições na plataforma aconteceram em repositórios privados. Isso é só o GitHub. Fora dele tem o código interno de toda empresa que nunca encostou num servidor público. Tem o fonte de todo software proprietário. Tem o código de todo jogo comercial e o de todo sistema embarcado. Nada disso nunca entrou no treino.

Exato. O modelo conhece profundamente o que o mundo já publicou, e é cego pro que o mundo mantém fechado. Quando você pede um formulário React, ele está reproduzindo padrões que viu milhões de vezes. Quando você pede algo que ninguém nunca fez em público, ele está operando num território onde o mapa dele é branco.

Porque o lado que funciona explica a sensação de fábrica. Olha o que tá pipocando: o Spotifast e o ZapFast, clientes nativos de Spotify e WhatsApp escritos em Rust por uma pessoa só, rodando em Linux, macOS e Windows. Nada ali é tecnologia nova. É o serviço que já existia, embrulhado num app nativo enxuto, em cima de biblioteca que já existia, fazendo o que os times oficiais sempre puderam fazer e nunca quiseram gastar o tempo.

E os meus projetos seguem o mesmo padrão, tá ligado? O FrankMD é um web app de notas em Markdown com cara de Visual Studio e features que já existiam nos meus outros apps. O Frank Sherlock é um organizador de imagens local que, no fundo, é um gerenciador de arquivos com miniatura e busca, coisa que existe aos montes. Nenhum dos dois inventa nada: são misturas de peças conhecidas, montadas do jeito que eu sempre quis. A LLM faz a parte chata, e é por isso que a velocidade aparece.

O cliente de email. Uso o Geary há anos, e duas faltas pequenas sempre me irritaram: o autocomplete de destinatário fraco e um painel lateral que eu queria poder esconder. Coisa boba, que nunca justificou montar ambiente de build, aprender a ferramenta do projeto e estudar o código só pra duas features. Esse ano eu finalmente resolvi os dois: um módulo de autocomplete, um módulo pra esconder o painel, e um fork inteiro com meus patches.

É mole? Eu não fiquei mais rápido. A parte chata ficou barata. Repara no que todos esses casos têm em comum: o problema já tinha sido resolvido antes, em outro lugar, de outro jeito. O mapa existia; faltava mão de obra barata pra refazer o caminho. É a reprodução trabalhando a favor, e é por isso que o seu feed está cheio de gente entregando app novo toda semana. Guarda esse raciocínio. O resto é o que acontece quando o mapa acaba.

Eu não tô teorizando. Nos últimos meses eu rodei uma maratona de projetos de retrocomputação que são exatamente o caso patológico: trabalhar com software proprietário de trinta ou quarenta anos atrás, cujo código-fonte nunca foi público. É o ponto cego perfeito. O primeiro se chama nes-to-sms, e esse eu desisti.

A ideia: pegar a ROM binária de um jogo de NES, traduzir instrução por instrução do processador 6502 pro Z80, converter os gráficos, e gerar uma ROM de Master System que roda no hardware real. Esquece emulador e port manual: é uma máquina que transforma um jogo num outro. Recompilador estático de NES existe, o NESRecomp traduz pra C e roda nativo em PC, e eu estudei ele de perto.

Cruzar de um console pra outro console de oito bits, com orçamento de relógio e de processador de vídeo totalmente diferente, ninguém nunca fez. Não existe referência pública, não existe artigo, não existe projeto abandonado pra copiar. Quase trezentos e cinquenta commits. Mais de trinta dias ativos espalhados por quase quatro meses. Mais de cem mil linhas de motor em Rust e Z80. Quase setecentos testes passando no último registro do README.

O resultado: Super Mario Bros. jogável, lento, com áudio limitado, mas jogável, com a trajetória de memória igual à do NES numa rota de quase cinco mil quadros. Castlevania jogável na fase um. Super Mario Bros. 3 renderizando. E uma fila de jogos que ligam três quadros e morrem. E não foi por falta de empurrar os modelos.

Só nesse projeto passaram quatro gerações de Claude, do Opus 4.7 ao Fable 5.1, com mais de duzentos commits co-assinados e mais de cem ligados a sessões no histórico, mais sessões de Codex nos trechos sem co-autoria, com passagem de bastão documentada entre agentes. Teve até auditoria entre gerações: uma sessão nova revisou os mais de cinquenta commits anteriores e reverteu conclusões que a geração anterior tinha exagerado.

Só a caçada aos travamentos do Castlevania consumiu mais de quarenta commits em cinco dias. O sprint final de setembro foram quase cento e oitenta commits em dezessete dias antes de eu decretar a pausa. As regressões estão registradas pelo nome no histórico: tentativa revertida, mapa de banco revertido, resultado correto mas revertido, além de três hipóteses de alavanca compartilhada testadas e rejeitadas nos últimos três dias. Tokens eu não medi de forma confiável nesse projeto, então não vou inventar número.

O único jogo que ficou realmente pronto é o Super Mario Bros. Por quê? Porque é o jogo mais dissecado da história. Existe uma desmontagem completa e pública que a comunidade usa há mais de uma década, com cada função nomeada e comentada. Eu alimentei isso no perfil do jogo e a LLM tinha um mapa completo pra trabalhar. Pros outros, não existe mapa. Sem mapa, cada jogo novo morria alguns quadros depois de ligar, por divergência de fluxo de controle, e cada um exigia uma caçada forense instrução por instrução que não rendia nada pro jogo seguinte.

O próprio projeto documentou o padrão de giro. Teve uma campanha inteira de otimização que durou semanas tentando cortar o custo de emular as flags do 6502 no Z80. Aí em setembro eu parei pra comparar com o port manual que um hacker chamado lackoftrack27 fez de Super Mario Bros. pra Master System, escrito por um humano, rotina por rotina. Pela análise do código dele, o port humano roda dentro do orçamento de quadro, com uma folga que estimamos perto de noventa por cento de utilização. A minha máquina, depois de meses de otimização, ainda precisava de overclock.

Quando removemos uns trinta por cento das chamadas de emulação de flag, o tempo mal se moveu. As flags nunca foram o gargalo. A otimização certa era redesenhar a estrutura de dados: transpor o vetor de objetos pra páginas de memória. É um truque que depende de saber que o registrador X, naquele ponto, é sempre um índice de objeto. Essa invariante existe na cabeça do programador que escreveu o jogo em 1985. Ela não existe no fluxo de instruções. Um tradutor estático não tem como descobri-la. E o LLM, por meses, não descobriu.

O banner de pausa que eu escrevi no README é direto: a paridade em hardware real pode ser fundamentalmente inalcançável. E, citando, isso pode ser um limite dos modelos de fronteira atuais tanto quanto da abordagem. No mesmo dia em que pausei, eu comecei o gg-to-sms. Foi o pivô pro território com mapa.

Converter jogos de Game Gear pra Master System com a tela alargada. A diferença que importa é que esse problema não é novo. A cena de romhacking vem convertendo jogos de Game Gear pra Master System à mão há vinte anos, e o catálogo que eu montei no projeto contou quase duzentos deles. Existe corpus, existe referência verdadeira, existe padrão pra aprender.

Em um dia de trabalho a fase de pesquisa estava completa. O catálogo dos quase quatrocentos jogos de Game Gear estava montado. O scanner de pontos de patch foi validado contra patches humanos reais, acertando os endereços com margem de poucos bytes. E de quebra a ferramenta achou bugs de verdade em patches de vinte anos atrás que a cena inteira nunca tinha notado. O modelo era o mesmo. O que mudou foi o problema, que dessa vez tem referência.

Até agora, zero jogos passaram na revisão de aceitação da tela. O ponto novo do projeto, a máquina que gera os patches sozinha, que é a parte que ninguém nunca fez, continua por fazer. Mapa ajuda. Mapa não faz milagre na fatia inédita.

Sprint de quatro dias, praticamente uma sessão única de Codex que consumiu mais de quatrocentos milhões de tokens de entrada. O objetivo: rodar Super Mario Bros. Deluxe de Game Boy Color com tela alargada em resolução de NES, coisa que nenhuma ferramenta existente faz com sprites vivos. Subiu pra jogável em quatro dias. Mas olha o alicerce.

Um emulador pronto, vendido como dependência, e uma desmontagem dormente do jogo que alguém tinha publicado anos atrás, que a própria documentação do projeto chama de o artefato mais importante. O trabalho novo foi o renderizador customizado, e ele parou com umas vinte fases completadas de um total de mais de trinta. As que faltam travam em timing de plataforma móvel. O projeto está parado no meio do sprint desde então, e ainda não desisti dele.

Detalhe que diz muito: eu tive que dirigir a revisão olhando capturas de tela, porque o agente entregava coisa com glitch gráfico e não percebia sozinho. Ele gera. Ele não vê. Quem tinha o olho era eu.

O que funcionou nele: tudo que foi construído em cima de artefato existente. O motor é uma reconstrução em C feita por outra pessoa com Ghidra. Os pesos iniciais da IA vieram de checkpoints publicados. As regras de rede foram inferidas de uma engenharia reversa pública do netcode. Até a física: o bug central foi diagnosticado porque eu tinha uma trajetória de referência gravada pra comparar quadro a quadro.

O que não funcionou: as fases de castelo com labirinto. O treino por reforço estaciona nelas. Mais de quarenta milhões de passos de agente, reinício de treino do zero, recompensa anti-loop, e no fim a única coisa que resolveu uma das fases foi cirurgia manual de viés no modelo treinado. Das mais de trinta fases, quase vinte limpas. As piores continuam travadas.

Exato. Quando o treinamento não resolve, o fluxo vira roleta de seleção de checkpoint, dezenas de variações de viés e de cabeças de saída, jogando permutação e computação no problema no lugar de uma correção de princípio. Eu reconheço esse padrão de todos esses projetos. E isso me leva ao que eu sinto depois de meses operando a máquina.

Intuição de quem operou a máquina por meses, não dado duro. Mas o padrão se repete com Claude, com GPT, com Kimi, com GLM, então não parece defeito de um modelo. O começo de qualquer projeto é uma maravilha. Os primeiros marcos voam, porque montar estrutura, escrever harness de teste, replicar API, isso tudo é território coberto. Aí o projeto chega na parte que ninguém nunca fez, e a velocidade desaba.

O histórico de commits do nes-to-sms está cheio de mensagens honestas tipo tentativa revertida e hipótese fechada com resultado correto mas revertido. Muito token queimado, pouco avanço. Minha leitura do que acontece por dentro: a amostragem de tokens é probabilística. Quando o problema é parecido com o treino, os tokens certos têm probabilidade alta e a resposta sai direto. Quando o problema é inédito, a probabilidade do caminho certo é baixa, e o processo vira uma força bruta direcionada. Tentativa e erro guiada, mas tentativa e erro mesmo assim.

A saída que eu encontrei pra esse giro é sempre a mesma: dar um oráculo. Se eu consigo definir que o resultado tem que ser igual a X, uma imagem de referência, uma trajetória gravada, um emulador ciclo-exato como gabarito, a máquina consegue iterar até esbarrar no X. No nes-to-sms, cada destravamento real veio disso: a desmontagem do Super Mario, o diff de quadro, o emulador de referência. Quando eu não consigo definir o X direito, ela gira indefinidamente.

Caçar projeto abandonado, artigo, qualquer material que o modelo nunca viu mas que aproxima o problema, e enfiar no contexto. Isso aquece a distribuição e melhora muito o resultado. Mas é limitado: se nada parecido existe, não tem o que alimentar. E antes que o cético diga que isso é anedota de um cara teimoso com console velho, vamos pra pesquisa, porque tem gente medindo exatamente isso.

O estudo GSM-Symbolic da Apple pegou problemas de matemática de benchmark e fez duas coisas simples: trocou só os números, e depois adicionou uma única frase irrelevante no enunciado. A performance cai só de trocar os números. E despenca até uns dois terços com a frase irrelevante. A hipótese dos autores, no texto: os LLMs atuais não fazem raciocínio lógico genuíno; eles replicam passos de raciocínio dos dados de treino.

O GSM1k da Scale AI criou um espelho do GSM8K escrito do zero por humanos, garantidamente sem contaminação, e viu quedas de até uns oito por cento em várias famílias de modelo, com sinais de overfitting sistemático nas piores. Pra ser justo com o artigo: os autores dizem que os modelos de fronteira mostram sinais mínimos de overfitting e que todos generalizam até certo ponto pra problemas novos. O sinal existe. O tamanho dele é discutível.

Avaliar em problemas de código publicados depois do corte de treinamento. Performance inflada em problema de antes do corte e queda em problema de depois do corte em vários modelos populares. O sinal clássico de contaminação. E tem o ARC-AGI, o benchmark do François Chollet desenhado especificamente pra ser à prova de memorização: cada tarefa é inédita, nenhuma parecida existe no treino.

No ARC-AGI-2, lançado em março de 2025, a tabela oficial diz: LLMs puros marcam zero. Sistemas de raciocínio ficam em dígito único. E cada tarefa de avaliação foi resolvida por pelo menos dois humanos em até duas tentativas. O Chollet, aliás, resumiu minha tese melhor que eu, lá em fevereiro de 2024: LLMs não são AGI, são um grande ajuste de curva num dataset muito grande. Funcionam por memorização e interpolação.

Se você quer automatizar uma tarefa conhecida que casa com a distribuição do treino. Memorização funciona, desde que você não precise se adaptar ao novo. No mundo real, o estudo que mais me impressionou foi o ensaio controlado da METR: uns dezesseis desenvolvedores experientes, quase duzentas e cinquenta tarefas reais nos próprios repositórios maduros deles, randomizado com e sem IA. Os devs apostavam que IA ia acelerar uns vinte e quatro por cento. Mediu-se: ficou quase vinte por cento mais lento.

Exatamente o ponto cego. E o benchmark favorito da indústria pra dizer que IA já faz engenharia de software, o SWE-bench, é só Python, uma dúzia de repositórios open source famosos, ou seja, a fatia mais coberta do treino. A métrica de sucesso da indústria mede o território com mapa. Até a literatura de código legado diz a mesma coisa: um artigo de 2026 sobre LLMs gerando COBOL crava que, nessas linguagens, a maior parte do código de produção está em sistemas corporativos e raramente é publicamente disponível. É a tese desse artigo, dita por outras pessoas.

Steelman, pra quem não conhece o termo: o oposto de espantalho. Em vez de atacar a versão mais fraca do argumento contrário, você responde à versão mais forte. E ela existe e é boa. Em maio de 2025 o DeepMind publicou o AlphaEvolve: um sistema que achou um algoritmo de multiplicação de matrizes quatro por quatro complexas com uns quarenta e oito multiplicações escalares, melhorando o recorde do Strassen de 1969 nesse cenário específico.

Numa lista de mais de cinquenta problemas abertos de matemática, ele redescobriu o estado da arte em uns setenta e cinco por cento dos casos e melhorou a melhor solução conhecida em uns vinte por cento. Isso é novidade. O o3-preview da OpenAI saltou pra perto de setenta e seis por cento no ARC-AGI-1 em dezembro de 2024, mais de vinte pontos acima do melhor resultado anterior no mesmo conjunto, e a configuração de compute alto chegou a perto de oitenta e oito por cento a um custo estimado de mais de quatro mil dólares por tarefa.

E lá em 2016 o AlphaGo fez o lance 37 contra Lee Sedol, um lance que os dados do próprio DeepMind estimavam ter uma chance em dez mil de ser jogado por um humano, provando que busca sobre modelo pode transcender imitação. Agora olha o mecanismo dos três. O AlphaEvolve é um loop evolutivo: o LLM propõe mutações, um avaliador automático pontua, a seleção itera. O o3 faz síntese de programas em tempo de teste, explorando o espaço de soluções. O AlphaGo é busca em árvore sobre aprendizado por reforço.

O insight veio do sistema de busca ao redor do modelo. Os três são força bruta direcionada com um verificador barato, o mesmo mecanismo que eu descrevi acontecendo nos meus projetos. A diferença é que o DeepMind tem oráculo perfeito e orçamento infinito. Na configuração que chegou a perto de oitenta e oito por cento, o o3-preview gastava milhares de dólares por tarefa do ARC. A própria ARC Prize escreveu a ressalva: sabemos que uma busca de força bruta poderia acabar resolvendo o ARC-AGI, dados recursos e tempo de busca ilimitados. Isso não representaria inteligência de verdade.

Se o seu problema tem verificador barato e você tem tokens pra queimar, dá pra ir longe. Foi assim que o nes-to-sms chegou onde chegou: quase setecentos testes e gabarito de emulador segurando cada passo. Mas quando não tem oráculo, não tem corpus e não tem referência, você está pagando força bruta em dólar, com regressões no caminho, e o teto aparece. E quando a força bruta vence, dá pra medir o tamanho da tentativa e erro.

A prova de Navier-Stokes da OpenAI: uns dez mil agentes rodando em paralelo por quase quatro dias, queimando na casa de mais de cem bilhões de tokens de saída num único problema. O Noam Brown, da OpenAI, confirmou que o resultado custou milhões, e a New Scientist estimou uns quinze milhões a preço de tabela. E nem essa montanha de compute partiu do zero: a prova se apoiou no maquinário que matemáticos humanos publicaram ao longo de décadas atacando o problema e os problemas irmãos. Sem o mapa dos humanos e sem o orçamento da OpenAI, não tem prova.

A reconstrução forense contou quase dezoito mil ações de atacante até os agentes conseguirem executar código em mais de quarenta servidores de produção da Hugging Face e pegar root. De quebra, no ambiente da própria OpenAI, leram quase mil segredos do gerenciador de segredos da empresa. Insight brilhante de um lance só? Não. Foi um enxame executando tentativa atrás de tentativa, com verificação automática dizendo o que colou. A inteligência da manchete é volume.

Tentativa e erro em escala industrial, sem garantia nenhuma de que a busca acha o que você precisa. E quem pode assinar esse cheque é meia dúzia de empresa no mundo, nível OpenAI e Anthropic, com orçamento praticamente ilimitado de compute. Pro Zé da esquina, com cartão de crédito e uma chave de API, o teto chega muito, muito antes.

Aqui mora uma confusão que eu vejo toda hora, e vale desfazer porque ela contamina a interpretação de tudo até agora. Quando você lê que a Anthropic tem data centers do tamanho de cidades, dá a sensação de que existe uma IA gigante usando aquelas máquinas todas ao mesmo tempo, pensando, acumulando experiência a cada interação. A realidade é bem mais medíocre que isso.

Um modelo tipo Fable ou Astra é um arquivo de computador. Arquivo estático, nem banco de dados é: depois que o treinamento e o pós-alinhamento terminam, aquele arquivo é trancado e fica só leitura. O que roda no data center são cópias desse arquivo. Cada usuário que consome o modelo está executando uma cópia dele num servidor diferente, isolada das demais, sem colaborar com nenhuma. A sua sessão não conversa com a sessão de ninguém, e nada do que acontece nela volta pro arquivo original.

Aprendizado novo só entra num lugar: na próxima leva de treinamento. Quando a Anthropic tinha o Opus 4.7 e lançou o 4.8, foi ali que conhecimento novo foi assado no modelo, num processo que custa milhões e leva semanas. Fora disso, o arquivo não muda um byte. Seu agente queimando milhões de tokens em tentativa e erro está contribuindo exatamente zero de aprendizado novo pro modelo que ele usa. Quase cento e oitenta commits daquela maratona? Do ponto de vista do modelo, não aconteceu.

Estagiário inútil pelo menos finge que lembra da daily. Esse acorda e ontem não existiu. E é por isso que a metáfora do estagiário que aprende com o tempo está errada: estagiário acumula. Modelo não. O que acumula na maratona é o seu contexto, suas notas, o seu arquivo de instrução, seus testes. O ativo que você constrói é seu, e evapora se você não documentar. Essa é também a resposta pra quem acha que é só deixar o agente rodando que ele aprende o domínio. Ele não aprende domínio nenhum: ele explora o espaço com o conhecimento congelado do dia do treino, e no dia seguinte acorda com amnésia.

Na moral. Agora a pergunta seguinte do amador: mas e se a IA treinar a IA? Ela parte de uma premissa errada, a de que isso seria novidade. IA treinando IA existe há décadas e tem nome: aprendizado por reforço. O AlphaGo já fazia isso em 2016, jogando milhões de partidas contra si mesmo. O AlphaZero, em 2017, levou a ideia ao limite: aprendeu xadrez, shogi e Go partindo do zero absoluto, sabendo só as regras de cada jogo, e chegou a nível sobre-humano em questão de horas de jogo contra si, sem ver uma única partida humana.

LLMs também já usam reforço. O RLHF que transforma um modelo base em assistente é aprendizado por reforço, e a geração dos modelos de raciocínio levou isso adiante: o DeepSeek-R1-Zero mostrou em janeiro de 2025 que comportamento de raciocínio, auto-verificação, reflexão, cadeias longas de pensamento, emerge de reforço puro, sem ajuste supervisionado. É o AlphaZero aplicado a matemática e código. Agora repara no que esses exemplos têm em comum.

Jogo tem placar, matemática tem prova, código tem teste. Fora desse território não tem de onde tirar o sinal de recompensa. É o mesmo oráculo do steelman, só que institucionalizado: eficaz, caríssimo e nichado. O AlphaZero joga Go melhor que qualquer humano que já existiu e não sabe fazer absolutamente mais nada. E tem o detalhe que derruba a pergunta por completo: todo esse aprendizado acontece no laboratório, durante o treino.

IA treinando IA produz um arquivo novo. O arquivo, uma vez lançado, continua sem aprender nada. A resposta mais sofisticada pra objeção só reforça a conclusão. E o mercado já sabe disso. Desde o fim de 2024 os laboratórios admitem, oficialmente e extraoficialmente, que os retornos de escala estão encolhendo.

A Reuters reportou em novembro de 2024 que OpenAI, Google e Anthropic colhiam ganhos menores que o esperado no pré-treino, com o Orion da OpenAI decepcionando a ponto de ser rebaixado de GPT-5 pra GPT-4.5. O Ilya Sutskever, o cara que basicamente inventou a tese do scaling, subiu no palco do NeurIPS 2024 pra declarar que pré-treino como conhecemos vai acabar: os dados públicos são combustível fóssil, e a gente já raspou o fundo. Os ganhos de reforço pós-treino são reais, mas incrementais. A era do salto de ordem de grandeza a cada geração ficou pra trás.

LLM vai substituir programador? Minha resposta ficou mais precisa depois desses meses: vai substituir a parte do trabalho que é reprodução. E essa parte é grande. Formulário, relatório, CRUD, integração com API documentada, migração de framework: isso tudo já existe mil vezes no treino, e a máquina reproduz melhor que a maioria dos humanos. Quem só faz isso está mesmo com os dias contados.

A fatia de reprodução é grande, e quem vive só dela vai sentir. Mas o trabalho que é de verdade novo continua humano: o sistema que ninguém construiu, o domínio sem documentação, o código proprietário que você não pode mostrar pro modelo, o problema em que você não sabe nem escrever o teste que define certo. Tudo isso depende do que nunca foi publicado: a invariante que existe na cabeça de quem entende o problema, e não no fluxo de instruções.

Confesso que teve uma hora em que eu achei que a conta ia fechar pro lado do legado: finalmente uma ferramenta capaz de dar conta do COBOL que assombra banco e governo até hoje. Depois desses meses, acho que esse problema vai demorar muito mais do que parecia. Não existe uma comunidade open source gigante de COBOL. Quase todo esse código é privado, e privado de verdade: banco, seguradora, governo. Não tem material de treino, ou tem muito pouco. O modelo não sabe o que fazer com código que nunca viu, e COBOL de produção é quase tudo código que ele nunca viu.

LLM consegue replicar o que é aberto, mas não adivinha o que é privado. Se esses modelos são bons em código, é porque décadas de comunidade open source lutaram pra manter código livre, público e reutilizável, e os provedores treinaram em cima desse patrimônio sem pagar um centavo de licença por ele. O mínimo que a indústria de IA deve ao mundo é reconhecer isso: a capacidade dela é, em grande parte, a nossa generosidade compilada.

A ironia final: o programador que sobrevive é justamente o que sabe construir oráculo, definir teste, caçar referência obscura e reconhecer quando o agente começou a girar. A habilidade que a máquina mais precisa de você é a que ela menos consegue aprender com o treino dela. Por enquanto o emprego segue. Diferente, e ainda humano.