Há uma vasta quantidade de conhecimento especializado que não está na internet. Também não está em nenhum livro ou banco de dados. Ele é distribuído através do cérebro humano, codificado em sistemas de execução, e incorporado em processos que ninguém entende completamente.
Friedrich Hayek articulou isso em 1945 melhor do que ninguém desde então:
“Não há dúvida de um corpo de conhecimentos muito importantes, mas desorganizados, que não podem ser chamados de científicos no sentido do conhecimento das regras gerais: o conhecimento das circunstâncias particulares do tempo e do lugar.” [1]
Ele estava escrevendo sobre economia, mas a observação é muito mais geral. Grande parte do mundo tem conhecimento local, tácito e distribuído. Pense no coordenador logístico que ganha a vida sabendo sobre a capacidade de retrocesso temporariamente não alocada em uma faixa de caminhoneiro. O agente imobiliário que vê oportunidades fugazes antes de qualquer um. O árbitro que lucra com as diferenças de preços locais, ninguém notou ainda. Cada um possui conhecimento de que, como Hayek disse, “por sua natureza não pode entrar em estatísticas e, portanto, não pode ser transmitido a qualquer autoridade central em forma estatística”.
Este é o problema do conhecimento. Não falta informação, mas um reconhecimento de que a informação mais importante resiste à centralização.
Também descreve, quase perfeitamente, o que aconteceu dentro dos maiores sistemas de software do mundo.
O conhecimento bloqueado no código de execução
Mainframe COBOL sistemas processam trilhões de dólares em transações todos os dias. Eles foram construídos ao longo de décadas por milhares de desenvolvedores, cada um respondendo às suas próprias circunstâncias particulares: uma mudança regulatória, um incidente de produção em uma noite de terça-feira, uma reclamação do cliente sobre um erro de arredondamento em interesse trimestral.
Ninguém desenhou estes sistemas como um todo. Eles cresceram. Camada por camada, patch por patch, cada desenvolvedor contribuiu com o conhecimento local para uma base de código compartilhada. As regras comerciais que regem as aprovações de transações, os cálculos de juros, o tratamento de exceções e as transições do estado de conta raramente foram anotadas de forma limpa. Eles foram incorporados em código, layouts de dados, convenções de chamada, hábitos operacionais e correções de produção. À medida que os autores originais se aposentam, grande parte desse conhecimento se aposenta com eles.
Este é o problema de conhecimento de Hayek, tornado executável.
O conhecimento é muito distribuído em milhões de linhas de código, muito implícito em interações de programas, e muito dependente de dados específicos e estado para ser capturado por qualquer pessoa ou documento. Ninguém entende completamente. O sistema tem. E ainda assim funciona. Todos os dias processa as transações certas, aplica as regras certas e produz os resultados certos.
Por que a abordagem padrão falha
A abordagem convencional da modernização do mainframe é, em termos Hayekianos, uma forma de planejamento central. Contratar uma grande equipa de consultoria. Lê o código. Documente as regras de negócio. Reescreva o sistema a partir da documentação.
Isto falha pela mesma razão que o planeamento central falha. A abstração perde os detalhes que importam.
Um consultor lêSe WS-FICO-SCORE < 300e escreve: "As pontuações de FICO abaixo de 300 são rejeitadas." Mas o verdadeiro conhecimento não está nessa frase. Está no comportamento do sistema em condições reais. O que acontece quando esse cheque falha na metade de uma transação? O que acontece quando a área de comunicação contém um estado específico? O que acontece quando um cursor é posicionado em um registro específico e um caminho de exceção é acionado dois programas mais tarde? É aí que vive a verdadeira regra.
O conhecimento vive parcialmente em código, mas mais importante no comportamento do sistema em execução sob restrição.
Uma resposta comum, mas ingênua, é: você não pode apenas apontar uma fronteira LLM para o COBOL e perguntar o que ele faz? Um LLM de fronteira apontado para um arquivo COBOL pode frequentemente dizer-lhe o que um parágrafo parece fazer isoladamente. Ele não pode dizer de forma confiável o que acontece quando dezessete programas interagem através de buffers de byte compartilhados, áreas de comunicação interprogramados, limites de transação e dados em forma de produção. Ler não é suficiente. O importante conhecimento é expresso através da execução.
Construir o ambiente, deixar AI explorar
Assim, a alternativa é replicar o ambiente em que esse conhecimento é expresso.
Em vez de pedir aos humanos que leiam o código e reconstruam as regras, você constrói uma réplica fiel e instrumentada do sistema legado: aquele que se comporta como o original, mas funciona em um ambiente onde cada ramo, cada mutação, cada estado intermediário, e cada interação pode ser observada. Então você deixa IA operar dentro desse ambiente, formando hipóteses, executando experimentos, observando resultados, e revisando sua compreensão.
Esta é uma orientação fundamentalmente diferente. Paras de tratar a compreensão como uma tarefa de leitura. Em vez disso, você constrói um mundo em que o entendimento pode ser descoberto através da interação.
Em umaensaio anterior, Argumentei que a Lição Amargo de Rich Sutton [6] se aplica à compreensão de código. Métodos gerais que alavancam a computação tendem a superar métodos construídos em torno de abstrações feitas por humanos. Resumição, RAG, ontologias projetadas manualmente, gráficos de conhecimento: estas são todas tentativas de comprimir a compreensão através de heurísticas que funcionam até um ponto e, em seguida, quebrar em escala e complexidade suficientes. Esta é a Lição Amarga aplicada à modernização.
Não construa esquemas de compressão cada vez mais inteligentes para o conhecimento tácito. Construa o ambiente em que esse conhecimento é expresso, e deixe a exploração – usando métodos gerais como pesquisa e aprendizagem – fazer o trabalho.
Na prática, isso significa construir um gêmeo comportamental do sistema legado e dar aos agentes de IA as ferramentas para interagir com ele: navegar telas, enviar entradas, inspecionar dados, observar traços de execução, comparar resultados e testar conjecturas sobre lógica de negócios contra o comportamento real do sistema.
Isto é só um teste em roupas mais chiques? Nem por isso. O ensaio começa com uma especificação e verifica se o sistema o satisfaz. Isto começa sem uma especificação e tenta descobrir uma. A direcção está invertida. Está mais perto do método científico do que da QV.
Por que construir o gêmeo em vez de ler o código?
À primeira vista, construir uma réplica fiel soa ainda mais difícil do que entender o código diretamente. Em certo sentido, é. Mas é um tipo diferente de difícil.
Ler um grande sistema legado e reconstruir seu verdadeiro comportamento é um problema de julgamento. Depende da interpretação, contexto tácito e esforço humano heróico. Construir um gémeo fiel é um problema de engenharia. O objetivo é fazer da fidelidade uma propriedade do sistema que você constrói, não um subproduto da intuição de alguém.
Isso significa traduzir o sistema legado em uma representação cujo comportamento pode ser verificado sistematicamente, em seguida, apertar a equivalência através de métodos formais e validação diferencial contínua. Execute as mesmas entradas através do sistema original e do gêmeo. Compare saídas, traços e efeitos colaterais. Onde divergem, fecham a lacuna. Com o tempo, transformas a fidelidade em algo mensurável.
Isto importa porque, uma vez que a infra-estrutura existe, cada novo sistema torna-se explorável pela construção. Trocamos um processo quebradiço, manual e irredutível contextual por um processo baseado em engenharia repetitiva.
Os laboratórios de IA já entendem o padrão
Uma das lições mais claras da IA moderna é que os ambientes batem conjuntos de dados estáticos.
DeepMind não conseguiu sobre-humana Vá construindo uma base de dados gigante de comentários de especialistas. Eles construíram um motor de jogo e deixaram o agente aprender agindo dentro dele. Quando AlphaGo Zero [2] removeu dados de jogos humanos completamente e aprendeu através do auto-jogo, ele ultrapassou o sistema anterior. O ambiente era o currículo.
O mesmo padrão aparece noutro lugar. O SWE-bench [4] avalia agentes codificadores dentro de repositórios reais onde eles podem inspecionar código, fazer edições e executar testes. WebArena [5] avalia agentes web dentro de aplicações web funcionando em vez de conjuntos de dados estáticos de vestígios de navegador. Os grandes laboratórios foram para sistemas de uso de computador onde o modelo opera uma interface real com imagens, movimentos do mouse e ações de teclado. Em cada caso, a capacidade vem não apenas de mais dados, mas de atuar dentro de um mundo estruturado que produz feedback.
O padrão já está visível: se você quiser que um sistema domine um domínio, descrições são muitas vezes um substituto ruim para o próprio domínio.
Esse princípio se aplica tanto ao software corporativo quanto aos jogos, repositórios de códigos ou navegadores.
Se você quiser que a IA entenda um sistema bancário de quarenta anos, não apenas entregue arquivos de origem e peça um resumo. Dê-lhe um ambiente para operar.
Fidelidade é todo o jogo
Naturalmente, isto só funciona se a réplica for fiel. Se o gêmeo divergir do sistema real, o entendimento extraído estará errado.
É por isso que a verificação não é apenas um bom-para-ter, mas todo o jogo.
O gêmeo deve ser validado continuamente contra o sistema original através de execução paralela. As mesmas entradas devem produzir as mesmas saídas, as mesmas transições de estado chave e o mesmo comportamento observável. Cada discrepância é útil. Revela onde o modelo do sistema está incompleto e onde o ambiente deve tornar-se mais preciso.
Feito corretamente, o ambiente torna-se um instrumento progressivamente mais afiado para extrair a compreensão.
Isto é o que estamos construindo na Hypercubic: não ferramentas de documentação, não plataformas estáticas de análise de código, mas ambientes fiéis e exploráveis onde a IA pode descobrir o conhecimento que nunca foi escrito.
Em breve teremos muito mais a dizer sobre as especificidades.
Referências
- Hayek, F.A. (1945).O uso do conhecimento na sociedade. American Economic Review, 35(4), 519-530.
- Silver, D. et al. (2017).Dominando o jogo de Ir sem conhecimento humano.Natureza, 550, 354-359.
- Open Ended Learning Team, DeepMind. (2021).Aprendizagem aberta leva a agentes geralmente capazes.
- Jimenez, C.E. et al. (2023).SWE-bench: Modelos de linguagem podem resolver problemas GitHub do mundo real?
- Zhou, S. et al. (2023).WebArena: Um ambiente realístico para a construção de agentes autônomos.
- Sutton, R. (2019).A lição amarga.