Hacker News Reader

> If software engineering goes the way of the dodo, I suspect most other white collar jobs are also displaced (anything done entirely on the computer, really).

Strongly disagree with this. In contrast to most jobs, software engineering is unusually self-contained, with short feedback loops and immediate validation. You (or Claude) implements the feature, you run the tests, you fix the bugs.

Most white collar jobs are nothing like this: lawyers have to prepare briefs (AI can help here) but they have to file briefs, they have to wait weeks or months for rulings, they have to argue in court. Marketing execs might spend millions preparing a new campaign, launch it for the holiday season, and it has to be right the first time. Most white collar work involves judgement, anticipation, and ambiguity in a way that software doesn't.

Software lets you guess-and-check over and over again until it works.

> Most white collar work involves judgement, anticipation, and ambiguity in a way that software doesn't.

In my current position as a software engineer, this is MOST of the job.

I don't know what everyone else's role is like, but a software engineer that isn't dealing with those three items sounds more like a compiler.

"Most white collar jobs are nothing like this: [software engineers] have to [implement features] (AI can help here) but they have to [coordinate releases across teams], they have to wait weeks or months for [real-world usage to validate architectural decisions], they have to [defend technical decisions to stakeholders]. [Engineering teams] might spend millions preparing a new [platform migration], launch it for the holiday season, and it has to be right the first time. Most [software engineering] involves judgement, anticipation, and ambiguity in a way that [isolated code production] doesn't."

Sure, and to the extent that your job involves those things, it won't be taken over by AI as quickly. But this whole thread is full of software people screaming that the sky is falling and Claude can already do their entire job and they are the horses, not the farrier. So...which is it?

I think software development is a field unusually vulnerable to LLMs because there's lots of good examples for training data, and the work is easy to validate in short order according to somewhat-objective criteria.

Note that certain kinds of mathematical proofs also fit these criteria, and also have been an early showcase for AI abilities. Anything where the bot can get to a good result by just grinding on it for days is going to get taken over by AI quickly.

> You (or Claude) implements the feature, you run the tests, you fix the bugs.

...you then take it to the customer. And wait, and wait, and wait, and maybe eventually they'll get around to trying out what you created, and if you're lucky they'll even give you some feedback to loop back with to try again. They will only try your application a few times before giving up on you, so even if the feedback loop is immediate like you claim (its not; not even close), you aren't afforded many iterations. A software engineer's job is, of course, to get ahead of the customer using judgment, anticipation, and dealing ambiguity to minimize how many round trips are required to satisfy the customer.

If AI can replace the software engineer, why can't it replace all "white collar" work?

For the record, I don't think AI is likely to replace those parts of the work, at least not in the near term (15-20 years). But at many companies, the people interfacing with stakeholders or users — deciding what problems need solving and how to solve them — are product owners or project managers, not software engineers.

I think there will be a convergence where AI enables more POs to create software directly, and more SEs move up the value chain to work on product-level problem solving.

Product owners/managers typically act as the communication channel between customers and software engineers, but engineers are responsible for designing the software. It is they who have to use judgment, anticipation, and deal with ambiguity in order to find software customers want to use. The product owner/manager does not. They simply pass messages back and forth. Of course it is possible for one person to be both a product owner and a software engineer, but often the engineer is separated from having to play telephone tag with customers so that they can more efficiently focus on their primary task.

Perhaps you have confused software engineer with coder? LLMs are most definitely the final death knell for anyone still working as a coder, but that profession was on the way out for decades already. The earlier comment was clear about software engineer.

Yeah, most PO/PMs I've encountered know awfully little about the business processes, their constraints and complex interactions within their own product. They know quite a bit about priorities the various customers voiced, fancy stuff they'd like to demo on the next review or trade fair or customer relationship meeting, or new features they want to get customers interested in. But don't ask them how those features interact with others!

If you want to go into detail with that kind of stuff, your best bet is not the PO, but the lead engineer of the team. If the team was properly staffed, the lead engineer will have a solid knowledge of the business aspects of the product while at the same time being able to cross-reference that with the most important technical aspects.

LLMs will make more people into "lead engineers", even if all they're "leading" is the LLM agents and not other humans, as it was common before the LLM age. One of those will then emerge as the "lead lead engineer" who's going to lead the humans which in turn lead the LLMs. If it wasn't for the "engineer" in the meaning of "code monkey" dying out - which I also expect - we'd have to invent a new title, but I'm currently expecting this shift to go without that. It'll still leave some engineers who made themselves comfortable just churning out code that does whatever a ticket requests, without even understanding one iota of the business process behind the ticket, without a job, but that's the kind of "software engineer" who in my opinion shouldn't ever have taken up the profession anyway.

> Of course it is possible for one person to be both a product owner and a software engineer

This was the norm in every job I had from late 90s to around 2015.

Engineering Managers were responsible for both technical and business outcomes, and it worked fine.

The scrum solution of having from the business side acting as a literal "product owner" or "client representative" and giving feedback IMO was a much better direction that unfortunately companies have not followed.

I don't think "software engineering" is a real thing. So-called software "engineers" do not practice engineering in the way that a mechanical engineer or a civil engineer does. Consider: How often do bridges collapse? How often do elevators plunge to their doom? How often does some critical piece of software utterly fail? [0]

> They simply pass messages back and forth.

So you claim. We're about to conduct a real-life experiment to see which is more valuable: passing messages back and forth to the computer, or passing messages back and forth to the customer.

[0] https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

> I don't think "software engineering" is a real thing.

You don't think anyone designs software? It just magically appears?

> So-called software "engineers" do not practice engineering in the way that a mechanical engineer or a civil engineer does.

And? The dictionary defines engineer as someone who designs and builds things. It does not prescribe how the thing is designed.

> How often do bridges collapse?

Not often, but often enough to know that we still consider the designer to have been an engineer and not a project manager. I still have no idea where the idea that project managers do the design work came from.

> passing messages back and forth to the computer, or passing messages back and forth to the customer.

When AI can handle the judgment, anticipation, and deal with ambiguity neither are important. The customer will go straight to he AI. Hence why "white collar" jobs of all sorts are ultimately doomed. Unless you believe AI cannot reach that level, in which case software engineers will be fine, since that's the whole reason for their existence.

What we do see happening already is the decline of the project owner/manager role. More expensive money and technology increasing engineering efficiency has made it such that it is becoming hard to justify an assistant to bridge the telephone tag gap. That doesn't really affect engineers much, though. Before ZIRP allowed budgets for project managers/owners engineers also played that same role, so it is nothing unusual for them. Engineering getting secretarial assistants for a time, something historically reserved only for the upper brass, is but a curious aberration.

> You don't think anyone designs software? It just magically appears?

Do you actually write software for money?

Most commercial software is never designed, it evolves, over the course of repeated "agile" "sprints". Every two weeks, someone hacks together something that kinda-sorta works and then that is released.

Eventually (often many years later) the thing becomes so complex and unwieldy that it's impossible to add any more features, so someone gets angry, throws it away, and starts again growing a new monster.

> Do you actually write software for money?

No. I am paid to be involved in the software industry, but as an engineer, not as a coder. Writing software is not part of what I do. That is, to use your bridge analogy, for the construction crew.

> over the course of repeated "agile" "sprints".

It is true that not all engineers know what they are doing, are good at what they do, or bold enough to push back against out-to-lunch stakeholders.

> so someone gets angry, throws it away, and starts again growing a new monster.

I never understood that. Untangling the messes was always the fun part back when coding was still a job. But I don't really see any coders in industry anymore. Any last remaining ones I knew of have already been replaced by LLMs. LLMs will also happily untangle the messes, though, so still no reason to abandon code.

Boeing ships software that crashes planes, Microsoft Windows regresses so you can't move the start menu, medical devices come with hardcoded admin credentials.

I'm very very curious where all these mythical software engineers are working. Finance, maybe? ... or not https://www.bloomberg.com/opinion/articles/2025-03-03/citi-k...

>> One quirk of the program was that the amount field came pre-populated with 15 zeros, which the person inputting a transaction needed to delete, something that did not happen.

> One quirk? Fifteen zeros? The quirk in the software is that if you type “send $1” it says “okay sending one quadrillion dollars” and you have to backspace over all the zeros? Incredible interface design.

> I'm very very curious where all these mythical software engineers are working.

Boeing, Microsoft, and medical device manufacturers mentioned seem like pretty good candidates. Were you under the impression that the software designed at those places just magically appears?

As before, being an engineer does not imply being good at the job. It only implies designing things. The designation of Professional Engineer institutes a vetting process to try and weed out those who aren't good at the job, which may be the source of your confusion, but PE is a designation, not a job. Not all PEs even work as engineers, although certainly many do.

Ok so why is all their software such garbage, then? You can't gaslight me, I work in this industry. I see the absolute nonsense that passes for marketable product. I know there are smart people involved in creating software, but they are not engineers and (with the possible exception of some groups at NASA[0]) nothing they produce is the result of an engineering process.

Has any software "engineer" ever lost his license because he signed off on trash code that failed? Where is the Otis elevator emergency brake[0] of the software world?

[0] https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...

[1] https://www.otis.com/en/us/tools-resources/high-rise-safety-...

> Ok so why is all their software such garbage, then?

Because the people involved weren't good at their job...? We've been over this multiple times now. It doesn't seem like it should be hard to figure out. What do you continue to miss?

> but they are not engineers

Sure, software involves lots of different types of work. Engineers are just one tiny piece of the puzzle. But design is exclusively the domain of engineers. Anyone working on the design is an engineer, by definition. That, again, does not imply that they know what they are doing, are good at their job, or bold enough to push back against out-to-lunch stakeholders. Having someone doing engineering work does not magically mean you are going to see an excellent product on the other side. Most people are pretty lousy at what they do.

You, again, increase your chances if you involve PEs, but that's not a job, just a designation.

> Anyone working on the design is an engineer, by definition.

You and I have very different definitions of "engineer". To me, an engineer is a licensed professional who adheres to the code of practice for his or her profession. We'll have to agree to disagree on the semantics. I think lots of software people want to call themselves "engineers" because it sounds like someone who should be paid more money.

...or it did, until the AI revolution.

> To me, an engineer is a licensed professional

Again, we’re talking about jobs (and whether they will remain in the future), not professional designations. Licensed professional engineers are usually referred to as PEs, but even if you want to call them engineers it is clear that not all engineers of that sort work in engineering. In context, we can establish that we are talking about engineers in the worker sense, not the professional license sense.

Is English a second language for you? Maybe context doesn’t translate well. English is certainly bad for assigning multiple meanings to words and relying on context to figure out which meaning applies.

> I think lots of software people want to call themselves "engineers" because it sounds like someone who should be paid more money.

How would describing the job by what it is, literally by dictionary definition, garner more money?

I am aware of the time physicians started calling themselves doctors to try and ride on the coattails of academics, so I think I understand the angle you are trying to come up with, but this isn’t like that. In this case engineer was already the word in the dictionary that existed to describe the work.

> To me, an engineer is a licensed professional

Even outside of "software engineering" there are tons of people working jobs that almost everyone would consider "engineering" that don't require a stamp. Chemical engineers, electrical engineers, mechanical engineers, tons. Only ~5% of chemical engineers have passed the PE, I guess there are essentially no real chemical engineers then?

Even in a civil engineering firm, most likely the kind of engineering you're talking about, only about half will actually be licensed and have a stamp. Tons of people will work on a project and figure out a lot of details, then work with the person with the stamp to sign off on the implementation details. Their work is undoubtedly still "engineering", but they don't have a stamp.

how many software engineers can reliably pick the failure modes of their software, and also build in appropriate safety factors on them?

Engineering is ultimately all about managing tradeoffs, so the more important question is: How often does reliably picking failure modes and applying appropriate safety factors actually matter in software, especially when most designs are little more than simple line-of-business CRUD with a (if you are lucky) slick UI?

>In contrast to most jobs, software engineering is unusually self-contained, with short feedback loops and immediate validation.

This is nice and makes things easier for the models to learn. Emphasis on easier. They are still capable of learning how to deal with other kinds of problems and being better at it, and they have, over the last couple years.

I'm a little surprised by how easy people joke about residential electricians and plumbers in this context. To begin with it requires young and healthy back and knees. How many men after 40 and especially 50 are like that and for how much longer?

Secondly, in CA to be a real residential electrician you need to be C-10 licensed. Which requires all kinds of time consuming prerequisites to begin with. Some of them could be a challenge if you are not the kind of guy who knows a guy. Apprenticeships, unions, depending on your major 1 to 4 year of "hands-on, full-time journey-level experience" and such. Your best hope is probably that your EE degree from 20+ years ago still counts for something.

And there quite a few 20 yo candidates to compete with who are taking DC/AC circuits classes in community colleges this very moment. They are not spoiled with life-long office work experience.

The competition among people who'd like to be an industrial robotics technician at the Tesla Fremont Factory is very real too.

This is generally how I feel - whenever new levels of abstraction have been introduced the goal posts for what can be built are now orders of magnitude further. This seems to be the case with all technology.

Consider assembly -> higher order languages -> libraries -> open source -> stack overflow -> now AI.

> If software engineering goes the way of the dodo

Much more likely is that software engineering goes the way of the elevator operator. Advancements in technology saw the number of elevator operators explode, to the point that we've all become one!

Unfortunately for those wishing to make a living as an elevator operator, due to the properties of supply and demand, us all joining the ranks of elevator operator means that supply is effectively unlimited and thus price cratered to effectively zero. This is the real risk to software engineers, at least those who are in it for the money.

The cure for high prices is high prices.

I guess the question is more if you're a coder or a builder. If software engineering was about writing syntax and flipping bits for you, this might no longer be an economically viable activity.

If it was about building useful or fun things, then AI will probably not take that away, even if it's just for the simple reason that you care more about it than some hot GPU.

Yup I agree. I do think that all the low(er) skilled software jobs will disappear. Those mostly working on marketing websites or simpler CRUD apps. And if they don't disappear, they will just not need nearly as many people for those anymore. But those jobs were mostly about writing code, i.e translating a Jira ticket to reality, and that's not really "engineering" as such, so if your only marketable skill was knowing how to turn English (Jira) into Syntax (Code), then yeah, better start upskilling fast.

I completely agree.

The engineering part of software was already completely dead for a large portion of coders who didn't want to know anything about the domain, left all the decision-making to business people/product managers/designers and was downright allergic to doing anything that was more complicated than a CRUD in their favorite framework (which would invariably either change daily or remain static for their entirely career).

There was a huge influx of people like that in the last 10 years who got into it for the money, and frankly the industry got much worse and much more hostile to different perspectives and different experiences.

People who have not evolved into builders have visibly become meat interfaces to the LLM.