Ask a language model to explain a twenty-year-old ColdFusion application and it will oblige. It reads the templates, produces a confident architectural summary, drafts a modernization plan, and does it in minutes. The problem is not that the output is useless. The problem is that it is plausible, and on a legacy estate plausible is not the same as true.
We have built and maintained ColdFusion systems since 1998, and we shipped a production CF2025 migration this summer (the field notes are here). So when a client asks whether AI can accelerate work on a CF estate, the answer is yes, with a condition attached. The model only helps when every assertion it makes is checked against evidence, because its default mode is optimism, and optimism is fatal on code nobody fully understands.
The tourist prompt fails harder on CFML
A write-up published on martinfowler.com this month, The Archaeologist's Copilot, documents the failure mode with unusual candor. The author modernized a Java 1.5 codebase and started the way most people start: paste the code in, ask "how do I run this?" The model returned a pristine modern build file. It also hallucinated the wrong major version of a core dependency, assumed a standard directory layout the project never used, and presented a happy-path example that hid an implementation that was not thread safe. His name for the pattern is the hallucination of competence. The cure, in his telling, was to stop asking for a tour and start demanding a forensic audit grounded in evidence the model must cite.
Everything in that article applies to ColdFusion estates, and three things make it apply harder.
The model has seen less CFML. Java is among the best-represented languages in any training corpus. CFML is not. The confidence of the output does not drop to match, so the gap between how sure the model sounds and how much it has actually seen is wider on a CF estate than almost anywhere else. It will produce fluent CFSCRIPT that quietly mixes dialect eras, or reach for a function signature from a version your server never ran.
Half the system is not in the repository. A CF application's behavior lives partly outside its source: datasources, mappings, and scheduled tasks configured in the ColdFusion Administrator, stored procedures in the database, includes resolved at request time, settings that changed on the server years ago and never made it back to version control. A model reading the repo is reading a fraction of the system, and it cannot tell you which fraction it has.
Nobody is left to catch the miss. The developer who knew why the custom tag from 2009 exists has usually been gone for years. On an active Java project, a wrong summary gets smelled out in code review. On a quiet CF estate, the model's confident summary can become the de facto documentation, wrong or not, and every plan that follows inherits the error.
What counts as evidence on a CF estate
The discipline that works is the one the article converges on: the model proposes, the evidence disposes. On ColdFusion, the evidence looks like this.
Runtime truth over source reading. Which templates actually execute, at what volume, from which callers. Web server logs and application logs answer this; a code read does not. Dead code candidates come from months of access logs, never from the model's opinion of what looks unused. We have watched a "clearly dead" admin module turn out to be the quarter-end process for one department.
Configuration exports over assumptions. Export the Administrator settings and treat them as source. Every datasource gets resolved and tested. Every scheduled task gets an owner and a reason, or it gets flagged. The model can draft the inventory faster than any human, but each row is verified against the running system before it drives a decision.
Behavior baselines before any change. Characterization tests around the endpoints that matter, capturing what the system does today, bugs included. The baseline is what converts "the model says this refactor is equivalent" from an assurance into a claim a test suite can reject.
Containment before improvement
The Java article makes a decision most modernization efforts skip: containment first. The author refused to fix bugs, update dependencies, or even reformat whitespace until the system ran, verifiably, in a reproducible environment matching its own era. Only then did modernization begin.
The ColdFusion version of that move: stand the estate up on the versions it runs today, in an environment you can rebuild from scratch, and get the baseline green before improving anything. It is unglamorous work, and clients sometimes push back because it looks like spending money to stay in place. It is also the step that turns every later change from a leap into a diff. When we plan a migration, containment is a scheduled phase with its own exit criteria, not a hope.
Where the AI actually pays
None of this is an argument against using AI on legacy estates. Constrained by evidence, it is the best tool this work has ever had.
It builds the inventory at a speed no human team matches: every template, every include chain, every query that touches a given table. It does the translation grunt work, dialect upgrades and tag-to-script conversion, with the characterization tests as referee. It drafts the risk ranking that a senior engineer then validates against the logs. What it does not do is decide. What to migrate, what to rewrite, what to leave running untouched: that call rests on evidence plus judgment, and the judgment stays human.
The wrong question about AI and ColdFusion is "can the model understand our code?" It will produce something that looks like understanding either way. The right question is what evidence you will require before you act on what it says. If you are weighing a migration and want the evidence pass before the plan, that is how our ColdFusion migration work starts. AI that ships, not AI that demos.