Archeology or Exploration? Glover's Pre-Computed Understanding vs Claude's Real-Time Analysis

Ask Claude Code how a discount calculation works, and it will give you a good answer. It greps the codebase for keywords, reads the relevant files, follows the call chain, and synthesizes an explanation grounded in the actual source. If the discount logic lives in if (discountType == "BULK") { total *= 0.85; }, Claude Code will find that line, explain what it does, and trace how it's called.

That's impressive. It's also the wrong level of abstraction for modernization.

The Rediscovery Problem

Every time Claude Code answers a question about a codebase, it starts from scratch. It reads raw source, follows references, builds a mental model on the fly, and produces an answer. The next question? Same process. Different files, same approach — grep, read, synthesize, forget.

For a developer working on a feature branch, this is fine. The context window is large enough, the questions are scoped to a handful of files, and the throwaway nature of the analysis doesn't matter because you only need the answer once.

For modernization, it's a fundamental limitation.

Modernization requires understanding that persists across thousands of questions, hundreds of modules, and months of work. When an agent decomposes a monolith into services, it needs to know — durably, not ephemerally — that Module A and Module B share a transaction boundary that can't be split. It needs to know that the batch job in Module C is triggered by an external scheduler that isn't visible in the codebase. It needs to know that the business rule in Module D was superseded three years ago but the code was never updated.

Claude Code can discover each of these facts individually, on demand, by reading the right files at the right time. But it can't hold all of them simultaneously. It can't build a persistent map. And it can't connect a finding in Module A to an implication in Module D without someone asking exactly the right question in exactly the right sequence.

This is the rediscovery problem: real-time code analysis produces understanding that evaporates the moment the context window moves on. In a modernization program that runs for months and touches millions of lines, you end up re-deriving the same insights over and over — or worse, failing to re-derive them when they matter most.

What The Glover "Archaeologist" Does Differently

At Glover Labs, we built a system we call the Archaeologist that inverts the whole model. Instead of reading code on demand, the Archaeologist pre-computes a structured understanding of the entire system before any modernization work begins.

The pipeline runs in layers. It parses the AST. It builds cross-reference graphs. It traces data flows across modules, databases, and external interfaces. Then it uses LLM-driven analysis to extract meaning — not just structure, but business rules, domain boundaries, user journeys, entity relationships, and gaps where the code contradicts the documentation or where documentation doesn't exist at all.

The output is a knowledge graph: a pre-computed, queryable, versioned representation of what the system does, why it does it, and how the pieces connect. This is what feeds the Living Spec — the bidirectional system of record that all of our agents coordinate through.

When you ask the Archaeologist the same discount calculation question, you get a different kind of answer. Not if (discountType == "BULK") { total *= 0.85; }, but: "The Pricing domain applies three discount strategies — bulk, loyalty, and promotional — each with configurable thresholds defined in the DISCGRP batch job." The answer is grounded in business terms, with context about which domain it belongs to, what entities it touches, and what the invariants are.

Different Altitudes, Different Uses

Neither approach is strictly better. They operate at different altitudes, and the right one depends on what you're trying to do.

Claude Code gives you answers grounded in exact lines of source. If you need to know precisely how a calculation is implemented — the specific conditional, the specific variable — Claude Code is more precise and more traceable. A developer debugging a function wants this level of detail.

The Archaeologist gives you answers grounded in business intent. If you need to know what a subsystem means to the organization — how it fits into the broader domain model, what business rules govern it, where the boundaries are — the Archaeologist captures context that may not be obvious from the code alone. Especially in legacy software like COBOL, where the business intent is often buried under forty years of accumulated patches, the code-level answer and the business-level answer can be surprisingly far apart.

For day-to-day development, Claude Code's approach is fast, cheap, and sufficient. You ask a question, you get an answer, you move on.

For modernization, you need the Archaeologist's approach — because modernization isn't about understanding one function at a time. It's about understanding the system. The whole system. At a level of abstraction that lets you make architectural decisions, not just line-level edits.

Why Pre-Computation Matters at Enterprise Scale

Abstraction levels aside, there's a brute economics argument for pre-computation. When hundreds of questions will be asked about the same codebase over the course of a project, doing the deep analysis once and querying the results is dramatically cheaper than re-reading the code every time.

Claude Code's read-on-demand approach means that every agent, every query, every analysis session re-traverses the same code. In a 10-million-line codebase, that's a lot of redundant reading. The Archaeologist pays the cost of deep analysis once, up front, and every subsequent query runs against pre-computed knowledge — faster, cheaper, and without the risk of the context window losing critical findings.

It also means understanding is durable. When the Archaeologist identifies that 40% of a codebase is dead code — because it correlates static analysis with production telemetry — that finding is written to the knowledge graph and available to every agent, every human reviewer, every planning session from that point forward. It doesn't need to be rediscovered. It doesn't degrade as the conversation gets longer.

For enterprise modernization programs that run for months with multiple teams, this is the difference between a system that learns and a system that reads.

Where They Work Together

The strongest modernization architecture isn't one or the other — it's both. The Archaeologist builds the understanding layer: the persistent, structured, business-level map of what the system is and does. Claude Code (or any capable coding agent) does the execution: writing the actual migration code, generating tests, producing pull requests.

The Archaeologist tells the coding agent what to build. The coding agent builds it. When the coding agent discovers something unexpected during implementation, that finding flows back through the understanding layer and the map updates.

This is the Figure-8 architecture we've written about before — two loops, coordinating through a shared system of record. The Archaeologist powers the understanding loop. The coding agent powers the action loop. Neither is sufficient alone.

The question for enterprise teams evaluating their modernization toolchain isn't "which AI coding tool should we use?" It's "who builds the understanding layer that the coding tool needs to operate on?" The coding tools are commoditizing fast. The understanding layer is where the value — and the difficulty — actually lives.

Book a demo to see the Archaeologist in action.