The future of software engineering is SRE

https://swizec.com/blog/the-future-of-software-engineering-is-sre/

by Swizec • 6 months ago

265 138 6 months ago

adelmotsjr• 6 months ago

For those who were oblivious to what SRE means, just like me: SRE os _site reliability engineering_

F7F7F7• 6 months ago

I knew what an SRE was and found the article somewhat interesting with a slightly novel (throwaway), more realistic take, on the "why need Salesforce when you can vibe your own Salesforce convo."

But not defining what an SRE is feels like a glaring, almost suffocating, omission.

ares623• 6 months ago

Seemingly Random Engineering

bravetraveler• 6 months ago

Sales Recovery Engineering

bronlund2• 6 months ago

Stuckup Retro Engineer

ithkuil• 6 months ago

Sysadmin Really Expensive

samyar• 6 months ago

Super Ready Engineer

arionmiles• 6 months ago

Servers, Ready to Eat

almosthere• 6 months ago

Until you find out there are 40 - 80 startups writing agents in the SRE space :/

Nextgrid• 6 months ago

It only matters if any of those can promise reliability and either put their own money where their mouth is or convince (and actually get them to pay up) a bigger player to insure them.

Ultimately hardware, software, QA, etc is all about delivering a system that produces certain outputs for certain inputs, with certain penalties if it doesn’t. If you can, great, if you can’t, good luck. Whether you achieve the “can” with human development or LLM is of little concern as long as you can pay out the penalties of “can’t”.

ikiris• 6 months ago

And I wish them luck, because the thought of current ai bots doing SRE work effectively is laughable.

ozim• 6 months ago

Basically that’s what people are doing with YOLO mode letting Claude do everything in the system.

cl0ckt0wer• 6 months ago

Reliable ai agents would make you a trillionaire.

stackskipton• 6 months ago

As someone who works in Ops role (SRE/DevOps/Sysadmin), SREs are something that only works at Google mainly because for Devs to do SRE, they need ability to reject or demand code fixes which means you need someone being a prompt engineer who needs to understand the code and now they back to being developer.

As for more dedicated to Ops side, it's garbage in, garbage out. I've already had too many outages caused by AI Slop being fed into production, calling all Developers = SRE won't change the fact that AI can't program now without massive experienced people controlling it.

bionsystem3• 6 months ago

Most devs can't do SRE, in fact the best devs I've met know they can't do SRE (and vice versa). If I may get a bit philosophical, SRE must be conservative by nature and I feel that devs are often innovative by nature. Another argument is that they simply focus on different problems. One sets up an IDE and clicks play, has some ephemeral devcontainer environment that "just works", and the hard part is to craft the software. The other has the software ready and sometimes very few instructions on how to run it, + your typical production issues, security, scaling, etc. The brain of each gets wired differently over time to solve those very different issues effectively.

rincebrain• 6 months ago

It's possible to do both, you just need to be cognizant of what you're doing in both positions.

A tricky part becomes when you don't have both roles for something, like SRE-developed tools that are maintained by the ones writing them, and you need to strike the balance yourselves until/unless you wind up with that split. If you're not aware of both hats and juggling wearing them intentionally, in that case, you can wind up with tools out of SRE that are worse than any SWE-only tool might ever be, because the SREs sometimes think they won't make the same mistakes, but all the same feature-focused things apply for SRE-written tools too...

zinodaur• 6 months ago

I don’t understand this take - if all engineers go on call, they learn real quick what happens when their coworkers are too innovative. It is a good feedback loop that teaches them not to make unreliable software.

SREs are great when the problem is “the network is down” or “kubernetes won’t run my pods”, but expecting a random engineer to know all the failure modes of software they didn’t build and don’t have context on never seems to work out well.

giancarlostoro• 6 months ago

What? Maybe OPs future. SWE is just going to replace QA and maybe architects if the industry adopts AI more, but there's a lot of hold outs. There's plenty of projects out there that are 'boring' and will not bother.

augusteo• 6 months ago

stackskipton makes a good point about authority. SRE works at Google because SREs can block launches and demand fixes. Without that organizational power, you're just an on-call engineer who also writes tooling.

The article's premise (AI makes code cheap, so operations becomes the differentiator) has some truth to it. But I'd frame it differently: the bottleneck was never really "writing code." It was understanding what to build and keeping it running. AI helps with one of those. Maybe.

nasretdinov• 6 months ago

because SREs can block launches and demand fixes

I didn't find that particularly true during my tenure, but obviously Google is huge, so there probably exist teams that actually can afford to behave this way...

ks2048• 6 months ago

This says nothing about how if AI can write software, AI cannot do these other things.

Sparkyte3• 6 months ago

As an SRE I can tell you AI can't do everything. I have done a little software development, even AI can't do everything. What we are likely to see is operational engineering become the consolidated role between the two. Knows enough about software development and knows enough about site reliability... blamo operational engineer.

mellosouls• 6 months ago

"As an SRE I can tell you AI can't do everything."

That's what they used to say about software engineering and yet this is becoming less and less obvious as capabilities increase.

There are no hiding places for any of us.

TuxSH• 6 months ago

Not the person you are replying to but, even if the technical skills of AI increase (and stuff like Codex and Claude Code is indeed insanely good), you still need someone to make risky decisions that could take down prod.

Not sure management is eager to give permission to software owned by other companies (inference providers) the permission to delete prod DBs.

Also these roles usually involve talking to other teams and stakeholder more often than with a traditional SWE role.

Though

There are no hiding places for any of us.

I agree with this statement. While the timeline is unclear (LLM use is heavily subsidized), I think this will translate into less demand for engineers, overall.

bigstrat2003• 6 months ago

It's still perfectly obvious as AI can't remotely write software if you want it to actually, you know, work.

squidbeak• 6 months ago

Paraphrase: "As an SRE I can tell you that the undetermined and unknowable potential of AI definitely won't involve my job being replaced."

Sparkyte3• 6 months ago

Actually it is more that my role will transform and I have no say in it.

deadbabe3• 6 months ago

CRE - Code Reliability Engineering

AI will not get much better than what we have today, and what we have today is not enough to totally transform software engineering. It is a little easier to be a software engineer now, but that’s it. You can still fuck everything up.

falcor84• 6 months ago

AI will not get much better than what we have today

Wow, where did this come from?

From what just comes to my mind based on recent research, I'd expect at least the following this or next year:

* Continuous learning via an architectural change like Titans or TTT-E2E.

* Advancement in World Models (many labs focusing on them now)

* Longer-running agentic systems, with Gas Town being a recent proof of concept.

* Advances in computer and browser usage - tons of money being poured into this, and RL with self-play is straightforward

* AI integration into robotics, especially when coupled with world models

jayd16• 6 months ago

What does robotics have to do with writing better code? Is this just a random AI wishlist?

deadbabe3• 6 months ago

All the new “advances” in AI (LLMs) will mostly be from better context engineering. The core feature of an intelligent response for a given prompt will not improve much.

The stuff you mention is unproven in usefulness or is so far away that most software engineers have enough time to wrap up their careers and retire gainfully.

AI has already been integrated with robotics. We have entire factories running entirely with robots in the dark. For mass consumer markets, a floor vacuuming and mopping robot that can also climb stairs is probably peak robotics. They already build world models that map out your entire home and reason about materials and cleanliness.

There’s not much more juice left to squeeze here. The next frontier is genetic programming (biological).

dionian• 6 months ago

But there is bad code and good code and SREs cant tell you which is which, nor fix it.

bionsystem3• 6 months ago

My take (I'm an SRE) is that SRE should work pre-emptively to provide reproducible prod-like environments so that QA can test DEV code closer to real-life conditions. Most prod platforms I've seen are nowhere near that level of automation, which makes it really hard to detect or even reproduce production issues.

And no, as an SRE I won't read DEV code, but I can help my team test it.

dmoy• 6 months ago

And no, as an SRE I won't read DEV code, but I can help my team test it.

I mean to each their own. Sometimes if I catch a page and the rabbit hole leads to the devs code, I look under the covers.

And sometimes it's a bug I can identify and fix pretty quickly. Sometimes faster than the dev team because I just saw another dev team make the same mistake a month prior.

You gotta know when to cut your losses and stop searching the rabbit hole though, that's true.

VirusNewbie3• 6 months ago

And no, as an SRE I won't read DEV code, but I can help my team test it.

that doesn't sound like my definition of an SRE. How is what you're doing different than Ops?

VirusNewbie3• 6 months ago

Why not? I'm a SWE SRE and I'm arguably better at telling good code from bad code than many of the pure devs I've worked with.

VirusNewbie3• 6 months ago

Edit: ^ At the cost of being much worse at being able to tell what features are useful or well implemented.

hahahahhaah• 6 months ago

Operational excellence will always be needed but part of that is writing good code. If the slop machine has made bad decisions it could be more efficient to rewrite using human expertise and deploy that.

willtemperley• 6 months ago

This may be true about SaaS. Not all software is SaaS, thankfully.

chubot• 6 months ago

Yeah, I think that when writing code becomes cheap, then all the COMPLEMENTS become more valuable:

    - testing
    - reviewing, and reading/understanding/explaining
    - operations / SRE

mon_• 6 months ago

But what if those complementary skills also become cheap?

kristianpaul• 6 months ago

Then you are a product manager, but humans cant do it all..

joshuaisaact• 6 months ago

Couldn't disagree with this article more. I think the future of software engineering is more T-shaped.

Look at the 'Product Engineer' roles we are seeing spreading in forward-thinking startups and scaleups.

That's the future of SWE I think. SWEs take on more PM and design responsibilities as part of the existing role.

reeredfdfdf• 6 months ago

I agree. In many cases it's probably easier for a developer to become more of a product person, than for a product person to become a dev. Even with LLM's you still need to have some technical skills & be able to read code to handle technical tasks effectively.

Of course things might look different when the product is something that requires really deep domain knowledge.

pjmlp3• 6 months ago

Or architects, someone has to draw the nice diagrams and spec files for the robots.

However, like in automated factories, only a small percentage is required to stay around.

jzig• 6 months ago

I don't think the two are mutually exclusive! e.g. a T-shaped product engineer on one side and a T-shaped SRE on the other. Both will kind of compact what used to be multiple roles/responsibilities together. The good news (and my prediction) IMO is the engineering won't be going away as much as the other roles.

pcj-github• 6 months ago

If the agent swarm is collectively smarter and better than the SRE, they'll be replaced just like other types of workers. There is no domain that has special protection.

measurablefunc• 6 months ago

What about C-suite executives & shareholders? Are they safe from automation?

bjt123452• 6 months ago

The thing about C-suite executives is they usually have short tenures, however the management levels below them are often cozy in their bureaucracy, resist change, often trying to outlast the new management.

I actually argue that AI will therefore impact these levels of management the most.

Think about it, if you were employed as a transformational CEO would you risk trying to fight existing managers or just replace them with AI?

p_v_doom• 6 months ago

Generally yes. The more power one holds in an organization the more safe they are from automation.

vjvjvjvjghv• 6 months ago

The make the decisions so I doubt they will soon themselves to be automated away. Their main risk will be that nobody can buy their products once everything is automated.

I wonder if capitalism and democracy will be just a short chapter in history that will be replaced by something else. Autocratic governments seem to be the most prevalent form of government in history.

vkou• 6 months ago

Automating away shareholders can't come soon enough.

rcbdev• 6 months ago

Yes. The AI cannot be the child/other type of beneficiary of a well-connected person, yet.

meindnoch• 6 months ago

A uniquely important thing that a CEO brings to the table is accountability. You can't automate accounta- ...sorry, I can't continue this with a straight face :DDD

TeMPOraL2• 6 months ago

Ultimately, no. But when we get to this point - once we have AI deciding on its own what needs to be done in the world in general - then the bottom falls out, and we'll all be watching a new global economy, in which humans won't partake anymore. At best, we'll become pets to our new AI overlords; more likely, resources to exploit.

oytis• 6 months ago

You can only replace someone who was useful. If one is useless, but is still there, it means they are not there for their contribution and you can't replace them by automating whatever it might have been.

netdevphoenix4• 6 months ago

You can probably automate the full economy. Both production and consumption

bronlund2• 6 months ago

My thoughts exactly. This is just some guy grasping at straws before he understands that he will have to bow to our new overlords sooner or later.

Edit: Or maybe he is fully aware and just need to push some books before it's too late.

TeMPOraL2• 6 months ago

Or, most charitably, maybe they're not sure and trying to Cunningham's Law their way through the conundrum.

ottah4• 6 months ago

The models are not smarter than us by far. Have you not run into issues with reasoning and comprehension with them? They get confused, they miss big details, build complicated code thats ineffective. They don't work well at tasks that require a larger holistic understanding of the problem. The models are weak, brittle reasoners, because they have an indirect and contradictory understanding of the wold. We're several breakthroughs away and several hardware generations from having models that are robust reasoners for grounded, non-kind problems.

whoamii• 6 months ago

There absolutely is. Sports.

zahlman• 6 months ago

And you definitely don't care how a payments network point of sale terminal and your bank talk to each other... Good software is invisible.
...
Are you keeping up with security updates? Will you leak all my data? Do I trust you? Can I rely on you?

IMO, if the answers to those questions matter to you, then you damn well should care how it works. Because even if you aren't sufficiently technically minded to audit the system, having someone be able to describe it to you coherently is an important starting point in building that trust and having reason to believe that security and privacy will work as advertised.

solatic3• 6 months ago

I think there's two kinds of software-producing-organizations:

There's the small shops where you're running some kind of monolith generally open to the Internet, maybe you have a database hooked up to it. These shops do not need dedicated DevOps/SRE. Throw it into a container platform (e.g. AWS ECS/Fargate, GCP Cloud Run, fly.io, the market is broad enough that it's basically getting commoditized), hook up observability/alerting, maybe pay a consultant to review it and make sure you didn't do anything stupid. Then just pay the bill every month, and don't over-think it.

Then you have large shops: the ones where you're running at the scale where the cost premium of container platforms is higher than the salary of an engineer to move you off it, the ones where you have to figure out how to get the systems from different companies pre-M&A to talk to each other, where you have N development teams organizationally far away from the sales and legal teams signing SLAs yet need to be constrained by said SLAs, where you have some system that was architected to handle X scale and the business has now sold 100X and you have to figure out what band-aids to throw at the failing system while telling the devs they need to re-architect, where you need to build your Alertmanager routing tree configuration dynamically because YAML is garbage and the routing rules change based on whether or not SRE decided to return the pager, plus ensuring that devs have the ability to self-service create new services, plus progressive rollout of new alerts across the organization, etc., so even Alertmanager config needs to be owned by an engineer.

I really can't imagine LLMs replacing SREs in large shops. SREs debugging production outages to find a proximate "root" technical cause is a small fraction of the SRE function.

ffsm8• 6 months ago

SREs debugging production outages to find a proximate "root" technical cause is a small fraction of the SRE function.

According to the specified goals of SRE, this is actually not just a small fraction - but something that shouldn't happen. To be clear, I'm fully aware that this will always be necessary - but whenever it happened - it's because the site reliability engineer (SRE) overlooked something.

Hence if that's considered a large part of the job.. then you're just not a SRE as Google defined that role

https://sre.google/sre-book/table-of-contents/

Very little connection to the blog post we're commenting on though - at least as far as I can tell.

At least I didn't find any focus on debugging. It put forward that the capability to produce reliable software is what will distinguish in the future, and I think this holds up and is inline with the official definition of SRE

bigDinosaur• 6 months ago

This makes sense - as am analogy the flight crash investigator is presumably a very different role to the engineer designing flight safety systems.

ottah4• 6 months ago

I don't think people really adhere to Google's definition; most companies don't even have nearly similar scale. Most SRE I've seen are running from one Pagerduty alert to the next and not really doing much of a deep dive into understanding the problem.

weitendorf4• 6 months ago

Having worked on Cloud Run/Cloud Functions, I think almost every company that isn't itself a cloud provider could be in category 1, with moderately more featureful implementations that actually competed with K8s.

Kubernetes is a huge problem, it's IMO a shitty prototype that industry ran away with (because Google tried to throw a wrench at Docker/AWS when Containers and Cloud were the hot new things, pretending Kubernetes is basically the same as Borg), then the community calcified around the prototype state and bought all this SAAS/structured their production environments around it, and now all these SAAS providers and Platform Engineers/Devops people who make a living off of milking money out of Kubernetes users are guarding their gold mines.

Part of the K8s marketing push was rebranding Infrastructure Engineering = building atop Kubernetes (vs operating at the layers at and beneath it), and K8s leaks abstractions/exposes an enormous configuration surface area, so you just get K8s But More Configuration/Leaks. Also, You Need A Platform, so do Platform Engineering too, for your totally unique use case of connecting git to CI to slackbot/email/2FA to our release scripts.

At my new company we're working on fixing this but it'll probably be 1-2 more years until we can open source it (mostly because it's not generalized enough yet and I don't want to make the same mistake as Kubernetes. But we will open source it). The problem is mostly multitenancy, better primitives, modeling the whole user story in the platform itself, and getting rid of false dichotomies/bad abstractions regarding scaling and state (including the entire control plane). Also, more official tooling and you have to put on a dunce cap if YAML gets within 2 network hopes of any zone.

In your example, I think

1. you shouldn't have to think about scaling and provisioning at this level of granularity, it should always be at the multitenant zonal level, this is one of the cardinal sins Kubernetes made that Borg handled much better

2. YAML is indeed garbage but availability reporting and alerting need better official support, it doesn't make sense for every ecommerce shop and bank to building this stuff

3. a huge amount of alerts and configs could actually be expressed in business logic if cloud platforms exposed synchronous/real-time billing with the scaling speed of Cloud Run.

If you think about it, so so so many problems devops teams deal with are literally just

1. We need to be able to handle scaling events

2. We need to control costs

3. Sometimes these conflict and we struggle to translate between the two.

4. Nobody lets me set hard billing limits/enforcement at the platform level.

(I implemented enforcement for something close to this for Run/Appengine/Functions, it truly is a very difficult problem, but I do think it's possible. Real time usage->billing->balance debits was one of the first things we implemented on our platform).

5. For some reason scaling and provisioning are different things (partly because the cloud provider is slow, partly because Kubernetes is single-tenant)

6. Our ops team's job is to translate between business logic and resource logic, and half our alerts are basically asking a human to manually make some cost/scaling analysis or tradeoff, because we can't automate that, because the underlying resource model/platform makes it impossible.

You gotta go under the hood to fix this stuff.

vrosas• 6 months ago

Every time I’ve pushed for cloud run at jobs that were on or leaning towards k8s I was looked at as a very unserious person. Like you can’t be a “real” engineer if you’re not battling yaml configs and argoCD all day (and all night).

firesteelrain• 6 months ago

Lots to unpack here.

I will just say based on recent experience the fix is not Kubernetes bad it’s Kubernetes is not a product platform; it’s a substrate, and most orgs actually want a platform.

We recently ripped out a barebones Kubernetes product (like Rancher but not Rancher). It was hosting a lot of our software development apps like GitLab, Nexus, KeyCloak, etc

But in order to run those things, you have to build an entire platform and wire it all together. This is on premises running on vxRail.

We ended up discovering that our company had an internal software development platform based on EKS-A and it comes with auto installers with all the apps and includes ArgoCD to maintain state and orchestrate new deployments.

The previous team did a shitty job DIY-ing the prior platform. So we switched to something more maintainable.

If someone made a product like that then I am sure a lot of people would buy it.

spockz• 6 months ago

Since you are developing in this domain. Our challenge with both lambdas and cloud run type managed solutions is that they seem incompatible with our service mesh. Cloud run and lambdas can not be incorporated with gcp service mesh, but only if it is managed through gcp as well. Anything custom is out of the question. Since we require end to end mTLS in our setup we cannot use cloud run.

To me this shows that cloud run is more of an end product than a building block and it hinders the adoption as basically we need to replicate most of cloud run ourselves just to add that tiny bit of also running our Sidecar.

How do you see this going in your new solution?

linuxftw• 6 months ago

There are plenty of PaaS components that run on k8s if you want to use them. I'm not a fan, because I think giving developers direct access to k8s is the better pattern.

Managed k8s services like EKS have been super reliable the last few years.

YAML is fine, it's just configuration language.

you shouldn't have to think about scaling and provisioning at this level of granularity, it should always be at the multitenant zonal level, this is one of the cardinal sins Kubernetes made that Borg handled much better

I'm not sure what you mean here. Manage k8s services, and even k8s clusters you deploy yourself, can autoscale across AZ's. This has been a feature for many years now. You just set a topology key on your pod template spec, your pods will spread across the AZ's, easy.

Most tasks you would want to do to deploy an application, there's an out of the box solution for k8s that already exists. There have been millions of labor-hours poured into k8s as a platform, unless you have some extremely niche use case, you are wasting your time building an alternative.

solatic3• 6 months ago

real-time usage -> billing

This is one of the things that excites me about TigerBeetle; the reason why so much billing by cloud providers is reported only on an hourly granularity at best is because the underlying systems are running batch jobs to calculate final billed sums. Having a billing database that is efficient enough to keep up with real-time is a game-changer and we've barely scratched the surface of what it makes possible.

tryauuum• 6 months ago

those alertmanager descriptions feel scary. I'm stuck in the zabbix era.

what do you mean "progressive rollout of new alerts across the organization"? what kind of alerts?

solatic3• 6 months ago

Well, all kinds. Alerting is a really great way to track things that need to change, tell people about that thing along established channels, and also tell them when it's been addressed satisfactorily. Alertmanager will already be configured with credentials and network access to PagerDuty, Slack, Jira, email, etc., and you can use something like Karma to give people interfaces to the different Alertmanagers and manage silences.

If you're deploying alerts, then yeah you want a progressive rollout just like anything else, or you run the risk of alert fatigue from false positives, which is Really Bad because it undermines faith in the alerting system.

For example, say you want to start to track, per team, how many code quality issues they have, and set thresholds above which they will get alerted. The alert will make a Jira ticket - getting code quality under control can be afforded to be scheduled into a sprint. You probably need different alert thresholds for different teams, and you want to test the waters before you start having Alertmanager make real Jira issues. So, yeah, progressive rollout.

alexgotoi• 6 months ago

There were several cheaper than programmers options to automate things, Robot Processing Automation being probably the most known, but it never get the expected traction.

Why (imo)? Senior leaders still like to say: I run a 500 headcount finance EMEA organization for Siemens, I am the Chief People Officer of Meta anf I lead an org of 1000 smart HR pros. Most of their status is still tight to the org headcount.

nbevans• 6 months ago

Surely SRE is just a .md file like everything else? :upside-down-face:

silisili• 6 months ago

I was an old school SRE before the days of containerization and such. Today, we have one who is a YAML wizard and I won't even pretend to begin to understand the entire architecture between all the moving pieces(kube, flux, helm, etc).

That said, Claude has absolutely no problem not only answering questions, but finding bugs and adding new features to it.

In short, I feel they're just as screwed as us devs.

ivan_gammel• 6 months ago

Operational excellency was always part of the job, regardless of what fancy term described it, be it DevOps, SRE or something else. The future of software engineering is software engineering, with emphasis on engineering.

tasuki• 6 months ago

Writing code was always the easy part of this job. The hard part was keeping your code running for the long time.

Spoken like a true SRE. I'm mostly writing code, rather than working on keeping it in production, but I've had websites up since 2006 (hope that counts as long time in this corner of the internet) with very little down time and frankly not much effort.

My experience with SREs was largely that they're glorified SSH: they tell me I'm the programmer and I should know what to type into their shell to debug the problem (despite them SREing those services for years, while I joined two months ago and haven't even seen the particular service). But no I can't have shell access, and yes I should be the one spelling out what needs to be typed in.

stared• 6 months ago

Yet, AI is not there yet. Even the top models struggle at simplest SRE tasks.

We just created a benchmark on adding distributed logs (OpenTelemetry instrumentation) to small services, around 300 lines of code.

Claude Opus 4.5 succeed at 29%, GPT 5.2 at 26%, Gemini 3 Pro at 16%.

https://quesma.com/blog/introducing-otel-bench/

petetnt• 6 months ago

Again there's a cognitive dissonance in play here where the future of coding is somehow LLMs and but at the same time the LLMS would not evolve not to handle the operations as well even if we disregard pipedreams about AGIs being just around the corner. Especially when markdown files for AI are essentially glorified runbooks.

mexicocitinluez• 6 months ago

All he wanted was to make his job easier and now he's shackled to this stupid system.

What people failed to grasp about low-code/no-code tools (and what I believe the author ultimately says) is that it was never about technical ability. It was about time.

The people who were "supposed" to be the targets of these tools didn't have the time to begin with, let alone the technical experience to round out the rough edges. It's a chore maintaining these types of things.

These tools don't change that equation. I truly believe that we'll see a new golden age of targeted, bepsoke software that can now be developed cheaper instead of small/medium businesses utilizing off-the-shelf, one-size-fits-all solutions.

metasim2• 6 months ago

What’s an “SRE”?

netdevphoenix4• 6 months ago

Site Reliability Engineering. It is the role that, among other things, ensures that a service uptime is optimal. It's the closest thing we have nowadays to the system admin role

metasim2• 6 months ago

Thank you!

ginko• 6 months ago

Seems like that would only be relevant to web development, not software engineering in general.

joe_91• 6 months ago

True, but also need to know the basics well of what constitutes good code and how it should scale vs just working code. Too many people relying on LLMs to produce stuff which just about works but give users a terrible experience as it bearly works.

pjmlp3• 6 months ago

Except the small detail that as proven by all the people that lost their jobs to factory robots, the number of required SRE is relatively small in porpotion to existing demographics of SWEs.

Also this doesn't cover most of the jobs, which are actually in consulting, and not product development.

v_CodeSentinal• 6 months ago

Hard agree. As LLMs drive the cost of writing code toward zero, the volume of code we produce is going to explode. But the cost of complexity doesn't go down—it actually might go up because we're generating code faster than we can mentally model it.

SRE becomes the most critical layer because it's the only discipline focused on 'does this actually run reliably?' rather than 'did we ship the feature?'. We're moving from a world of 'crafting logic' to 'managing logic flows'.

mupuff1234• 6 months ago

But the cost of complexity doesn't go down

But how much of current day software complexity is inherent in the problem space vs just bad design and too many (human) chefs in the kitchen? I'm guessing most of it is the latter category.

We might get more software but with less complexity overall, assuming LLMs become good enough.

legorobot• 6 months ago

I agree that there's a lot of complexity today due to the process in which we write code (people, lack of understanding the problem space, etc.) vs the problem itself.

Would we say us as humans also have captured the "best" way to reduce complexity and write great code? Maybe there's patterns and guidelines but no hard and fast rules. Until we have better understanding around that, LLMs may also not arrive at those levels either. Most of that knowledge is gleamed when sticking with a system -- dealing with past choices and requiring changes and tweaks to the code, complexity and solution over time. Maybe the right "memory" or compaction could help LLMs get better over time, but we're just scratching the surface there today.

LLMs output code as good as their training data. They can reason about parts of code they are prompted and offer ideas, but they're inherently based on the data and concepts they've trained on. And unfortunately...its likely much more average code than highly respected ones that flood the training data, at least for now.

Ideally I'd love to see better code written and complexity driven down by _whatever_ writes the code. But there will always been verification required when using a writer that is probabilistic.

oblio• 6 months ago

That probably requires superhuman AI, though.

ottah4• 6 months ago

I dunno, I don't think in practice SRE or DevOPs are even really different from the people we used to call sys admins (former sysadmin myself). I think the future of mediocre companies is SRE chasing after LLM fires, but I think a competitive business would have a much better strategy for building systems. Humans are still by far the most efficient and generalized reasoners, and putting the energy intensive, brittle ai model in charge of most implementation is setting yourself up to fail.

stvvvv4• 6 months ago

Former sysadmin and I've been an SRE for >15 years now.

They are very different. If your SREs are spending much of their time chasing fires, they are doing it wrong.

wavemode2• 6 months ago

By "SRE", are people actually talking about "QA"?

SREs usually don't know the first thing about whether particular logic within the product is working according to a particular set of business requirements. That's just not their role.

zeroCalories• 6 months ago

Most companies don't have QA anymore, just their CI/CD's automated tests.

stvvvv4• 6 months ago

Good SREs at a senior level do. They are familiar with the product, and the customers and the business requirements.

Without that it's impossible to correctly prioritise your work.

storystarling• 6 months ago

I see it less as SRE and more about defensive backend architecture. When you are dealing with non-deterministic outputs, you can't just monitor for uptime, you have to architect for containment. I've been relying heavily on LangGraph and Celery to manage state, basically treating the LLM as a fuzzy component that needs a rigid wrapper. It feels like we are building state machines where the transitions are probabilistic, so the infrastructure (Redis, queues) has to be much more robust than the code generating the content.

belter• 6 months ago

> As LLMs drive the cost of writing code toward zero

And they drive the cost of validating the correctness of such code towards infinity...

franktankbank• 6 months ago

This sounds like the most min maxed drivel. What if I took every concept and dialed it to either zero or 11 and then picked a random conclusion!!!??

austin-cheney2• 6 months ago

I manage a team of developers in a low code environment without AI. The junior developer positions require 8 years of experience, which I think is absurd. Everybody has to program on their own, though pair programming for knowledge transfer is super frequent, but the primary skills of concern are operational excellence (including some project management tasks), transmission, and reliability.

From a people perspective that means excellence when working with outside teams and gathering requirements on your own. It also means always knowing the status of your work in all environments, even in production after deployment. If your soft skills are strong and you can independently program work streams that touch multiple external parties you are golden. It seems this is the future.

mxuribe2• 6 months ago

I'm sorry, nothing personal...but any place that requires 8 years of experience but only gives a title of "junior" is pretty dang close to a sweat shop.

On a different note, i do see what you mention about some op excellence skills (e.g. project management, requirements gathering, etc.) being areas of concern at my $dayjob. But, i kinda always saw them as skills that are valuable in any era, and need not only be in this AI era....but everyone's mileage and environment certainly can vary that expectation. Also, at my $dayjob, the business lacks so much funding to pay software vendors fairly, properly that we get what we pay for....so its often low quality output. Its not low *code* because we employee and contract regular, full code devs....but it certainly often is poor quality...and i wonder as low code offerings and opportunities - paired with more solid AI development asistance - continue to emerge, i suppose something like a SRE role can become that much more important - regardless if one works in low code or low cost arena.

austin-cheney2• 6 months ago

I think you are too hung up on titles. This is the least sweatshop job I have ever had in my 20 year career. Vanity titles is how they get you.

stosssik• 6 months ago

Totally agree. Vibe coding will generate lots of internal AI apps, but turning them into reliable, secure, governed services still requires real engineering, which is exactly why we’re building https://manifest.build. It lets non-technical teams build Agentic apps fast through an AI powered workflow builder while giving engineering and IT a single platform to add governance, security, data access, and keep everything production-ready at scale.

outside2344• 6 months ago

And the other part of the future is that we are all going to become "editors" (in the publishing sense) instead of "writers"

northfield27• 6 months ago

Agreed. I believe this is going to be the trend.

I don’t think LLM context will able to digest large codebases and their algorithms are not going to reason like SREs in the next coming years. And given the current hype and market, investors are gonna pull out with recessions all over the world and we will see another AI Winters.

Code has become a commodity. Corporate engineering hierarchy will be much flat in coming years both horizontally and vertically - one staff will command two senior engineers with two juniors each, orchestrating N agents each.

I think that’s it - this is the end of bootcamp devs. This will act as a great filter and probably decrease the mass influx of bootcamp devs.

deadbabe3• 6 months ago

Bootcamp devs were always going to be doomed in the job market. They were a symptom of not having enough true classically trained computer science degree holding engineers to hire, so you compromised by looking for anyone that knew how to code well enough. But this problem eventually corrects.

Now, there are way too many computer science grads in a time when code is easy and cheap. Not much to gain from hiring a bootcamp dev over the real deal.

But I would say if you truly enjoy coding and you didn’t get to study CS in a university, a bootcamp is probably a fun experience to go through just for your own enjoyment, not for job seeking purposes. Just don’t pay too much.

siliconc0w• 6 months ago

IMO SRE works mostly because they exist outside the product engineering organization. They want to help you succeed but if you want to YOLO your launch and move fast and break things they have the option to hand back the pager and find other work. That option is rarely used but the option alone seems to create better than usual incentives.

With Vibecoding I imagine the LLM will get a MCP that allows them to schedule the jobs on Kubernetes or whatever IaaS and a fleet of agents will do the basic troubleshooting or whackamole type activities, leaving only the hard problems for human SRE. Before and after AI, the corporate incentives will always be to ship slop unless there is a counterbalancing force keeping the shipping team accountable to higher standards.

mg794613• 6 months ago

Euh, our job is hard enough as it is, don't start leaning on us to clean up the AI mess too.

coffeefirst• 6 months ago

In other words, the apps will be trash, and an operations team that doesn't have the time, capability, or mandate to fix them will be constantly scrambling to keep the fires out?

Sounds... reliable.

chickensong2• 6 months ago

Same as it ever was.

trkabv• 6 months ago

We have another person without any respect for the actual stack that powers his fantasies writing LLM propaganda.

Who probably has never written anything of value in his life and therefore approves the theft of other people's valuable work.

arbirk• 6 months ago

I have a lot of work: Make the agents work at warp speed. Prepare specs for next iteration Hopefully exhaust resources.. for free time. <rest as much as possible>

Every 5 hours 24/7. Rinse repeat

sylvainkalache• 6 months ago

If the future of software engineering is SRE, because GenAI is taking care of coding, a similar trend is coming for SRE-type work.

It's called AI SRE, and for now, it's mostly targeted at helping on-call engineers investigate and solve incidents. But of course, these agents can also be used proactively to improve reliability.

didip• 6 months ago

Real SRE? or low skilled sysadmin drowned in pagers calling themselves as SRE? Because the future is bleak if it’s the latter.

eschneider• 6 months ago

Who wants to be on-call for someone else's buggy vibe-coded app? Sign me right up for that...

Artoooooor• 6 months ago

The only thing lacking in this article was explanation of the abbreviation from the title. SRE = Site Reliability Engineer(ing).

johndoh42• 6 months ago

“People don’t buy software, they hire a service” is a bullshit straw man.

That OS on your laptop? Software. The terminal your SSH runs in? Software. The browser you’re reading this take in? Software. The editor you wrote your last 10k LOC in? Software.

The only “service” I buy is email — and even that I run myself. It’s still just software, plus ops.

Yes, running things is hard. Nobody serious disputes that. But pretending this is some new revelation is ahistorical. We used to call this systems engineering, operations, reliability, or just doing your job before SRE needed a brand deck.

And let’s be clear about the direction of value:

Software without SRE still has value. SRE without software has none.

A binary I can run, copy, fork, and understand beats a perfectly monitored nothing. A CLI tool with zero uptime guarantees still solves problems. A library still ships value. A game still runs. A compiler still compiles.

Ops exists to serve software, not replace it. Reliability amplifies value — it does not create it.

If “writing code is easy,” why is the world drowning in unreliable, unmaintainable, over-engineered trash with immaculate dashboards and flawless incident postmortems?

People buy software. They appreciate service when the software becomes infrastructure. Confusing the two is how you end up worshipping uptime graphs while shipping nothing worth running.

The future of software engineering is SRE

Related Stories