11 ms·

The future of software engineering is SRE

265 points by Swizec 9mo ago

adelmotsjr 9mo ago
For those who were oblivious to what SRE means, just like me: SRE os _site reliability engineering_
- F7F7F7 9mo 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 9mo ago
  Seemingly Random Engineering
  - bravetraveler 9mo ago
    Sales Recovery Engineering
  - bronlund 9mo ago
    Stuckup Retro Engineer
  - ithkuil 9mo ago
    Sysadmin Really Expensive
  - samyar 9mo ago
    Super Ready Engineer
- arionmiles 9mo ago
  Servers, Ready to Eat
almosthere 9mo ago
Until you find out there are 40 - 80 startups writing agents in the SRE space :/
- ozim 9mo ago
  Basically that’s what people are doing with YOLO mode letting Claude do everything in the system.
- Nextgrid 9mo 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 9mo ago
  And I wish them luck, because the thought of current ai bots doing SRE work effectively is laughable.
- cl0ckt0wer 9mo ago
  Reliable ai agents would make you a trillionaire.
stackskipton 9mo 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.
- bionsystem 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
This says nothing about how if AI can write software, AI cannot do these other things.
Sparkyte 9mo 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 9mo 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 9mo 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.
    - pjmlp 9mo ago
      Indeed, however the amount of "someone" is going to be way less.
    - Sparkyte 9mo ago
      I think it is important to know that AI needs to be maintained. You can't reasonably expect it to have a 99.9% reliability rate. As long as this remains true work will exist in the foreseeable future.
  - bigstrat2003 9mo ago
deadbabe 9mo 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 9mo 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 9mo ago
    What does robotics have to do with writing better code? Is this just a random AI wishlist?
  - deadbabe 9mo 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 9mo ago
But there is bad code and good code and SREs cant tell you which is which, nor fix it.
- bionsystem 9mo 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.
  - deleted 9mo ago
    [deleted]
  - dmoy 9mo 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.
    - bionsystem 9mo ago
      I agree with your nuance, but that's not my default mode, unless I know the language and the domain well I am not going to write an MR. I'm going to read the stack trace to see it it's a conf issue though.
  - VirusNewbie 9mo 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?
- VirusNewbie 9mo ago
hahahahhaah 9mo 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 9mo ago
This may be true about SaaS. Not all software is SaaS, thankfully.
chubot 9mo 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_ 9mo ago
  But what if those complementary skills also become cheap?
  - kristianpaul 9mo ago
    Then you are a product manager, but humans cant do it all..
joshuaisaact 9mo 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 9mo 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.
- pjmlp 9mo 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 9mo 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 9mo 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 9mo ago
  What about C-suite executives & shareholders? Are they safe from automation?
  - deleted 9mo ago
    [deleted]
  - bjt12345 9mo 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?
    - joe_mamba 9mo ago
      >I actually argue that AI will therefore impact these levels of management the most. Not AI but bad economy and mass layoffs tend to wipe out management positions the most. As a decent IC, in case of layoffs in bad economy, you'll always find some place to work at if you're flexible with location and salary because everyone still needs people who know how to actually build shit, but nobody needs to add more managers in their ranks to consume payroll and add no value.
      - mraza007 9mo ago
        This is so true Especially with middle managers they are they the ones that are hit the hardest
zahlman 9mo 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.
alexgotoi 9mo 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.
solatic 9mo 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 9mo 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/ 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
nbevans 9mo ago
Surely SRE is just a .md file like everything else? :upside-down-face:
silisili 9mo 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 9mo 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 9mo 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 9mo 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/ https://quesma.com/blog/introducing-otel-bench/
petetnt 9mo 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 9mo 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.
metasim 9mo ago
What’s an “SRE”?
- netdevphoenix 9mo 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
  - metasim 9mo ago
    Thank you!
  - ginko 9mo ago
    Seems like that would only be relevant to web development, not software engineering in general.
    - netdevphoenix 9mo ago
      True, but since the vast majority of software engineering is web engineering and the title is clearly about web, it seems fit to mention that.
      - chickensong 9mo ago
        IMO, that isn't true, nor is the vast majority of software engineering related to the web. Every industry has been undergoing digital transformation for decades. There are SREs ensuring service levels for everything, from your electrical meter, to satellite navigation systems. Someone wrote the code that boots your phone and starts your car. Somebody's wireless code is passing through your body as you read this, while an SRE ensures the packet loss isn't too high.
        netdevphoenix 9mo ago
        Your point doesn't really change what I said. There are many languages in the world but English is the most common one. Those two facts are true at the same time. This is the same, there are many types of software engineering out there but the most common software engineering job relates to building web applications. If you don't believe me, hit your regular job board and count.
deleted 9mo ago
[deleted]
joe_91 9mo 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.
pjmlp 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
austin-cheney 9mo 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.
- mxuribe 9mo 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-cheney 9mo 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.
    - mxuribe 9mo ago
stosssik 9mo 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 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 9mo 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 9mo 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.
- deadbabe 9mo 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 9mo 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 9mo ago
Euh, our job is hard enough as it is, don't start leaning on us to clean up the AI mess too.
coffeefirst 9mo 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.
- chickensong 9mo ago
  Same as it ever was.
pepperball 9mo ago
[dead]
trkabv 9mo 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 9mo 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
deleted 9mo ago
[deleted]
sylvainkalache 9mo 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 9mo 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 9mo ago
Who wants to be on-call for someone else's buggy vibe-coded app? Sign me right up for that...
Artoooooor 9mo ago
The only thing lacking in this article was explanation of the abbreviation from the title. SRE = Site Reliability Engineer(ing).
johndoh42 9mo 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.

265 points by Swizec 9mo ago

adelmotsjr 9mo ago

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

F7F7F7 9mo 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 9mo ago
Seemingly Random Engineering
- bravetraveler 9mo ago
  Sales Recovery Engineering
- bronlund 9mo ago
  Stuckup Retro Engineer
- ithkuil 9mo ago
  Sysadmin Really Expensive
- samyar 9mo ago
  Super Ready Engineer
arionmiles 9mo ago
Servers, Ready to Eat

almosthere 9mo ago

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

ozim 9mo ago
Basically that’s what people are doing with YOLO mode letting Claude do everything in the system.
Nextgrid 9mo 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 9mo ago
And I wish them luck, because the thought of current ai bots doing SRE work effectively is laughable.
cl0ckt0wer 9mo ago
Reliable ai agents would make you a trillionaire.

stackskipton 9mo 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.

bionsystem 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago

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

Sparkyte 9mo 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 9mo 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 9mo 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.
  - pjmlp 9mo ago
    Indeed, however the amount of "someone" is going to be way less.
  - Sparkyte 9mo ago
    I think it is important to know that AI needs to be maintained. You can't reasonably expect it to have a 99.9% reliability rate. As long as this remains true work will exist in the foreseeable future.
- bigstrat2003 9mo ago

deadbabe 9mo 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 9mo 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 9mo ago
  What does robotics have to do with writing better code? Is this just a random AI wishlist?
- deadbabe 9mo 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 9mo ago

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

bionsystem 9mo 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.
- deleted 9mo ago
  [deleted]
- dmoy 9mo 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.
  - bionsystem 9mo ago
    I agree with your nuance, but that's not my default mode, unless I know the language and the domain well I am not going to write an MR. I'm going to read the stack trace to see it it's a conf issue though.
- VirusNewbie 9mo 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?
VirusNewbie 9mo ago

hahahahhaah 9mo 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 9mo ago

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

chubot 9mo 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_ 9mo ago
But what if those complementary skills also become cheap?
- kristianpaul 9mo ago
  Then you are a product manager, but humans cant do it all..

joshuaisaact 9mo 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 9mo 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.
pjmlp 9mo 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 9mo 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 9mo 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 9mo ago
What about C-suite executives & shareholders? Are they safe from automation?
- deleted 9mo ago
  [deleted]
- bjt12345 9mo 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?
  - joe_mamba 9mo ago
    >I actually argue that AI will therefore impact these levels of management the most. Not AI but bad economy and mass layoffs tend to wipe out management positions the most. As a decent IC, in case of layoffs in bad economy, you'll always find some place to work at if you're flexible with location and salary because everyone still needs people who know how to actually build shit, but nobody needs to add more managers in their ranks to consume payroll and add no value.
    - mraza007 9mo ago
      This is so true Especially with middle managers they are they the ones that are hit the hardest

zahlman 9mo 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.

alexgotoi 9mo 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.

solatic 9mo 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 9mo 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/ 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

nbevans 9mo ago

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

silisili 9mo 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 9mo 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 9mo 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 9mo 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/ https://quesma.com/blog/introducing-otel-bench/

petetnt 9mo 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 9mo 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.

metasim 9mo ago

What’s an “SRE”?

netdevphoenix 9mo 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
- metasim 9mo ago
  Thank you!
- ginko 9mo ago
  Seems like that would only be relevant to web development, not software engineering in general.
  - netdevphoenix 9mo ago
    True, but since the vast majority of software engineering is web engineering and the title is clearly about web, it seems fit to mention that.
    - chickensong 9mo ago
      IMO, that isn't true, nor is the vast majority of software engineering related to the web. Every industry has been undergoing digital transformation for decades. There are SREs ensuring service levels for everything, from your electrical meter, to satellite navigation systems. Someone wrote the code that boots your phone and starts your car. Somebody's wireless code is passing through your body as you read this, while an SRE ensures the packet loss isn't too high.
      - netdevphoenix 9mo ago
        Your point doesn't really change what I said. There are many languages in the world but English is the most common one. Those two facts are true at the same time. This is the same, there are many types of software engineering out there but the most common software engineering job relates to building web applications. If you don't believe me, hit your regular job board and count.

deleted 9mo ago

[deleted]

joe_91 9mo 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.

pjmlp 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago

austin-cheney 9mo 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.

mxuribe 9mo 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-cheney 9mo 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.
  - mxuribe 9mo ago

stosssik 9mo 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 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 9mo 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 9mo 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.

deadbabe 9mo 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 9mo 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 9mo ago

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

coffeefirst 9mo 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.

chickensong 9mo ago
Same as it ever was.

pepperball 9mo ago

[dead]

trkabv 9mo 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 9mo 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

deleted 9mo ago

[deleted]

sylvainkalache 9mo 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 9mo 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 9mo ago

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

Artoooooor 9mo ago

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

johndoh42 9mo 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.