Table of Contents
- AI Hype is Wearing Off Slowly But Surely
- So Staying Old School Isn't That Bad After All?
- What's so Cool in Old-School Anyway?
- When Does It Make Sense to Go Old-School?
- Summary and What's Next
AI Hype is Wearing Off Slowly But Surely
AI is here to stay, it's not going anywhere despite videos and articles claiming its bubble will pop. While there's some truth to these concerns, most such titles are clickbait. Sure, people are realizing that AI won't solve all their problems or make them rich without effort, but let's not be too dramatic - AI is going to stay like it is now for the most part. Though, it's encouraging to see both software engineers and non-technical people recognize that "vibe coding" isn't something to trust your business and career on - it's a slippery slope.
Check out my article about vibe coding:
But hey, let's be honest, if you're experienced enough in this field, you've seen this pattern before - it's the natural cycle of any hyped technology. Everything that gets hot eventually cools down, just like this race car brake rotor does after the race, and AI is no exception.
Here's a visual representation of how hype works for any new hot thing in tech.
We'll talk more about the AI bubble later in this series.
So Staying Old School Isn't That Bad After All?
0 or 1?
Our field is completely built upon the idea of 0 and 1, but pretty much anything built on top of that concept involves one magic phrase - "it depends." The higher the abstraction, the more "it depends" answers we encounter when discussing any topic, and AI is no exception. In fact, AI is the topic with the highest share of "it depends" right now.
However, you're not wasting your time reading my article only to end up with me saying "it depends," right? So let's dive into this topic and find out what exactly it depends on.
You Don't Have to Pick Sides, Don't Label Yourself
For some strange reason, people are obsessed with the idea that they should pick sides in literally everything, which is really strange. It's like they want to label themselves for no reason. I think that's because they want to build a personality they think is cool, one that might be based on someone they know or an imaginary person they're obsessed with becoming. And it's not only in tech. Let me give you a few examples:
- Rock music vs. Pop music - you might be a huge rock fan (just like I am) but you can't convince me that you haven't lip-synced and chair danced to a pop song while being alone, nobody watching (I have). It really depends on a particular song, not the genre.
- Ford vs. Chevy - while I'm a massive Ford fan (and owner), I appreciate quite a few Chevy cars that are out there. They're fun, cool, and do the job. It really depends on a particular model, not the brand.
- Pizza vs. Burger - now that's a tough one for me, I still don't know. Again, it depends on about 150 different factors.
Now a few examples from tech:
- Backend vs. Frontend - why not both, depending on preferences, what you need currently, what you want to build and tons of other factors?
- Microservices vs. Monolith - how about you tell me what you're building first and then we discuss. Though some people consider a monolith as an anti-pattern. Guess what? Microservices can be an anti-pattern in equally many cases (if not more).
- Old school coding vs. modern coding - this one's quite vague and general, so let's discuss it in a more detailed way.
Important: as the title suggests, this article is going to focus only on old-school. In the next article we'll talk about the modern approach. To make the comparison fair, the next article will also have a similar structure.
What's so Cool in Old-School Anyway?
Picking the Right Tool for the Right Job
The main appeal that old-school has is that when a person claims they're old-school, it's a social convention that this person is inherently cool, no matter the context, because they seem like someone who's been around for quite some time and is knowledgeable enough not to care about new trends and technologies... and that's a mindset issue, well at least in software engineering.
I think it goes without saying that as a software engineer, you should always be trying to improve your skills and effectively the products you make. You can't just pick any technology, framework, library, or language and create a product that will be efficient, maintainable, and performant at the same time. One of the best skills you can have as a software engineer is picking the right tool for the right job, and make no mistake, this skill is one of the hardest skills you can obtain, even though it sounds pretty straightforward, it's not.
Example: Can You Write a Website on C Programming Language?
Absolutely. You can... technically.
However
While it's entirely possible to develop a web server or even a complete website backend using the C programming language, it's generally not the most practical approach for modern web development. C provides very low-level control over networking, memory management, and I/O operations, which means a developer can, in theory, implement every layer of the HTTP stack manually, from parsing requests and generating responses to handling sockets and concurrency. However, this level of control comes at a significant cost in terms of development speed, security, and maintainability.
Modern frameworks and languages such as Go, Rust, Node.js, Python (Flask, Django), or .NET abstract away most of the boilerplate network handling and offer robust standard libraries, concurrency models, and built-in HTTP servers. In contrast, writing a web server in C typically involves directly managing sockets via the Berkeley sockets API, implementing the HTTP protocol manually (including headers, content length, and encoding), and ensuring thread safety and memory correctness - tasks that are both error-prone and time-consuming.
C-based web servers can be extremely efficient in performance-critical, embedded, or specialized environments (for instance, using libraries like Mongoose, libmicrohttpd, or CivetWeb), but for general-purpose website development, higher-level languages and frameworks deliver far better productivity and maintainability without sacrificing reliability. And to be honest, you don't lose that much in terms of speed and performance as well.
Now, Let's Apply That Context to AI
As much as we love our job—software engineering—it can be extremely stressful. It's incredibly competitive and doesn't forgive standing still.
Software engineers are pretty much like professional athletes: we need to work to survive and, at the same time, constantly improve our general skills outside work to make sure we're in a good position in a global perspective.
Well, there are a few key differences though: if we tear our ACLs or injure our Achilles, we can still work. However professional athletes, unlike us, don't have to learn completely new things over and over again, they mostly drill what they already know and deepen their skill and understanding in that regard. Us, the software engineers? We have to do both. We need to constantly learn new things, and that includes AI.
As we already mentioned, our industry is extremely competitive, not only at the individual engineer level, but also at the company level too (even more so). That's why companies are so desperate to find as good engineers as possible. Have you checked out the recent news about big tech giants literally poaching AI engineers and researchers from each other? Crazy right? I guarantee you that none of those engineers have ever complained that AI is taking their jobs and it's evil. Instead they used the situation for their benefit and it worked out pretty well for them, hasn't it?
Don't Be Too Cool for School
"So you're tellin' me that tin Lizzie of yours is better than my Quarter Horse? Ha! You've lost your senses, boy." 🤠
I'm 100% (a hundred percent) sure this conversation happened much more than once way back in the beginning of the 1900s when Henry Ford produced a brand new Model T and popularized it. Look at the world now. Now horses are transported using a special trailer towed by Ford F-150s. Fair play, horses!👏
The point I want to make is, don't be that person who's always trying to gain validation from society by parroting popular ideas, that's easy and cheap. Try to think about stuff yourself. Out-of-the-box thinking isn't only thinking of a business or AI startup idea that nobody even cares about, or saying something controversial that you don't even believe.
Out-of-the-box thinking can be subtle, not even comprehensible for other people. As subtle as decluttering your mind from other people's perspectives and thinking about something by yourself. Tech and software engineering isn't about how things work, or how people think things work, it's all about how you make things work your way to create something special or solve a specific issue. While everyone else is just complaining about tech going backwards and AI ruining everything, the best thing you can do is sit down and brainstorm how you can use the whole AI situation to make your career even better.
Do Me a Favor and Once You've Read This Article Do the Following:
Take a notebook and a pen and write down the following questions:
- What are the most repetitive tasks that I can delegate to AI?
- How can I use AI tools to make my personal repositories cleaner and more efficient?
- What are the ways to communicate with AI to make sure my development skills aren't getting rusty?
- What skills am I lacking and how can I sharpen them using AI tools?
- How to decide when I use an AI-assisting or AI-assisted approach?
- Which AI tools should I use?
- Should I limit myself on how much I use AI during coding?
- In what ways can I validate that I actually understand the code AI generates for me?
You don't have to answer all these questions right away, just write them down and think about them. Let off the LinkedIn influencers and YouTube clickbaiters for some time, because more often than not, they either don't fully understand how the industry really works (which is normal because some of them aren't even technical people) or they're just throwing hot takes or popular takes into the public so they can get hundreds of likes/comments. Make your own path with your own mind.
"AI Makes You Dumber, AI Makes Your IQ Lower, AI This... AI That..."
I see tons of posts, articles, and videos with a title like this. And I'm not a big fan of it. Not that I'm an AI power-user and I'm taking it personally, but because it's nothing but a "wanna be smart and cool" statement that's totally out of context and something that's easy to get many people nodding at you and liking your comment/post.
In reality, it's not AI that'll make you dumber, it's you and how you use AI. It's like saying that automatic gearbox cars cause more accidents because people have more ability and freedom to use phones while driving. It's not the cars, it's the irresponsible and bad drivers who don't have the first idea how to drive a car safely.
Any tool out there is there standing still waiting for your input and does stuff based on it. So if you think that AI is making you dumber and that's why being old school is the way to go, please pause for a moment and think and reflect about what's the actual reason why that happens.
- Maybe you're doing something wrong?
- Maybe you're delegating way too much to AI?
- Maybe you should stop vibe coding?
- Maybe before you ask ChatGPT to generate an email for you, you should try it?
There are so many maybes that you should think about before discouraging others from using a tool that can absolutely be used productively.
When Does It Make Sense to Go Old-School?
Even though staying up-to-date is what every developer should focus on, in some specific scenarios, it's better to stay old-school.
When I think about this topic, what comes to my mind is the tweet I came across on Reddit:
A friend learned COBOL and received a codebase
where the last change was done in the 90s...
by. his. mum.
There's an extremely good reason why that code was so old and why that person had to maintain code that was maintained by his mum. You might not even have heard of COBOL, especially if you're a gen-z software engineer. It's a programming language that is still used, even though it's over 60 years old. Not only that, plenty of unbelievably critical systems run on COBOL, like: banking systems, insurance systems, government, transportation, you name it.
When you have a working system for several decades, THE VERY LAST THING you ever want is going modern. Just stop for a moment and imagine rewriting these systems written in COBOL in modern alternatives. It's a terrible idea, right? I've actually had a discussion about this topic with a few people and some of them were even advocating that point because "it's a good investment in the long term." But in reality, it's not. It's a good investment when the update isn't that hugely significant AND you gain something out of it. Don't be just a purist who thinks only about modern technologies and the cleanest code possible—think about what you're going to bring to the table for the client. And let me tell you that if anyone touches that COBOL code written and developed for decades by the people who are retired now (at least most of them), you're not going bring nothing but bugs and tons of issues to the table. Doesn't matter how good you are, or how good your team is, you're going to cause a catastrophe.
Imagine messing up the whole financial system in the USA. That will not only affect the country, but the whole rest of the world, because every other country is at least indirectly dependent on the USA's economy. And even if everything goes perfectly and there are no issues, there's still no point in doing this modernization work, because it's going to cost so much, there's literally no value whatsoever, quite the contrary.
Whether you can use AI to maintain your super-legacy code, that's questionable, but if you're a COBOL developer and you're planning on using AI for maintaining your systems, please do a thorough review before you update the code.
This is a perfect example when it's better to stay old-school and don't try to do crazy stuff with the system.
Another example can be Real-Time and Embedded Systems.
Embedded systems are specialized computers built into devices rather than general-purpose machines. Examples include microcontrollers (Arduino, STM32, ESP32), device drivers (GPUs, sensors, storage), aerospace flight control software, and medical devices (pacemakers, insulin pumps, MRI machines). These systems often have hard real-time requirements, meaning they must respond to events within strict timing constraints, missing a timing window can cause system failure or even be life-threatening.
Why Assembly / Embedded C Works:
Maximum control: Direct access to hardware registers, precise memory management, and deterministic instruction execution.
Predictable timing: No garbage collection or dynamic allocation, ensuring interrupts and timers fire exactly on schedule.
Minimal overhead: Small, efficient machine code suitable for devices with limited RAM, flash, or slow CPUs.
Hardware-specific features: Bit-level operations, DMA control, and inline assembly allow precise control impossible in high-level languages.
This is another case where caution is crucial, especially when dealing with older systems dedicated to critical functions. For example:
Flight control software: Airbus, Boeing... these systems cannot risk unexpected pauses.
Medical devices: Pacemakers, infusion pumps—any failure can be life-threatening.
With systems like these, you simply don’t take risks, because the consequences can be far more catastrophic than financial loss.
There's Still No Excuse
We've identified a few examples when it's better to stick to your current tech and not upgrade it, no matter how appealing it might sound. Remember, we software engineers are here to solve problems, not to create them. Some legacy systems are legacy for a good reason—they just work and they're time-tested, quite a lot. In these cases, find something else to test your adaptability skills and learn new languages and frameworks.
Summary and What's Next
Being old school is useful when it comes to critical scenarios like this and it's mainly about technology and infrastructure, but your mindset should never be only old-school, you need to also look forward and try to stay up-to-date. There's still no excuse for being old-school when it comes to your mindset. Stay hungry, stay competitive, stay awesome!
The next chapter will be a complete opposite of this one, we'll talk about the pros and cons of being too obsessed with being up-to-date.
Top comments (0)