# How cooked are software developers?

## Метаданные

- **Канал:** Let's Get Rusty
- **YouTube:** https://www.youtube.com/watch?v=AW_X6soZbQY
- **Дата:** 23.04.2026
- **Длительность:** 9:53
- **Просмотры:** 14,714

## Описание

👉Join the Rust Live Accelerator waitlist: https://letsgetrusty.com/join

Is software development still a safe career in 2026? With AI reshaping the industry, many developers are starting to feel uncertain about their future.

In this video, we break down two viable paths for mid to senior developers to stay relevant.

Chapters: 
0:00 Intro
0:52 The Squeeze
2:14 The 1st Path
3:14 The 2nd Path
7:33 Why Rust?
8:34 Final thoughts

## Содержание

### [0:00](https://www.youtube.com/watch?v=AW_X6soZbQY) Intro

The worst possible job you can have in 2026 is being a software developer. We went from crazy pay packages in office sleeping pods and daily free meals to being absolutely terrified for our livelihood in the short span of 24 months all because of this technology that we created ourselves. So what can we still do? Is it still possible for software developers to survive AI? If you're a mid or senior level software developer, I think there are still two viable paths you can take to have a longlasting software career. You can either one, go much higher up the stack and become what I call an AI orchestrator, or two, go much lower down the stack into areas like systems programming. So, let me break down these two paths for you and explain which of these two paths you might want to consider or prioritize to maintain a longlasting career as a software developer. All right, so let's talk

### [0:52](https://www.youtube.com/watch?v=AW_X6soZbQY&t=52s) The Squeeze

about what's actually happening to software jobs right now. Here's the thing. AI isn't going to replace all software development, but it's clearly automating one specific layer, the middle layer. What do I mean by middle layer? I'm talking about CRUD applications, front-end templates, basic API endpoints, glue code that connects services together. essentially all the stuff that follows predictable patterns. The work where you're mostly wiring things together according to established conventions. And honestly, the middle layer represents a huge chunk of what most developers do dayto-day. In fact, for a lot of developers, it's almost everything they do. Junior developers are already feeling this, not because they're bad engineers, but because their primary value is implementing straightforward features, which is exactly the stuff AI is already really good at. And mid-level developers are next in line. Senior developers have more runway because they're usually doing higher level architecture and system design. But even they aren't immune. Companies are already restructuring entire engineering teams around AI first workflows that design, spec out, and implement entire systems. So the middle layer is getting squeezed out fast, which means if you want to survive as a software developer, you need to move either up to the orchestration layer or down to the systems layer. All right, so here's the

### [2:14](https://www.youtube.com/watch?v=AW_X6soZbQY&t=134s) The 1st Path

first path. If you can't beat AI at writing code, what if you direct it instead? This is the path that a lot of developers are gravitating towards. Becoming an LLM orchestrator. You're the one designing the system architecture, breaking down complex problems into smaller pieces, and then having AI generate the implementation. You're still doing real engineering work, making decisions about databases, choosing frameworks, reviewing AI generated code for correctness. And honestly, this can work. But here's the issue. Everyone is trying to go down this route. Every developer who's seen AI eat into their work is now positioning themselves as a senior architect who manages the AI. Plus, as AI gets better at understanding requirements and system design, how long before AI starts eating into the work at this level, too? So, here's another approach. Instead of trying to stay above AI's capabilities, what if you went the opposite direction? lower into the foundational systems that everything else is built on? Okay

### [3:14](https://www.youtube.com/watch?v=AW_X6soZbQY&t=194s) The 2nd Path

now let's talk about going lower down the stack. I think this is the second path software developers can take to still have a long lasting software career. I'm talking about low-level systems programming. Things like databases, networking, operating systems, or embedded devices. Systems that require so much more human intervention and deep understanding that AI becomes a tool you use, not a replacement for what you do. And there are three specific reasons why. Reason one, the error tolerance is basically zero. In low-level systems work, a single bug doesn't just break a feature. It can cost millions of dollars or take down critical infrastructure. AI slop simply won't cut it here. You need excellent engineering. AI coding tools are already causing disasters. In July 2025, an AI coding agent on Replet deleted a live production database during a code freeze despite being explicitly told not to make any changes. It wiped out over a thousand executive records and hundreds of company entries. It then lied about whether the data could be recovered. Or take Amazon. Their internal coding tool Kro was asked to fix a minor bug in the AWS cost explorer. Instead of fixing the bug, it decided to delete and recreate the entire production environment that caused a 13-hour outage. And it got worse. A later incident in March 2026 lost Amazon 6. 3 million. Amazon had to force a 90-day safety reset across 335 critical systems. This is Amazon, one of the most sophisticated engineering organizations on the planet. and their own AI tool destroyed their own production systems. Now imagine the same AI generating code running in medical devices or flight control systems or a nuclear power plants monitoring system. The stakes aren't just lost orders, their human lives. That's why in low-level systems work, you need engineers who deeply understand what every line of code is actually doing. You can all solve that by generating more code faster. Reason two, a lot of this low-level work is in regulated industries. We're talking about medical devices, military software, aerospace, automotive, government systems. These industries have strict requirements for how software is built, tested, and certified. Take aerospace. There's a standard called DO178C. It's what the FAA uses to certify all commercial flight software. Under this standard, every single line of code has to be traceable back to a specific requirement. It has to be independently verified by someone other than the person who wrote it. And for the most critical systems, the ones that can bring down a plane, there are dozens of objectives you have to satisfy before that software is allowed anywhere near an aircraft. You can't just walk into the FAA and say, "Yeah, our AI generated the flight control software looks good to us. " That's not how any of this works. And that's not going away. If anything, regulation is increasing. Governments are now mandating that safety critical systems move towards memory safe languages. This isn't a suggestion, it's a requirement. So even if AI gets really good at writing code, the regulatory structure around these industries creates a permanent floor on how many skilled human engineers you need. Reason three, someone has to own it. This is one people don't think about. In these domains, when something goes wrong and something will go wrong, a human engineer needs to explain why it happened and prove the fix works. You can't just tell a judge, "The AI wrote the code. " You can't tell the National Transportation Safety Board, "We're not sure why the system failed. Our AI agent handled that module. " Someone has to deeply understand every line of code, own all the decisions, and actually stand behind them firmly. That means even as AI helps you write more code, you still need engineers that could read it, reason about it, trace bugs through different layers of hardware and software, and more importantly take responsibility for the system. That's not a capability gap that AI will close. These are structural requirements of how these industries should operate by law and bureaucracy. These three reasons are why systems programming demands excellent engineers with deep understanding, not just code monkeys turnurning out AI slop. Now, here's

### [7:33](https://www.youtube.com/watch?v=AW_X6soZbQY&t=453s) Why Rust?

something interesting. If you go on LinkedIn or any other job board right now and search for roles in embedded systems, cloud infrastructure, or safety critical software, one technology keeps showing up over and over again. Rust. Why Rust? Because it gives you the low-level performance of C and C++, but with memory safety built into the language. The compiler catches bugs like memory leaks and data races before your code ever runs. When a single bug can be catastrophic, that matters a lot. And the biggest engineering organizations in the world are betting on it. Microsoft is rewriting parts of Windows and Rust. AWS built Firecracker entirely in Rust. Cloudflare replaced EngineX with a Rustbased proxy. The Linux kernel officially adopted Rust. And Google saw a 68% drop in memory vulnerabilities after adopting Rust for Android. Even the White House published a report in 2024 explicitly urging developers to move to memory safe languages and named Rust specifically. Now, if you're

### [8:34](https://www.youtube.com/watch?v=AW_X6soZbQY&t=514s) Final thoughts

watching this YouTube channel, you probably aren't the kind of developer who wants to spend their career churning out AI slop. You want to solve hard engineering problems. You want to build things that actually matter. And I think going lowlevel is how we software developers can still get a longlasting career. Not just right now, but especially as AI keeps advancing. Because here's the trend. As more AI software gets built, it's going to require the underlying systems to be more reliable, even more performant. The demand for this kind of work isn't going away. Rather, it's accelerating. And Rust is becoming the technology of choice for these exciting projects. Now, if you're serious about making this transition and you don't want to spend years figuring it out on your own, I built something called the Rust Live Accelerator. It's designed specifically for developers who want to break into systems programming with Rust. It covers everything from the fundamentals to building real production grade systems, and you'll be learning alongside other engineers making the same move. If that sounds like you, click the link in the pinned comment below to find out more. Thanks for watching, and remember to stay rusty.

---
*Источник: https://ekstraktznaniy.ru/video/49661*