@nixCraft ooh, i have a relevant anecdote!

About 15 years ago, my employer has been spending a decade trying to modernize their flagship product. It was written in Natural, which is very similar to COBOL, and this was hurting sales. Several projects to rewrite this massive ancient code base in something more modern had failed.

Then we found a company from Hungary which had a magic tool that would do a machine translation from Natural/adabas to Java/sql.

The most incredible thing is, it worked and they delivered on time. Obviously a lot of manual fixes to deal with bits of code that confused their tools, but it actually worked.

But it didn't work well. It was painfully slow, the whole system would lock up on the most trivial actions (like querying a customer's balance), but that was because natural and Java are conceptually VERY different. The correct logic of one is totally stupid and clumsy on the other. And that's before we get to the database... Adabas predates relational databases. That account query that took so long? It was doing something like iterating through the entire table till it found the correct record because adabas commands were very low level and that was the correct and most efficient way to do things. But in a SQL db, that command logic translated to SELECT * FROM TABLE; and then doing a for loop on each line of output till you find the record you want. DB server thrashing, app server suffering memory exhaustion, and nobody can do a thing till the query ends.

The magic translator tool could not optimise for stuff like that.

Anyway, this AI tool is facing an almost identical task and I bet it will have the same problem.