[mrinfinitiesx]

I think the enterprise stuff is programmers become more tool-assisted, so fewer programmers are needed. A team of two seniors and 6 juniors can just be two seniors. As you said, it's mostly breaking down a problem and knowing what's needed, then telling it what components are needed. 'Make me a function that does this and that' I use it all the time to make things I know I can make but it makes it, if it makes it a weird way I modify the prompt to tell it not to make it that way. Good for frameworks for skeleton code and simple hacking things together at sysadmin level and tinkering with things. Not sure about full fledged program projects though.

Helps devs get 'unstuck' if they get the writers block. It's absolutely changing the game for marketing, bizdev, and programmers now. Intel layoffs ~20,000, IBM ~24,000. Kind of scary.

Smart people with better tools can be a dominant force. So, yeah programmers might be looking for newer skillsets.

Operations and Sysadmins I don't forsee ever changing, especially with AI.

As you said, will be interesting to look back in five years and see.

[al_borland]

I did see a take from someone (it may have been Alan Kay, but I could be misremembering) who said no one should layoff programmers due to AI. If AI makes programmers more productive, and everyone is getting it, they will need everyone to keep up with the competition.

2 seniors + AI may be able to have the same output at the 2 seniors + 6 juniors you mention. But if their competitors keep all those people and add AI, will they accelerate past the company when the layoffs by moving faster? Cost savings aren’t so great if they are at the expensive of remaining competitive in the market and retaining customers.

This is the perspective I hope takes hold. I think the layoffs you mentioned from Intel and IBM were very premature, if AI was the only basis for them.

[packetlost]

AI was absolutely not the basis for the layoffs at Intel, they are doing bad full stop. I don't know enough about IBM, but I strongly suspect that one is more influenced by macroeconomic conditions and general slowing down of the economy than anything else and AI is the convenient excuse to point to.

> If AI makes programmers more productive, and everyone is getting it, they will need everyone to keep up with the competition.

This assumes that there's competition. When money is expensive to borrow, companies stop throwing shit at the wall and seeing what sticks, they start being more conservative with where they expend their capital. Efficiency will absolutely be the name of the game for 2-3 of the next 5 years. I don't really see AI being a huge part of it. Writing code doesn't take up the majority of my time as a senior engineer.

[smegsicle]

jevons paradox

[fragmede]

try https://github.com/OpenInterpreter/open-interpreter. sysadmining stuff just got a whole lot easier. I've been admining Linux systems for over two decades, but I give LLMs a shot at dealing with some stupid Unix shit so I don't have to. it won't get 100% of the problems, but I can ask it to fix the mess made of, say, my system SSL certificate authorities, and it won't judge me for saying SSL and not TLS and it'll go off and try the first couple of fixes it basically the same way I would, saving me time while I work on something else.

[pram]

I've had very mixed experience with LLMs (Perplexity) and sysadmin stuff. More often than not I ask questions for specific CLI invocations and it will literally just make stuff up. This is even after (supposedly) Googling the documentation and analyzing it.

Even today I got terrible advice from Claude about calling Close() on a database in Golang. This kind of stuff would screw over a junior Dev who didn't know better:

"You're right to question this, and I apologize for the oversight in my previous response. Let me clarify: If you're using a connection pool (which is typically the case with sql.Open), you generally don't need to (and shouldn't) call Close() on the *sql.DB object after each operation."

I feel like all AI is doing atm is giving me extreme paranoia from being gaslit so much lol

[kemotep]

My work is trialing Microsoft’s Copilot for 365. So I have a built in chatbot in teams to ask various questions among other features.

Asking about specific Microsoft documentation it will just immediately bail and tell me to look that up on my own because it was built on training data up to 2022 and may not be fully up to date on the latest documentation. It won’t even link to the page last time I tried. It makes up PowerShell commands and suggested completely out of date options.

So Microsoft’s own AI assistant cannot even provide accurate information about the Microsoft products it is integrated with let alone anything else.

It can be useful for a short script but anything beyond that it is slower and less reliable than doing things myself.

[fragmede]

I don't disagree. There's still value in having eg Linux sysadmin skills, because the LLM still doesn't always get to the solution, but I kick off the job and come back a bit later and don't need to try the basic stuff myself, which means I spend more times on the harder problems.

For some reason I don't run into hallucinations as much as other people seem to, assumedly because I'm on well trod paths, but being lied to like that is always a fear. I asked it about argocd and it told me there is a command line program for it and I didn't believe it and had to Google it for myself, which didn't save me time or energy, but I got to ask it how to do things instead of hooting hoping the documentation had the right example.

[0xjnml]

Except AI was correct this time.

"It is rare to Close a DB, as the DB handle is meant to be long-lived and shared between many goroutines."

source: https://pkg.go.dev/database/sql#DB.Close

[pram]

No. That was the reply after I corrected it, as in it originally told me to call Close after every *sql.DB handle.

[piperswe]

If we're replacing 2 seniors and 6 juniors with just 2 seniors, where are you gonna get more seniors when the 2 retire?

[pjmlp]

The same way that currently most HR departments only care about people with at least 10 years experience in exactly the same stack the company is using, and more often than not, training is not even part of the picture.

[treyd]

That problem isn't in scope. That's a long term issue, we care about returns we can deliver in the next 2 quarters.

[tivert]

> If we're replacing 2 seniors and 6 juniors with just 2 seniors, where are you gonna get more seniors when the 2 retire?

Happily drive off a cliff?

[jedmeyers]

With a golden parachute nonetheless.

[madcadmium]

> Operations and Sysadmins I don't forsee ever changing, especially with AI.

Why not?

[mrinfinitiesx]

I've worked operations most of my working life, it's, well it's 'expect the unexpected' territory always, there's always stuff you can never be prepared for and have to really play with the cards you're handed and hope for miracles. Sysadmins find job security in knowing they can fix things right then and there but let them break so they can go fix them, I say that half jokingly, keyword on half.. I love sysadmins. But, sysadminning and trusting AI deployers with a focus on security and stability is a long time out, especially with needing people to ensure those systems stay operational.

When I say operations I don't mean devops, there's that too, but I mean the actual operations of an organization. The team leaders, go-getters, etc. Everybody has their niche.