I Learned the LAST Software Engineering Skill

Added: 2026-05-22

[00:00:00]I spent seven years sweating to learn hard programming skills like system design, DSA, clean code, but honestly, they're becoming less and less important for what I'm actually doing at my job.

[00:00:13]>> Resistance is useless.

[00:00:17]>> SO, is software engineering solved? We started interviewing engineers at my company a couple months ago and I noticed that the questions we were asking were all targeting one specific skill, but no one had it.

[00:00:30]>> What are you people idiots?

[00:00:31]>> Even though the job was supposed to get easier, it became harder to find people who actually have what it takes. So what is that skill and how do you actually build it? But more importantly, I'll tell you the quieter reason most engineers won't build it even though they know they should, which will lead them to becoming useless. I was working on a project that I've built from scratch. The system was clean and stable, which allowed features to be shipped pretty fast. We hired a new middle engineer and he was excited to work with us and seemed like he's going to be very productive. He was using cloud code from day one and we were glad these tools are powerful and we wanted him to lean in. His first pull request landed on day two. The feature worked but I rejected it completely. It was all backwards. The validation was in the wrong layer. Business logic wasn't living where it's supposed to be. He didn't see it because he didn't write it. Claude didn't see it because it has no theory. Neither of them had been there for the bug that got us to build a pattern that was working so well. That's when I realized what I was actually dealing with. I knew he wasn't a bad engineer because I interviewed him. He was a fast engineer, confidently using a powerful tool exactly the way we told him to, but quietly eroding years of architecture faster than I could articulate why. In a couple of such PRs, he went from promising to annoying. What turned it around was him sitting down.

[00:02:10]He stopped opening pull requests and started reading the codebase like a foreign language he meant to become fluent in. He built on his own a theory of the product. Then he ran every AI suggestion through it before he ever opened APR. So the code base stopped getting sloppy and he actually became a valuable member of the team. AI generates code that looks like it belongs but it doesn't. You can't tell the difference without a theory of what your code base is actually trying to be.

[00:02:44]Most companies are now transitioning to writing code with AI and timeline usually looks like this. We start with full mental model of a system that works. AI right here is great. It generates code fast and you still understand all of it. But every day AI suggests something that violates a decision you made for a reason. So you catch it and steer it back. It genuinely makes you more productive. But the longer you do this, the more tempting it is to just let it run. You review code faster. You pay less attention. And the very clear theory you once had starts to fog. So bad decisions slip in. The codebase pollutes, things break, the product, your team, your productivity, and your value all go down at once. So, let's check if you're not in danger.

[00:03:38]Answer this question honestly. Of the code you shipped this week, what percentage did you genuinely understand versus accept because it looked right.

[00:03:48]Now, based on the percentage, here are three zones you are in. 0 to 60, the red zone. This should be not acceptable for you if your goal is to produce quality software to the company and grow as an engineer. 60 to 90 yellow zone where most of the engineers I know are. And it's the most dangerous because you feel like it's okay and 90 to 100 is green.

[00:04:15]If you are in red yellow zones, you're acting like a middle engineer from my story. If you want to actually build theory at a senior level and become impossible to replace, I've built a lab exactly for that. You will read the best programming books while completing challenges like code reviews, system designs, refactors, and get instant feedback with indepth explanations so the knowledge sticks. You can find the link in the description. Getting back to your zone, this is most visible in debugging. People say AI is good at finding bugs and it is. My usual workflow now is to get a bug report, launch cloud code with a debug comment in parallel, launch my mental models to scout for the location. Talking numbers, AI finds 95% of bug locations very fast, but the fix it proposes is acceptable only 20% of the time. Usually, it's a local patch for the symptom, not the actual root. Bugs in mature code bases aren't local syntax errors. They are violated assumptions from the design process. You need theory to decode the AI's finding and fix the actual cause.

[00:05:30]AI can find a location, but without theory, you're making a blind decision about how to fix it. AI is powerful, but it's not a magic wand. Now, here is where the current narrative gets it backwards. The current narrative is that AI replace theory building with clawed MD files. In reality, AI's performance is bounded by the theory you bring to it. A good prompt is compressed theory which is very specific, very accurate to the current task and module. Dumping API docs into cloud code prompt will not make it to know your project. But one sentence explanation for main constraints and invariance of the target system will steer AI into the right direction. And that's mostly what I do nowadays. Senior engineers outperform juniors with AI not because they use magic words, but they have stronger mental models. So they can verify, redirect, decline, and steer with better control and precision and do it with less tokens. There's another piece.

[00:06:37]Nobody talks about when you're in a meeting with stakeholders and someone asks, "Can we do X or what if we do Y?"

[00:06:46]Your ability to answer immediately is what makes you visibly valuable to a business. If the only thing that knows your codebase is AI, nobody actually knows your codebase. You either built the theory or you didn't. And then there's the mistake I'd fire someone for. Juniors, middles, and even seniors using AI heavily are making it almost every day. They are transferring the responsibility for their messy code onto the reviewer. So the tempting workflow is get the task, spin up cloud code, code it, vibe code the tests, glance at the result, and submit. If you do this, you're not adding value. Your teammates are. They're building the theory while you skim. So what are you actually being paid for? The complexity isn't in generating code anymore. It's having enough knowledge to verify it's right.

[00:07:44]Mitchell Hashimoto, a maintainer of Ghosty Terminal, who is by the way very pro AI after getting to review a bad AIPR every week said, "As a reviewer, I do not care what the AI said. AI output is noise. I want to see contributors thinking. What I want to see in a PR isn't two pages of AI generated docs nobody reads. It's the theory a real engineer built while working on it. And that same trap I was watching the new middle engineer fell into. I caught myself doing it like 6 months earlier. I vip coded an important feature. The code looked fine. I was kind of lazy. So I submitted it. And then my team lead called me to discuss it and had good arguments why my design was wrong. But I couldn't defend it because I didn't even know why I built that way. I felt embarrassed and I should have. I wasted my team's time reviewing something that wasn't ready. That was my responsibility, not theirs. So my golden rule now, I don't commit anything I couldn't explain to someone else. But all of this is secondary. Debugging, code review, meetings, that's not the main thing. In AI era, your job is making decisions that serve the product long term. And decision-m is entirely a function of theory. Speed of producing badly designed software is worth nothing. Writing code is the easiest part of software engineering and it's getting easier by the day. The hard parts are what you do with that code.

[00:09:25]Operating it, understanding it, extending it, and governing it over its entire life cycle. Building theory fast is the new meta skill. Right now, while you're watching this video, learning about an important skill that will greatly benefit you, I bet you have a tab open with the latest AI announcement that stresses you out.

[00:09:47]>> Building theory. You need to research the latest AI engineering workflow with agents for all the roles in your company. You need to learn how to orchestrate 10 agents in parallel or you stay behind.

[00:10:01]>> Maybe investing so much effort into something that is going to become obsolete with the next model release is stupid. But every time I need to do something hard to achieve a great result, someone is waving a shiny thing in front of me that is so easy to get and I fall for it. Isn't building an evergreen skill better than chasing one shiny tool after another? It is. He's making money on my emotions while my foundation rots. So this time I'm doing what's better for my future. Now, every time new model or tool drops, I take a look at it, evaluate how useful it will be, and go back to my actual work.

[00:10:46]Because the skill I'm building isn't going anywhere. It's mine. If you want to finally become a senior engineer, you don't have much time to waste. So, I would strongly recommend watching this video next. Goodbye.