One idea to consider might be going into safety critical embedded work (e.g. brake controllers, critical systems for airplanes/trains, medical devices, some industrial systems, ...). AI hasn't penetrated much here yet. It isn't at all clear how or if you would be able to certify the process for example.

That might change with time, but for now, all I see AI used for is additional code review and side scripts/tooling that don't need to be safety rated.

Of course, that might mean entirely switching language (C, C++ or increasingly but still in minority Rust), learning entirely different skills (control system theory, real time systems, possibly formal verification but usually not), etc.

▲

HeyLaughingBoy 4 days ago | parent | next [-]

The problem is that everyone is having that idea at the same time! Posts on /r/embedded asking a related question keep being shut down because there are so many web developers now asking daily how they can get into embedded systems because of a perceived lack of LLM penetration.

No such thing! Companies that aren't already actively using AI for embedded development are looking closely at it and experimenting with procedures to incorporate into their workflow. Why anyone would think that a company would ignore a potential improvement to their bottom line is beyond me.

Yeah, it might take a while, but it will happen faster than you think.

▲

foldr 4 days ago | parent [-]

Indeed. GPT 5.4 was perfectly happy to help me write some 8051 assembly and integrate it into a weird vendor-specific Eclipse/Keil C51 build system. I would never have had the time or patience to figure it out. Embedded isn’t ready for full vibe coding to the extent that web development is, but it’s certainly not going to be an escape from AI.

▲

VorpalWay 4 days ago | parent [-]

The issue with AI isn't that it can't write embedded code (though it is noticeably worse at it), the issue is specifically with the safety certification of code the AI produced. There is a lot of paper trail to show that you followed all relevant standards, a lot of which pertains to your development process.

It is not just what you do or don't do in the code (e.g. MISRA or CERT C) but there is also a lot about how you test, review, show that your tests cover everything relevant (not just code coverage, but also specification coverage), show how you check that everyone involved followed the process, etc.

▲

Obscurity4340 3 days ago | parent | next [-]

Cant they just implement all the papertrail-generating and checkbox-checking and ass-covering into its instructions or harness?

	▲	ehnto 2 days ago \| parent [-]
		The AI can't be held liable so it somewhat defeats the purpose of that kind of paper trail and compliance work. If the threat was losing your livelihood and possibly jail time, would you currently be comfortable being held responsible for AI output?

▲

foldr 4 days ago | parent | prev [-]

There's plenty of embedded code in consumer products that doesn't need to meet any special standards like MISRA.

	▲	VorpalWay 3 days ago \| parent [-]
		Well sure, but that isn't what my original comment that you were replying downthread of said. I specifically recommended safety critical embedded. :)

▲

rdbell 4 days ago | parent | prev | next [-]

"Switch to a field that involves many people dying if you write a bug" doesn't sound like the less stressful alternative to me.

▲

tempodox 4 days ago | parent | next [-]

Especially for developers of server, desktop, or web software. Experience in those fields will be more a hindrance than an advantage if you want to enter embedded development. Embedded is a whole different beast and you’d have to unlearn a lot of bad habits and expectations that your former field instilled in you. No hiring manager will give you the time for that.

▲

dosisking 4 days ago | parent | prev [-]

So maybe try the weapons industry? If you write a bug, it will probably miss the target, and people won't die.

	▲	lcnPylGDnU4H9OF 3 days ago \| parent [-]
		Or it hits a school instead.

▲

mlsu 3 days ago | parent | prev | next [-]

Safety critical embedded just doesn’t need as many lines of code. Your typical embedded codebase is small and long-lived, and if you’re spending a fortune to do verification and validation on a piece of code, the bottleneck is not the programmer.

A code change at my role recently, the diff was 6 lines, and that took at least 10 hours of combined writing documentation, figuring out which tests to run and then running them, pre-work for me, to propose the change and describe the behavior of the SW. So AI helps in all these processes, but having the agent write the code vs having me write the code makes no difference at all. I think most safety critical systems are like that.

▲

Eddy_Viscosity2 4 days ago | parent | prev [-]

> going into safety critical embedded work

The move-fast-break-things crowd is going to come after these as well, along with medical and defense software where lives are fully on the line. Sure, there will be failures and needless deaths and bombings of elementary schools, but that's just the price of being on the bandwagon.