Aviation is a good example if you want to have zero fatal mistakes. There is a way and there is a cost to do so.

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.

A (very) key difference is that this behaviour is mandated by the FAA, and consistent across all providers. There isn't a (legal) option of just not-doing-it because it's "cheaper".

Modern companies generally do not have the same incentive to keep their SRE (or engineers in general) upskilled. Cutting SRE because "we don't really have incidents, why do we keep paying them? If we need to do layoffs I would rather keep a product engineer" will always* (okay, _generally_) be the direction that organizations go without external influence or requirements.

Now I am sure there are some companies or industries where this is required (for example, I would not be surprised if certain military software/services contracts had requirements for support staff with X hours or training/etc), but that is not consistent everywhere.

If we want something that is "money-losing" in the short/medium term to be consistently applied, it unfortunately needs to be (uniformly) regulated.

This was just the default where I worked. We called the exercise Wheel of Misfortune: facilitator sets up an outage / bug in a non-prod environment (inspired by real events or not), spins a wheel, picks a victim, and the problem is solved collectively, manually. That's the standard format, but it could be much more freeform than that: the point is to educate each other regarding "incident management."

I will say, I'd always been skeptical that AI could be better at incident management than an experienced engineer with deep domain / institutional knowledge, but I was recently proven wrong: Claude root-caused and helped resolve a Postgres lock queue pileup that I believe would have taken me much longer to fix.

Re: aviation being a perfect industry to learn from, I think https://m.youtube.com/watch?v=5ESJH1NLMLs might be a good watch. I was introduced to this at a Wheel of Misfortune around 5 years ago, so it's interesting watching it today when AI is encroaching upon everything.

Just like pilots, SREs will have to spend a minimum number of annual hours in the simulator to keep their skills sharp.

It's not a great example.

The plane lands in the same amount of time whether an autopilot lands it or a human, so there's no incidental cost.

If you let a human SRE handle a problem completely, not only will it likely take longer than an AI, but since that SRE is now deskilled, it may take FAR longer. And that's a cost. Who's going to pay it?

Aviation is a perfect industry to learn from if you are willing to hold IT to the same standard of regulatory scrutiny. You can bet your entire net worth that anyone running anything in the industry would fight tooth and nail to prevent that sort of regime from coming into force.

The thing is, without the FAA mandating something like this for SRE’s, no one will do it. In the moment, getting the broken thing back up and running is seen as far more important than the learning opportunity.

I noticed this constraint a few years ago when the SRE/DevOps hiring market was really tight, but no one was investing in non-senior talent. I ended up founding a startup that tried to address this by supplying training via simulated outages. Maybe we were too early.

> Aviation is a perfect industry to learn from, they figured out a lot of things about how to keep humans from making mistakes.

Aviation is used to paying through the nose for stuff. For developers, employers want to pay as little money as possible.

no offense, but I think aviation is a horrible example. if we treated every problem like we treated aviation, we would still be living in the 1950s. honestly, probably the 1850s. hell, we sent a guy to the moon LONG before it was actually safe to do so. (is it safe even now?). do we really think LLMs would be more blasé about human life than humanity itself up until... iono, since the Baby Boomer generation? the "issue", such as it is, with AI is not "we need to make so many guardrails in order for it to be useful", it's that unlike aviation, where the ground truth is "did the plane crash or not?", AI is an open-ended experiment in what would happen where we don't have any feedback from anything other than... how humans feel about it. humans are the antithesis of paperclip maximizers.

I don't see any reason whatsoever why "AI regulations" would become antifragile from their having been "written in blood" in the way that aviation regulations have been; if anything, our inevitable present and future AI crises will each be exponentially more devastating than the last. Modern aviation is a triumph because of how fallible humans are-- that's why we delegate control of aircraft mostly to machines. The shape of AI disruption isn't "the computers aren't following the rules", it's that even by our own rules of rationality our world is terribly underspecified-- we have computer security that isn't secure, subjective rules of ethics/fairness/judgment that defy straightforward explication, "knowledge work" that is actually neither "knowledge" nor "work"... the whole situation is much closer to the human domestication of the dog (letting a potential threat into one's home) than any traditional story of humans coming to terms with their own technological innovations. human behavior is FAR easier to predict than un-aligned AI behavior-- that is why it is such a singular moment in human history.

lol wait until self driving becomes popular.

Those will be fun times.

Fuck aviation, stop using it as a dead horse metaphor for safety through human protocols. I am private instrument rating holder and there's very much a top down push for single pilot ops. Your newer jets (even the jetliners) are all designed with that in mind even though they may not be certified as such.

Aviation is different because their rent-seeking is enforced by the required legal hedging. I'm not sure the same incentive structure exists in the software side of things.

In other words, we might need to find some hobbies.

> skill atrophy is real

It is also both a choice and avoidable.

Atrophy happens when you trade understanding for productivity. Productivity benefits your employer and your KPIs, but not your understanding and your opportunities going forward.

Understanding used to be an unavoidable of the exploration process, and writing documentation used to be the thing that never got done. Now, writing documentation is automatic, but reading it still isn't.

I've been managing a team of interns at my last job, and as they were all equipped with coding agents, they'd deliver complete solutions to problems once or several times per day that would normally take days, or weeks if you factor in necessary learning.

As review of their understanding, and for the sake of my own cognitive debt, I would first ask them the question "How does it work?" and they usually couldn't answer. After a handful of tasks, they started preparing answers. This forth-and-back is still more shallow than getting the deep knowledge chiseled through hours of trial and error, debugging and wrong directions. Spending two hours to find a problem to realize you forgot to save or upload a file, or had an x instead of a y. I look back with nostalgia, and I wonder if there weren't always better ways, and we just get to pick them now. I can literally convert any task, solved or not, into a quiz that brings me towards understanding, in rainbow-colored pig latin.

The way I think about this -- AI makes all of us managers. We need to figure out when we are convinced by what is brought in front of us, when to ask to do more checks/validation, when to fully reject, when to accept. To do this properly we need to have to have enough background knowledge to evaluate the what is AI brings, otherwise otherwise a person in the loop is simply not needed if they only type a prompt and always click yes.

I think people indeed need to constantly practice our low level skills, otherwise they will atrophy.

But there's a new skill blossoming there, right? That's what I'm noticing. The atrophying skill is one you don't need anymore. The new one - prompting, routing the output, spotting the hallucinations, managing singal/noise etc. - is now where you can add tremendous value.

To say nothing of being bold enough to run systems like that in the first place. I know some of engineers that are still folding their arms and refusing to engage with AI!

Skills that you need come and go. I owned a commodore 64 once and knew how to use it. All gone. I fired up an emulator a few years ago and then had a big "now what moment" where I realized I had no clue what to do with it. I had a vague memory of inserting tapes and issuing commands to load stuff from it. Function keys were important. And there was a manual I once had that explained it all. But no muscle memory. Nothing. I'm sure I could have figured it out eventually. Same with DOS. It's decades ago since I did anything on a DOS command line. All gone.

This doesn't matter. That stuff belongs in a museum. I've used AWS pretty extensively a few years ago. I switched to gcloud and other providers later. At some point in the last year, I started delegating all of the pesky work of interfacing with that stuff to AI. It's amazing. I've always referred to AWS documentation as a maze of misdirection. Just endless amounts of documentation mixed with marketing pages that are completely useless. All links lead back to those. So you are constantly fighting their marketing people to get at the bit you actually want which is a mess of fragmented reference documentation with parameters, endpoints, etc. Staying on top of that and keeping it in your head is a skill that will atrophy that I never cared about.

AI is great for figuring out micro detail like that. It's also great for coming up with a bigger plan that involves stringing together lots of tools, commands, scripts, and what not to execute a high level goal of "I want to run this thing over there". And with a bit of work you can actually do this the right way as well. It's fine. I never really liked devops to begin with. I can do it and I appreciate it done properly and can tell the difference. But I've always hated how it sucked up my time when what I really wanted to do was move our product forward. Instead of which I ended up dealing with a lot of arcane AWS or whatever crap that just needed dealing with. And there's always more of it. Just endless amount of micro detail. AI is great for getting on top of that.

I used to scour through server logs, build logs, test reports etc to figure out why tests were failing in CI. That was exhausting work and could take days of investigation. Now I get the exact root cause in a couple of minutes. Just had to give LLMs a token to call Jenkins API and it knows how to do the rest. What an unbelievable experience. Never ever thought computers would be able to do this in my lifetime.

You may never be as fast, but you should absolutely feel at least hypothetically capable of using the CLI at least as well. Or just.. Reading docs and understanding patterns or interfaces was never a superhuman skill and it still isn't. You are a lot more capable than you probably think!

And I am not just trying to platitude you here. Without that basic confidence everything ends up just eventually being harder with the AI, even if maybe the feedback and loop of it all feels faster.

Velocity is sought because we lost traction. If you can effect your designs in few actions, speed has nothing on intention.

> skill atrophy is real

Did you tried adding skill.md?

jokes aside, I agree - models are getting crazy good with CLIs and I kinda gave up learning all the syntax on every tool etc. it makes no sense - what I usually try to do after some _serious_ fkup/incident is to write a human-redable summary and some deterministic scripts which help to debug/fix the problem; for the future when I will eventually ran out of tokens, lol

but aside that I think "the skill" is shifting and a lot of stuff becomes irrelevant indeed; more useful seems to know how to setup your agents so they have access to relevant data easily to investigate and secure your infra and so on; e.g. recently I /llms/ spotted major misconfiguration in reverse proxy setup after I gave it access to all terraform/ansible stuff and let it just probe the hosts/network

I am in a similar situation but I have a different take. Skills themselves are shifting. Where the world is going, professional skills will be closer to what you are doing now. In my view, the valuable part will be to become the person who is responsible. How you do your work, in terms of how much AI you use, will likely become less and less material (in the sense that it will not be an issue if you use a lot of AI to achieve your goals).

Obviously, those who use little or no AI will not be able to deliver as much as those who do. But as long as you become the person who is responsible and show a track record off mitigating things quickly and professionally and able to take responsibility, it will accelerate career progression really fast.

There will be exceptions, of course, like in systems/software where lives are dependent on it or laws are super strict on the software working exactly as expected, but those are going to be exceptions that prove the general rule.

> I dunno wtf is gonna happen.

me either but i do know it will happen sooner than i expect

I’m doing interviews as a senior sre and frankly it’s extremely weird.

I’m being asked very open ended scenario-based questions, I’m answering honestly, and it seems to be going well (i’m moving through the interview funnel).

I’m not getting asked deeply technical questions. No weird obscure trivia. No stack-specific things. No linux internals. No weird networking trap questions. Coding part is essentially gone.

My interviewers so far have mostly been other senior SREs.

It looks like a market where a senior sre can recognise another senior sre. Some kind of closed circle.

So weird, so so weird.

Was the main focus of your job genuinely using the aws CLI and pulling logs though? I was pretty good at it and jq but the only advantage I ever got from that was more time to deal with the problem on the ticket which has been 50/50 in my experience unless the ground is prepared with context + dev environment etc.

>> I will never be able to use AWS CLI as well as claude does.

Are you sure that it's superhuman; and not super -you- man?

AWS CLI‘s API surface is huge, it’s all of AWS. You can abstract over that with your own tools. Agents are great at these little greenfield scripts, both building and using them.

For the last 10 years, I don't think I met a lot of senior architects or dev who could understand all that.

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.

idk, I develop a lot of connected systems: Pis, Macs, lights, Google speakers, custom ESP32 boards. Understanding the capabilities and communication methods to pool them together is still very much part of what I do. If you're thinking one prompt -> production via AI, sure. But I don't think we are anywhere near that because there are so many moving pieces which still require human sign off: legal, design, QA, etc. To me, it just shift ups the level of understanding rather than replaces it.

There's a lot of chatter about how AI is advancing mathematics at the expense of human understanding. This is going to be true for software industry also at some point. The main gripe of mathematicians is how AI is discouraging young people from persevering. Right now job market is rough for junior SWE and unlike mathematics professors, nobody gives a damn. A few years down the line we'll see a real shortage of software engineers who "understands" and it will come back to bite the industry.

Agree up to certain levels but your examples are too specifc.

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

Have the AI explain it to you. You probably won't understand it as well as if you created it yourself, but there is (the potential for) lots of understanding.

The same understanding most of the devs lack because they aren't.... curious. And thus, why they aren't SREs.

What would you think of easier-to-debug infrastructure building blocks? I'm building an easier-to-debug web server and reverse proxy, and I want to know how this would compare to trying to use AI SRE agent to reduce debugging friction. Or maybe both complement each other?

> There is no understanding with AI-generated applications, full stop.

Full slop, you mean.

Thank you. I have been a software dev a long time. More than 30 years. I did not know what this acronym stood for. I read the article and the article it linked to. Neither spent half a sentence explaining what the acronym means.

Thank you! I wish people would define acronyms more.

> SREs should configure their infra by hand sometimes to not lose that skill

Actually... yeah, I'd totally say that. Some SREs in my company never wrote a single line of HCL that wasn't a call to a in-house, pre-approved module. They think they know Terraform - they don't, and they don't know what's under these modules either.

Opus 5.5 is quite effective at generating Terraform for a "typical" app that needs a load balancer, compute, and a database or two. That's the exact sort of cookie-cutter, rote work that AI is perfect for and no one is really going to miss.

AWS condensed 5 SMEs from the NOC into 1 expensive cPanel wannabe and so it goes, and will continue to go.

That ship (of Theseus) has sailed. Computing is going to become intensely personal again.

Along the same lines, Docker "deskilled" a lot of what used to be called "sysadmins."

I bought Sully Sullenberger's book in early 2012. He's the pilot who perfectly ditched his Airbus A320 in the Hudson River after losing both engines on takeoff to bird strikes.

One of the things from the book was how Sully spent a lot of time investigating other pilots' accidents: 'was there anything that pilot could have done to have survived?' When he got to his own emergency situation over the Hudson, time slowed down and he decided over the course of a few seconds that ditching in the river was their only option.

"One way of looking at this might be that for 42 years, I've been making small, regular deposits in this bank of experience, education and training. And on January 15, the balance was sufficient so that I could make a very large withdrawal." https://en.wikipedia.org/wiki/Sully_Sullenberger

DevOps was a reasonable idea, but it rarely actually manifested. If a company had an actual "DevOps group" separate from the developers, by definition they weren't doing DevOps.

Google's SRE was always about building infrastructure to make things reliable, and started in a world where LAMP on bare-metal + DNS load balancing was common. It makes sense to have a separate org/team/role responsible building real load balancing with health checks and failover, figuring out how to do zero-downtime updates, etc.

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.

I need the company to have skin in the game, so I prefer that I am entirely unreachable outside M-F 9-5. Otherwise they just exploit people who submit far too quickly to being on-call 24/7. It also gives me motivation to make my stuff work as best as possible so that I'm not being annoyed by management about my non-existence outside core hours.

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.

SRE at google works closely with devs to architect and build systems together. Most of them are on the SWE ladder, are able to bug fix and scale directly. They're not just ops.

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.

> SRE was always a lame job description and so was the entire "DevOps" movement we had to suffer through during ZIRP. Real ones are oncall for the systems they build.

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.

On-call problems are mostly just a result of Kubernetes' "cattle not pets" brainrot ideology where people throw local simulate-ability out the window because the Rube-Goldberg web of pods and operators and cluster state gets too complex to simulate locally or keep in your head (esp. if code is located in 50+ microservice repos).

Machines (esp. Virtual Machines) are ultimately predictable and crashes don't "just randomly happen". But it's what this entire "enterprise cloud" culture has brought in, the idea that it's impossible to simulate all possible failure conditions of a cluster locally and therefore we shouldn't even try doing it. Maybe that's true at Google scale, but most companies are simply not, not, not Google-scale.

As a counter-example, I recently built a simple "cloud storage" system with a minimal Linux ISO: everything is stripped down to the absolute minimum to just boot, start a minimal S3 server and pull (encrypted and signed) update commands from an SQL "control plane" database. The entire userspace is ~50k lines of Rust (minus 10k init system) and I can simulate the entire VM locally and play with the "cluster" of VMs locally. The ISO is ~20 megabytes large and I can simulate entire datacenters "burning down", virtually, locally, before it happens for real. I can simulate everything: network failures, disk failures, slowdowns, latency, try getting Fable to hack it, etc.

But in the kubernetes "enterprise" world, I can't do any of this. First I need 10.000 values.yaml files, 10 add-ons for logging and metrics (because pushing metrics to some collection endpoint over HTTP is clearly PhD level complexity) and on top you need a service mesh to restrict random containers talking to each other because nobody knows anymore what services can talk to which other services. The results are constant outages because of misconfigurations and someone having to be on-call at all time.

Needing on-call at all (except for maybe security alerts, but those are usually not part of DevOps) is the result of this Google-influenced "crashes just happen" nonsense where "manager" culture is preferred over results (aka uptime).

> Real ones are oncall for the systems they build.

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.

> Real ones are oncall for the systems they build.

Code of Hammurabi's Law 229: "If a carpenter has erected a poorly constructed house, so that the walls cave in and kill the homeowner, that carpenter shall be executed."

Sre seems to be disappearing anyway in favor of infrastructure and platform engineering. Which seems to just be kubernetes admin jobs using terraform.

> Real ones are oncall for the systems they build.

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.

I call that job SysOps - caring about systems and operation

SRE just came from the big guys calling their sysadmins SRE

there's eventually a point in organization size where it makes sense to have some kind of centralization to make it easier for teams to actually be on call for the systems they build without grinding them to dust.

ZIRP? That's not an acronym I'm familiar with.

That doesn't apply when your org is big.

there is always infra/platform underneath the system, they are the SREs

> Real ones are oncall for the systems they build.

What the fuck do you think the DevOps movement was about?

I've been having this same gnawing feeling. I just started reading the book "The Collision" by Eric C So which promises to cover this subject. I haven't finished it but seems decent so far.

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.

Nice video, but I have said it before, the difference between just “vibe coding” and reliably using AI is the specs you need to write first and the tests after. If you start prompting the end goal/s the AI will basically guide you on what needs to be done and you just accept it as long as it runs, and this is following what most software developers were doing before LLM, the agile way, the quick ship way, the daily standup and ship first discus later way, the code pairing way, which worked mostly (even though I hated personally) in teams, so these developers are replacing what they were used to do with an agent and that’s the mistake. However, if you go with traditional engineering ways, waterfall, specs based, blueprints, and then tests, you control the agents and guide them not the other way around, in your specs you define the tiniest possible thing to what library to be used or excluded, the methods and approaches, among others, the agent here will produce the syntax and help you in the tests, just like in other engineering aspects how machines didn’t take over, they follow your specs and frameworks. The syntax is the past, AI can produce better syntax than any human alive or all combined, if you think otherwise you are delusional and still didn’t move on, it’s time to stop the “developer” mindset and do the engineering one.

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.

> make concerted efforts to do programming (like a coding hour every week), do a Leet code question

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.

People don't appreciate how much of engineering is just as you've described.

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.

This has always been the most valuable part of the job if you ask me. Its just that the other parts of the job were quite hard to get right letting people build a career out of that specialization.

What contexts would the AI model need for analyzing, let's say, cluster-wide incident other than the observability data that such systems anyway collect already?

Is it really that complicated to set up? A basic version is make everything work from a CLI in terminal coding agent of choice (probably already mostly there), hook it up to alerts, and let it run in a corner?

The point I got from the article was that AI is a cause for skill atrophy for any level of seniority, and tends to worsen over time. I can see this happening to myself in some areas, while in others I’m able to learn new skills I’m interested in.

Bottleneck is intelligence, not experience.

Hang in there, in a few years we'll be mining gold cleaning up the mess.

I work in an AI sceptical organization, it's not that we don't use AI agent or consult chat bots, but they are kept a good distance from production. Talking to other SREs in AI heavy and AI first companies I don't see that ending well. SREs struggled with operating applications from developers who cannot or will not understand how computers and the internet work. Now many of the junior developers are even worse and some of them are given the title of "DevOps" and they are using AI to create some of the most broken ass Terraform code and bastard Helm charts to run their broken code. Some SREs are spending more time fighting agents and agent written infrastructure code than they would have, had they been allowed to write it themselves.

If tokens becomes to expensive, we're left with a ton of broken code and infrastructure that can only be managed at an inflated cost. There will be good money to be made consulting and cleaning up the mess of AI boom.

Learning to Be Me by Greg Egan is also apropos.

Org 1 will probably survive better as they will adopt the right primitives - logging, compliance, etc.

Ref: Agent management by Microsoft, AI Gateways springing up everywhere, etc.

When you're just starting out in a system, every incident is a novel, never-before-seen issue. That's putting aside existing sources of knowledge like coworkers and runbooks of course, but I've had to do "software archeology" on lots of stuff because coworkers are gone and docs are wrong. But that's where you build up that intuition, like how the company typically builds things, how deployments usually work, what's that terrible load bearing service installed 10 years ago and not updated since, etc. Yeah every T3 incident eventually is novel, but being able to cut out the non-novel parts helps a lot

Pretend you are a (SR)Engineering Manager with an offshore Cloud Ops team, or with a devops consulting shop on contract: How would you progress your career? How would you get the job done?

[flagged]

I don't think this is as black and white. You skill up by spending time with the domain. Of course, you learn better when you are involved in situations or jobs that actually matter. But getting rid of all the "mundane" distances you from the nitty-gritty and you lose that feel for the problem.

I think that's one reason - another reason is that people are time-constrained, backlogged and expected to do more than ever.

> These are people who have little passion to do what they do, and for whom their role is primarily a chore.

I think maybe this is the realisation I'm coming to with the people in my team and it sucks. I didn't realise it when I joined them 2 years ago, before they started really adopting LLMs use. Trying my best to redirect thay frustration in hopes I find a team that I feel are as passionate as me.

Yes. I bet it was really fun debugging punch card computers.

Also, skills can be re-acquired, if needed. People are acting like it's the end of the world for them, like their knowledge will become impossible to understand anymore. I'm not as fast at solving equations as I was in high school, but I still understand the logic behind it.

We will adapt just fine, like we did before.

Agreed. I think there's also an argument to be made that it's upskilling non SREs to now be able to do SRE things.

I'm glad you apparently live in an ideal world where every incident is fully root caused and fixed at the origin, and all your coders produce perfect, bug-free code.

Most of us, however, do not.

[dead]

Is your org at the point where it would make sense just to upstream patches for FOSS projects and pull rather than patch and push to just your infra?

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.

> why is it that I can't do long division?

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

Edit: "HackerNews" and people can't do long division??

I think a closer analogy would be forgetting basic arithmetic as a concept. Imagine how hard it would be to work with more complex math without understanding what division is. How do you prompt the genie, or understand its outputs, without the foundational knowledge?

You still need to be able to do long division so you can tell when you screwed up on the calculator.

Nobody can read a map anymore, either. Or operate a loom, etc, etc.

Except as every damn AI app says: AI is prone to making mistakes. If AI deskills you with a non-zero chance of getting the problem wrong, that seems deeply, profoundly bad.

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?

> in the macro, humanity becomes far more capable as a species

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.

This is a poor analogy because I don't think your inability to do long division will cause as much damage as an inability to bring the site back up in an emergency situation.

the analogy doesn't work unless your role means having to occasionally do long division, on the spot, without a calculator

You can own a calculator for $2, good luck owning your own frontier model

Honestly, as the expectations change I don't see you really have a choice unless you're in the top 1% of engineers and can essentially dictate your terms. Even then I'd say the clock is running out.

At some point (we might already be there) someone insisting on doing everything manually will be seen like a carpenter who does traditional joinery. They might exist, but they're never going to be a significant percentage of the market compared to 4 guys with nail guns knocking walls together in hours.

Because for the vast majority of cases, "good enough" is good enough.

Eh, I think they're still terrible at architecture. They'll find bugs but they'll try to make them go away instead of building a sustainable system.

They also have a propensity to try to rewrite gigantic amounts of code in one go making changes riskier and harder to scrutinize... without using more LLMs.

Thought about this one too. I was expecting to re-read this same article to see how I feel about it now.

SRE has been around for at least a decade or more.

Site reliability engineers respond to emergencies and keeps systems online in real time. They are perpetually on call. As a swe, it's much better than having on call rotations.

[dead]

I think this works better when you have the underlying knowledge which was probably always a minority of the market ( but still a significant cohort )

The best is when it's just two devs blindly sharing output from Claude back and forth during a major outage instead of USING THEIR BRAINS

Serious question: why are you reading this site?

I am more worried that an LLM company could destroy your entire company by removing access or losing enough cash to go under.

As long as I receive my paycheck I don't care, be passive aggressive to me as much as you want!