Introduction

I have been coding for a long time now, and ever since my beginnings, I had a thought in mind that in order to be able to write code, you need to start with fundamental concepts and principles. If all goes well, and you don't give up, then you will be able to write code you understand at your own pace on your own terms. You see, our minds work in different ways and speeds, some people like to solve a problem in their heads then write some code to solve it, while others like to write code first (maybe a cool UI first) and then solve the problem in their heads as they go. Some others, like to take it easy and slow, some others like to take it fast and furious.

Nobody is wrong, in fact, all approaches are valid. All approaches have chances to lead to success.

The 2016 way

Back in 2016, when I was getting started, the path was clearer. You picked up a book about programming, maybe it was Java or C++, and you worked through it page by page. You struggled with pointers, you wrestled with memory allocation, you spent hours debugging segmentation faults. It was slow, sometimes painfully so, but each concept built on the previous one. By the time you finished, you understood not just how to write code, but why the code worked the way it did.

The internet existed, sure, but Stack Overflow was for getting unstuck, not for copy-pasting your way through entire projects. You couldn't just ask an AI to generate a complete authentication system or a database migration script. You had to understand what a foreign key was before you could use one. You had to know how HTTP worked before you could build an API. The guardrails forced you to learn.

There was something valuable in that friction. When you finally got your code working after hours of debugging, you understood every line. You knew where the memory was allocated, how the request traveled through your application, why your query was slow. That knowledge stuck because you earned it the hard way.

Vibe coding and its problems

Fast forward to today, and we've entered what we call the "vibe coding" era. Someone has an idea for an app, they fire up their AI assistant, and within hours they have something that looks like it works. They've never written a SQL query themselves, but their database is up and running. They don't understand async programming, but their API endpoints are all asynchronous. They've never debugged a race condition, but their concurrent operations seem fine.

Until they're not.

The problem with vibe coding isn't that it produces broken code on day one. The problem is that it produces code nobody understands on day one. Every feature added, every bug fixed, every change made builds on a foundation of borrowed understanding. You're not writing technical debt for later, you're shipping it with version one.

I've seen this pattern repeat itself in production systems. Someone builds a feature quickly using AI-generated code, it works in testing, it ships to production. Then six months later, when that feature needs to scale or integrate with a new system or handle an edge case nobody thought about, the original developer is gone or has no idea how it actually works. The code becomes unmaintainable not because it's poorly written, but because nobody ever understood it in the first place.

The speed feels productive in the moment. You're moving fast, shipping features, checking boxes. But you're not building software, you're accumulating complexity. And complexity without understanding is just chaos waiting to happen.

Why fundamentals matter more than ever

Here's the thing though, and this is where it gets interesting. The rise of AI coding tools doesn't make understanding fundamentals less important. It makes it exponentially more important.

Companies are starting to realize that having a team of developers who can prompt an AI to generate code is not the same as having a team that can build and maintain complex systems. When something breaks at 3 AM in production, you need someone who understands why it broke, not someone who knows how to ask ChatGPT for a fix.

The demand for senior engineers, the ones who actually understand how systems work, is about to skyrocket. Not the kind of senior who just has years on their resume, but the kind who can look at a distributed system and understand the trade-offs, who can debug a performance issue without reaching for an AI, who can make architectural decisions based on actual knowledge rather than what sounds good in a prompt response.

This creates a weird bifurcation in the industry. On one end, you have engineers who understand fundamentals, who can reason about code and systems, who can mentor and lead. On the other end, you have engineers who are really good at prompting AIs but struggle when the AI gives them broken code or when they need to understand why something works the way it does.

The market is going to reward the former and struggle with the latter.

The junior engineer trap

This puts junior engineers in an impossible position. The industry expects them to be productive immediately. Companies want engineers who can ship features from day one, who can contribute to the codebase without much ramp-up time. AI tools seem like the perfect solution, they let junior engineers produce code at senior-level speed.

But here's what nobody talks about. You can't learn to code by having AI write your code for you. You can learn to use AI, sure, but that's not the same as learning to think like a programmer. And the pressure to be productive, to ship features, to prove your worth, that pressure actively works against the learning process.

Capitalism pushes these engineers to deliver value, to make money for the company, to justify their salary. AI pushes companies to expect more output, faster iteration, constant productivity. Together, they create an environment where taking the time to actually understand what you're building feels like a luxury you can't afford.

The cruel irony is that the only way to actually become a good engineer is to have that time. You need space to struggle with concepts, to write bad code and figure out why it's bad, to debug problems until you understand them completely. You need permission to be slow before you can be sustainably fast.

But the current industry trend is eliminating that space. Junior engineers are expected to perform like seniors from day one, using AI as a crutch to bridge the gap. The problem is that crutch never comes off. Years pass, and they're still dependent on it, still unable to reason about code independently, still one bad AI response away from shipping broken code to production.

The path forward

I don't think AI in coding is going away. That horse has left the barn. But I do think vibe coding, the idea that you can build production systems without understanding what you're building, that's dying. It has to die, because it doesn't scale and it doesn't work.

What we're going to see, what we're already starting to see, is a return to fundamentals. Not because anyone thinks it's noble or pure, but because it's the only thing that actually works. You can't maintain what you don't understand. You can't debug what you never learned. You can't scale what you built by vibe alone.

For junior engineers coming up now, my advice is this. Take the time. Learn the fundamentals, even when it feels slow, even when AI could do it faster. Build things from scratch, not because it's practical but because it's educational. Understand your tools, don't just use them.

The industry is going to need engineers who can think, not just engineers who can prompt. The gap between those two groups is only going to widen, and the rewards for being in the first group are only going to increase.

AI isn't going anywhere. But neither are the fundamental realities of building software. Systems still need to be designed, maintained, and debugged by people who understand them. No amount of AI assistance changes that.

The vibe coding era gave us a glimpse of what's possible with AI assistance. But it also showed us its limits. Now we're entering the phase where we figure out how to use these tools properly, not as a replacement for understanding but as an amplifier for it.

And that, honestly, is a much more interesting place to be.