[al_borland]

So many bad takes in that article. It will be interesting to look back in 5+ years to see how things play out vs this unlimited optimism.

> "everyone is a programmer now"

I’ve heard this about so many things. Various tool they make everyone a programmer, or everyone a DBA. Nice dreams, that never seem to play out.

Being a programmer isn’t about the syntax, it’s about breaking problems down, so they can logically be built back up in code. I have yet to see anyone without an extensive background in programming write good spec for what they want code to do. How many assumptions are we comfortable having AI make?

On my last project I was given 1 sentence of direction, and the people giving the direction truly thought that’s all they needed to say… or it was the extent of their understanding of the topic. It took thousands of lines of code, backed by a bunch of testing and design decisions, informed by 15+ years with the company and the various personalities involved, to make that 1 sentence a reality in a way that would make sense for the organization. Call me a cynic, but I don’t see AI doing a good job with something like that in a world where “everyone is a programmer.”

I did try putting it in Copilot at the start, just to see what it dumped out. It gave me maybe 40 lines of broken code. It was the blog post version of how to do it, not an enterprise solution.

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

[samsk]

I'll be afraid when AI takes a bug report with that typical one sentence problem description (like 'Paypal payments are not being processed, we loose 30k a day'), and fixes the problematic one line of code that the AI wrote before.

[InDubioProRubio]

They despise dependencies so much. Half of there life is to get rid of them - declared as "risks" and "depending on some guy down the hall who codes really well" just makes them loose sleep at night.

And they put so much effort into this side-quest. No code, low code, everyone codes, simple languages, uml-programing,graph-based programing, so easy my intern can do it, outsourced programming, code by specs, all just to get rid of that dependency that can not be- and it never works out. The complexity was inside the company and its product all along.

[InDubioProRubio]

I guess dependency is powerlessness and thus depending on programming, without the ability to control your destiny, is the equivalent of power thirsty sociopath torture. Makes ones life that one notch more beautiful, going into work..