Hacker News Reader

Comment by ehnto | Hacker News Reader

I have certainly noticed my stress skyrocket in this new mode of working. I was used to getting a lot done very quickly, with intense pockets of work followed downtime. Now it feels more like a steady stream of medium stress, and there is no opportunity to stop or drop the thread.

I must admit, if this is the new way of doing software development (eg: not actually programming but working with LLMs) I am not going to stick around for that long. It's not what I fell on love with, it's not what I trained for etc. I may as well do a job I don't enjoy that lets me rest my brain for later.

View on HN

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.

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

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

Or it hits a school instead.

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.

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

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.

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.

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.

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

Well sure, but that isn't what my original comment that you were replying downthread of said. I specifically recommended safety critical embedded. :)

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

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?

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.

Yeah, same thoughts. And this industry is becoming so volatile, I'm not sure what will happen tomorrow. I mean it's highly unlikely that AI will replace developers at least in the next 10 years, but I'm not sure what will "software developer" become. Certain people love to work with details. If AI is taking away this joy, I'll rather retire as early as possible from this volatile industry.

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.

> major catastrophes haven't happened yet because of vibe coding

Didn't Azure, AWS and Cloudflare crash a few times in the second half of 2025 because of vibe coding?

Catastrophies would be we vibe coded a nuclear plant or space rocket system and we blew up thousands of people due to a vibe coding error.

Bringing most of the western world economy to a standstill isn't one? When I say AWS was down I mean AWS was down.

> Bringing most of the western world economy to a standstill

That’s a huge exaggeration.

True, it was Crowdstrike that did that, and that one wasn't AI.

The Crowdstrike outage only affected Windows machines. It probably improved the world economy.

I can confirm that nuclear power plant software has much higher quality level than normal commercial software and extremly extensive testing. In addition, lot of nuclear safety is checked below the software level on hardware level.

Developement of nuclear power plant software is very conservative, it will use LLMs maybe in 10-15 years.

They crashed yes, but not for too long and they did recover. And was it ever confirmed it was because of vibe coding? Not sure how much if any it even impacted their stock.

It was confirmed each was because of vibe coding.

Can you share some links?

Asking for myself, some friends and HN community at large.

programmers were always against "software patents" - the idea of copyrighting algorithms and implementations

implementations are already copyright

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.

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/

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.

In my company it's a bit more complicated, but I have the spirit of your thoughts. I think business software (such as the ERP-like software I work on) is often an entropy magnet from the complexity point of view. It doesn't strive to be simple and elegant because business / finance world is messy. Whether all the complexity and messiness of the financial world is accidental or justified, this is irrelevant for me because I don't care about their business problems. It will be soul sucking anyway.

Yeah I agree. And sometimes it is not really the complexity. For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.

>> For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.

IMHO, the complexity of kernel and compilers is usually more justified and less accidental. At least non technical people are rarely the cause.

Yeah I’d rather fight with concurrency or obscure language features than fight with ever changing and ambiguous business rules.

it was impossible to write code for 8 hours straight, you naturally had to stop

but you can prompt for 8 hours more or less

like running versus cycling - you can cover more distance by cycling and it's less intensive (I'm talking casual running/cycling, not racing)

agents are a bicycle for the mind

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

But the metaphorical goal is to cover distance not get fit or to make the best use of what you trained for. A trained runner on a bike is faster than a trained runner.

At least if the metaphor is about coding as a means to creating usefully functional code as efficiently as possible. Careful coding by hand may eventually be a hobby activity.

Personally, while I do get some satisfaction in coding by hand it was always the production of something useful that I found most rewarding. I was never someone who wrote code for a hobby. With LLM's I'm more productive. And I find that very satisfying.

> A trained runner on a bike is faster than a trained runner.

Not true if they kept going the wrong direction.

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

Is it because the prompts matter less?

I find the opposite to be true. I'm much less in control when prompting than programming. So I can be much more in the flow during programming and 8h (well stopping to lunch) can be no issue. I feel bad prompting 2h straight.

I don’t know how any engineer can claim this. Is this guy even reviewing his “output”?

You have to take a lot of these comments on this site with a grain of salt. These guys are not pushing out stuff they are professionally liable for.

That sounds dangerously like your organization has overcommitted to AI, is hemorrhaging money and is squeezing their human engineers to make up the difference.

Not sound harsh but that the people who solved problems with code just because they love coding disappears from problem-solving environments does sounds like a win-win for everyone involved. I've both been in situations where I loved coding the solution more than I want the problem solved, and I got in the way of people who just wanted the solution, and vice-versa where architect-astronauts are more interested in coding then solving things so they get in the way. If these could be better separated, that feels like the right direction, in both cases.

Loving code does not necessarily mean being an architecture astronaut.

The people I'm talking about literally like coding for the sake of coding (many have shared comments here on HN about it in the past too), which I think is the same group who now are loosing their "passion for software engineering" as the LLM takes over the typing/coding part, but still leaves the design/intention to the human. But yes I agree, one does not equal the other, but if one person has one of those characteristics they tend to also have a bit of the other, at least in my experience.

Agreed, I see a lot of the type of people you're describing on here.

That type are called "engineers". I used to interview them and I didn't care if they knew anything about the business.

Large codebases are the most complex things we have ever worked on and can easily become unmaintainable. I wanted people who really cared about code quality and consistency in order to offset this.

I think that it would be even more important to hire people like that now and even though we will need less programmers there were never enough of that type to go around anyway.

If you have ever endured the pain of bad code and cumbersome architecture when trying to fix a bug or implementing a feature, you start to be adverse to anything that increase the likelihood of it happening.

Most people that happily use the LLM for coding either are not responsible for the code running or have no qualms to being a reverse centaur.

Weird. Ive seen the exact opposite. The LLM drones talking endlessly how to write fairly basic code using LLMs in a way that is not actually solving problems any quicker or more effectively but is doing it in a way that they see as "more modern".

Ironically I don't think software engineering has progressed much at all since vibe coding got fashionable. Real, meaningful engineering advances are being drowned out by the AI coding religion.

The front page of HN has definitely be sparse on actual software accomplishments, it's been a lot of meta-level chatter on AI. Obviously a very important technology, but also just a tool, a means to an end. I am not seeing much progress in other fields making it to HN regardless of what tool they used. I hope it's happening, and just being drowned out.

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.

Just wondering if we are working a lot but perhaps we do not get the same feeling of accomplishment that we used to get since we feel that we are not really doing the work?

I feel the complete opposite. I am much more relaxed now since I can be way more effective while actually working less.

Reply on news.ycombinator.com