LLMs are eroding my software engineering career and I don't know what to do

Except this was not the case, it had of course hallucinated what the regulation actually required (I know this because the code in question had already been reviewed by human counsel). This is (supposedly) the most bleeding-edge model available.

We use a lot of genAI to help us write code, but there is no way in the mid-term we could ever rely on these tools to actually build compliant financial products. We'd have to be totally mad. Yes, lots of Fintech companies are using these agents to accelerate, but anyone who's using them to actually ship product without a human actually digging into it is opening themselves up to a world of risk.

But how are you so sure your colleagues are not more "expert" than you? Prior LLMs there was room for very good engineers and mediocre engineers to work together in 99% of the companies out there. With LLMs, only the "best" engineers will survive, because nobody needs mediocre engineers anymore.

This being HN, I imagine every engineer reading this thinks they are in top the 10-5% of their company/city/country, and therefore they think they are not "mediocre" engineers that can get affected by the introduction of LLMs. Statistically, they are probably wrong. So, it's all about ego. Chances are you are not a rockstar and LLMs will eventually take over your job.

As usual, the only winners here are corporations and executives. Most of us are the last monkeys in the chain, and so we'll get screwed.

I understand the frustration of spending years nurturing a skill and then seeing its value decline.But this isn’t really an LLM problem. The same thing happened to factory workers, typists, draftsmen, and many others before. The technology changes, but the underlying issue is the economic system we live in, where the market can suddenly decide that something you’ve spent years mastering is worth much less than before.

LLMs are not creating that dynamic. They’re just accelerating it.

I am not sure but for complex cases it seems to me that the earlier sum of moderately long PR time + moderately long review time has been replaced by very short PR time + even longer review time. I am not sure if there's a net gain in these cases. Sometimes even if the code is functionally correct, it's verbose enough (e.g., too many intermediate functions) that I think they will impact future reviews.

Dunno how much longer that is going to remain true for your specific employer - all the fintech companies I deal with personally have had some sort of AI account for their devs since last year.

Even places like jane street have employees posting blogs (one of which was on HN frontpage about 60m ago) saying they mostly direct agents.

How long do you think your specific employer is going to hold out?

I'd posit there's another layer. You have domain knowledge, certainly. But more valuable still is the wisdom to find more.

Anthropic and OpenAI can stick financial regulations in the training data all they want, but the AI systems will never learn to anticipate the future, or reach out to clients, partners, or regulators in complicated situations.

A lot of companies are investing money on “ai factories” that are join to automate a lot of software development (that is, steer LLMs) on the basis of jira tickets (or linear/trello cards or whatever).

Most surprising to me about the article was the desire for OP's company to use AI for design docs. I feel like AI-generated design docs are some of the worst -- basically treating English as a programming language. They aren't enjoyable to read, and they often miss the forest for the trees. A human written sketch explaining why we're here and what we're working towards is still meaningful and important. If you want code-level details of every decision and algorithm, we have code for that.

I have mixed feelings on whether these documents are useful LLM inputs. I did a project where I carefully paired with Claude Code on producing a specification that another model would actually implement. I'm not sure it saved me any time, and it was very un-fun. (I kind of blame Opus 4.7 xhigh for this. It ain't speedy.) I feel like I can nitpick code to get exactly what I want, but defining exactly what I want an auto-mode LLM to go and do, in English, is much more difficult. I don't think the PLAN.md I generated would have been useful for a human trying to understand the system (too verbose), and Claude Code still made its usual mistakes that I have reminded it a billion times not to make (t.Context() in tests, not context.Background()!), so I'm just not sure it was worth it. I would say I probably wouldn't do it again in the near future. A rough sketch to get humans on board and to get the high level details worked out, written by hand, and then pairing with the LLM on actually typing in the code seems the most productive to me. But I do try to go outside my comfort zone once in a while to test the edges of these tools. They are very impressive and are worth a lot of the hype. (I know I will never write a YAML file again. I hate it more than anything, and Claude is amazing at it. But I worry I wouldn't feel the same way if I hadn't already had 8 years of k8s experience.)

If you build your environment to be specification based, you have to make sure you have good specifications. If your "memory solution" uses freeform markdown notes, you already lost from the start.

Also choose languages with good unit testing built-in, and languages with unified code styles, and unified toolchains. If you use C++, assume that there's a million ways to build your algorithm. If you use JS, assume 10 different build pipelines. If you use java, assume bloat by dependency hell.

LLMs mimic the ecosystem's variety and variadicity(?). Languages like Go shine so well because it's a very opinionated language, where there's only one proposed way on how to implement things. And that's a good harness to begin with. LLMs are like children on the playground. You have to build better rulesets and fences to make them behave how you expect them to.

Also, check out qwen3.6 coder and heretic models. 30b is the sweet spot for coding and unit testing. For planning and designing, gemma4 is pretty good.

Love the metaphor. Planes are sophisticated machines capable of auto-piloting, but humans are still needed to ultimately pilot the beast.

it only matters what upper management think, and its clear that more and more companies value "good enough" and reducing costs over "good"

I give LLMs snippets of text messages exchanges with my wife and I can't believe how dumb the LLMs are of getting basic facts right let alone nuance.

I'm 100% not one those "LLMs are just stochastic parrots" people, but coding and coding-like activities are extraordinarily well fit for LLMs, but for things that there's less training data, LLMs probably do a lot worse

I like your comment, want to try to expand on it

Comment long but there is a TL;DR at the bottom

My theory is that there are 4 areas to domain knowledge worth taking about here - there may be more but I like 2*2 matrices

1) explicit internal requirements - core of how the how the app should work towards achieving your business objectives - code expresses what should be done and to a pretty large extent, why it should be done - from business unit requirements - we are building a tool to do “X”

2) implicit internal requirements - core of how the how the app should work towards achieving your business parameters and constraints

eg profit = selling price - ( total of costs )

  - code expresses what should be done but really can’t express why. At best it is in the comments 

3) implicit internal requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments

eg if item is “rocket” , shipping = $1m ( we only make rockets in Antarctica and shipping from there is $1m)

4) implicit external requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments

eg if item is “rocket” , add a 3 month gating stage to get approval from government to sell the item and do not collect payment till gating approved - AI can see the code but has no idea why it has to be done

These come from partners, regulation, compliance, auditability etc

So, my theory

AI can be good at the explicit stuff trivially (1, 2) but cannot be good at the implicit stuff (3,4)

It might be able to figure out implicit stuff needs to be done but will probably not be able to figure out why it needs to be done and it will definitely not be able to definitively figure out edge cases for when to do it / not do it

As long as you focus on implicit stuff, you will be fine for a little bit

TL;DR - become good and keep being good at being the person who understands the implicit external drivers of software dev

Absolutely true, many things will continue to improve in significant ways. However, if we look at the modern history of rapid disruptions driven by technology (a side interest of mine), persistent patterns emerge. Similar to avalanches or flash floods, such periods of very rapid disruption are often triggered by one or more significant breakthroughs in certain technologies. Early rates of change tend to be fast and furious but eventually begin to taper as recently unlocked low-hanging fruit is harvested and those racing through newly found terrain encounter all-new significant barriers and points of friction. Early in such periods, extrapolating the recent extraordinary rates of change forward has poor predictive power. Sudden extreme bursts tend to regress back toward the long-term trend line.

Arguably, the current disruption in LLMs can be traced to post ~2010 research slowly building to the 2017 transformer paper and the adjacent work it quickly inspired. So today is, arguably, mid or late-ish in the LLM rapid burst phase. The rate of fundamental, broad-based breakthroughs lifting all LLM applications has clearly slowed with many of the most impactful recent discoveries being in scaling, optimization, tuning and productization toward specific domains. That doesn't mean there can't be another transformer breakthrough tomorrow but, historically, black swans rarely travel in flocks.

Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.

https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r

Ironically, I don’t think tech support is going to be fully replaced by these anytime soon. That’s one place you definitely need to have actual people talking to other people. Lawyers and doctors are gonna be legally protected too because you still need a human to sign off on all those actions though we will probably need far fewer.

The first one-shot app was created with ChatGPT in June 2023 - 3 years ago. In my experience, the current result of one-shotting apps is just as bad today as it was back then.

What “full MVP app” are you talking about? I know of none that have been anywhere near production ready. With all due respect, I think you’re portraying fantasy as reality. I would love to be proven wrong.

Also MVP apps are great and all, but I've seen 0 evidence of actually useful software from all this tooling, if anything all the software I'm using has just become more buggy and less reliable over time

This is the case perhaps 95% of the time.

Oversight is very important, and architectural thinking cannot yet be outsourced, only execution.

This is domain expertise - software engineers are not needed for that. Ofc often senior sws are expert in it, but they aren't necessary.

Traditionally its been useful for frictionless production to have engineers to be able to do maybe 90% of their work without consulting the business experts but this is the whole crux of the moment TFA discusses - "tradition" is over.

In this new world its now the job of a senior engineer not to have this domain expertise themselves, but to know how to ensure the agents have it, or can acquire it and it be verifiably correct.

Senior engineers who hang on to the idea that their advanced business domain expertise makes them safe will soon be as dead in the water as juniors who haven't pivoted.

They are very good at writing code and debugging visible errors- but that's like 50% the harness.

My company also deals with a lot of complex regulations and domain-specific system implementations, which AIs used to struggle with. We were able to solve the problem with well-organized claude.md/agents.md files. On top of that we also implemented supermemory.ai, so newly made decisions are always recalled by AI agents when starting new sessions.

Would a skill which forces you and LLM to reach a shared understanding of the product features and the regulations those features are supposed to capture be of help here? The main idea is we provide documents to the LLM and it asks lot of questions which clear ambiguity and possible misconceptions the LLM might have. I would suggest please take a look at skills. They are really helpful.

https://www.youtube.com/watch?v=6BB6exR8Zd8

So there is a spectrum here, and i dont know what i dont know - meaning i can just be wrong. But we're both on that spectrum and are you sure its not a skill issue?

All of the specifics you list seems so fundamental that in similar projects I've inserted them straight into the AGENTS.md or a strong reference and where to look them up.

If you boil it down to it, you're quite literally saying the problem is the LLMs dont have access to a bunch of facts.

That’s my take on this, at least. I’ll never be very good at Scythe, or the most creative role-player, certainly never managed to do anything beautiful in pottery class (although the glazing is pretty).

That’s fine. I achieve enough in other areas ._.

So first off, I mean, of course you didn't, right? You had already learned most of what you were going to learn from this specific project by doing it by hand.

But yes, if you use AI to do projects that might have been at the edge of your abilities pre-AI, you will learn a lot less. The solution, I've found, is to get more ambitious until you're back to the edge of your abilities even with AI. You should be asking the agent questions like "has anyone tried?" and keep pushing until it isn't sure, and you're not sure you have any idea what you're doing. Then ask questions until you feel like you sort of know what you're doing, and verify your understanding by directing the agent to build.

I also don't fear for my job, but it's because I was already laid off 1.5 years ago, right at the start of this AI boom. :/

However, I love coding with the AI. I can get it to handle all the crap that I know what it should look like, but don't want to spend the time doing myself. Instead, I get to focus on making the thing work well and do what I want. I am so much happier coding with it than without it.

Now if I can just find a job to do it in, I'll be set. :/

Such fuzzy times...

I played with it a bit, and no, it doesn't! And I am talking as someone with limited music culture, musicians are likely to be even more critical.

For the first few tries, it sounds impressive and the tunes are catchy. It used to sound wrong in the background but they mostly (but not completely) fixed that. However, after a few dozen songs, it starts to always sound the same. It is all generic stuff, the songs tell no story, it is a bit like the kind of music that accompany corporate advertisement. You can try to be more precise in your prompt, but I never had any success, it will just ignore most of the details that could make your song interesting.

The most interesting result I had was actually when I managed to get it off rails, a bug more or less. I asked it to mix two very different genres together, and it made something unsettling in a way I don't remember hearing before. But as always, further working on it proved extremely difficult, as it always tried to go back to making generic stuff, ignoring the details you give it.

Suno can do remixes though. And it is a bit like with code. LLMs are very good at porting, when you already have something that works, it can make it work in another language. But if you just have an idea, it will screw up at anything original. If you want a LLM to implement your idea properly, you have to give it so much guidance that it amounts to writing the code yourself, while struggling with the ambiguousness of natural languages.

They don't "solve" execution.

If you're willing to push them enough, and put in place the system that they can actually get working code, they can solve execution - but that IS engineering!!

They are far from doing that by default now (replacing engineering).

Maybe in 3 years. They're moving fast.

But you can't ask them to build you a better Rust compiler, sit back and watch, and get a result today.

That is what takes determination and why you have to really care about the thing you are trying to sell to people. You have to stick to it before they will stick to it.

https://x.com/chamath/status/2033385903520129161

> I think a great example of what probably will happen is found in Suno, the AI Music thing. I don't know if y'all have tried it, but it now produces really good stuff. What's happening there? A lot of people play with their own little universe and get tired quickly, move away from it, and only a few prolific creators stay and turn it into a "job like" environment.

https://en.wikipedia.org/wiki/Sturgeon%27s_law

Sturgeon's law states, "Ninety percent of everything is crap". The adage was coined by American science fiction author and critic Theodore Sturgeon while defending the merits of the genre. Sturgeon observed that most works in any field were low quality. Therefore, science fiction was not uniquely inferior.

Steve Jobs didn't mean "writing good code" as "execution", he meant "making things that align with how people want to use the product". Frontier LLMs are not solving Steve Jobs-level execution (even in the near future) because what that would mean understanding human nature – something that Steve Jobs or Henry Ford were much better than most in the industry today, so at best we're going to see LLMs making things that are as good as the majority of products. Because AI does not see whether something is perfect-according-to-Steve-Jobs or merely good-code-according-to-engineering-practices.

In this case, it's difficult for me to see what exactly is gained by offloading all of those decisions to a mean regression algorithm. I agree it's a fun toy, but I can't imagine actually listening to or deeply enjoying any song made with these music models.

I could imagine it being used successfully in some targeted part of the process. For example, manipulating drums or changing the timbre of some previously recorded instrument. In that case it's not much different than traditional music creation tools like sampling.

Good ideas are expensive. They're expensive because you have to weed through all the bad ones to identify them, find a market, and turn them into a product. You don't know that from the start, which is why the landscape is littered with millions of dead projects from thousands of dead companies.

Even if the execution were cheap and implementation were perfect, if the starting idea was bad, it's all been a waste.

Ideas aren't cheap, because bad ideas are expensive and good ideas cost money to vet.

As an information architect I find it amazing it works so good, but is useless to me except being a great think to play with… a toy really. I’m much more fascinated by Strudel.cc and LLMs do a great job to educate me into it, myself being mostly an autodidact.

As a dev I struggle to maintain coherence with Claude Code even though I’ve piped more than 10b tokens since Jan. Certain trivial stuff is easily remedied but even more devil lives in abundance of details now. So the task moves one level above in terms of abstraction, but is not solved.

If guys were good at typing one and the same thing in one and the same lang, which is nothing wrong about given how crafts went for ages, then they will be struggling to compete with the GPTs. But if they are in the architectural and operational perspective … well - work and demand just increased, so please stop whining.

Does it? It produces passable stuff that is fine. However the lack of passion and care completely disinterests me.

It's great that people find joy in it, but as someone that is critical of both music production and fidelity, the current offerings fall incredibly short of anything I would ever want to listen to.

It is the whole business flow chain of value to the end user what is valuable.

Suno doesn't make music, it makes simulacra of music. Music is only made by humans.

No. I assumed that at best it will be not better than average human-made music available to listeners.

> but it now produces really good stuff.

Does it? Do you have examples?

(note: I actually do not care about all "hand-made" and have no preference for once-off over serially made products)

The same is true for LLMs. You can get Claude to spew 2,000 lines of garbage in 15 minutes, but the number of developers actually willing to sit there and reason over the output and make the tweaks--often very minimal tweaks--that make it go from 90% correct to 100% correct are vanishingly few. And it's typically just laziness and a lack of any kind of genuine interest in the field.

If there is any skill in consistent demand it is the ability to wrap your head around the new work, new processes, new people, whatever it all may be.

For me, understanding and development of this skill into a keen tool happened while I worked as a prototype mechamic. For those unfamiliar, a prototype mechanic does what it takes to make often demanding parts on consistently short timelines week after week.

Metals, plastics, you name it.

One gets good at ramping up on processes, machine tools, materials. And after doing that for a while, you end up able to very rapidly absorb new info and understand work far more quickly and accurately than many.

Anyone can start this.

Just get curious and build things. Then build more things.

Share your builds and build things other people want made!

Overall society feels more turbulent, but this is otherwise all the same song and dance all over again.

The 90s and 00s had this wave of "object oriented programming changes everything". Hey we're doing this thing that's been done successfully 100s of times before, but now it's OO. Writing some code in involving an airplane? Just purchase this omni-airplane object that does everything for airplanes (an actual thing I was told in college).

That's weird OO isn't the be all end all? Code gen, get this Ruby on rails running. Look at me building this website in two seconds. Code gen everywhere.

Huh, that's going to a funny place... TDD. If you aren't TDDing then you're such a bad engineer that you should be locked in prison (real conversation I observed). Oh wait, not TDD, BDD. That fixes it.

Lean, no Agile, no agile like with a small a ... but it was first, no scrum, no xml wait that was last decade, json, and finally SAFe.

Hey, have you seen this chat bot thingy?

Every iteration brings good stuff if you're paying attention. But it also brings a lot of hype and anxiety. Experiment and learn.

The one thing that's remained constant for me is that nearly everyone would rather die than to think carefully about the consequences of their dreams coming true. And as long as that remains true they'll continue to pay for someone else to ride the hype dragon on their behalf.

Except the entire value proposition of these tools is that there is no skill or mastery to be built.

The entire slop factory workflow, or sorry I mean "AI-native" workflow is:

"Woah, I cajoled a chatbot into building something I don't understand at all, I'm so good at my job!"

It's the participation trophy of building. Something else builds it, I take credit for it despite not understanding much about about it. There's no compounding return on my effort. No lessons learned. No understanding built. No insights gleaned for possible future innovation. No differentiation. Just mind-numbingly screaming into a void until the slot machine shits out some slop amalgam that seems "good enough", and then I do it all again the next day.

If that's the game, count me out. It's nice that others apparently enjoy it, I guess. But to think there's any sort of mastery here is delusion. The only requirement to be "successful" with these tools is to stop giving a shit and surrender to it.

But I used to enjoy learning - I think most of us did. The existential crisis many are experiencing is about the lack of fulfilment in rolling an LLM slot machine all day in an already dopamine depleting environment.

You can have the Big Boy LLM do _everything_. It can and it will do it. It will also cost fucktons of money and take a long time.

But if you build tools (with AI) that do as many tasks in the process deterministically as possible and let the AI use those, it'll be a lot faster and cheaper to run it.

As a bonus you can eventually drop the expensive cloud AI and run a small/medium sized local model instead.

For those unaware, Jenkins (Hudson), is a CI server that supports all sorts of pipelines. Those pipelines can very easily be turned into huge balls of mud by putting logic in them. The proper way to do it is to put that logic into simple scripts and tools and have Jenkins just do high level orchestration.

None of this comes out of the box atm, but it's not clear that it's not possible.

fooBar() and fooBarExtended()

The latter had additional params and functionality that was needed for the current problem.

Instead of calling that function though Claude kept trying to add in the same extended params to the first function

Even after telling it not to do that it kept suggesting the same thing again later, its so annoying sometimes

The open question for me is whether too much code is actually a problem.

These tools are a fact of life now. If we can solve problems or debug faster, and the software is less buggy, than it's not too much lines of code, it's just right.

There was an entire thread a week ago about how domain expertise has always been the real moat: https://news.ycombinator.com/item?id=48340411

I'm old enough to remember the dot-com crash, specifically the years afterwards. In 2002-2003, the unemployment rate of software engineers was something like 40%. In fact, the only reason it wasn't higher was because of the number of people who had permanently left the field to become plumbers (or other trades).

I think this is going to be worse. In the dot-com crash, what really happened is that non-businesses got funded and it basically the capital markets ceased to function to a large degree. That's not what's happening now. Yes, huge amounts of money are going into AI companies but the change is more structural.

Other industries have gone through this. In the 1980s a bunch of industries were intentionally destroyed or offshored in areas that have never recovered. This has continuing social, economic and political impacts. I think people are being naive here thinking this can't or won't happen in tech.

I'm not sure that's universally true. Good software engineers who are arrogant about easily acquired domain knowledge have been the downfall of many an ERP system.

There's SO much IT that's literally all about putting business rules into the system.

Partially disagree. Broad-strokes domain knowledge can be learned quickly, but honing that domain knowledge with nuance and consideration for complexity, particularly for organisations that are unique and are not often thought of as 'software development houses', can take years if not decades.

Yet I still see (and code review) 'professional' software developers that don't follow good software engineering practice.

> Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering.

The same is also true of engineers without domain knowledge, certainly in my experience. Maybe we just got unlucky...

Can it? I'm of the opposite opinion. You can improve methodology much faster than gaining specialized knowledge.

You can enforce and fast-track the former because it's a matter of approach.

The latter is subject to the person's learning affinity, capacity and availability at the time and can't be forced beyond reasonable facilitation. It also builds on itself, with the corollary that there's a much steeper curve early on.

With that said, there are still many SWE principles that are not fully internalized or adequately practiced by domain knowledge experts, and that will remain the case as much as domain knowledge remains valuable, because software engineering is yet but another domain.

If you’ve been lucky enough to get jobs that expose you to the right things then you have a big advantage when the interviewers are looking for those specific things instead of your generic abilities or potential. It feels nice because you’re competing against a much smaller pool of people.

Unless you are not lucky enough to have been exposed to those specific domains yet. You can be a great engineer and even someone who learns quickly, but if you can’t point to the lines on your resume that match the job description then nothing else matters when the interviewers are playing experience bingo with your resume.

The move to generic coding interviews changed that. It was no longer enough to say that you had exposure to a topic at a past job. You had to show your coding skills, too. It wasn’t enough to ride on your credentials any more, which was highly frustrating to the well-credentialed.

However if you didn’t have the exact experience then the world of job opportunities becomes much larger. The people I know who like coding interviews the most (other than the rare competitive programming enjoyer) are people who are highly talented but came from less credentialed backgrounds: They don’t have an amazing university on their resume, they had to work at some company you’ve never heard of in their small town, but they are great at programming and just want a chance to prove that so they can move up to better companies. They’re never going to be picked by a company that’s looking for exact domain experience, but as companies open up job listings to people without that exact experience they have a chance to prove themselves.

The other people who relied on that domain experience to lock other candidates out of the hiring process don’t like it at all, though.

What kind of domains did you have in mind?

The best people I've worked with were the people who learned the ins and outs of the business they were making software for, not the people who learned how to write code really well or read logs or learn software architecture patterns. Those people (and I've been one of those people) often go around looking for nails for their hammers rather than really focusing on the customer need.

It takes a really sharp brain to pick up and learn an area of expertise that has nothing to do with software development, and figure out how software development makes that domain better.

Applied to real world complex businesses good luck.

I’ve had people tell me I should try selling some of the furniture I make and my response is always that I made the mistake of turning a hobby into a career once, I don’t intend to make that mistake again, and at least software still pays pretty well.

I work with a guy who does decking (gardens, caravans, etc) and builds sheds, fences, things like that and he does very well indeed (he's also incredibly good at it to be fair)

A small percentage of the market, maybe a fraction of a percent, are still willing to pay for hand-built goods - bonus if it's thoroughly modern but retro (steam-punk keyboards, maybe).

Exactly zero percent of the market is willing to pay for hand-built software.

not woodworking. farming. get a pot of land and grow your own food. do not participate in economy at all. that's the only survival.

Right now non-tech people just think AI will do anything they want and are the one in charge of hiring/firing, managing, etc. It's horrible to be a software dev right now, you've to deal with AI and lunatics.

Of course Domain Knowledge is important but, right now it's very hard to have reasonable conversation because... you know... AI this, AI that. I had a customer showing me a Claude vibe coded atrocity trying to convince me it's was a great app, now ask yourself: How are devs even supposed to collaborate with this without going insane? Simple, you can't.

SQL was first released in 1973. More new SQL is being written today than ever.

C++ (1985) is the de facto standard implementation language for web browsers, JavaScript engines, networking stacks, telecommunications, video games, high speed trading, CAD/CAM, video rendering and editing, audio processing, filesystems, databases, hardware drivers, automotive, aerospace, and robotics, among others.

Is Rust making inroads? Sure, and it's a tiny fraction of C++ still. It's a long ways from being the standard.

Likewise, Python is often cited as the "AI language," but that's on the surface -- CUDA, tensor libraries, inference languages, GPU kernels, compiler stacks, and so on are usually C++.

Then there's C -- introduced in 1972. Still widely used for greenfield in kernels, device drivers, embedded systems and microcontrollers, filesystems, firmware, network stacks, cryptography, databases, compilers.

LaTeX, MATLAB, Erlang, Verilog, PostScript, Lisp (including Scheme and Clojure), shell scripting (and the UNIX paradigm itself)... the list of old tech that still sees new projects in 2026 goes on.

https://en.wikipedia.org/wiki/Computer_(occupation)

Calculators are not a replacement for accountants, online accounting services are in many cases. Which again can be run by an AI if they reach that level of reliability.

Today with LLMs this is still sci-fi, though.

But bread shops are available on every corner. Will software jobs become as common as bread shops? If yes, what happens to the salaries? Something to think about.

If we apply the same argument to software engineering I think it's a good point... just maybe not the one you intended to make.