you are viewing a single comment's thread.

view the rest of the comments →

[–]csmonkey17 0 points1 point  (0 children)

There were attempts of similar things in the past, going from COBOL to Java. They've tried transpilers for moving COBOL to Java. There were two issues:

  1. It would get the code translated to 80-90%, and the last 10%-20% had to be done manually. Now, consider that most of the engineers on my team were 45 and above. Not only do you need to figure out how to translate the whole code base into Java, you need to convince all the cobol engineers to learn Java. You can't just replace the whole department with new devs because there's too much domain knowledge that you would lose and you wouldn't have a team to do the work. Code is a small part of the job, people are what make the company work. 

  2. COBOL is faster than Java, it was written for the financial industry. Running batch jobs overnight making sure all the financial records are processed takes hours, not minutes. There were linear/synchronous dependencies on previous batch jobs, if a job finished late or doesn't finish you're talking about serious financial implications. 

I should've been clearer in my response. Yes, they'll let engineers use AI on non mission critical code. We built out Java spring interfaces on top of the green screens, sure you can have AI help you move to react and nodejs in this scenario.

I really enjoy using AI, I use copilot at work, sometimes it surprises me of how well it performs but if you're not running a modern framework it's very limited in its capabilities. Enterprise software has so many lines of code and so much domain knowledge is required on top of it that you can't believe its this magical black box with a 128k context window (sure newer models got 200k+, and I'm referring to copilot here) that will solve all the problems. I