223 points dorianniemiec 1 hour ago 175 comments
dorianniemiec 1 hour ago | parent
recroad 1 hour ago | parent
okdood64 1 hour ago | parent
I'll probably get downvoted for this but: At 15 YoE, hell no.
Day-to-day coding lost it's allure to me about 3-4 years ago; it's just a means to an end. I think AI came at the right time for me.
leptons 1 hour ago | parent
radlad 1 hour ago | parent
Plus, some people enjoy the rigors of solving in-the-weeds code problems and others enjoy building systems-level designs. This was always true.
hparadiz 1 hour ago | parent
radlad 1 hour ago | parent
hedgehog 58 minutes ago | parent
okdood64 33 minutes ago | parent
Do you need good quality code to do that? Sure, but that's just another line-item on the laundry list of things to make it happen.
uludag 1 hour ago | parent
It's so depressing a thought that if I continue on this path, in a few years, let alone a decade, I'll be utterly unable to produce or even understand code. I realize the skill may not be very economically useful, but losing it is still a depressing outcome that's preventable in theory. At the same time I'm feeling a deep apathy towards building anything. Playing a Zachtronics game is the farthest my internal motivation can push me towards...
I'd love to hear what others are thinking/doing.
itishappy 58 minutes ago | parent
Avicebron 55 minutes ago | parent
gtufano 30 minutes ago | parent
I'm more worried about people that did never program and started directly with LLM support...
everforward 11 minutes ago | parent
I use my agent to prototype a rough version that mostly works, and then I iterate through (with or without my LLM) to clean it up. Then back to the top with a new feature until I’m satisfied with the project and code.
I do tend to like it. My real selling point is that I’m not “locked in” to any choices until I’m happy with how it looks. I used to have to build the thing to see how it looks and acts, and going back on those choices was painful.
I do think there will be value in it, but I’ve been wrong before. My agent occasionally makes stupid choices that make every prompt after that 4x as hard to fix. Like I screwed up a pydantic model in an unreleased library and it supported a “legacy” path no one would ever use for like the next 5k LoC. By the time I noticed, legacy handlers were like 25% of the codebase.
That’s gonna burn a looot of tokens if you scale it up to a million line of code app.
tamimio 39 minutes ago | parent
I personally have a project that have been spending 2 months now making the specs and blueprint, more than 1000 files defining every bit including the future features too, and not a single code has been written yet, later, an agent will use this to produce the syntax and all the needed tests to have exactly what’s been needed.
okdood64 1 hour ago | parent
AI is already pretty good at this in "SRE" workflows.
> AI-driven change risk assessment
And half decent at this.
bcvvvy 1 hour ago | parent
If Claude goes down or stops existing when we go down, we're fucked.
winrid 1 hour ago | parent
perching_aix 1 hour ago | parent
bcvvvy 16 minutes ago | parent
temporallobe 1 hour ago | parent
rubiquity 1 hour ago | parent
jghn 1 hour ago | parent
LargeWu 1 hour ago | parent
Conversely, there are lots of folks who love ops type problems and are not well suited to building apps. So, it makes sense to put them on separate teams where they can each do the thing that they're best at, rather than fumble through the parts of the jobs they hate. But yes, at this point it's not really DevOps anymore, it's just ops.
iamflimflam1 1 hour ago | parent
oasisbob 3 minutes ago | parent
Some places do have really well built out platforms where logging, instrumentation, databases, deployment methodologies, IaC, etc have well-built happy paths that exclude a bunch of accidental complexity.
I think a lot of other places are either too small or grow too quickly with the wrong set of values and admit too much into their "platform" which had very little design to begin with.
dcss_gardener 1 hour ago | parent
Having the maintenance/ops requirements directly feed back into the design and engineering of the product is genuinely powerful. Especially for certain kinds of products, if executed with discipline you can get really good engineering reaction time with no degradation of quality, and often with much cheaper infra costs.
The problem is what you said though. People with both skillsets are rare, and combining them is legitimately a third skill on its own. And even "both" skillsets is a simplification once you start accounting for data, security, compliance, large scaling DB work etc.
It was mostly a dead end for these reasons but it was worth exploring for its potential. And some genuinely good engineering techniques went mainstream out of it, not a total waste.
sublinear 57 minutes ago | parent
I've found that "ops" has become far too overabstracted and jargony. Their moat is endless "certifications". Their "experts" are the dogmatic personality types who try everything in their power to prevent their feet from ever touching the ground like it's lava. They lack the kind of dev or sysadmin experience where you have to stand under your own constructions like a Roman engineer.
Any formerly-known-as "full stack" dev who kept at it for the last decade and a half would run circles around anyone in ops. That's every senior dev working right now who doesn't like to manage people.
It used to be that the ones who went SRE just wanted a pay bump for a bullshit job of relatively light coding puzzles and parroting stuff in meetings, but I guess that well has dried up with "AI".
dcss_gardener 45 minutes ago | parent
But if you have the budget and connections to hire a department of people with these skills and experience, and a problem interesting enough to keep them engaged in the day to day building, and a leader capable and charismatic enough to align them all into the business's goals... you should do that.
everforward 39 minutes ago | parent
It turns out about as well as if you set the Ops team to shipping features.
Eg I’ve seen more than one full stack dev team build a synchronous RPC-over-message-bus framework because they can’t figure out how to make HTTP or actual RPC calls reliable. It is hands down the most poorly and overengineered thing I have ever seen on a service that takes single digit qps.
The ops teams fight that shit tooth and nail because if it blows up, they’re the ones who get called. And it is 100% too late to fix it by then. Ripping it out will take months, and the dev team will say they’ll do it, but they never will because the VP is leaning on them about some feature.
You either say no early, or you are forever on the hook for whatever abomination the intern has cooked up.
netcoyote 54 minutes ago | parent
You’re so right. This is the key, whether a team is doing devops or not.
One of my major contributions when I took on the CTO role was getting dev, ops, and support teams to talk about the pain points. There were so many easy wins to make things run better because the teams didn’t understand the difficulties the other teams were going through.
KaiserPro 58 minutes ago | parent
Where it worked well is the "devops" or sre/sysadmin would sit in the same team and take away the rough edges of the infra.
conversly they would also keep an eye on the web people and see what they are doing and why, learning the tooling they use and try and rationalise it so they don't install 50 messaging queues.
aleph_minus_one 56 minutes ago | parent
Exactly this was the idea: persons in a DevOps role have skills in both areas, i.e. are very wide skill set, so that one can assign them to very diverse tasks for more flexibility. Additionally, these persons can implement synergies to make things more efficient in areas that intersect both development and operation.
ragall 15 minutes ago | parent
blauditore 46 minutes ago | parent
everfrustrated 23 minutes ago | parent
VirusNewbie 1 hour ago | parent
The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.
If SRE cannot throttle the release cadence or fix bugs or change architecture in binaries, it's not really SRE.
rubiquity 1 hour ago | parent
> The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.
Sounds like a cultural issue. Google should look into that.
hparadiz 1 hour ago | parent
ImPostingOnHN 1 hour ago | parent
It's still something everyone can theoretically learn, of course, and someone who works in that role is most effective by instilling those disciplines in others as they go, and making everyone successful.
unethical_ban 52 minutes ago | parent
RexySaxMan 49 minutes ago | parent
everfrustrated 18 minutes ago | parent
aleksiy123 17 minutes ago | parent
Easier to shit on people and things with hot take then actually have a grounded and coherent argument or realise that different companies/teams have different constraints, problems and environments they operate as well as different solutions.
deadnomore 52 minutes ago | parent
okdood64 34 minutes ago | parent
bovermyer 1 hour ago | parent
grahamedgecombe 1 hour ago | parent
steveklabnik 1 hour ago | parent
NortySpock 1 hour ago | parent
This caused a lot of money to be poured into all kinds of projects, not all of which had a positive return on investment.
chris_j 1 hour ago | parent
dragontamer 1 hour ago | parent
tancop 18 minutes ago | parent
Give literal zero interest loans from a state bank based on social value and economic priorities, just like they do in China. And set up an extreme progressive tax (90% top bracket) on returns that are paid out to owners to make sure everything gets invested back into production.
More investment is the driver of economic growth. All the bad parts of ZIRP came from letting companies use the money for unproductive activity. If it's used efficiently the downward pressure from higher product supply will be stronger than inflation from more money in the system. And you get more demand in the labor market leading to higher wages.
tayo42 1 hour ago | parent
rubiquity 1 hour ago | parent
spankalee 1 hour ago | parent
tayo42 45 minutes ago | parent
everforward 32 minutes ago | parent
If you build tools with that context, they’ll have to replace you with someone that has that context. There’s few of them, and they’re expensive.
It’s easier to hire folks that should be interns or juniors that know that one tool, and then replace the whole department every decade.
It’s why everything is YAML now, despite it being horribly verbose and clunky. Can’t have our people needing to know how load balancing works, just add another 95 lines of YAML boilerplate so they don’t need to learn 5 lines of nginx config.
JimBlackwood 16 minutes ago | parent
If you run simple workloads, it’s probably not necessary but then you’ll probably be paid for that. Your company can also choose to outsource complexity to the cloud, and you’ll just be writing YAML. Then there’s also companies where you host everything yourself AND you have large/high workloads, then you still need people with understanding.
With your type of comments, it feels like you’re pretending a developer who writes WordPress websites does the same work as someone doing Erlang for instance. You’ll have different skill sets for every type of engineer, and they’ll all be necessary.
0x1F8B 1 hour ago | parent
I don't think that's a bad thing, it makes infrastructure more consistent and less weird (assuming you understand k8s) but it is a very high level of abstraction and for a bunch of people is just a black box.
chimeracoder 1 hour ago | parent
You're conflating a whole lot of different models here. In fact, "developers should be on call for the systems they build" is a principle that most schools of DevOps thought emphatically subscribe to.
hparadiz 1 hour ago | parent
advisedwang 1 hour ago | parent
When these problems because largely solved with off-the-shelf software SRE became either a bureaucracy (ensuring reliability through policy and enforcement) or just deploying other people's code and holding the pager.
hparadiz 1 hour ago | parent
Waterluvian 1 hour ago | parent
But I really do need the company to have a competent plan for handling issues that isn't just, "call the developer." It's amazing how much it makes them care about proper support and testing when the alternative isn't exploiting a developer, but is a customer outage.
SoftTalker 7 minutes ago | parent
Realistically nothing is perfect, there will be cases where something randomly breaks and will need attention after hours. Responding to a call for this should get you double pay for your time. Plumbers and electricians work this way, why not software folks?
If it absolutely has to get fixed, the company will pay the cost. If it can wait until Monday morning, they can save that cost.
bijowo1676 1 hour ago | parent
twalla 1 hour ago | parent
Swizec 58 minutes ago | parent
Yes! This is devops, thank you for coming to my ted talk.
Coincidentally I’ve found putting engineers oncall for their stuff really does wonders to ensure they check their AI agents’ code and know how it works.
InsidiousWombat 51 minutes ago | parent
SRE just came from the big guys calling their sysadmins SRE
VirusNewbie 20 minutes ago | parent
Aurornis 8 minutes ago | parent
That’s what DevOps meant where I worked.
I remember the separation of developers from deployment being one of the things DevOps pushers wanted to reduce.
In fact it was the beginning of my career when the older senior people were already trying to get away from the assembly line style of software where each person worked on their part and then tossed it over to someone else to become their problem.
tayo42 1 hour ago | parent
Ime this doesn't happen or reflect the reality of work. I had one mythical job where I wasn't directly on call and only received escalations and didn't have a problem with debugging whole system issues. I still worked on the whole system day to day.
Also I feel like this post is also my frustration with sre. In people's minds it's just the job that deals with issues pumped out by swes and they have to work magic because no one else can be bothered to try at their job. This just reinforces that idea.
a012 1 hour ago | parent
hedgehog 1 hour ago | parent
llama052 48 minutes ago | parent
It can certainly get closer but unless your tech stack is a webserver and an application it can get complicated.
menaerus 58 minutes ago | parent
jmyeet 1 hour ago | parent
But how do you make Senior+ SWEs? By having a pipeline of juniors who get trained and mentored. That pipeline is cooked now.
There is going to be a brief period where some like Staff+ SWEs are going to make a lot of money by being AI specialists. But the flood waters are rising for everyone. Those opportunities are going to shrink.
It's eventually going to be a problem that the ecosystem has died because there's no new blood and the people there lack the experience and critical thinking to understand what's being done.
I can use AI on topics I know because I can spot the errors. LLMs lie a lot and get things wrong a lot. What happens when nobody can check the output?
digilypse 22 minutes ago | parent
docheinestages 1 hour ago | parent
radlad 1 hour ago | parent
thelastbender12 1 hour ago | parent
tehjoker 38 minutes ago | parent
elpakal 1 hour ago | parent
andix 1 hour ago | parent
This is a great example. Aviation is a perfect industry to learn from, they figured out a lot of things about how to keep humans from making mistakes. While complexity increases and automation takes away more and more tasks.
caaqil 1 hour ago | parent
In other words, we might need to find some hobbies.
andix 53 minutes ago | parent
goncharow 52 minutes ago | parent
caaqil 37 minutes ago | parent
I am not convinced humans can do much better in "disasters" than Autopilot, despite the emotional stories to the contrary (survivorship bias is one hell of a drug).
renehsz 16 minutes ago | parent
The autopilot does not do "almost all critical work", not even close. It only does some of the routine work (definitely not all of it). But the real critical work is when stuff goes wrong, dealing with emergencies.
The inherent complexity of aviation means that there are so many different failure modes and combinations thereof that no traditional system could ever handle all possibilities and edge cases.
I'm not going to claim that an AI could never do it. But as of right now, with current technology, well-trained pilots are absolutely critical to safety in even the most advanced airliners.
Also, the survivorship bias argument runs against you. Most events where pilots save the day are completely invisible. Like catching an incorrect clearance, a misconfigured approach, dealing with a technical malfunction, etc.
And even when disasters happen, it is very rare that simply enabling the autopilot would have saved the day. In fact, there are plenty of examples where the opposite is the case, and dropping to a lower level of automation would, in hindsight, have been better.
marcosdumay 19 minutes ago | parent
Instead, they are the weakest part on that market.
Muromec 59 minutes ago | parent
The same way erlang is good example of how to run a highly available system with hot reload and observability and stuff. There is cost for that too.
Maybe not all of the projects need the same properties. I'm fine if some of the stuff is having scheduled or unscheduled maintenance. Some kind of government portal that I use once a year had my permission to be offline between 0300 and 0500 and then again after 1200.
brightball 52 minutes ago | parent
andix 52 minutes ago | parent
toomuchtodo 48 minutes ago | parent
"Security is for losers"
> Andy Yen, the CEO of Proton, had a message for an employee in the company’s security Slack channel who urged the company to at least take a few days to pentest newly written code before pushing it live. “That’s bullshit and loser thinking. Of course it’s possible to be fast and secure,” Yen wrote in the channel at the end of August. “Stop thinking always of how to be slower, and focus more on how to be faster.” In a follow-up message, Yen reiterated his point: “only losers think like that.” His ultimate message for the team was to “stop lovingly handcrafting all our code and use AI more.”
Proton CEO Andy Yen: "This will be the last year that we hire engineers." - https://news.ycombinator.com/item?id=50295112 - October 2026
Manifestos, Fear, and 'Loser Thinking': Inside Proton's AI Reckoning - https://news.ycombinator.com/item?id=50289692 - October 2026
Good luck.
Edit: There appears to be some consequences for acting like this.
Proton's CEO Cancels AI 'Re-Interviews' - https://news.ycombinator.com/item?id=50307183 - October 2026
thereader12 40 minutes ago | parent
toomuchtodo 39 minutes ago | parent
mcv 34 minutes ago | parent
tancop 28 minutes ago | parent
boredatoms 25 minutes ago | parent
fcarraldo 12 minutes ago | parent
Either he's been like this the entire time, trying to crack the whip and failing, and thus a bad leader who has repeatedly failed to get results, or he's (as his employees have said) very deep in AI Psychosis and completely abandoned his principles.
It doesn't matter which it is, they're both extremely damning for the company and his leadership.
znpy 14 minutes ago | parent
Jokes aside, you can’t get anywhere near zero fault unless to impose strict operating regulations , requirements and procedures and regular checks… just like in aviation.
And even there, boeing manages to fuck it up somehow.
sobellian 51 minutes ago | parent
SoftTalker 24 minutes ago | parent
There are no guarantees we'll ever reach perfection.
nimih 47 minutes ago | parent
geraneum 45 minutes ago | parent
You might be, and your customers may not! And your competitor could be more than happy to offer a more reliable service.
leecoursey 53 minutes ago | parent
oblio 45 minutes ago | parent
sunrunner 18 minutes ago | parent
Onavo 33 minutes ago | parent
bee_rider 10 minutes ago | parent
Not too surprised to see pressure to reduce the number of pilots.
numbsafari 1 hour ago | parent
It's mildly orthogonal, but I think the metaphor is really quite apropos.
hvis 42 minutes ago | parent
solatic 1 hour ago | parent
* AI-resistant organizations led by graybeards who refuse to send telemetry off-prem (to either observability vendors or to inference providers) and will be dragged, kicking and screaming, into the future, over their cold, dead bodies. There's a lot of large, conservative organizations in this category like banks and governments, where budgets are rubber-stamped and Don't Break It If It Ain't Broken attitudes are tacitly approved of.
* AI-accepting organizations where Ops will go through the same great narrowing that Dev is going through now - build the dark factory and let it run. You do still need people who know what good architecture looks like and to shepherd changes to improve the overall system to make it more observable, scalable, and maintainable. You do still need Non-Functional Software Engineers who don't answer to Product, for the sheer political reason that you need people who have a long-term perspective, compared to Product that has a short-term perspective. The business will make decisions like "Vendor X is too expensive so we're migrating to Vendor Y" and you will need somebody to drive the agents to make that happen in a way that respects availability and compliance requirements. You probably don't need, in the long-term, a whole team of people to handle it, let alone a whole group or a whole division.
At the end of the day... focus on being a strong engineer. Somebody will always be needed to take care of the trees.
hparadiz 1 hour ago | parent
Every person on my team is capable of networking, product engineering, database, job processing and we have command of the entire stack. We will push updates for CVEs with stuff we manually compiled. We own the build system and have the ability to change product as needed. We all have experience in product and we're all capable of pushing fixes as needed. Frankly the SRE team is by far the smartest team I have ever worked with at any company I've ever worked at.
kevinrineer 22 minutes ago | parent
Just a matter of curiosity for me as my career progresses, where I think that is the ideal, but I don't work in a heavily privatized nor regulated space at the moment of posting.
I did read your latest blog post looking for an answer, but it wasn't clear to me from that reading.
colinrand 1 hour ago | parent
himata4113 1 hour ago | parent
0x1F8B 1 hour ago | parent
cadamsdotcom 1 hour ago | parent
The Calculator!
Calculators deskilled long division!
Thing is though: who gives a damn about long division? The real task is your taxes or making a massive BI report for your presentation tomorrow.
AI "deskilling" due to automating things makes old key skills become something you can just ask for and have done for you. Why bother staying skilled at those things when you can broaden? It clears the way for what used to take forever and be a specialist skill, to become something to steamroll through on your way to finishing a much greater outcome/task. It's the micro way that, in the macro, humanity becomes far more capable as a species. The gates are being flung wide open and the gatekeepers are being lapped and they have blogs!
It's not a tragedy, it's universal access to leverage.
debo_ 1 hour ago | parent
cadamsdotcom 5 minutes ago | parent
Planning for mitigation before resolution lets a team address production issues at leisure (because the customer impact is mitigated)
All this knowledge is in your agent - ask it for ideas!
Roonerelli 1 hour ago | parent
cadamsdotcom 8 minutes ago | parent
Where're you doing your debugging? The tundra??
ToucanLoucan 1 hour ago | parent
You can type the same long division problem into a calculator 65,000 times and you will get the right answer 65,000 times.
Can AI get even CLOSE to that?
cadamsdotcom 24 minutes ago | parent
We're on to the next frontier, and it's a bit weird. Jagged frontier and all. But it's opening up new worlds.
Luckily loads of problems are amenable to a non-deterministic approach - even better, many have lots of solutions. SRE is in that bucket. There are as many ways to SRE as there are SREs
(source: one of the first SREs at Uber, co-invented Chaos Engineering as a sub-branch of SRE, hosted first chaos eng conf at Uber, played a key role in Uber's global SRE and incident response "Ring0" initiative, managed many SRE teams over a period of roughly 7 years before a career pivot. You could say I know a thing or two about SRE.)
To SRE well you look at the situation and pull from a huge range of tools. With such a broad range of solves, you're better to focus on the outcome: did we achieve our SLOs? Are they aligned with customer expectations? Focus on defining that and providing the right support for it to be achieved and you'll be fine - you might even get a surprise.
233mhz 1 hour ago | parent
manofmanysmiles 36 minutes ago | parent
I feel there is a potential to "distill" the frontier models into useful tools that can run on smaller hardware. Or distill that knowledge to produce hardware, compute or otherwise. Iff one day the frontier model become inaccessible, the tools that were carved with them may remain valuable.
They will remain most valuable if they are designed in a way that is maintainable even without LLMs. If not, they can be studied as artifacts, or reference designs and then recreated using human intelligence.
The analog I'm playing with:
You can rent time at a high end machine shop and use the best CNC machines to produce extremely valuable tools. Once you leave, you don't have access to those tools, so it is advantageous to produce durable artifacts that are valuable on their own — on a different frontier.
Imagine you're going beyond the frontier physically, exploring new parts of the earth or space. You can't bring the giant machine shop, let alone the machinery of society, the entire economy etc. What do you bring? What do you build now while you have access to the best machines to take with you?
empath75 1 hour ago | parent
maddie0 12 minutes ago | parent
(It was a full 250g of this fantastical kempy Herdwick, absolutely unlike anything you can get commercially, and I'm honestly more proud of it than of anything I built in six years working at NVIDIA.)
jacquesm 1 hour ago | parent
> The Calculator!
Well, I'm sorry to hear that. I have a calculator and some pretty neat computing hardware. If I go into the attic and search long enough I can probably find my old sliderule. I can also do long division, as can all of my kids. I think it is an essential skill to understand all basic mathematical operations, and to be able to use them on small data sets. If I didn't know how to do division without a calculator I would consider that a failure of my basic education.
alerighi 57 minutes ago | parent
Not humanity, a small number of people in this planet, will benefit about this, because now they no longer have to depend on under payed workers to do the job, and will use AI to make the lives of all other human being poorer.
I think that we need to oppose this tech dictatorship, first thing stopping using AI and thus stop depending on an handful of companies that are able to provide it, that while they gain more and more power we all gets poorer.
What was wrong in using our brain, in the end? I still use my brain on my job and I always will, maybe one day they will say that there is no more need of computer experts because AI can do everything (still people bring me their laptop to reinstall Windows, something I've done for 20 years and that AI didn't change), I will just find another job but I will refuse to use this AI shit.
tripleee 54 minutes ago | parent
win311fwg 6 minutes ago | parent
But as we're only imagining anyway, let's forget about the genie for a moment. If we did lose our sense of basic arithmetic all of a sudden what would like at its core even be? If there were two apples on a table you wouldn't even be able to comprehend what happens if you took one. Could we even function like that?
tehjoker 38 minutes ago | parent
pluc 1 hour ago | parent
There is no understanding with AI-generated applications, full stop.
hectdev 53 minutes ago | parent
oblio 44 minutes ago | parent
Full slop, you mean.
Foobar8568 40 minutes ago | parent
Companies loves to have "specialized experts" who skilled up in one afternoon in their field. It might be different in startup, but in consulting world in relatively large enterprises, it's just a fucking joke.
zero_shift 27 minutes ago | parent
They wouldn't be able to draw it all onto a whiteboard from memory. But give them a half day and they will have mapped out the data flow
yipinwong 38 minutes ago | parent
Understanding should come in different levels abstraction of what you are building,and managing.
There are different levels SREs, from beginner to say Fellow level.
Do you expect the Fellow level to understand nitty gritty details of each component his apps or services are interacting with and how each of them start? No. Especially when they have to deal with hundres or thousands of services each of them hosted by different teams, orgs, or different companies.
junior SREs, yeah probably got their hands dirty with those nitty gritty details you listed because they tend to deal with smaller or lower levels of components
So my point is, I agree withyour "Understanding" but not specific details as they differ per one's level of experience
okdood64 36 minutes ago | parent
butwhat 1 hour ago | parent
Yall this was always just a money making scheme.
Never was it meant to carry humanity into the future.
kristianpaul 55 minutes ago | parent
SREs are about super-thinking, context switching, recognize patters and workflows, data movements, etc..
sesteel 53 minutes ago | parent
hombre_fatal 43 minutes ago | parent
When they imagine someone using AI (except for themself), they imagine the least curious, least inquisitive vibe-coder. And they invent the idea that the only way to be someone who asks questions or remains curious is to have paid the dues that they see themself as having paid. Therefore the world must always need them.
Well, all you have to do now is imagine the vibe-coder who has the same curiosity and inquisitiveness that you had especially when you were starting out and weren't yet a professional programmer. The only difference is that now you don't have to bootstrap a whole software career to understand how things work; you can skip that and merely ask.
sesteel 22 minutes ago | parent
armanckeser 21 minutes ago | parent
perching_aix 53 minutes ago | parent
IaC codebases, configs, utility scripts are relatively tiny, and fit into context windows whole. Models are eating them for breakfast.
They're really good at incident response. Sadly, much better than our dedicated colleagues from <location> ever will be. They'll chew through cloud service logs, application logs, application code, iac code and config, CI output, etc. to get whatever is needed, cause wide knowledge is no issue. Even disassembling stuff is no barrier, tracing things down from app level, to runtime level (e.g. JVM), to native calls.
They're really good at handling deployments, end to end infra setup and migrations, following checklists. Hell, they don't even really need checklists. Something that cannot be said about other dedicated colleagues from <location>, who cannot breathe without a checklist, will skip over steps, or otherwise very creatively misinterpret them or improvise something wicked.
They're really good at spinning up mad nice dashboards, and keeping business types happy with impressive looking write-ups they'll never read. It's really refreshing to not have to write those write-ups anymore (or the aforementioned checklists).
It's straight up both not looking good and looking better than ever. Having it be fully hands off remains an issue though.
danielovichdk 51 minutes ago | parent
Like it's the fault of someone else that you cannot say no.
Fuck you, you are just part of a privileged wanking industry and the whining is like hearing children fight.
I am going back to making my Napoletanian pizzas, so shut the fuck up and leave me at, at least these pizzas are not changing.
Wanks
antonvs 43 minutes ago | parent
waffletower 46 minutes ago | parent
solaire_oa 45 minutes ago | parent
Clearly the "author" didn't even put in the effort necessary to make a real title. Not "SRE persists but a skill crisis looms" not "SRE careers remain but competency lowers in spite of AI" not "AI lowers SRE skill but demand is steady". Moreover, hasn't this type of insufferability been dramatically reduced in recent models? It screams that in addition to being slop, it's outdated.
Why would anyone take this at face value?
kccqzy 43 minutes ago | parent
> Alert noise reduction and intelligent grouping, runbook execution for known issues, log pattern detection and anomaly flagging, and basic root-cause suggestions from historical incident data, and auto-remediation for well-understood failure modes like restarting a crashed pod or scaling up a service that’s running hot, are all fairly automated today.
Let’s stop here and ask, why do we not fix the underlying issue? Alert noise? Design better alerts. Runbook execution? Make it a cronjob. Known issues? Why aren’t people fixing these known issues? Root cause suggestion from historical data? Sorry if root cause A is in the historical data you expect problem A is fully solved so it wouldn’t appear again in the next incident. Restarting things? Why doesn’t your health monitor restart things automatically?
SREs also need to climb up the abstraction ladder. Instead of using AI to assist with grunt work, use AI or human thinking to build more reliable systems with fewer incidents. Every incident should be novel.
MetaMalone 40 minutes ago | parent
Do LLMs “deskill” us in general? I suspect we are just replacing old skills with new skills.
recursivedoubts 37 minutes ago | parent
gnfargbl 36 minutes ago | parent
Kaethar 32 minutes ago | parent
gnfargbl 18 minutes ago | parent
ljouhet 34 minutes ago | parent
bigbuppo 33 minutes ago | parent
sloob 32 minutes ago | parent
All that said, skill atrophy is real. Thinking about getting back on the interview circuit is p scary because of it. I dunno wtf is gonna happen.
miah_ 31 minutes ago | parent
Now if only companies wanted to hire people that still have skills and aren't just prompt engineers.
rebeccajae 26 minutes ago | parent
One of these orgs had basically all of the noisy pages under control through automated remediation and a culture that pushed towards aggressive automation of pages that had the same root causes. Almost everything I was paged for was some novel or uncommon fault condition. Developing an intuition about how the system worked (well, more specifically, how the system failed) took a lot longer because most things I had to look at were some edge case failure.
jstummbillig 21 minutes ago | parent
You guys are still doing things, correct? Is my experience so outside the norm, or is stuff still challenging?
hsuduebc2 11 minutes ago | parent
tirumaraiselvan 9 minutes ago | parent
> But here’s the catch.
> If human SREs (okay, now we have to use adjectives like human ) only engage with Tier 3 incidents, i.e. the novel, never-before-seen outages, where do they build the intuition to handle them?
How did they do this before AI? I have done a bunch of complex production level debugging and these Tier 3 incidents are always "starting from scratch" never seen before issues. The main "intuition" I built is persistence and verifying/refuting random hypothesis. In other words, I think we can build an intuition for Tier 3 issues only by engaging with Tier 3 issues.
phendrenad2 5 minutes ago | parent