A Arquitetura da Compreensão: Além da Sintaxe na Modernização de Legado Empresarial

Resumo executivo

A modernização de sistemas legados empresariais — especificamente a migração de arquiteturas de mainframe para ambientes nativos da nuvem — chegou a um ponto de inflexão crítico em meados da década de 2020. Por décadas, os setores financeiro e governamental operaram sob um paradigma paradoxal: o imperativo de modernizar é existencial, mas a taxa de falha dessas iniciativas permanece catastroficamente alta, oscilando entre 70% e 80%. ¹ O advento recente dos Large Language Models (LLMs) prometeu uma revolução, oferecendo a possibilidade tentadora de tradução automatizada de código. No entanto, os ciclos iniciais de adoção revelaram uma deficiência crítica e sistêmica nas abordagens padrão de IA Generativa quando aplicadas a repositórios monolíticos complexos.

Estamos testemunhando o surgimento de uma nova categoria de falha de engenharia, tipificada pelo cenário apócrifo, porém altamente realista, de um grande banco tentando reescrever trinta anos de COBOL em Java usando um assistente comercial de programação. A IA, funcionando como um tradutor localizado sofisticado, converteu a sintaxe perfeitamente. No entanto, a aplicação resultante derrubou o banco de dados na implantação. A falha não foi de sintaxe, mas de contexto. A IA, limitada pela síndrome "Lost in the Middle" e por uma compreensão do software baseada em texto, perdeu uma dependência crítica de variável definida milhares de linhas antes do bloco de execução. ³

Este whitepaper, apresentado pela Veriprajna, argumenta que a abordagem vigente de "Wrapper de LLM" — que trata o código como uma sequência linear de tokens de texto — é fundamentalmente inadequada à complexidade não linear da modernização empresarial. Software não é texto; é um grafo. É um sistema altamente estruturado de dependências lógicas, fluxos de dados e mudanças de estado que existe em um espaço topológico multidimensional. ⁵

Defendemos que o único caminho viável é a adoção de Grafos de Conhecimento Conscientes do Repositório . Ao passar da predição estocástica de texto para o raciocínio determinístico baseado em grafos, podemos mapear dependências de variáveis em milhões de linhas de código, resolvendo o fenômeno "Lost in the Middle" e transformando a modernização de uma aposta arriscada em um processo de engenharia matematicamente verificável. ⁷ Este documento descreve a transição técnica da tradução de sintaxe em nível de superfície para a transformação estrutural semântica profunda.

Capítulo 1: A Crise Silenciosa da Infraestrutura Legada

1.1 O Paradoxo da Modernização

Na economia digital atual, a infraestrutura do comércio global depende de forma precária de tecnologia desenvolvida durante a Guerra Fria. É uma realidade surpreendente, frequentemente não reconhecida, que, em 2025, uma maioria significativa dos sistemas financeiros, de saúde e governamentais do mundo é alimentada por bases de código legadas — aplicações monolíticas escritas em linguagens como COBOL, PL/I e RPG que há muito saíram do currículo mainstream de ciência da computação. Esses sistemas não são meramente "antigos"; são o alicerce fundamental da economia global, e ainda assim estão se erodindo a um ritmo alarmante.

As estatísticas pintam um quadro sombrio dessa dependência. Aproximadamente 70% do software que roda nas empresas da Fortune 500 foi desenvolvido há mais de duas décadas. ⁹ No setor bancário, a situação é ainda mais aguda: 43% dos sistemas bancários são construídos em COBOL, e esses sistemas processam 95% de todas as transações de ATM. ¹ Estamos, na prática, operando a economia moderna de pagamentos instantâneos sobre uma base digital que antecede a internet.

O custo de manter esse status quo está disparando. A dívida técnica acumulou-se a um estimado $1.52 trillion somente nos EUA. ¹ As organizações estão presas em um ciclo de "manter as luzes acesas", com 80% dos orçamentos federais de TI dedicados a operações e manutenção, restando magros 20% para inovação. ⁹ Esse dreno de recursos é agravado por uma grave escassez de competências; à medida que a geração de desenvolvedores que escreveu esses sistemas se aposenta, o conhecimento institucional necessário para mantê-los desaparece. ¹⁰

Tabela 1: O Ônus Econômico dos Sistemas Legados

Métrica	Estatística	Fonte
Custo da Dívida Técnica (EUA)	$1.52 Trillion	1
Manutenção de TI Federal Orçamento	~80% do Gasto Total	9
Dependência Bancária	95% das Transações de ATM em COBOL	1

Probabilidade de Violação de Dados	3x Maior para Sistemas >10 Anos de Idade	11
Rotatividade de Desenvolvedores	58% Consideram Sair devido a Stacks Legadas	1

Esses dados indicam uma vulnerabilidade sistêmica. O imperativo de modernização não é apenas sobre redução de custos; é sobre sobrevivência. Sistemas com mais de dez anos têm estatisticamente três vezes mais probabilidade de sofrer uma violação de segurança em comparação com aplicações modernas. ¹¹ À medida que os requisitos regulatórios de privacidade de dados e relatórios em tempo real se tornam mais rígidos (p.ex., GDPR, DORA), a incapacidade dos sistemas legados de se adaptar torna-se um risco de conformidade da mais alta ordem.

1.2 A Anatomia da "Falha Bancária"

Para compreender a necessidade de uma nova abordagem, precisamos dissecar o cenário que se tornou o "Paciente Zero" das falhas de modernização com IA. Este estudo de caso, referenciado pela liderança da Veriprajna, ilustra o mecanismo específico pelo qual a IA padrão falha em ambientes empresariais.

Uma grande instituição financeira iniciou um projeto para migrar um sistema central de processamento de transações de um IBM Mainframe (COBOL/DB2) para uma arquitetura de Microsserviços Java nativa da nuvem. O banco utilizou um assistente de programação de IA popular — essencialmente um wrapper em torno de um modelo de fundação — para traduzir o código.

A IA ingeriu um programa COBOL responsável por processar transferências eletrônicas de alto valor. O programa continha uma instrução COMPUTE complexa envolvendo uma variável que chamaremos de TRN-LIMIT. A IA traduziu a sintaxe perfeitamente. Converteu a instrução COMPUTE em uma operação Java BigDecimal. O código compilou. Os testes unitários — gerados pela mesma IA com base no bloco de código local — passaram.

No entanto, na implantação no ambiente de Teste de Aceitação do Usuário (UAT), a primeira transação derrubou a verificação de consistência do banco de dados.

A Autópsia: A variável TRN-LIMIT não estava definida no arquivo-fonte que a IA traduziu. Ela foi definida em um COPYBOOK (um arquivo de cabeçalho compartilhado) incluído milhares de linhas antes na cadeia de execução. Mais importante, esse COPYBOOK continha uma cláusula REDEFINES — um construto COBOL que permite que o mesmo endereço de memória seja interpretado como dois tipos de dados diferentes dependendo de um flag definido em um módulo completamente diferente. A IA, operando sobre um "chunk" de texto, viu TRN-LIMIT como um campo numérico simples. Ela não viu a cláusula REDEFINES porque esta estava localizada em um arquivo diferente que não estava na janela de contexto imediata. Ela "alucinou" uma definição padrão para a variável. No ambiente de mainframe, o endereço de memória continha um packed decimal; no ambiente Java, a IA tratou-o como um inteiro padrão. O descompasso fez a aplicação Java gravar dados binários corrompidos na coluna do banco de dados, disparando uma falha de integridade referencial. ⁴

A falha não foi de sintaxe; o código Java era sintaticamente perfeito. A falha foi de cegueira contextual . A IA perdeu uma dependência que existia fora do seu "campo de visão", levando a uma divergência semântica catastrófica.

1.3 O Dilema "Lift and Shift" vs. Refatoração

O histórico do setor em modernização é abismal, mesmo antes da introdução da IA Generativa. Pesquisas indicam que entre 70% e 80% dos projetos de transformação digital e modernização de legado falham em atingir seus objetivos. ²

Tradicionalmente, as organizações enfrentaram uma escolha binária:

1.​ Rehost (Lift and Shift): Mover a aplicação compilada para um emulador na nuvem. Isso preserva o "spaghetti code" e a dívida, apenas mudando a fatura de hospedagem. Falha em desbloquear a agilidade da nuvem. ¹⁴

2.​ Rewrite (Refatorar): Reescrever manualmente o código em uma linguagem moderna. Isso é astronomicamente caro, lento e arriscado devido à falta de documentação e à arquitetura "Big Ball of Mud", em que a lógica de negócio está inextricavelmente entrelaçada com o acesso a dados. ¹⁰

A IA Generativa deveria oferecer um "Terceiro Caminho" — refatoração automatizada. No entanto, a "Falha Bancária" prova que, sem uma compreensão mais profunda da topologia do software, a IA apenas acelera a criação de código falho.

Capítulo 2: A Falha da Tradução Estocástica

2.1 A Economia do "Wrapper" e seus Limites

Nesse ambiente de alto risco entrou o "Wrapper de LLM". A reação imediata do mercado de consultoria de software ao lançamento do GPT-4 foi a proliferação de ferramentas que atuam como camadas de software finas entre um desenvolvedor e um modelo de fundação. ¹⁵ Essas ferramentas prometem "conversar com o seu código", permitindo que desenvolvedores colem um parágrafo COBOL e recebam um método Java em troca.

Embora esses wrappers reduzam a barreira de entrada para a adoção de IA, eles são fundamentalmente falhos quando aplicados à reengenharia de sistemas em larga escala. Wrappers tipicamente dependem de RAG Ingênuo (geração aumentada por recuperação). Nesse processo, o sistema recebe uma consulta do usuário, busca em um banco de dados vetorial trechos de código que são textualmente semelhantes à consulta e alimenta esses trechos no LLM como contexto. ¹⁷

As limitações dessa abordagem em um contexto empresarial são graves:

1.​ Miopia Contextual: Um wrapper vê o código como segmentos de texto. Ele não compreende que uma variável ACCOUNT-BALANCE modificada em SECTION-A dirige uma lógica de decisão em SECTION-Z a cinco mil linhas de distância.

2.​ Sucesso Sintático, Falha Semântica: Como observado, um LLM pode produzir código Java que compila perfeitamente, mas falha em replicar o comportamento exato de runtime do COBOL original porque perdeu uma mudança de estado global. ⁴

A Veriprajna se diferencia ao rejeitar a filosofia do "Thin Wrapper". Afirmamos que soluções de IA profunda devem compreender a estrutura do repositório, não apenas o texto do arquivo.

2.2 A Síndrome "Lost in the Middle"

Para entender por que a IA padrão falha na modernização de legado, precisamos compreender a arquitetura cognitiva dos Large Language Models. Esses modelos se baseiam na arquitetura Transformer, que usa um "mecanismo de atenção" para ponderar a importância de diferentes partes do texto de entrada. ¹⁸

Embora os LLMs modernos ostentem janelas de contexto massivas (até 1 milhão de tokens), sua capacidade de usar efetivamente esse contexto não é uniforme. Pesquisa empírica demonstrou um fenômeno conhecido como o efeito "Lost in the Middle" . Quando apresentados a uma longa sequência de informação, os LLMs exibem uma curva de desempenho em forma de U:

●​ Viés de Primazia: São altamente precisos em recordar informação no início do prompt.

●​ Viés de Recência: São altamente precisos em recordar informação no fim do prompt.

●​ A Depressão: O desempenho degrada significativamente para informação localizada no meio. ³

Em um projeto de modernização, um único programa COBOL pode ter milhares de linhas, e pode referenciar copybooks (dependências) que também têm milhares de linhas. Se a definição de uma variável crítica — por exemplo, MAX-TRANSACTION-LIMIT — aparece no meio desse contexto massivo, a IA é estatisticamente propensa a ignorá-la. ²¹

Quando a IA ignora uma definição de variável, ela não para. Ela "alucina". Assume um tipo ou valor padrão para a variável com base em probabilidade, não em fato. Em um sistema bancário, assumir que uma variável é um Integer quando na verdade é Packed Decimal pode levar a erros de arredondamento que corrompem dados financeiros. ²²

Tabela 2: As Limitações Cognitivas dos LLMs Padrão

Fenômeno	Descrição	Impacto na Modernização
Lost in the Middle	Atenção degradada no centro de prompts longos.3	Definições de variáveis perdidas enterradas em arquivos grandes.
Alucinação	Fabricação de fatos plausíveis, mas incorretos.22	Inventar dependências ou lógica para preencher lacunas de contexto.
Viés de Primazia/Recência	Foco no início/fim do texto.20	Ignorar a lógica de negócio central localizada no meio de um procedimento.
Geração Estocástica	Predição probabilística de texto.	Geração inconsistente de código; reexecutar o prompt produz lógica diferente.

2.3 O "Saco de Palavras" vs. A "Árvore da Lógica"

LLMs padrão e sistemas de RAG vetorial processam código principalmente como uma sequência de tokens. Eles se baseiam em similaridade semântica — verificando se palavras da consulta coincidem com palavras no espaço vetorial do documento. ¹⁷

No entanto, código não é linguagem natural. Em linguagem natural, "The cat sat on the mat" tem um significado em grande parte independente de uma frase cinquenta páginas antes. Em software, x = y + 1 tem zero significado a menos que conheçamos as definições, tipos e estados atuais de x e y. Essas definições podem existir em um arquivo diferente, um módulo diferente, ou ser herdadas de uma classe pai. ⁵

Quando uma IA "wrapper" recupera contexto para uma consulta como "Refatore a lógica de pagamento", ela pode buscar cinco trechos de código que contêm a palavra "payment". Provavelmente perderá o trecho chamado GlobalVarDef.cbl, que define a alíquota usada pela lógica de pagamento, porque esse arquivo nunca menciona a palavra "payment".

Essa desconexão representa a lacuna fundamental entre recuperação textual e compreensão estrutural . Para transpor essa lacuna, precisamos parar de tratar código como literatura e começar a tratá-lo como um grafo. ²³

Capítulo 3: A Física do Software –

Código como um Grafo

3.1 Software como um Sistema Relacional

Na Veriprajna, reconhecemos que um repositório de software é fundamentalmente um banco de dados relacional de lógica . Toda entidade dentro da base de código — variáveis, funções, classes, módulos, banco de dados esquemas — existe em uma teia densa de relacionamentos.

●​ Contenção: Um arquivo contém uma classe; uma classe contém um método; um método contém uma declaração de variável.

●​ Herança: A Classe B herda propriedades e métodos da Classe A.

●​ Invocação: O Método X chama o Método Y.

●​ Fluxo de Dados: A Variável Z é modificada pela Função Q e lida pela Função R.

Esses relacionamentos constituem a "verdade fundamental" da aplicação. Não são probabilísticos; são determinísticos. Se o Método X chama o Método Y, isso é um fato concreto, não uma verossimilhança estatística. LLMs padrão operam no domínio probabilístico. Para modernizar com segurança sistemas legados, precisamos ancorar suas capacidades de geração probabilística à realidade determinística da estrutura do código. ⁷

3.2 A Árvore de Sintaxe Abstrata (AST)

A unidade fundacional dessa compreensão estrutural é a Árvore de Sintaxe Abstrata (AST) . A AST é uma representação em árvore da estrutura sintática abstrata do código-fonte. Diferentemente de uma cadeia bruta de texto, uma AST captura a hierarquia e as regras gramaticais da linguagem. ²⁴

Por exemplo, a instrução COBOL: COMPUTE INTEREST = PRINCIPAL * RATE não é apenas cinco palavras. Em uma AST, é um AssignmentNode com um Target (Interest) e uma Expression. A Expression é um MultiplicationNode com um LeftOperand (Principal) e um RightOperand (Rate).26 Ao analisar código legado em ASTs, superamos as ambiguidades do texto. Podemos identificar programaticamente cada uso de variável, cada operação aritmética e cada ramificação de fluxo de controle. Isso nos permite realizar engenharia de "Round Trip" — converter código em AST e de volta para código sem perda de dados — garantindo que nossa análise estrutural seja precisa. ²⁷

Diferentemente do "Text Chunking" usado no RAG padrão — em que um arquivo é cortado às cegas em segmentos de 500 tokens, frequentemente dividindo uma função ao meio — o parsing de AST respeita os limites lógicos do código. Uma função é tratada como uma unidade discreta de lógica, não como um intervalo aleatório de texto. ²³

3.3 O Grafo de Chamadas e a Matriz de Dependências

Enquanto a AST representa a estrutura de um único arquivo, o Grafo de Chamadas representa o sistema nervoso de toda a aplicação. Ele visualiza o fluxo de controle, mapeando quais parágrafos ou sub-rotinas invocam outras. ²⁹

Em sistemas COBOL legados, os grafos de chamadas frequentemente ficam obscurecidos por chamadas dinâmicas ou lógica GOTO que cria "spaghetti code". Uma análise estática de texto não consegue resolver facilmente onde um GOTO LABEL_X aterrissa se LABEL_X for definido dinamicamente ou condicionalmente.

Ao construir um Grafo de Chamadas rigoroso, a Veriprajna identifica "Dead Code" (código que nunca é chamado) e "God Classes" (módulos excessivamente acoplados). Essa análise é crítica para desmembrar monolitos em microsserviços. Se não conhecemos a cadeia completa de chamadas, não podemos extrair com segurança um serviço; corremos o risco de deixar para trás uma "referência pendente" que causará uma falha de runtime — exatamente o cenário que assolou o banco no estudo de caso de abertura. ³¹

Tabela 3: Análise Estrutural vs. Análise de Texto

Recurso	Análise de Texto (IA Padrão)	Análise Estrutural (Veriprajna)
Unidade de Análise	Token / Palavra	Nó (Elemento AST)
Limite de Contexto	Limite Arbitrário de Tokens	Escopo Lógico (Função/Classe)
Resolução de Dependências	Correspondência de Palavras-chave	Travessia de Grafo
Tratamento de GOTO	Trata como cadeia de texto	Mapeia arestas de fluxo de controle
Precisão	Probabilística	Determinística

3.4 Injeção de Dependência e Inversão

Arquiteturas modernas Java e Cloud-Native dependem fortemente de Injeção de Dependência (DI) e Inversão de Controle (IoC). O COBOL legado, inversamente, depende de dependências hardcoded e estado global. Passar de um para o outro exige identificar cada dependência no grafo e "invertê-la".

Precisamos mudar o paradigma de "O Módulo A codifica de forma rígida uma conexão com o Banco de Dados B" para "O Módulo A aceita uma Conexão de Banco de Dados como parâmetro." Essa mudança arquitetural é impossível se a IA não consegue ver a dependência em primeiro lugar. O Grafo de Conhecimento torna essas dependências explícitas, permitindo que a IA gere o boilerplate de DI necessário automaticamente, garantindo que o novo sistema seja modular e testável. ⁴

Capítulo 4: A Forja Semântica Veriprajna

4.1 Arquitetura do Grafo de Conhecimento Consciente do Repositório

A solução para a síndrome "Lost in the Middle" e a fragilidade da migração baseada em texto é o Grafo de Conhecimento Consciente do Repositório . Este é um banco de dados de grafos unificado que combina a estrutura estática do código (ASTs, Grafos de Chamadas) com o significado semântico da lógica de negócio (Documentação, Comentários, Intenção das Variáveis). ⁵

A Veriprajna emprega um pipeline proprietário, frequentemente referido em pesquisa avançada como uma "Forja Semântica", para construir essa inteligência. Isso não é um processo ETL genérico; é um motor construído especificamente para a modernização de legado. ³³

4.2 Fase 1: Parsing Inteligente com Tree-sitter

Utilizamos parsers robustos, principalmente Tree-sitter, para ingerir a base de código legada. Esse processo suporta mais de 13 linguagens, incluindo COBOL, JCL, PL/I e Java. O parser gera uma AST para cada arquivo no repositório.

De forma crucial, empregamos Fragmentação Semântica . Pipelines RAG padrão usam "divisão ingênua", cortando o texto a cada n tokens. Isso frequentemente separa a assinatura de uma função do seu corpo ou uma definição de variável do seu uso, destruindo o contexto. A Fragmentação Semântica usa a AST para identificar limites lógicos. Fragmentamos o código por SECTION, PARAGRAPH ou METHOD, garantindo que cada nó no nosso grafo represente uma unidade completa e executável de lógica. ²³

4.3 Fase 2: Extração de Entidades e Relacionamentos

Uma vez geradas as ASTs, a Forja Semântica extrai as entidades e os relacionamentos para popular o banco de dados de grafos (p.ex., Neo4j, Memgraph).

●​ Entidades: Classes, Paragraphs, Variables, Database Tables, API Endpoints.

●​ Relacionamentos:

○​ CALLS: Conecta um parágrafo à sub-rotina que ele invoca.

○​ UPDATES_TABLE: Conecta um bloco de lógica à tabela DB2 que ele modifica.

○​ IMPORTS_COPYBOOK: Conecta um arquivo-fonte à sua dependência.

○​ DEFINES_VARIABLE: Conecta uma data division às variáveis que ela cria.

Essa fase transforma o texto estático em uma topologia dinâmica. Agora podemos consultar o grafo: "Mostre-me cada parágrafo que atualiza o campo CUSTOMER-ID." Essa consulta retorna resultados exatos instantaneamente, um feito impossível com grep ou busca vetorial. ¹⁴

4.4 Fase 3: Resolução e Fusão de Entidades

Este é o ponto crítico de diferenciação. Um parser padrão vê ACCT-NUM no Arquivo A e ACCT-NUM no Arquivo B como duas cadeias diferentes. Nosso sistema realiza Resolução de Símbolos . Ele determina que ambas se referem à mesma entrada em um Copybook compartilhado. Ele as funde em um único Nó de Variável no grafo.

Além disso, realizamos Fusão Cross-Modal . Se a base de código contém um documento PDF de requisitos que descreve a "User API", e o código contém uma classe chamada UserAPI, o sistema calcula embeddings para reconhecer que são o mesmo conceito. Ele funde o nó de documentação com o nó de código. Isso liga a intenção (docs) com a implementação (código), fornecendo à IA o "Porquê" junto com o "Como". ⁸

4.5 Fase 4: Cálculo do Fechamento Transitivo

A "Falha Bancária" foi causada por uma dependência transitiva: A depende de B, B depende de C. A IA viu A, mas perdeu C.

O Grafo de Conhecimento Veriprajna calcula o Fechamento Transitivo . Quando o sistema analisa o Módulo A, ele não para nos vizinhos diretos. Ele percorre o grafo profundamente (A -> B -> C) para identificar a "Raiz da Verdade" de cada variável. Isso garante que, quando a IA gera código para o Módulo A, ela importe as definições corretas do Módulo C, mesmo que o Módulo C esteja em um diretório ou repositório diferente. ⁸

Capítulo 5: Geração Aumentada por Recuperação em Grafo (GraphRAG)

5.1 As Limitações do RAG Vetorial

A Geração Aumentada por Recuperação Vetorial (RAG) é o padrão da indústria para adicionar conhecimento aos LLMs. Ela converte texto em vetores (representações numéricas) e encontra vetores semelhantes. Embora excelente para consultar texto não estruturado como FAQs, é insuficiente para código.

●​ Renomeação de Variáveis: Se um desenvolvedor renomeia Account para Acct, a similaridade semântica cai, mesmo que a lógica seja idêntica.

●​ Lógica vs. Palavras-chave: Buscar por "Interest Calculation" pode perder a matemática real se a função se chama FNC-001 e não contém comentários.

●​ Contexto Fragmentado: O RAG vetorial recupera "chunks" com base em similaridade de cosseno. Pode recuperar um teste unitário e um comentário de UI, mas perder a lógica de negócio central porque os nomes das variáveis não coincidem com as palavras da consulta. ³⁶

5.2 A Vantagem do GraphRAG

GraphRAG opera sobre a estrutura do Grafo de Conhecimento, não apenas sobre a similaridade textual.

1.​ Identificação de Âncora: Quando um usuário pede "Refatore a Lógica de Pagamento", o sistema usa busca vetorial para encontrar o ponto de entrada (p.ex., o parágrafo ProcessPayment).

2.​ Travessia de Grafo (Expansão): Em vez de parar ali, o GraphRAG percorre as arestas do grafo. Ele puxa:

○​ As arestas CALLS para encontrar sub-rotinas.

○​ As arestas READS para encontrar definições de variáveis.

○​ As arestas INCLUDES para encontrar Copybooks.

3.​ Construção de Contexto: Esses pedaços conectados — que podem ser textualmente dissimilares, mas são logicamente inseparáveis — são montados em um prompt coerente.

Essa Expansão de Relevância garante que o LLM receba uma fatia auto-contida e executável de lógica. Ele compreende não apenas o texto do cálculo, mas a maquinaria dele. ³⁶

5.3 Raciocínio Multi-Hop

Pesquisas mostram que o GraphRAG supera significativamente o RAG vetorial em tarefas que exigem "raciocínio multi-hop" — conectar fatos separados por vários passos. Em software, quase todo bug é uma falha de raciocínio multi-hop (p.ex., A chama B, B altera X, C lê X. Se A muda, C quebra?).

O GraphRAG permite que a IA responda perguntas complexas de análise de impacto: "Se eu alterar a lógica da taxa de juros no Módulo A, quais telas de relatório no Módulo Z serão afetadas?" O RAG vetorial não consegue responder isso porque o Módulo A e o Módulo Z não compartilham similaridade textual; estão ligados apenas por uma cadeia de chamadas de função. O Grafo percorre essa cadeia para fornecer uma resposta definitiva. ³⁸

Tabela 4: RAG Vetorial vs. GraphRAG

Recurso	RAG Vetorial	GraphRAG
Chave de Recuperação	Similaridade (Distância de Cosseno)	Relacionamento (Aresta de Grafo)
Qualidade do Contexto	Alto Recall, Baixa Precisão (Ruído)	Alta Precisão, Contexto Conectado

Raciocínio Multi-Hop	Fraco (Perde ligações indiretas)	Excelente (Percorre cadeias)
Risco de Alucinação	Alto (Adivinha ligações ausentes)	Baixo (As ligações recuperadas são explícitas)
Melhor Caso de Uso	Texto Não Estruturado (FAQs)	Sistemas Estruturados (Código, Biologia)

Capítulo 6: Engenharia da Migração – Imersão Técnica

6.1 Resolvendo a Armadilha da "Variável Global"

Um dos aspectos mais perigosos do COBOL é o uso de variáveis globais definidas na DATA DIVISION e modificadas por várias instruções PERFORM ao longo do programa. Em Java, a melhor prática dita encapsulamento; um método não deve depender de estado oculto.

A Solução: Os agentes da Veriprajna realizam Análise de Fluxo de Dados no grafo. Rastreamos o ciclo de vida de cada variável.

●​ Se um parágrafo CALC-TAX lê GROSS-INCOME, o grafo identifica GROSS-INCOME como uma Dependência de Entrada .

●​ Ao gerar o método Java calcTax(), a IA adiciona explicitamente BigDecimal grossIncome à assinatura do método.

●​ Em seguida, atualiza o chamador do método para passar o valor correto.

Essa refatoração automática de "Estado Global Implícito" para "Passagem Explícita de Parâmetros" previne os bugs de efeito colateral que assolavam o banco no nosso estudo de caso. ⁴

6.2 Desconstruindo o Espaguete GOTO

Um dos obstáculos mais ferozes na migração COBOL é a instrução GOTO. GOTO permite que a execução do programa salte para qualquer lugar, criando fluxos de controle não lineares que são anátema para a programação estruturada moderna. ⁴⁰ Java não tem instrução GOTO.

Traduzir a lógica GOTO exige mais do que tradução de sintaxe; exige Achamento do Fluxo de Controle .

1.​ Análise de Grafo: Mapeamos os destinos GOTO como arestas no Grafo de Fluxo de Controle (CFG).

2.​ Reconhecimento de Padrões: O grafo identifica padrões.

○​ Um GOTO que salta de volta a um rótulo anterior é identificado como um Loop .

○​ Um GOTO que pula um bloco é identificado como um Condicional (if/else).

○​ Um GOTO para um parágrafo de saída é um Return .

3.​ Reestruturação: A IA, guiada pelo grafo, refatora esses saltos em loops while, loops do-while, ou instruções break/continue em Java.

Sem um grafo para visualizar os "loops" criados por GOTO, um LLM baseado em texto frequentemente gera uma chamada de função recursiva que leva a um StackOverflowError, ou simplesmente alucina um fluxo de lógica que não existe. ⁴

6.3 Tratando "Dead Code"

Sistemas legados estão cheios de código que não é mais usado — promoções antigas, produtos aposentados, rotinas de debug. Migrar esse código é desperdício de dinheiro e aumenta a superfície de segurança. A IA baseada em texto migra tudo o que lhe é dado; ela não consegue distinguir entre código ativo e morto.

A Solução: O Grafo de Chamadas identifica Nós Inalcançáveis — parágrafos ou arquivos que não têm arestas de entrada (nenhum chamador). O sistema da Veriprajna marca esse "Dead Code" para exclusão antes de a migração começar. Isso tipicamente reduz o tamanho da base de código em 20-30%, resultando em economia significativa de custos e uma arquitetura final mais limpa.31

Capítulo 7: O Futuro Agêntico – IA Profunda vs. Wrappers Superficiais

7.1 Além do Chatbot: O Fluxo de Trabalho Agêntico

A Veriprajna não implanta "Chatbots". Implantamos Agentes Autônomos de IA . Um agente é um sistema capaz de planejar, executar e corrigir suas ações com base em feedback. ²

O Fluxo de Trabalho do Wrapper Superficial:

1.​ Usuário: "Converta este código."

2.​ Wrapper: Envia texto para o GPT-4.

3.​ Saída: Retorna código Java.

4.​ Resultado: O código falha ao compilar ou executar. O desenvolvedor depura manualmente.

O Fluxo de Trabalho do Agente Profundo Veriprajna:

1.​ Planejamento: O agente analisa a AST do arquivo COBOL-alvo. Ele identifica dependências e consulta o Grafo de Conhecimento.

2.​ Recuperação: Ele busca o contexto GraphRAG necessário para a migração.

3.​ Geração: Ele gera o código Java usando um "Schematic-Constraint Decoder" que impõe regras de sintaxe Java e type safety. ⁷

4.​ Verificação (O Loop): O agente compila o código Java gerado em um sandbox.

5.​ Autocorreção: Se o compilador lança um erro (p.ex., "Variable not found"), o agente lê o erro, consulta o grafo pela dependência ausente e regenera o código.

6.​ Validação: Ele executa testes unitários (gerados a partir dos traces COBOL originais) para garantir que o resultado corresponda ao comportamento de entrada.

Esse Loop Compilar-Corrigir transfere o ônus da validação do humano para a IA, reduzindo dramaticamente o custo da refatoração. ⁴²

7.2 Supervisão Human-in-the-Loop

Embora o agente seja autônomo na execução, ele é supervisionado na estratégia. O Grafo de Conhecimento fornece Interpretabilidade . Diferentemente de uma rede neural "Caixa-Preta", o grafo permite que desenvolvedores vejam exatamente por que a IA tomou uma decisão. "A IA importou com.bank.logic porque encontrou uma dependência em COPYBOOK-X."

Essa transparência é vital para indústrias reguladas como o setor bancário, em que cada linha de código deve ser auditável. Passamos de "Confie em mim, sou IA" para "Aqui está a cadeia de citação desta lógica". ⁴³

Capítulo 8: Conclusão e Perspectiva Estratégica

8.1 O ROI da Consciência de Repositório

Dados da McKinsey sugerem que a GenAI pode reduzir tarefas de programação em 50%, mas somente se implantada corretamente. ¹⁴ O Retorno sobre o Investimento (ROI) da abordagem baseada em grafos da Veriprajna é impulsionado pela eliminação de retrabalho.

●​ Migração Manual: Alto custo, alto risco, lento time-to-market.

●​ IA Wrapper: Custo médio (devido à depuração de "alucinações"), alto risco (bugs ocultos), time-to-market médio.

●​ IA de Grafo de Repositório: Baixo custo (automação), baixo risco (verificação determinística), rápido time-to-market.

Ao eliminar o overhead de "Context Switching" — em que desenvolvedores passam horas caçando onde uma variável está definida — a Veriprajna aumenta a produtividade do desenvolvedor em 2x a 3x em comparação com ferramentas de IA padrão. ²

8.2 Proteção do Futuro via Modernização Contínua

A modernização não é um evento único; é um ciclo de vida. Uma vez que a base de código é convertida em um Grafo de Conhecimento, ela permanece um ativo vivo. À medida que o novo código Java evolui, o grafo é atualizado em tempo real. Isso possibilita:

●​ Documentação Automatizada: A IA pode gerar documentação atualizada para o novo sistema lendo o grafo. ⁴⁴

●​ Detecção de Deriva Arquitetural: O sistema pode alertar arquitetos se o novo código violar regras de modularidade definidas no grafo. ⁴⁵

8.3 A Mudança Estrutural

A lição da "Falha Bancária" é clara: Código não é texto. É um sistema complexo e interconectado de lógica. Tentar modernizá-lo com ferramentas que só entendem texto é análogo a tentar navegar uma cidade usando uma lista de nomes de ruas, mas sem mapa. Você ficará "Lost in the Middle."

A Veriprajna oferece o mapa. Ao construir Grafos de Conhecimento Conscientes do Repositório, fornecemos à IA a inteligência estrutural de que precisa para navegar as complexidades dos sistemas legados. Mapeamos as dependências, desatamos os nós e entregamos modernização que funciona não apenas na sintaxe, mas na realidade.

Não apenas escrevemos código; fazemos a engenharia da compreensão. Esta é a diferença entre um chatbot e um provedor de soluções. Este é o futuro da modernização empresarial.

Veriprajna. IA Profunda para Soluções Profundas.

Obras citadas

1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders, acessado em 10 de dezembro de 2025, https://www.pragmaticcoders.com/resources/legacy-code-stats

2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy, acessado em 10 de dezembro de 2025, https://softprodigy.com/ai-driven-legacy-app-modernization/

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, acessado em 10 de dezembro de 2025, https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs, acessado em 10 de dezembro de 2025, https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation, acessado em 10 de dezembro de 2025, https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

6. Structural-Semantic Code Graph (SSCG) - Emergent Mind, acessado em 10 de dezembro de 2025, https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate, acessado em 10 de dezembro de 2025, https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv, acessado em 10 de dezembro de 2025, https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, acessado em 10 de dezembro de 2025, https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help, acessado em 10 de dezembro de 2025, https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix, acessado em 10 de dezembro de 2025, https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions, acessado em 10 de dezembro de 2025, https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz, acessado em 10 de dezembro de 2025, https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, acessado em 10 de dezembro de 2025, https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs, acessado em 10 de dezembro de 2025, https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome, acessado em 10 de dezembro de 2025, https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch, acessado em 10 de dezembro de 2025, https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium, acessado em 10 de dezembro de 2025, https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

19. A practical guide to the Claude code context window size - eesel AI, acessado em 10 de dezembro de 2025, https://www.eesel.ai/blog/claude-code-context-window-size

20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct, acessado em 10 de dezembro de 2025, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

21. Why Language Models Are “Lost in the Middle” - Towards AI, acessado em 10 de dezembro de 2025, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind, acessado em 10 de dezembro de 2025, https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers, acessado em 10 de dezembro de 2025, https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

24. AST-Based Source Code Migration Through Symbols Replacement, acessado em 10 de dezembro de 2025, https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

25. BMSD 2011, acessado em 10 de dezembro de 2025, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

26. Abstract Syntax Tree Creation - Compiler Design - Meegle, acessado em 10 de dezembro de 2025, https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium, acessado em 10 de dezembro de 2025, https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

28. Daily Papers - Hugging Face, acessado em 10 de dezembro de 2025, https://huggingface.co/papers?q=outlier%20chunk%20handling

29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp, acessado em 10 de dezembro de 2025, https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, acessado em 10 de dezembro de 2025, https://ieeexplore.ieee.org/document/9138056/

31. Enhancing Neural Code Representation with Additional Context - arXiv, acessado em 10 de dezembro de 2025, https://arxiv.org/html/2510.12082v1

32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, acessado em 10 de dezembro de 2025, https://www.ijcai.org/proceedings/2025/0848.pdf

33. Code Graph: From Visualization to Integration - FalkorDB, acessado em 10 de dezembro de 2025, https://www.falkordb.com/blog/code-graph/

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, acessado em 10 de dezembro de 2025, https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv, acessado em 10 de dezembro de 2025, https://arxiv.org/html/2511.07584

36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph, acessado em 10 de dezembro de 2025, https://memgraph.com/blog/rag-vs-graphrag

37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype, acessado em 10 de dezembro de 2025, https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

38. Navigating the Nuances of GraphRAG vs. RAG - foojay, acessado em 10 de dezembro de 2025, https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket, acessado em 10 de dezembro de 2025, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

40. Why not GOTO Statement? [closed] - Stack Overflow, acessado em 10 de dezembro de 2025, https://stackoverflow.com/questions/19766205/why-not-goto-statement

41. Alternative to a goto statement in Java - Stack Overflow, acessado em 10 de dezembro de 2025, https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers, acessado em 10 de dezembro de 2025, https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

43. Legacy IT Modernization with AI | MITRE, acessado em 10 de dezembro de 2025, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, acessado em 10 de dezembro de 2025, https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

45. The AI revolution in application modernization: from manual burden to strategic advantage, acessado em 10 de dezembro de 2025, https://vfunction.com/blog/ai-app-modernization-strategy/