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.

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

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.

> 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.

I’m trying to get a bit away from the business stakeholders, into more technically required roles. Eventually my goal is to get into a system programming role.

The issue with roles close to business is that it doesn’t provide the right soil for good engineering . Your stakeholders have no concept of engineering and wants everything ASAP; Your manager is just a yes man who takes all tickets, and want you to use AI for everything because it’s so easy and quick; Your VP thinks your team is not moving quickly enough; Your VP puts speed before quality literally.

The thing is, I believe that some roles and some industries just don’t care about good engineering. If you want to be a good engineer, you have to stay away from them, even if they are high paying, and get yourself into a system programming role, in a company that fails you if you do not have good engineering practices. The only way to be a good engineer is to put yourself in such an environment that you will almost surely fail if you are not a good one. There is a cool-aid and many engineers drink that the most important thing is "business value", and I politely vomit that all out a while ago. The new rule is to become an engineer that they are still willing to pay you even if you spit on their faces.

Those roles and companies can die and I don’t give a fuck about those business clowns.

Maybe we just aren't far enough in the vibe coding side of things and there are still too many people in the industry who still pay attention to details, so no major catastrophes haven't happened yet because of vibe coding. So the people who pay attention to details are still carrying their organizations, but I do wonder how long it is going to be sustainable.

When it comes to joy killers because of AI, then it is dismal how plagiarism (going by the definition of "presenting someone else's work without attribution") suddenly became widely accepted. When I see long lists of bullet points with interspersed bold text, I know that it is something the sender did not write or bother reviewing. Absolute cherry on top when in the end of that text you see the typical LLM suggestion that you can ask for more information, which the sender didn't even bother removing.

It’s not just that. Working with multiple agents and tasks switching will increase cognitive load significantly leading to both poor decision making and increased stress.

https://pmc.ncbi.nlm.nih.gov/articles/PMC7075496/ https://pmc.ncbi.nlm.nih.gov/articles/PMC7614709/

10 years is a long time. 10 years ago the Transformer architecture didn't exist. I would call it moderately unlikely at best. At the very least, I would say it's likely that development will require an entirely different skillet 10 years from now.

Why is prompting for 8 hours easier than coding for 8 hours?

Is it because the prompts matter less?

The point was they trained to be a runner, not a cyclist.

I think I understand, but I will say that problem solvers are often masquerading as coders. I think they will leave software too. It is exactly the interesting problem solving that goes missing with heavy LLM use. Most business problems are not that challenging, from a problem solving perspective, that's just life. So the interesting part was always the problem solving in the build. I have built things with a huge spectrum of skills and tech, not just software. I learn details fast and have good systems thinking that help me apply that new knowledge.

What LLM usage has changed is that there is no longer a deep dive into domain knowledge, the LLM goes off and does that. Then implementation time comes and again it's just handholding the drunk chatbot inside the codebase until it is done. The whole time my mind is barely engaged. Yes my expertise is required to guide it, I am constantly catching issues and problems it generates, but that's still not engaging the problem solving skillset I developed. It's just leveraging my experience.

Loving code does not necessarily mean being an architecture astronaut.