Every modernization vendor now has an AI slide. The pitch is some version of: point a large language model at the COBOL, let it read and rewrite the logic, and the conversion that used to take a team of engineers a year now takes weeks. It is a compelling story, because it borrows the credibility of everything AI has genuinely gotten good at — summarizing, pattern-matching, explaining unfamiliar code — and quietly applies it to a task those strengths do not cover: producing byte-for-byte identical behavior in code that moves money.
Those are not the same skill. A model that reads a thousand-line COBOL program and gives you an accurate plain-English summary of what it does is doing something LLMs are legitimately strong at — pattern recognition over familiar shapes, in service of a human who is going to verify the output. A model that generates the replacement logic and hands you a translation to trust is doing something categorically different, and the industry has quietly let the first thing's credibility launder the second thing's risk.
Probabilistic output has no place in a deterministic requirement
An LLM does not execute COBOL semantics. It predicts plausible-looking target-language tokens conditioned on the source, trained on a mountain of code that was mostly not the specific dialect, the specific compiler quirks, or the specific three-decade accretion of business rules sitting in the file you handed it. It will get the common cases right, because common cases are common in the training data. It will also, with total fluency and no visible hesitation, get the rare cases wrong — the packed-decimal rounding rule, the ON SIZE ERROR branch nobody has hit in a decade, the COMP-3 field that behaves differently at a truncation boundary. The output looks exactly as confident when it's wrong as when it's right. That is the property that makes it dangerous specifically for money-handling code: there is no visible seam between "translated correctly" and "translated plausibly," and plausible is the whole problem.
Compare that to what a deterministic transpiler does: it applies a fixed, auditable mapping from source construct to target construct, the same way every time, on every input. You can point at the rule that produced a given line of output. You can prove — not sample-check, prove — that running it twice on the same input produces the same result. An LLM conversion gives you none of that. Re-run it and you may get a different phrasing of the same logic, or a subtly different one, because the process that produced it was never designed to be repeatable in the first place.
The methodology dressed as engineering
What makes this a lottery ticket rather than a legitimate risk is how it gets sold. A vendor pitching "AI-accelerated conversion" is rarely offering a coin flip and calling it that — they're offering a process with a name, a slide deck, and a case study, and the packaging does the work of making a probabilistic guess feel like an engineering method. The tell is what happens after the AI produces its output: is there an independent, byte-exact comparison against real production data, on every path, including the ones the requirements doc never mentioned? Or is the AI-generated code treated as substantially done, with testing reduced to a curated set of cases chosen to demonstrate confidence rather than find the failure?
Ask that question directly and the answer usually reveals the actual methodology: generate with AI, spot-check by hand, ship. That is not a modernization process. That is a lottery ticket with a consulting invoice stapled to it — you may win, in the sense that the common paths mostly work and nobody notices the rare ones failed until a customer's account balance is wrong eighteen months later. The house always collects the fee regardless of which way the ticket lands.
Where AI genuinely earns its place in this work
None of this is an argument against AI in modernization — it's an argument about which part of the job it belongs in. Comprehension, not conversion. Pointing a model at an undocumented COBOL system and asking "what does this program appear to do, and where should a human look first" is a legitimate use of exactly the pattern-matching strength that makes these models useful — it accelerates a human's understanding without asking the model's guess to become the system of record. The output is a starting point for a person to verify, not a replacement for verification. That is the honest version of "AI in modernization," and it looks nothing like the pitch deck that promises a converted, production-ready codebase by Friday.
The question that separates the two
If a vendor's methodology includes AI anywhere near the actual code that will run in production, there is one question that exposes which version you're being sold: is the AI's output the thing that ships, or is it a draft that gets checked against real behavior by a deterministic, reproducible process before anyone trusts it? If the answer is the former, you are not buying a conversion — you are buying a probability distribution over correctness, priced as if it were certainty. Determinism is not a nice-to-have on money-handling logic. It is the entire point of the exercise, and it is precisely the property that a generative model, by design, does not have.