7 software skills that AI won't replace

while AI, it's already able to write millions of lines of code. Here are seven skills that will make you irreplaceable as a software engineer. Number one, scope engineering. Great software engineers, don't just blindly follow the specs. They change the requirements based on a deep understanding of the real operating environment and boundary conditions of the system. The most important, again, when building software, it's not building things in the right way, but building the right things. Yes, the F-22 and a very good example of engineers pushing back and redefining requirements is the airplane we see in the picture. It's the Lockheed SR-71 Blackbird. It's the fastest airplane ever built, and initially the Air Force came to the engineers and requested an airplane that is non-detectable. They just wanted a better U2, which was the car and model. They wanted something that radars cannot detect, and what they were asking for it's more fuselage, more titanium, more materials on top to make sure the rather doesn't detect the airplane. But when the engineers saw the requirements, they realized that the only way to make it undetectable is to make it faster and to make it fly at a higher altitude, and that's what great engineers do. And it's the same in the software world, if you want to keep being relevant as a developer, as a software engineer, in a world where AI can write code, you have to get better at giving input to product and changing requirements based on the technical environment. Onto point number two, lateral thinking, going from zero to one, because despite what Sam Altman wants you to believe, hallucinations are not directed creative thinking. Engineering and software development, it's not again about building faster horses. Like you seen in the picture, this is Henry Ford with 1903 model A. Henry Ford said, if I were to listen to my customers, I would have built faster horses. And this is what LLMs are pretty good at, they are very good at building, you know, faster horses.

faster whatever they've been trained on. And what people claim as creative abilities of the LLM are actually hallucinations and I'm not going to dive deep into the types, the different types of hallucinations, because it's not the scope of this video. But in both cases, hallucinations are not creativity, they are actually either the LLM changing factually correct data or ignoring, using instructions. But you cannot really brute force your way into designing an automobile from scratch, or the HTTP protocol. The ability to invent and the ability to come up with new things from scratch, it's strictly human. Exactly, there wash and just like you mentioned about the HTTP protocol, there are thousands of examples in the software world. One of them is graphQL, and with graphQL, we did not got a better API technology, a better rest API. But actually a whole new way to think about APIs, to think about how we consume data with totally new tooling and capabilities. And so what great engineers do is they do not just linearly increment a specific metric, like making a faster system or a faster train, but they actually think about the problem as a whole, and what's the best way to achieve certain objective. Number three, technical amortization. Managing technical depth and entropy. LLMs cannot really identify what is technical depth and what is not, you know, and this is because unless you are able to reason about the code base and really have a conceptual understanding and a mental model about what good code and bad code is, it's just like cancer, which for your immune system, the reason why cancer can actually duplicate and, you know, the body cannot get rid of it is because cancer looks a lot like healthy cells. So they basically bypass the immune system. And this is exactly what happens with technical depth. It bypasses the LLM understanding of what good code and bad code could be. Now, there are some people in the vibe coding camp that says, hey, starting from scratch, when the system accumulated certain technical depth, it's what you should do. Right, it's so easy to query the AI that you can just ask it again to generate things from scratch. But this is not doable when we're talking about a few million lines of code. And also it's why would you do that?

Maybe you have certain integrations that you don't want to to rewrite again, right? And you just want to fix a specific part of the system. Refactoring using heuristics and best practices, such as clean code and solid principles, it's much more efficient, especially when done in a pragmatic way, not just following best practices by the book, right? But adapting them to the real context of where you're applying.

Yeah, so as you see in this example, a good combination of old architecture and good architecture, the biggest problems we see with LLMs used on production code is that unless very directed, unless you very specify everything, it cannot really tell the difference between what's old code and new code. And yes, you could tell it, hey, can you refactor my code base using solid principles, and it will somehow interpolate that and give you a result, but it cannot really tell the difference between that code being better or not.

It really just follows whatever you give it in the context or in the prompt and then give you the best interpolation to those instructions. And being able to actually apply solid and clean code principles to huge code bases will become more and more valuable. Because what it's usually happening is you'll have a lot of developers shipping a lot of code with AI code that they haven't reviewed way too well, the code bases will grow very fast and there will be a huge need for someone that can use modern debugging tools and go very fast and fix problems in a lot of spaghetti code.

Uh, we already had that problem in software and that's one of the most demanded profiles, that's someone that's very senior that can go into an unfamiliar code base and immediately use mental models to fix problems. And by the way, folks, if you're a JavaScript developer looking to level up, the best way to start is to understand your tingle gaps. This is why Bugden and I created this free 10 minutes tingle assessment. Answer the questions without GPT, without Google, you'll get a complete analysis of your current strengths and weaknesses and tingle gas, including what you should learn next for you to level up. Check out the link in the comments.

deduct, which basically means starting from a general principle or premise to reach a specific solution. Right, this kind of top-down reasoning. LLMs seem to think logically, and this is why we get fooled by them. Uh, but most times they are following patterns that they learned in their training. Right, they're thinking it's an illusion. And companies who claim that LLMs are have near human performance are talking about very biased assessments and very specific assessments.

And sometimes, and and my guess is that most times those LLMs had access to the training data. Because these companies have huge valuations to maintain and they have a vested interest in those benchmarks getting better and better. But the reality is when faced with an example that is outside of their training data, performance there decreases dramatically, and you can even test this yourself. Exactly, Daos.

And so if you use inference as your main reasoning model, you never get from things like classical Newtonian mechanics to the relativity theory. You need heuristics and you need mental models to do that. Now, a lot of people are saying that you have things like chain of thought and agent mode, but what we've seen is that chain of thought, it's actually artificial. Is that they use a separate capability to generate something that looks like a chain of thought, but the internal processes of the model are not what GPT is telling you that it's doing.

They actually have two different systems, and the only reason they did that is to make it look more human and so you feel like the model it's actually reasoning. But in reality, those are two different systems, and it's just a way for them to make it look more human, but deductive reasoning per se, it's for now something limited exclusively to humans. Which is why, if you are a software engineer, the best thing you can do is to double down on mental models and heuristics that can help you outperform AI by using deductive reasoning.

And just to clarify, deductive reasoning means that, you know, from certain concepts and instructions, we can reach the specific conclusion, which is something that humans are very good at. Uh and what LLMs are actually doing very well, it's inductive reasoning. uh you were fed different thousands in the case of LLM, like thousands of specific observations and you come up with an approximation with the general principle. Actually, the LLM's are not even coming up with a with an with an abstract principle, they come up with a with an interpolated answer, right? That matches the the training data, right? Uh which is why this is kind of how they code, right? You You give them examples and then they can approximate the Python function, but they cannot really uh come up with a Python function from scratch. Humans, we don't need to do that. You know, if I show you a bunch of sums, you will already know what the sum is and I give you different numbers and you can sum them without you having done thousands of sums. On to point number five, second order consequences. Meaning thinking beyond immediate cause and effect. Second order thinking means being able to predict second and third order consequences. And for that, you actually need petabytes of context if we follow the traditional LLM architecture the way they've been built up to today. But this is something that humans can do very well. Uh if we take a bit of time and I ask you, hey, what is the consequence of the consequence of a certain decision are you going to make in your life? Most people will be able to to deduct and they can go many levels deep and as Bogdan mentioned, people talk about inference time or chain time compute, but they both of these techniques showed very limited results. Uh reinforcement learning approaches are just tweaks to the next token prediction process. And again, as long as LLM's are based on the current architecture, which is basically predicting the next token, uh this architecture will fail to deliver. Humans predict the future, not only based on what happened in the past or what we've been trained on, but we have cognition, right? We we see what happened in the past, but then we think about it, we try to identify, hey, why did this happen? Why did it happen this way? And this is something that developers do on a daily basis, like this is part of our job. We try to understand uh what what was the cause and effect behind of what we did and how can we apply it to create a better future. And again, this kind of reasoning will be probably physically impossible because of hardware limitations, unless we start using heuristics, which are basically the

still thinking like us humans do. Exactly, the garage and a very good example of this, it's when we want to change the UI framework of a front-end application. So imagine you want to move from React to next JS. Somebody will propose that. And so a vague engineer will think not only about the immediate benefit, which is how we get server side rendering and so faster faster websites and better SEO. But they'll also think, wait, what will be the development complexity?

Is it easy to hire people that know next JS? What about testing? And then what if effect will that have on the product bottom line? So are we going to get slower are developers going to handle uh more bugs? Are those bugs going to be more complex? So you have all kinds of levels of abstractions that humans can navigate very fast and they can extrapolate very quickly. And yes, you could maybe theoretically have an LLM that has all the context in the world uh and can do that, but so far that's physically from from a hardware and even software point of view, it's very far away from reality.

Onto skill number six, system thinking, seeing the forest from the trees. And the thing here is that how complex systems work cannot be encoded in just one token. Which is what LLMs try to do. Again, regardless of the techniques you're using, it's all about predicting the higher order token, next token. So, in reality, if you think about it, LLMs actually work as a database, right? In this case of vectors.

Not as a thinking system. Thinking it's stored. In the case of LLMs, thinking it's stored, it's not actively generated during usage. They're just looking at the patterns they learned from the training data and based on that, they're trying to predict the future. Which by definition is going to be flawed. Humans and human software engineers, on the other hand, can abstract a system into its core components and think about it as a whole.

And this is what gives them real predictability because they can handle the different pieces of the system on a say time and they can understand how will this pieces react when I'm changing a certain part. And we do this all the time when, for example, we change an API connection, right? You think How will this affect the database? How will this affect the performance of the application? Right, because you have a holistic understanding of the system, which LLMs, in the way they are built right now, do not have, won't have, and we probably will need a much better, you know, we probably going to need to start with this AI problem from scratch for us to find something that will mimic human ability to design systems.

Exactly. And we see a lot of those models looking like they have certain system understanding and system intelligence. And so if you go and query any of those LLMs or GPT4 or DeepSeek or whatever Claude, reasoning models, they would go on and if you ask them for a vision of a system design problem, they'll probably be able to solve it. But the biggest flaw there is that they are extremely limited in terms of you just give them a lot of context and then they will give you the next step.

And that's where this brittle crumbling process happens where you give the next step and then the next step and then the next step. That is not how intelligence works in humans. You don't go to software architect and you ask them a question, they answer and then you give it back to them and then they answer the next question. They will not be very competent. So humans are really good at relating certain parts and see how they work as a system as a whole.

And they don't need to memorize everything. They just can't think in terms of relationships and interactions. And the way LLMs are built right now is that it looks like they also do that, but in reality they're just taking in a bunch of text and passing it through their billion data of parameters, they memorize and giving you back a pseudo coherent answer. That's not intelligence. It's just it's a copy of what intelligence looks like.

So as a software engineer, you want to be able to work across the stack. If you are right now in the front end, make sure you slowly start moving towards the full stack. It is extremely hard for AI to work with ambiguity or to work on systems that are very big or very distributed. It's almost impossible for you to keep some coherence. Because again, it cannot get it think across all those different possibilities.

And if you can do that, yeah, you can leverage AI and and maybe help it to write you faster code. But you are designing the system, you are the driver of the changes. Number seven, estimation and priorities. dealing with competing goals and ambiguity. And I think because of all the marketing going on and all the noise that's happening now around LLMs and this AIC systems, we forget just how limited computers are and just how hard is to predict the future when we talk about complex systems. Same day weather predictions are accurate only about 80% of the time. And they are using one of the most advanced computing models to do this estimation. And we're talking about same day, right? If you just try to to predict the weather 10 days from now, it will be probably impossible. Real life software engineers decide between competing goals with incomplete information and ambiguous requirements. You have to balance time to market with code quality. And I think the mistake that a lot of people, especially outside of software do, it's to believe that software engineering is this kind of very repetitive process, where we just get a requirement and we code it. When in reality, it's more like this image that you see where we have all these airplanes trying to to fit in into the picture and all this moving is like a moving chessboard, like that we need to manage and make sure that in the end, whatever happens, you know, the the the pieces stay on the on the board and we actually get the game to an end, which in the end, it's always a delivery, right? Because software, as we said in a previous video, it's an ever-changing solution to ever-changing user needs built on ever-changing technology. The context, the context window when building software, it's almost infinite and humans can deal with infinite because we can approximate, right? And we can use heuristics again to to deal with infinite boundary constraints, which is something that LLMs cannot, or any kind of machine intelligence that's been designed up to date. Exactly. There also you have all these moving pieces in terms of what the code base looks like, what the infrastructure looks like, what the delivery, kind of the pipeline looks like, what is the current backlog. And then there's the the other layer of what other people around me working on, what are the other teams doing, what are the complementary products that we integrate all the time. And you have all these different platforms. You you can ship to the browser, but then you have the back end, you have database,

and so humans are really good at dealing with this ambiguous, incomplete situations and be able to kind of parallelize these competing goals. And I think that's something where, yes, if you would fed all the context in the world to the letter, uh, to the AI, it might be able to come up with a decent solution. But again, we live in the real world where everything changes very fast. You need to improvise and I think a lot of people are making this one-to-one comparison between the AI writing some spitting out some code and then what software engineer does and what every experienced software engineer

knows is that the code was never the bottleneck, it's rather about understanding a problem, defining the problem, prioritizing, estimating, and then finally you get to write some code. We will see you in the next one.