idk, I'm not a software engineer. I'm a sysadmin.

Or, am I a "devops engineer"?

or.. a "SRE"...

or... am I a platform engineer?

You know what, I don't know.

What I do know, is that people keep trying to make my job obsolete, only to hire me under a different title for more money later. The practices and the tools are the same too, yet to justify it to themselves they'll make shit up about how the work is "actually, a material difference from what came before" (except, it's really not).

I'm still employable after 20 years of this.

I'm not a software engineer, and I'm not a tech CEO - I don't care, but people have been trying to replace me my whole career (even myself: "Automate yourself out of a job” is a common sysadmin mantra after all). Yet, somehow, I'm still here.

> "Automate yourself out of a job” is a common sysadmin mantra after all

Not just sysadmin. I've been automating the hell out of tedious mundane tasks that are done by error prone humans, and only become more error prone as they get tired/bored of these mundane tasks. The automation essentially just becomes a new tool/app for the humans to use.

At this point of my experience doing this, employees scared of automation are probably employees that aren't very good at their job. Employees that embrace this type of automation are the ones that tend to be much better at their job.

I try to once in a while but, for example, last time I ended up being instructed to make a bunch of changes to make the automated tool make all the little mistakes that were usually done during the manual process, so that if the process needs to be done manually, they wouldn't be confused. For example: Setting up a volume of a particular size, and then, so they wouldn't have to bust out a calculator, they put in a nice round number that's nice for them to write (lots of zeros), meaning it wastes space.

The point of the automated tool is to do it quicker and correctly, and remove the need for a calculator (which just involves dividing one number by 4096 at some point, really). But I had to re-fuck-it, and as a bonus, they never used it at all. I doubt any of my colleagues remembers it exists.

Each generation of young workers seems to need to learn for themselves that the class warfare is endless, and mundane.

Very helpful insight, thank you!

I really loath that part of this industry; I spent over a decade in it and the only tangible thing I've taken away from it is that the problems these philosophies and practices set out to solve are derivative of two things:

- Infrastructure is very often fundamentally disconnected from the product roadmap and thus is under constant cycles of cost control

- The culture of systems administration does not respond well to change or evolution. This is a function that is built around shepherding systems - whether at scale or as pets.

Long way of saying the gamut isn't that corporations will ever be free of systems administration any more than they'll be freed from software engineering. It is far easier to optimize software than it is to optimize infrastructure though, which is why it feels like someone is coming after you. To make matters more complex, a lot of software today overlaps with the definition of infrastructure.

Thank you for this, not only on the Ai-related discussion but painting the sense that sys admin work is still as complex and finnicky as it ever was. All we did with that role is let Amazon evangelize some weird taxing “standard” for hosting.

Same here, but this time is different. Truly.

Some of the easy jobs will be taken away and your job is not under threat. Right? But some of the people who were doing low skilled jobs will grow to compete with you. Less supply more demand. Either the pay will come down or there are very few jobs. Fingers crossed.

It always feels like “this time its different”.

NoOps, NoSQL, Heroku, PaaS, IaaS.

Maybe there are less people in operations than before, there are certainly some companies that do their best not to employ any operations focused people and use FaaS for everything and only hire feature developers… who, end up doing the operations work that crops up.

shrug

> Maybe there are less people in operations than before

Even that ended up not being true, and I'd argue we have even more people doing ops now than we did before all the buzzwords.

Going to change my job title to cockroach because no matter how many times companies and trends have tried to kill ops, I'm still around, and sometimes in larger numbers.

> But some of the people who were doing low skilled jobs will grow to compete with you.

Yes, and this is not shocking. This is how it is meant to work. You get a low level job because you're new and have a lot to learn. You learn more things as you work the low level job, and then you can get promoted or move to a new role that is not so low level. You keep growing until you eventually compete with the people that were senior level when you were working that low level job.

Many jobs aim to solve problems so well that there’s nothing left to fix — doctors curing illnesses, firefighters preventing fires, police reducing crime, pest control eliminating infestations, or electricians making lasting repairs. And that’s totally fine — people still have jobs, and when it works, it’s actually great for everyone.

> when it works

That’s a load bearing phrase

If you're like me, though, your day-to-day has probably shifted a lot.

My day used to be making sure desktops worked and we had a repeatable process to make new good desktops out of all the complex client software they needed.

Then I made sure servers got upgraded and patched and taken care of on a day-to-day level, although it was still someone else's job to keep desktops running. At home I compiled my own kernels and used tarballs to install and update packages. Desktop hardware support was iffy in Linux.

Then I jumped to borg and tupperware and kubernetes where hardware never mattered and it almost didn't matter what clients had because the browser they used auto-updated. At home I switched to distros where package management was automatic and rarely, if ever, broke.

I don't even know the hostnames or the network addresses of the hardware that runs my services, and AWS or GCP SREs probably rarely need to know either. Now I care about an abstract thing called a service that is instrumented with logs, metrics, and traces that would put the best local development tools of 20 years ago to shame. CI/CD and infrastructure as code pipelines actually did automate away many of the checklist-style sysadmin work of the past. At home I could run Talos and Ceph and Crossplane if I wanted to but so far I've dragged the old days of individual hosts along mostly for nostalgia.

I expect to eventually end up caring about systems at an even more abstract level once something like Crossplane becomes as universal as Terraform and GitHub actions. They'll probably run on something like web assembly on bare metal because no one actually cares what's underneath their containers if they keep working.

The stack of technology gets taller and more abstract and as it does so the job of caring about the lower layers gets automated and the lower layers get, if not simplified, standardized to the point that automation is more reliable than human intervention.

Humans will only get squeezed out of the loop when superhuman artificial intelligence arrives and our abstract design and management of systems becomes less reliable than the automation. Then hopefully we get a nice friendly button to push for more automatically-human-aligned utility.

EDIT: That's not to say that the lower levels can be automatically designed; not yet at least. Eventually once AI is good enough at formal design then quite likely. We still need low-level software engineering to keep building the stack but it is vastly more commoditized (the one open source developer in the xkcd cartoon keeping 99% of the world's infrastructure running on a 20-year old tool/utility)

>Then you have tech employees who want to believe they’re irreplaceable. It’s easy to want to keep working how we’ve always worked with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.

Eventually, things will stabilize to a point where we will know what the boundaries of all the new LLM based tooling is good for, and where humans add lots of value to that.

That will then drive a maximalist hiring spree, as the more people you have working at an increase in velocity, the faster you ship, and for once, perhaps the quality of code won't substantially decrease, assuming LLMs improve another few leaps in output quality and engineering workflows adjust in a normalized way.

Thats the hopeful side of the equation anyway.

I feel incredibly bad about customer oriented jobs, like white glove customer service. I already saw a trend (especially since 2020 but certainly before as well) where these AI chat bots and AI support lines will decimate that job category. These are pretty common white collar jobs, lots of people even in our industry got their starts on support lines.

I don't think any normal customer is going to want to talk to AI, once the novelty wears off. It's going to be "Let me talk to your supervisor" almost every time.

Maybe. It all depends on whether the AI can actually solve your problem.

Yeah, if the AI isn't shite and has access to tools to solve my problem, I'll take it over some overworked and undermotivated human call center any day.

Co I work for creates customer support software, so naturally we have some AI solution available to people.

A lot of our customers (aka businesses deploying our customer support software for their customers) are telling us people fucking hate dealing with AI in literally any capacity, even if some of the stuff we offer actually works quite good (FAQ bots, bots that redirect to the proper channels/teams and stuff like that). The C-suite at my company have had to go back on some of their OKRs of late, because after an initial huge bump of AI usage, clients are starting to kill off the AI tooling and our usage numbers are dwindling because their customers hate it.

I get to see some of the chats people have with the AI systems, and people will straight up say slurs in chats because they know it's the quickest way of escalating to an actual human lol. People really don't like this crap, but of course CEOs and their ilk are usually psychopaths so they don't really give a shit if it means they can save 5 cents per user.

That’s just like, your opinion man.

Oh, but there’s something called “containment” that you measure and optimize on your chatbots.

> the more people you have working at an increase in velocity, the faster you ship

That sounds like a contradiction to Brooks's law, which I don’t see being invalidated by AI tooling.

Also judging by my LinkedIn, but all the senior tech execs on the job market are now Generative AI Experts, which is funny because I thought they were all Cryptocurrency Experts when I last saw them posting this much in 2020.

The best is when you work with one, in a small enough company. During which they extoll some currently-hot grift, and then after the company goes under (maybe not due to thier poor leadership), you read about their huge successes there! Much win.

This rhymes with the guys I am currently observing.

Former cloud data lake enterprise architecture & agile development experts as well.

True Renaissance Men.

> you have [ ... ]. then you have [ ... ]

Those are groups defined by something other than actual LLM usage, which makes them both not particularly interesting. What is interesting:

You have people who've tried using LLMs to generate code and found it utterly useless.

Then you have people who've tried using LLMs to generate code and believe that it has worked very well for them.

I think this is an easy thing to wrap my mind around (since I have been in both camps):

AI can generate lots of code very quickly.

AI does not generate code that follows taste and or best practices.

So in cases where the task is small, easily plannable, within the training corpus, or for a project that doesn't have high stakes it can produce something workable quickly.

In larger projects or something that needs maintainability for the future code generation can fall apart or produce subpar results.

LLMs also don’t always generate code that works.

And you don’t always know or understand what the product owner wants you to build.

Writing code faster is very rarely what you need.

That about sums it up from my experience as well. But as parent said, such takes unfortunately don't get a lot of eyeballs :(

That was four short paragraphs with basically no details - there's basically nothing for eyeballs to see. If I wrote a history of the world that consisted of "Some people lived and died, some of them were bad, I guess", how many copies do you think I'd sell? Any? What's interesting is the details, and a post giving actual detail of building some app, and the benefits and shortcomings of a specific tool would be of great interest to many. If I ask an LLM to save the date to the database, and then ask it to save the time, do I get two variables in two columns? Does that make sense for my app? Do I have to ask it to refactor? Is it able to do that successfully? Does it drop tables during program initialization? How does the latest model do with designing the entire program? How often does it hallucinate for this set of libraries and prompts? There's quite a bit of variance! If it hallucinated libraries and APIs left and right it would be far less useful. Some people don't even get hallucinations because their prompts are so we'll trod. There are all sorts of interesting details to be learned and shared about these new tools that would get a ton of eyeballs.

I've just seen that change happen in the a pet project within less than 10 hours of work.

I tried vibe-coding something for my own use, your classic "scratch your own itch" project.

The first MVP was a one-shot success, really impressive.

But as the code grew with every added feature, progress soon slowed down. The AI claimed to have fixed a bug when it didn't. It switched chest several timea back and forth between using a library function and rolling its own implementation, each time claiming to have "simplified" the code and made it "more reliable". With every change, it claimed to have "improved" the code, even when it just added a bunch of shamelessly duplicated shit.

One effect I am sure AI will have is to massively excarbate the phenomenon of people who quickly produce a large amount of shitty, unmaintainable code that fulfills half the requirements, and then leave the mess behind for another greenfield project.

We’re so unaccustomed to working with non-deterministic computer tech that rather than acknowledge they are hit-or-miss, everyone just picks one side and goes all-in on it.

Which sounds an awful lot like politics.

> We’re so unaccustomed to working with non-deterministic computer tech

The whole history of computer history is about making computing deterministic, after we found out that having generative anything (Recursion, Context-Free grammar,...) is a double-edged sword. So for any known set of inputs, you want the output to be finite and non-zero, and all items having the correct properties.

All of physics was like that until QM

"non-deterministic" is a weird way to say "mangles data 1/3 to 1/2 the time"

Recent LLMs are fairly good at following instructions, so a lot of the difference comes down to the level of detail and quality of the instructions given. Written communication is a skill for which there's a huge amount of variance among developers, so it's not surprising that different developers get very different results. The relative quality of the LLM's output is determined primarily by the written communication skills of the individuals instructing it.

It seems to me If you know all these instructions clearly, then you know everything, and it's easy for you to write the code yourself, and you don't need an LLM.

The amount of typing it takes to describe a solution in English text is often less than the amount of typing needed to actually implement it in code, especially after accounting for boilerplate and unit tests. Not to mention the time spent waiting for the compiler and test harness to run. As a concrete example, the HTTP2.0 spec is way fewer chars long than any HTTP2.0 server implementation, and the C spec is way fewer chars long than any compliant C compiler. The C++ spec is way, way fewer chars long than any compliant C++ compiler.

>The amount of typing it takes to describe a solution in English text is often less than the amount of typing needed to actually implement it in code

I don't find this to be true. I find describing a solution in English well to be slower than describing the problem in code (IE, by writing tests first) and having that be the structured data that the LLM uses to generate code.

Its far faster, from the results I'm seeing plus my own personal experience, to write clear tests which benefit from being a form of structured data that the LLM can analyze. Its the guidance we have given to our engineers at my day job and it has made working with these tools dramatically easier.

In some cases, I have found LLM performance to be subpar enough that it is indeed, faster to write it myself. If it has to hold many different pieces of information together, it starts to falter.

I don't think it's so clear-cut. The C spec I found is 4MB and the tcc compiler source code is 1.8MB. It might need some more code to be fully compliant, but it may still be smaller than 4MB. I think the main reason why code bases are much larger is because they contain stuff not covered by the spec (optimization, vendor-specific stuff, etc etc).

Personally I'd rather write a compiler than a specification, but to each their own.

Use shorter variable names

Yea this! How many devs say "it doesn't do what i expect" did not try to write up a plan of action before it just YOLO'd some new features? We have to learn to use this new tool, but how to do that is still changing all the time.

> We have to learn to use this new tool, but how to do that is still changing all the time.

so we need to program in natural language now but targeting some subset of it that is no learnable?

and this is better how?

Corpus also matters. I know Rust developers who aren't getting very good results even with high quality prompts.

On the other hand, I helped integrate Cursor as a staff engineer at my current job for all our developers (many hundreds), who primarily work in JavaScript / TypeScript, and even middling prompts will get results that only require refactoring, assuming the LLM doesn't need a ton of context for the code generation (e.g. greenfield or independent features).

Our general approach and guidance has been that developers need to write the tests first and have Cursor use that as a basis for what code to generate. This helps prevent atrophy and over time we've find thats where developers add the most value with these tools. I know plenty of developers want to do it the other way (have AI generate the tests) but we've had more issues with that approach.

We discourage AI generating everything and having a human edit the output, as it tends to be slower than our chosen approach and more likely to have issues.

That said, LLMs still struggle if they need to hold alot of context. For instance, if you have a bunch of files that it needs to understand to also generate code that is worthwhile, particularly if you want it to re-use code.

>Corpus also matters. I know Rust developers who aren't getting very good results even with high quality prompts.

Which model were they using, out of interest? I've gotten decent results for Rust from Gemini 2.5 Pro. Its first attempt will often be disgusting (cloning and other inefficiencies everywhere), but it can be prompted to optimise that afterwards. It also helps a lot to think ahead about lifetimes and explicitly tell it how to structure them, if there might be anything tricky lifetime-wise.

No idea. I do know they all have access to Cursor and tried different models, even the more expensive options.

What you're describing though, having to go through that elaborate detail really drives to my point though, and I think shows a weakness in these tools that is a hidden cost to scaling their productivity benefits.

What I can tell you though both from observation and experience, is that because the corpus for TypeScript / JavaScript is infinitely larger as it stands today, even Gemini 2.5 Pro will 'get to correct' faster even with middling prompt(s) vs for a language like Rust.

I do a lot of work in a rather obscure technology (Kamailio) with an embedded domain-specific scripting language (C-style) that was invented in the early 2000s specifically for that purpose, and can corroborate this.

Although the training data set is not wholly bereft of Kamailio configurations, it's not well-represented, and it would be at least a few orders of magnitude smaller than any mainstream programming language. I've essentially never had it spit out anything faintly useful or complete Kamailio-wise, and LLM guidance on Kamailio issues is at least 50% hallucinations / smoking crack.

This is irrespective of prompt quality; I've been working with Kamailio since 2006 and have always enjoyed writing, so you can count on me to formulate a prompt that is both comprehensive and intricately specific. Regardless, it's often a GPT-2 level experience, or akin to running some heavily quantised 3bn parameter local Llama that doesn't actually know much of anything specific.

From this one, can conclude that a tremendous amount of reinforcement for the weights is needed before the LLM can produce useful results in anything that isn't quasi-universal.

I do think, from a labour-political perspective, that this will lead to some guarding and fencing to try to prevent one's work-product from functioning as free training for LLMs that the financial classes intend to use to displace you. I've speculated before that this will probably harm the culture of open-source, as there will now be a tension between maximal openness and digital serfdom to the LLM companies. I can easily see myself saying:

I know our next commercial product (based on open-source inputs) releases, which are on-premise for various regulatory and security reasons, will be binary-only; I have never customers looking through our plain-text scripts before, but I don't want them fed into LLMs for experiments with AI slop.

Yes, and also writing for an LLM to consume is its own skill with nuances that are in flux as models and tooling improves.

You're not wrong, in July 2025. But it will get better, and it will not stop getting better when it reaches equal-to-the-best-human level.

yeah and if my airplane keeps accelerating at the rate it does when taking off, it would reach the speed of light in a few months.

"this software doesn't work but if we 10x the resources in r&d a couple more times surely it will" is quite the argument to be seen making in public

No, but I think you're wrong. My child grew 3 inches in the last year alone, according to his latest physical.

If I were to adopt your extrapolation methods, he'll soon not only be the tallest human alive, but the tallest structure on the planet.

I think there is a strong case that experienced developers can not be replaced by AI anytime soon. Where the danger lies is for junior developers fresh out of college. How are they supposed to become experienced developers if an AI can do the grunt work they normally get assigned?

It really doesn't help that AI companies are hype machines full of salesmen trying to hype up their product so you buy it. There have been a lot of amazing AI "success stories" that don't hold up under scrutiny.

> Where the danger lies is for junior developers [...] if an AI can do the grunt work they normally get assigned?

Just because "well, maybe true for junior devs!" is a compromise over "AI will make all programmers obsolete!" it doesn't make it reasonable. It's still an extraordinary claim.

I think the problem with this one is that LLMs are somehow both unreasonably effective as well as unreasonably ineffective. Letting the code editor llms do their suggestions, I’ve gotten a ton of useless boilerplate garbage suggestions, but periodically, a couple times of day, it suggests blocks of code that are far more complete, comprehensive and correct than it has any right to be.

Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot; how much consideration you give to either outcome (focus on the random instances of brilliance, or the constant stream of bullshit) drives the final perception.

That has been my experience too. I recently turned it all off because I decided the amount of times it takes me 5x longer to accomplish something, in addition to the subtle increase of bugs, is not currently worth it. I guess I'll try it again in a few months.

> Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot

I have heard theories from people--whose ideas I don't ordinarily consider to be in the realm of purely uninformed speculation--that this can vary depending on system-wide GPU load, and is throttled accordingly based on real-time demand by the major LLM providers.

Whether it's true, I have no idea.

Sounds like conspiratorial thinking to come to terms with the fact that LLMs are fundamentally non-deterministic text predictors. You can get dramatically different responses to the same question, and that’s just how the system works.

That was my reaction as well, but I wondered.

Or are those people biased by what they want to be true because of their current situation (the dev who dont wanna change how they work and therefore wants AI to not work or the non-technical person who dont wanna learn to code or be dependent on a developer and therefore want it to work)

And then you have research that says they're both full of shit. The article is perhaps a bit shallow, but it's spiritually correct: there's a lot of uncertainty and people who claim they figured it all out are mostly spewing nonsense.

I mean it's working for me. It's definitely not living up to the hype IMO (market is way overvaluing), but I wouldn't want to work without it any more, which is actually saying a lot.

This take is as a senior (greybeard) developer using paid claude-code in the terminal only (I use plain vim for my own code). I'm running my own business while wearing all of the hats, so I'm not as worried about becoming obsolete, but I also have zero motivation to get other businesses using it (I'm not invested into any AI companies)!

To be honest, I could probably even be using it better, but I haven't spent much time yak shaving over my setup beyond zen mcp.

That being said, I think anyone looking to invest into established AI companies right now is in for a rude awakening. I think it'll be a commodity / utility like cloud computing with tons of competition and not a ton of differentiating features. That's just my opinion though, and I could be horrendously wrong!

I'm also seeing benefits, and I'm on pretty much the same stack as you. The METR paper I'm citing was misquoted a lot (N was small, and it wasn't a favorable setup for AI tools), but the most important finding was that it's very easy to fool ourselves about productivity benefits.

Am I going to cancel my Anthropic subscription? Certainly not, but I'm not going to pretend like my setup is The One True Way. The plural of anecdote isn't data. Nobody has this figured out, nobody.

AI is glorified autocomplete. Look at what happens when AI tries its hand at writing legal briefs, and you'll understand why it cannot possibly replace software developers.

That may be true. But it's pretty great at generating lines of questioning for cross-examination.

I wonder to what extent a non LLM system with access to the same original corpus of text would do, with some simple similarity search feature across the corpus?

As with all uses of current AI (meaning generative AI LLMs) context is everything. I say this as a person who is both a lawyer and a software engineer. It is not surprising that the general purpose models wouldn't be great at writing a legal brief -- the training data likely doesn't contain much of the relevant case law because while it is theoretically publicly available, practicing attorneys universally use proprietary databases like Lexis and WestLaw to surface it. The alternative is spelunking through public court websites that look like they were designed in the 90s or even having to pay for case records like on PACER.

At the same time, even if you have access to proper context like if your model can engage with Lexis or WestLaw via tool-use, surfacing appropriate matches from caselaw requires more than just word/token matching. LLMs are statistical models that tend to reduce down to the most likely answer. But, typically, in the context of a legal brief, a lawyer isn't attempting to find the most likely answer or even the objectively correct answer, they are trying to find relevant precedent with which they can make an argument that supports the position they are trying to advance. An LLM by its nature can't do that without help.

Where you're right, then, is that law and software engineering have a lot in common when it comes to how effective baseline LLM models are. Where you're wrong is in calling them glorified auto-complete.

In the hands of a novice they will, yes, generate plausible but mostly incorrect or technically correct but unusable in some way answers. Properly configured with access to appropriate context in the hands of an expert who understands how to communicate what they want the tool to give them? Oh that's quite a different matter.

> As with all uses of current AI (meaning generative AI LLMs) context is everything.

But that's the whole point. You can't fit an entire legal database into the context, it's not big enough. The fact that you have to rely on "context is everything" as a cope is precisely why I'm calling them a glorified autocomplete.

That's OK, I am also glorified autocomplete

Maybe it's too soon to say that autonomous LLM agents are the wave of the future and always will be, but that's basically where I'm at.

AI code completion is awesome, but it's essentially a better Stack Overflow, and I don't remember people worrying that Stack Overflow was going to put developers out of work, so I'm not losing sleep that an improved version will.

The problem with the "agents" thing is that it's mostly hype, and doesn't reflect any real AI or model advances that makes them possible.

Yes, there's a more streamlined interface to allow them to do things, but that's all it is. You could accomplish the same by copy-and-pasting a bunch of context into the LLM before and asking it what to do. MCP and other agent-enabling data channels now allow it to actually reach out and do that stuff, but this is not in itself a leap forward in capabilities, just in delivery mechanisms.

I'm not saying it's irrelevant or doesn't matter. However, it does seem to me that as we've run out of low-hanging fruit in model advances, the hype machine has pivoted to "agents" and "agentic workflows" as the new VC-whetting sauce to keep the bubble growing.

I don't want to blame Alan Turing for this mess, but his Turing Test maybe gave people that idea that something that can mimic a human in conversation is also going to be able to think like a human in every way. Turns out not to be the case.

Well, I agree with you. But I'd be remiss not to say that this is a lively controversy in the world of cognitive science and philosophy of mind.

To one camp in this discursive space, who of course see themselves to be ever the pragmatists, the essence of the polemic about whether LLMs can "think" is not about whether they think in exactly the same ways we do or capture the essence of human thinking, but whether it matters at all.

Well, it's an interesting question. I'm not sure we really know what "thinking" is. But where the rubber meets the road in the case of LLM agents is whether they can achieve the same measurable outcomes as a human agent, regardless of how they get there. And it seems not at all clear how to build those capabilities on top of an admittedly impressive verbal ability.

It may be because I've a writer/English major personality, and so am very sensitive to the mood and tone of language, but I've never had trouble distinguishing LLM output from humans.

I'm not suggesting anything so arrogant as that I cannot be fooled by someone intentionally deploying an LLM with that aim; if they're trained on human input, they can mimic human output, I'm sure. I just mean that the formulations that come out of the mainstream public LLM providers' models, guided however they are by their pretraining and system prompts, are pretty unmistakably robotic, at least in every incarnation I've seen. I suppose I don't know what I don't know, i.e. I can't rule out that I've unknowingly interacted with LLMs without realising it.

In the technical communities in which I move, there are quite a few forums and mailing lists where low-skilled newbies and non-native English speakers frequently try to disgorge LLM slop. Some do it very blatantly, others must believe they're being quite sly and subtle, but even in the latter case, it's absolutely unmistakable to me.

Why don't Tech CEOs and CTOs see how AI is going to "disrupt" their jobs? If anyone can write code, why will I hire your company to create the software I use?

I also see the non-development jobs as much more in peril from AI; I can go generate marketing copy, HR policies, and project plans of comparable (or better!) quality today.

Because it's meant to be a psyop more than a reflection of reality.

> It’s easy to want to keep working how we’ve always worked

There is no “how we’ve always worked”; there was no steady state. Constant evolution and progressive automation of the simpler parts has been the norm for software development forever.

> with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.

It doesn't, though. Productivity multipliers don't reduce demand for the affected field or income in it. (Tight money policies and economic slowdowns, especially when they co-occur, do, though, especially in a field where much of the demand and high income levels are driven by speculative investment, either in startups or new ventures by established firms.)

it has devalued the labor. i scoped a contract but they want me to do it in less time now that we have AI. this lets them pay me less for the same work. and AI CEOs sell it as "society will do less work" but instead now i'm expected to do more work because the work takes less time. same as it ever was with technology advances.

Look, maybe I’m saying the quiet part out loud, but if software engineering isn’t where the money is at anymore, and those jobs go away, I’d be competent at something else. I’m a smart person. I work hard. I’m confident I’d be able to displace someone who isn’t as smart as me and just “take” their job.

There’s going to be a need for smart people with a good work ethic unless literally everyone loses their jobs, and at that point we’re living past the singularly event horizon as far as I’m concerned and all bets are off.

(Note: This is an American take, and uses software jobs as the primary example, but a lot of this applies to other jobs)

Yes, well said - with one caveat: "Money and social status" is subtly but crucially different from "livelihood". You correctly identify the group of people whose lives are affected, but lump those people along with CEOs and AI companies under the umbrella of "money and social status" in your summarization, which maybe undersells the role of the masses in this equation.

The software job - traditionally one of the few good career options remaining for a large chunk of Americans - is falling. There are many different reasons, and AI, while not the apocalypse, is a small but crucial part of it. We need to get over the illusion that a large piece of that fall consists of wildly luxurious incomes reducing to simply cushy incomes - "boo hoo", we say, sarcastically. But the majority of software folks are going from "comfortable" to "unhappy but livable", while some are going from "livable" to "not livable", while others are no longer employed at all. There were already too many people across the job spectrum in these buckets, and throwing another gigantic chunk of citizens in there is going to eventually cause big, bad things to happen.

We need to start giving a shit about our citizens, and part of that is avoiding the implication that just because something disruptive is inevitable, doesn't mean the affect isn't devastating and we should just do absolutely nothing about the situation. Another part of that is avoiding the implication that the average person can just successfully change careers without enormous suffering. We can ease, assist, REGULATE (which the party in power would like to make illegal), etc. It's important to understand that none of that means "stopping" AI or something ridiculous like that.

We need to start giving a shit about our citizens.

A third time: We need to start giving a shit about our citizens.

And sorry, most of this was not directed personally at you. Just the first note about your wording.

Thank you. This is the most accurate take of what’s going on. Though the overwhelming population of people aren’t CEOs. It’s people.

That’s why the sentiment among most people and also HN is highly negative against AI. If you’re reading this you likely have that bias.

There are also a large number of people who have a deep-seated philosophical objection to the entire project of ai. It's not just about their job, it's about their sense of who and what they are as a human being, their soul or whatever. They will insist that AI's do not think or know anything, no matter what evidence there is to contrary.

Everyone has an agenda. Similarly, groups like r/singularity and the rationalists have spent years predicting the oncoming advent of a machine god, and are desperately reading too much into every LLM advancement.