I’ll age myself, but I vividly remember the fear and paranoia that went into Y2K. For those of you that don’t remember, or gasp weren’t alive at that time, software engineers had used a 2 digit field to store the year back in the early onset of computer programming. This was fine in the 60s and 70s when we were storing digits like 73 or 75, but the code at the time always assumed 19 was the prefix to that. Making them the years 1973 or 1975. Software is supposed to be relatively obsolete in a short amount of time, especially given the exponential growth that technology has seen. So where in lies the problem? Well, if we’re storing two digit years, that’s great until you hit the year 2000, which would be stored as 00, and computer programs were coded to read that as 1900.
We’re not just talking about insignifcant things like the program that calculates your weekly fantasy football scores, but we’re talking about titanic industries such as banking, healthcare, aviation, etc… where things are tuned to be so precise that any deviation would be catastrophic. So going from 29:59:59 1999-12-31 to 00:00:00 1900-01-01 was going to, in the words of the time, fuck some shit up. So what did these companies need to do? Well, they needed to update their software, and fast. Great, hire some programmers and get cracking, this shouldn’t be a big deal.
But it was a big deal. Why? Because these are slow moving industries when it comes to technology and a vast swath of the software powering them were written in Cobol and Fortran. Maybe some others, but these two were the biggest ones at the time. What’s the problem with those languages? They were largely considered dead at the time and nobody was learning them (rightfully so). So these companies were having to hire older engineers, people out of retirement even, and pay them vast sums of money to break the rust off and get back to coding. My friend’s mom was a Cobol programmer and they made a mint during that time period.
In the end, the day was saved to the point where there’s conspiracy theories about how overblown the hype was and how we, as a people, overreacted to a scenario that clearly never was going to happen. I believe that disaster was saved by these people who rocked back up to their computers, dusted off their arcane wizardry, and went to work. We’ll never know how badly things could have turned out, but we do know that these engineers were vital to the success of Y2K.
So what does that have to do with AI, junior engineers, and our Cobol moment? Glad you asked.
I’ve read countless article after article on how companies are really leaning into AI as a replacement tool, especially for entry level engineers, and just how competitive the market has become for people who are just graduating or trying to make a career switch. I’m definitely no stranger to using AI both in my personal and professional life, but unless there’s something that I’m missing and/or not doing right, it’s still not an amazing technology. It’s been heavily based on probability and the data that it has been trained with and that leads to some hilariously terrible code.
What’s the problem? AI is starting to write the code, which means AI can start fixing the code, we can just levaerage prompt engineers or senior/staff engineers to work with AI to manage this. Or even better, we can let our product team manage AI because they know what the product is supposed to be and can write all of the documentation needed for the model to do its thing. This probably works really well in greenfield projects where it’s utilized from the onset of the project. Until it doesn’t. Then what do you do? Well, you call up your senior engineers to fix the issue because they understand programming and logic and they’ll be able to work it out.
The knowledge issue
The first issue that comes up is that, sure, senior engineers are going to have a much better knowledge base to pull from over their career. They’ve worked through a myriad of problems across a wealth of industries and applications, and may have even tackled this specific issue before. But how did they gain that critical knowledge in the first place? Well, they were hired as a junior engineer and went through the phases of mentorship, learning, failure, attending courses and conferences, etc… All while climbing the ladder from junior, to senior/staff/principal, or whatever title they currently have. If we no longer hire, mentor, and nurture junior engineers, we no longer grow senior level engineers. I’ve personally seen this atrophy in companies that refuse to hire anyone below the senior level. It’s great when you need an influx of knowledge, especially at the early onset of a startup, but you can’t use that strategy forever. Unless you’re just willing to continue to shell out higher and higher salaries as time goes on. Great for me on the back half of my career, but awful for someone just starting out.
The understanding issue
What’s the big deal? Why can’t someone just get really proficient in AI and work their way into the field that way. They absolutely can do this, it’s called vibe coding and it’s already in practice today. But have you spoken to anyone who just vibe codes or exclusively leverages AI to write code for them? They are great at explaining what the product and application can do, but don’t have a great understanding at what the code actually does. So when vibe coding breaks down, how do they fix the issue at hand? It usually leads to having to call in someone who is able to reason out what the code is actually doing and find the bug. Remember AI wrote the initial code thinking it was bug free, you might even have gone through some rounds of bug fixes with AI, but if you can’t point out the flaw, it can’t always recognize what needs to be done.
The aging issue
Here’s where we get into our Cobol moment. I’m an old dude, I’ve been fortunate enough to have two wonderful careers in technology starting way back in the dial up ages working for an internet service provider. I’ve been professionally in tech for over 25 years now gasp and am right around the corner from 30. I’ve learned a lot over those almost 30 years which has led me to be pretty successful in my career, but I’m also starting to think about retirement. I’m not there yet, but I’m hoping to retire from working for someone in about 12-ish years or so. I’ll never stop working completely, I just want to work on my own things at my own speed. And I’m not alone, we’re the first generation who remembers both pre and post consumer computing technology. I’m not naive enough to think that my generation retiring is going to cripple things in any way, but if we’re only being replaced underneath by AI, then I wouldn’t be shocked if there is a moment in time where this tech we worked on in our career is not maintainable due to a lack of training data for these models. Then what happens? Well, who knows, maybe I’m completely wrong and AI solves those problems and I can just enjoy my retirement writing video games. Alternatively, maybe companies end up desperately needing someone who has previously worked with tech like jQuery, Angular 1, Groovy on Grails, etc… all tech that’s considered dead but still very much alive in the online world today.
Why can’t businesses just update their software? Businesses have one goal in mind… make money. Once a technology has built up a business, it’s extremely difficult to try and convince the business that their core product needs partially/completely rewritten, there’s just too much inherent risk to the business model. That’s why we found ourselves in this situation in the first place with Y2K. Banking, aviation, healthcare, education, etc… none of these industries have changed. Some of them may very well be running those same applications that needed patched in the first place. Some of these companies are still using ancient terminal based technology that they’ve written a nicer UI over and a translation layer because it was less painful that removing the underlying tech powering their business. And it’s not going to change anytime soon.
I know it’s easy to write this off as an old man shaking his fist at new fangled technology, but the technology isn’t the problem here, it’s the business practices. And that’s something AI will never be able to fix.