Benchmark is the language server COBOL never got.
Every serious AI coding tool has converged on the same architecture. One component of it does not exist for the mainframe, and that absence is the reason these programs keep going wrong.
What a language server does
If your teams use modern development tools, they rely on one constantly without thinking about it.
A language server reads source code and answers questions about it with authority. Where is this function defined. What type is this field, really, after the generics and the inheritance resolve. Every place this variable is written to. Which callers break if the signature changes.
It is not a search tool and not a guess. It parses and resolves the code the way a compiler does, and returns facts. When your engineers press go to definition and land in the right place, that is a language server.
Every AI coding tool is built on one
This is the part worth checking for yourself, because it is not a claim about our product. It is a description of how the field settled.
The tools that write code for your developers all work the same way. An approximate layer finds candidate code, using embeddings or keyword search or plain text matching. Then a second, exact layer establishes what is actually true about it. The first layer locates. The second states facts.
The second layer is almost always a language server. Editors resolve symbols through one. Coding agents trace references through one. Published guidance for using AI agents on large codebases recommends wiring one in, so the agent searches by symbol rather than by string.
The reason is not preference. An approximate match is a good way to find something and a terrible way to be certain of it. Anything that reaches generated code has to come from the exact layer, or you are shipping the model’s best guess.
Locate, then state, then cite
A search points at candidates. The model states the resolved fact. The provenance record names the line it came from. We hold that order everywhere, because it is the only version that survives an audit.
That is the component we supply
We build a complete, resolved model of your estate and make it queryable. Ask for a record layout and you get every field with its real precision and scale. Ask what writes to a variable and you get every place, across every program. Ask what a job depends on and you get the chain.
These are lookups against a resolved model rather than searches. There is one right answer and you get it, with the file and line range it came from.
Your engineers reach it through a web interface. Your pipelines call an API. AI agents connect over MCP, so a migration pipeline can request precisely the facts it needs and nothing else. Whatever is doing the work, it stops guessing.
A note on the analogy
We are not claiming to implement the Language Server Protocol, and you should be suspicious of anyone who blurs that. We are not a plugin for your editor.
What we are claiming is the role. In the architecture above, something has to be the authority that resolves the code and states facts. For Java or TypeScript that is a language server. For your estate, it is this model. The function is identical, the audience is a migration pipeline rather than a developer typing, and the scope is wider: not one language, but COBOL, JCL and CICS resolved together as a single system.
The wider scope is the part that matters most, because mainframe migrations rarely fail on the COBOL. They fail on the job network, the transaction state and the data access paths, and no language server for any language has ever modeled those.
Why not just use text search
Because it works when names carry meaning. Eight-character identifiers, storage that overlaps itself and branching computed at run time are precisely where it fails, and that is most of a mainframe estate.
Built on a standard
The model is structured on ISO/IEC 19506, published by the Object Management Group. You can read it without our software, and another supplier could pick it up if you replaced us.
The honest version of the counter-argument
Some AI tool builders have started removing the indexes they built. If you follow this space, you should ask us about it.
Their reasons are sound, and they are all about modern code. An index of an active repository is stale within hours, and a confidently wrong answer is worse than no answer. Storing it somewhere doubles the surface area of the intellectual property. And for a codebase whose names are meaningful, an agent reading files directly often does well enough.
None of those reach a mainframe estate. Your code has not moved in twenty years, so nothing goes stale. Our model is deployed inside your boundary and never leaves it, so there is nothing new to protect. And the identifiers are exactly the kind that defeat reading a file and hoping.
Every argument against precomputing rests on a property of modern codebases. Your estate does not have those properties. That is the whole point of it.
Test the claim on your own code
Give us one application and a question nobody can currently answer about it. That is usually the fastest way to find out whether any of this is true.