4 ms·

Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything. Cue some story here on a bank or airline somewhere sti

Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything. Cue some story here on a bank or airline somewhere still relying on cobol backend servers. These LLM conversions really seem to make modernization of large parts software layers possible!

geraneum 3mo ago
> Cue some story here on a bank or airline somewhere still relying on cobol backend servers. There's existing money and expertise in those environments to rewrite the whole thing, yet they don't. You may loan them free engineers/experts and they might still not rewrite anything.
- marcus_holmes 3mo ago
  It's a clean-cut financial decision. The existing system works. Yes, it costs a lot to maintain, and you could definitely reduce that if you moved to a more modern system. So now you're talking payback periods. Cost of development / maintenance cost savings per year = number of years before you pay back the project. Problem is, that the cost of the development is often unclear, and the maintenance cost savings, while definitely above zero, and often unclear, and approximated the numbers usually come to a payback period in decades. And that's without the usual tech caveats; We can't promise there won't be bugs. We can't promise deadlines will be met. We can't promise the project will succeed at all. We can't promise existing functionality will be faithfully reproduced in the new system. The normal risks around any software dev project. All in all, it looks really expensive and really risky compared to just doing nothing and running the same old system for another five years. Source: I helped do some of the maths on this for a Y2K project.
rixed 3mo ago
> the biggest blocker on moving to a new programming language, is the cost of re-writing everything In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?
- misiek08 2mo ago
  It’s still a thing in big corps. We have all business nanoservices (I can’t call them micro) at JVM (moving to Kotlin from Java) and any try using Go is silently killed by those JVM talibans. I wonder if no one really thought there about rewrite that will still connect with all old dependencies with old protocols, but also will expose new kind of API that can be used by next rewritten block. We also had mainframe, we used Oracle. It turned out that casual server is also reliable in long term and we restarted them only for upgrades of OS. Of course moving to some distributed, fault tolerant option also feels like good direction, but instead not-doing the perfect rewrite at once you can do it two/three step migration. Costs nowadays? You already fixed that.
CamouflagedKiwi 3mo ago
I have some familiarity with the bank situation, and while a lot of them are on some very old systems (maybe COBOL, maybe something else, either way they want off it) the cost of actually re-writing the code is far from the most significant issue. Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit out a Rust version is not what you actually want - you now have a modern language but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.
- jiggawatts 3mo ago
  > while you could ask your LLM to do that you aren't going to run your bank on the result. Why not? I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences. The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them! So if you sketch a design for the AI to follow, establish the rules in AGENTS.md, have a robust test suite, use a frontier model dialed up to eleven, etc... why not rely on the LLM output? At the end of the day, humans are not without fault either. I've been wading through some legacy "pre-AI" code recently and it has more bugs than a rainforest! Static fields used incorrectly, causing data races. Floating point types used for money amounts. JavaScript and SQL injection up the wazoo. Wildly unsafe password handling. So on, and so forth. This is the norm for most human-written software, not the exception. As a proof-of-concept, I tried an AI rewrite of one such legacy app[1], and it is not bug free, but it notably has fewer bugs than the original. Different bugs, sure, and I'll have to iron them out after a round or two of UAT, but I'm honestly more confident with what I got from the chatbot than the code inherited from humans. [1] Deals with money, but admittedly at a much lower level of risk and consequence than a banking app running on a mainframe.
  - athanagor2 3mo ago
    How did you conduct this rewrite? Did you hand the AI some specs, some tests, the existing code? I feel like AI has dramatically changed how complete rewrites can be considered, especially for long-lived, legacy projects.
BadBadJellyBean 3mo ago
It's not enough to do a rewrite. Someone has to maintain it. Such a huge codebase with literally zero experts is unmaintainable. There is no one who knows how the internals work. Sure you could keep vibe coding it but I wouldn't bet my data on that. A database needs to be rock solid.
- 72deluxe 3mo ago
  This seems to be the issue with using LLMs for any code generation. Even with my own code bases that I've written entirely by hand over years, if I use AI to implement anything, I don't go through the mental model of architecting it, so I don't know how it works. I can only imagine this to be far, far worse for large code bases maintained by a team of people who are all using AI.
  - win311fwg 3mo ago
    That depends on the language you are using. Some language communities had already rejected "architecture astronauts" before LLMs were born, so the training data was highly consistent, which has lead to LLMs being highly consistent in their output. You know how it works because the LLM spits out the same as what you would have written yourself. It's almost eerie that they can do that. Unfortunately that doesn't apply to all languages. LLMs are especially bad at producing code for the languages that were historically known as beginner-friendly as the training data was full of code by beginners doing what beginners do. All bets are off if you get stuck there. (Although maybe you could use an LLM to translate your code to a language that LLMs are good at!)
    - BadBadJellyBean 3mo ago
      One problem there is that even if the code is consistent, idiomatic Rust is not the same as idiomatic C. So either the translation produced Rust code in the "shape" of C code or the code is quite different from the C implementation. Add to that that you need to have people proficient in Rust and also Postgres as well as the very much unknown codebase as a whole you get a recipe for pain.
    - 2mo ago
bjt 3mo ago
OK but, Postgres is not one of those clunky "we have to replace this" systems.
win311fwg 3mo ago
At the same time that was ever the only reason for moving to a new programming language: abandoning all the bad ideas and craft that had accumulated in the previous language ecosystem. Needing to rewrite everything meant starting from a clean slate, allowing the new systems to be designed for the new age, making everything in that new language feel sleek and modern and thus appealing. Of course, as time progresses even the new language starts to accumulate bad ideas and cruft, historically necessitating yet another language to offer the clean slate again. If the code is going to be translated forward instead of abandoned and then rewritten, as is now completely viable via LLM, there is no reason to move to a new language at all.

geraneum 3mo ago

> Cue some story here on a bank or airline somewhere still relying on cobol backend servers. There's existing money and expertise in those environments to rewrite the whole thing, yet they don't. You may loan them free engineers/experts and they might still not rewrite anything.

marcus_holmes 3mo ago
It's a clean-cut financial decision. The existing system works. Yes, it costs a lot to maintain, and you could definitely reduce that if you moved to a more modern system. So now you're talking payback periods. Cost of development / maintenance cost savings per year = number of years before you pay back the project. Problem is, that the cost of the development is often unclear, and the maintenance cost savings, while definitely above zero, and often unclear, and approximated the numbers usually come to a payback period in decades. And that's without the usual tech caveats; We can't promise there won't be bugs. We can't promise deadlines will be met. We can't promise the project will succeed at all. We can't promise existing functionality will be faithfully reproduced in the new system. The normal risks around any software dev project. All in all, it looks really expensive and really risky compared to just doing nothing and running the same old system for another five years. Source: I helped do some of the maths on this for a Y2K project.

rixed 3mo ago

> the biggest blocker on moving to a new programming language, is the cost of re-writing everything In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?

misiek08 2mo ago
It’s still a thing in big corps. We have all business nanoservices (I can’t call them micro) at JVM (moving to Kotlin from Java) and any try using Go is silently killed by those JVM talibans. I wonder if no one really thought there about rewrite that will still connect with all old dependencies with old protocols, but also will expose new kind of API that can be used by next rewritten block. We also had mainframe, we used Oracle. It turned out that casual server is also reliable in long term and we restarted them only for upgrades of OS. Of course moving to some distributed, fault tolerant option also feels like good direction, but instead not-doing the perfect rewrite at once you can do it two/three step migration. Costs nowadays? You already fixed that.

CamouflagedKiwi 3mo ago

I have some familiarity with the bank situation, and while a lot of them are on some very old systems (maybe COBOL, maybe something else, either way they want off it) the cost of actually re-writing the code is far from the most significant issue. Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit out a Rust version is not what you actually want - you now have a modern language but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.

jiggawatts 3mo ago
> while you could ask your LLM to do that you aren't going to run your bank on the result. Why not? I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences. The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them! So if you sketch a design for the AI to follow, establish the rules in AGENTS.md, have a robust test suite, use a frontier model dialed up to eleven, etc... why not rely on the LLM output? At the end of the day, humans are not without fault either. I've been wading through some legacy "pre-AI" code recently and it has more bugs than a rainforest! Static fields used incorrectly, causing data races. Floating point types used for money amounts. JavaScript and SQL injection up the wazoo. Wildly unsafe password handling. So on, and so forth. This is the norm for most human-written software, not the exception. As a proof-of-concept, I tried an AI rewrite of one such legacy app[1], and it is not bug free, but it notably has fewer bugs than the original. Different bugs, sure, and I'll have to iron them out after a round or two of UAT, but I'm honestly more confident with what I got from the chatbot than the code inherited from humans. [1] Deals with money, but admittedly at a much lower level of risk and consequence than a banking app running on a mainframe.
- athanagor2 3mo ago
  How did you conduct this rewrite? Did you hand the AI some specs, some tests, the existing code? I feel like AI has dramatically changed how complete rewrites can be considered, especially for long-lived, legacy projects.

BadBadJellyBean 3mo ago

It's not enough to do a rewrite. Someone has to maintain it. Such a huge codebase with literally zero experts is unmaintainable. There is no one who knows how the internals work. Sure you could keep vibe coding it but I wouldn't bet my data on that. A database needs to be rock solid.

72deluxe 3mo ago
This seems to be the issue with using LLMs for any code generation. Even with my own code bases that I've written entirely by hand over years, if I use AI to implement anything, I don't go through the mental model of architecting it, so I don't know how it works. I can only imagine this to be far, far worse for large code bases maintained by a team of people who are all using AI.
- win311fwg 3mo ago
  That depends on the language you are using. Some language communities had already rejected "architecture astronauts" before LLMs were born, so the training data was highly consistent, which has lead to LLMs being highly consistent in their output. You know how it works because the LLM spits out the same as what you would have written yourself. It's almost eerie that they can do that. Unfortunately that doesn't apply to all languages. LLMs are especially bad at producing code for the languages that were historically known as beginner-friendly as the training data was full of code by beginners doing what beginners do. All bets are off if you get stuck there. (Although maybe you could use an LLM to translate your code to a language that LLMs are good at!)
  - BadBadJellyBean 3mo ago
    One problem there is that even if the code is consistent, idiomatic Rust is not the same as idiomatic C. So either the translation produced Rust code in the "shape" of C code or the code is quite different from the C implementation. Add to that that you need to have people proficient in Rust and also Postgres as well as the very much unknown codebase as a whole you get a recipe for pain.
  - 2mo ago

bjt 3mo ago

OK but, Postgres is not one of those clunky "we have to replace this" systems.

win311fwg 3mo ago

At the same time that was ever the only reason for moving to a new programming language: abandoning all the bad ideas and craft that had accumulated in the previous language ecosystem. Needing to rewrite everything meant starting from a clean slate, allowing the new systems to be designed for the new age, making everything in that new language feel sleek and modern and thus appealing. Of course, as time progresses even the new language starts to accumulate bad ideas and cruft, historically necessitating yet another language to offer the clean slate again. If the code is going to be translated forward instead of abandoned and then rewritten, as is now completely viable via LLM, there is no reason to move to a new language at all.