Amichai Mantinband · 15:34 · https://www.youtube.com/watch?v=SCXhmMbbh6g
0:00 What's up guys? My name is Amichai, and in this video, we're going to answer the really hard question, which is should developers learn .NET in 2026? Shocker, AI is out, things are changing, and there's a pretty harsh reality that we need to face as developers. So, in this video, that's exactly what we'll do. If you have no idea who I am, then a bit about me. My name is Amichai. I've been a .NET developer for several years now.
0:25 I have various courses on clean architecture, domain driven design, different uh design patterns, and I've also have like deep knowledge in .NET, the BCL, the nitty-gritty, the JIT, blah blah blah, all the low-level side of .NET as well. And I feel like I have a unique perspective and more objective perspective than I would have had a while back, since I've been working in the past 2 years extensively with Swift, with Flutter, with Go, with TypeScript,
0:54 uh with several technologies that I haven't been familiar with beforehand, plus coding extensively for several several hours every single day using um the latest and greatest models. So, that's a bit about me, where I'm coming from filming this video. But now, let's answer the hard question. And it really comes down to what agents are good at and what agents aren't good at. When I'm saying agents, I'm talking about models, but the way we practically work with um models today.
1:19 So, let's say things that models are extremely good at, and the second is things that models aren't yet extremely good at. And in the second group, this also divides. So, you have the things that they will be good at pretty soon, and then you've got things that we might have some time. So, given this is the state, then these are the categories that we have. And now that we have this, then let's start breaking it down, and let's think how this applies to us as .NET engineers.
1:49 So, the first thing that they are extremely good at is writing code in literally any language. So, no matter what language you're working with, even if you just invented your own language and now you gave the agent a brief, then it'll write perfectly good, high-quality code. Some of you may think that this isn't the case yet and agents aren't that good yet. I'm not sure what models you're using, but for me, in the past, I don't know, several months using Opus 4.6 and 4.7 has completely shifted and now the code that I'm getting, the output on extremely complex code bases is is actually really good and is production ready.
2:27 I think in this day and age it's naive to say that agents won't outperform us in quality in terms of the output. They are also really good given a direction, planning out in detail, and implementation. Now, this has literally changed the lives of every single developer. Obviously, we no longer write code by hand. It's a complete complete waste of time to try to write things yourself when all you need to do is give them a direction, they can build out a plan, then they can execute it.
2:58 Even if all you're doing is just reviewing it line by line, there's no reason to actually sit and write the code by hand just if you're think about it from a time perspective. But, there are some things that agents just aren't that good at. The very first thing, and this is maybe the most crucial thing that we need to understand because this is our advantage as humans, it's kind of surreal to say, but that's the truth, is handling huge amounts of context.
3:23 Okay, so even with agents that have a 1 million token context, that still is far, far from enough to have a good understanding and grasping a large production code base. And when this is the case, then you literally cannot trust agents blindly to come up with the correct implementation to a plan because they might be missing an entire part of the code base that they just didn't comprehend yet. Now, the question is that where do you put this?
3:53 So, some people think that they might be pretty good at it soon. Agents will be able to have, I don't know, 2 million, 3 million, 5 million uh token context windows. The compaction of context will be better. The handling of the amounts of code and compressing it in a way where um agents can reason about it will improve. But, I personally think that this sits over here and that we have some time just because increasing the amount of context or increasing the context window is very, very expensive just in terms of memory and GPU usage.
4:28 And there's a a physical bottleneck in just RAM, etc., when it comes to increasing the context window. And this has a huge cost implication. And I'm not sure that we're there yet to solve it. And especially not when it comes to just code bases of, let's say, 300,000 plus lines of code. So, I'm putting it over here and that we might have some time. This, I think, I'm I'm like guessing over here because there's also hardware that's coming out and things are changing.
4:57 But, I think this might stay true for at least at least another, let's say, year or 2 years. And if that's the case, then this over here is maybe one of our largest leverages. But, something that they aren't good at and they'll I'm confident be really good at real soon is uh vision. So, some people say, "Okay, they don't have the taste to create like high-quality designs. Um they don't see what the website actually looks like.
5:23 You give them an image and they can't recreate it. They need the human to actually look at things, assess them, give them feedback, etc. That human in the loop, that's sort of a place where we have an advantage. But, the truth is, I think, that um agents are rapidly improving there as well. I think that we're rapidly reaching a point where it switches and agents just have good enough vision. So, let's call it over here, agent vision.
5:45 Another thing that they are incredibly bad at is coming up with novel solutions. So, if you have a complex domain, then large code bases become incredibly complex, and sometimes you just need a novel, like simple idea that the agent just doesn't think of. If we're thinking about things that they are extremely good at, is like working within a known framework or solved problem space. And this also, I think, is the one of the biggest advantages that we have.
6:19 So, coming up with novel ideas. I'll add over here in the things that they'll be good at pretty soon, I'll add also writing production-grade code without needed human review. This will likely get a lot of heat because some of you have bad experience with AI writing a lot of stupid things, and of course you want to look at it to make sure that it looks good, but we are reaching the point where agents are just so good and so good at reviewing themselves that I believe this will be completely redundant.
6:54 We'll have tests, we'll need to validate things manually, etc., etc., but just reading every single line of code that the AI writes, this is becoming ab- obsolete real quick. Personally, I believe that we're already here with Opus um 4.7, but in case you think that even this is exaggerated, then you'll for sure think that this is exaggerated, but again, that's my take. You can disagree, and maybe you'll convince me in the comments. Okay, so this is the landscape as I see it, and coming to answer this question, this this is like the mindset that I have.
7:25 Now, you can definitely disagree with this, your experience will differ, your code base will differ, the models you're working with at will differ, etc., but let's just assume that what models are extremely good at is execution given a clear plan, and they're not necessarily that good at coming up with novel ideas and thinking about like the large large picture of the product. Now, if we step out of the small profession and expertise that we have in .NET and we look at the software ecosystem as a whole, then we're like all over this thing, right?
7:57 We need to obviously like do everything here, but our expertise is in writing code specifically within the .NET ecosystem and framework. And even within our niche, we have our specific expertise in web apps, uh Blazer, etc., etc. So, given the fact that agents are extremely good at writing language in writing code, sorry, in any given language, there's absolutely no reason, in my opinion, and that's the harsh reality, to become an expert in .NET specifically.
8:34 There is nothing special about .NET as a programming language and as a framework that is worth investing your time in as if the other languages and frameworks won't exist. The writing code and reading code is becoming less and less important. The even if you think about like the optimizations, the hot path, things that you want to have like extreme nuance and do you want to have precision over there, etc., agents are extremely extremely good at. What you'll actually likely do is learn the heck out of it using an agent and looking manually, etc.
9:09 Writing a clear markdown file with the rules of what you want, running tests, making sure it works end-to-end, verifying it in like a high level, but just the .NET specifics don't matter that much anymore, unfortunately. Now, some of you might be sitting in the bathroom. Just kidding. But, some of you may be sitting and saying, "What the heck are you talking about? Of course I want to look at what the agent is writing. You can't have agents just writing code freely, making mistakes in production. the cost will be like so significant that you'll always have to have a human in the loop.
9:41 That is a very, very strong case, but here's what I believe that will happen. Agents are getting increasingly, increasingly good at it. To the point where they're writing better code than most developers. I've worked within very large projects within Microsoft, within Microsoft Office. You have hundreds of developers and the output of the code and the quality of the code is nowhere near the quality that I'm getting from Opus 4.7.
10:12 If you have good rules in place and your system is built properly and structurally properly, then agents are really good at just working well within the system. If we equivalent this to autonomous driving, then as cars improve and autonomous cars improve and there are less and less accidents, at some point it passes a threshold where just driving the car manually, even if it seems like the right thing to do, it just becomes statistically wrong to do.
10:37 And when you've got companies that all they're trying to do is increase their shareholder value, then holding another 1,000 or 2,000 employees just doesn't make sense. And sadly, that's the reality and it's just the responsible thing for us to do to understand where this is going and how the heck do we keep our job and do our job properly. So, this is if this is a hill that you want to die on, then that's completely fine.
11:03 Just what I'm saying, this isn't a hill, this is sort of like a sinking ship. So, what I think you should do is the following. Everything over here, completely redundant if you're wasting any time in my opinion or if you're using your time to do improve on that, then you're wasting your time. Writing code, waste of time. Planning out a specific implementation, which abstract method should you add, what should be in the base class and what should be in the implement, blah, blah, blah, blah, blah.
11:29 All of that, complete, complete waste of time in my opinion. If you're working on a pretty simple app, so let's say just a simple web API with um proper crowd etc. This is also I wouldn't waste time here. Agents are just outperforming us like significantly. If you're a front-end developer and you're saying, "Yeah, but they can't implement it one-to-one as I'm imagining etc."Unfortunately, I think that that's not going to be the case. If you're saying, "Okay, but we'll still need to review code etc."
11:58 I also don't think that that is the case. So, where is our leverage? Here's what I think. Because codebases are extremely complex and they're going to become much more complex in the future as agents increase the velocity of the code that's being written and at some point it just becomes too big for the agents. They can't reason about it, they make mistakes, they have this confidence about the architecture and how things should look etc. etc. And they just don't have the clear picture because it's just too big to handle within their context window.
12:32 And this is something that I've been facing lately in my project where I spend, let's say, and I'm not joking, 500,000 tokens just to get the agent up to speed and completely fully understand my point of view and what I want to do. If the feature is complex and it touches a lot of places in the codebase, then the agent must understand exactly what you mean because of course you don't want to get things wrong.
12:59 That means that if you have a 1 million context window, then you now have only 500,000 tokens left for that and the quality decreases as you go on. So, if you think about it as layers of abstraction, then basically what we're doing is we're climbing the level of abstraction. We're not writing machine language anymore, we're not writing assembly, we're not writing C, we're not writing .NET anymore. We're writing English. The need for us to go into the nitty-gritty is irrelevant once the nitty-gritty is definitively written once you define it in a higher level.
13:32 So, if that didn't make sense, then I'll explain myself. So, I don't need to look at how the C# compiler is lowering my C# code because it will definitively take it and output the corresponding thing. If we're going up the levels of abstraction, then we are now at the point where we tell the agents what we want and we're having it It's not perfect yet. It's It's It's far from perfect yet. But once you explain properly properly what you want, then having it implemented one-to-one in the code base is rapidly becoming a solved problem.
14:05 So, to answer the question, should you learn .NET in 2026? Sadly, the answer is no. I don't think there's any reason to become super proficient in.NET. You want to be proficient with software architecture, how systems interact with one another, architecture of the cloud. If you're working on low-level systems, let's say you're working on your own compilers, things like that, or if you're writing a a library for .NET, then you definitely want to understand how things are working from a software engineering point of view.
14:39 You want to understand how the processing of writing code and how it's compiled and how it's cross-platform and blah blah blah. That is important if that's important for your job, but I'd learn it only if you need it for your job. I wouldn't learn it in advance. One last thing I'll say is that many projects just can't be exposed to LLMs so freely. If it's something that's sensitive, if it's a bank, whatever. And if that's the case, then you may not be able to work with agents and AI in general within your code base.
15:10 And I see that actually as a huge disadvantage and I wouldn't personally stay in a company where I couldn't use agents and had to write code by hand because at some point a company moving in a higher velocity will just outpace the current company. But that's what I think. Maybe I'm wrong. Let me know in the comments what you think. I'd love to hear it. Maybe you can convince me otherwise. So, that's it for now. I'll see you in the next one.