Remix.run Logo
▲ pluc 7 hours ago

SRE was always about understanding; understanding data flow, understanding bottlenecks, understanding logs, understanding application architecture, understanding end user functionality, understanding break points, SLIs, SLOs. Understanding how to mitigate, gracefully deteriorate, restart, restore, recreate, scale, etc.

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

▲Foobar8568 6 hours ago | parent | next [-]

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

Companies loves to have "specialized experts" who skilled up in one afternoon in their field. It might be different in startup, but in consulting world in relatively large enterprises, it's just a fucking joke.

▲zero_shift 6 hours ago | parent [-]

Really? I think that in most orgs up to medium size, you expect senior and especially staff engineers to have that scope

They wouldn't be able to draw it all onto a whiteboard from memory. But give them a half day and they will have mapped out the data flow

▲Wheaties466 5 hours ago | parent [-]

The bigger the org, the more specialized they want you to be.

▲dorianniemiec 23 minutes ago | parent | prev | next [-]

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

▲hectdev 7 hours ago | parent | prev | next [-]

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

▲SimonLarsen 6 hours ago | parent | next [-]

> To me, it just shift ups the level of understanding rather than replaces it.

This just sounds like convoluted way of saying you understanding much less than you would otherwise.

▲hectdev 6 hours ago | parent [-]

Seems like an odd criticism given that programming has always been about abstraction. But sure, I don’t know tree-level details (functions) but I also wasn’t doing leaf-level (bits) understanding because that became obsolete. Now I’m on forest level and expanding to eco systems.

You can always know more but at a certain point, after you’ve built enough validation and safe guards, you find it’s not the best use of your time and the things you can make beyond your specialization is quite remarkable.

Also, I think the toothpaste isn’t going back in the tube with this

▲archagon 2 hours ago | parent [-]

AI is not an abstraction.

▲ 7 hours ago | parent | prev [-]
[deleted]
▲ 7 hours ago | parent [-]
[deleted]
▲yipinwong 6 hours ago | parent | prev | next [-]

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

Understanding should come in different levels abstraction of what you are building,and managing.

There are different levels SREs, from beginner to say Fellow level.

Do you expect the Fellow level to understand nitty gritty details of each component his apps or services are interacting with and how each of them start? No. Especially when they have to deal with hundres or thousands of services each of them hosted by different teams, orgs, or different companies.

junior SREs, yeah probably got their hands dirty with those nitty gritty details you listed because they tend to deal with smaller or lower levels of components

So my point is, I agree withyour "Understanding" but not specific details as they differ per one's level of experience

▲okdood64 6 hours ago | parent [-]

There's nothing unique about junior SREs. They're replaceable with almost any "vanilla Dev". You don't really build a unique experience or expertise until Senior+.

▲slyall 3 hours ago | parent | next [-]

The difference between a junior SRE and a dev is that during an outage the dev will take responsibility for their own code only[1]

While the SRE will follow the problem to the next layer or component and try understand what is going wrong there even though they never heard of the system 10 minutes ago.

[1] "I know I'm on call for this team but the guy who sits next to me wrote that code" is something I've heard way too many times.

▲okdood64 2 hours ago | parent [-]

Fair.

▲yipinwong 4 hours ago | parent | prev [-]

That's where my analogy breaks as all of them do.

My point is that @pluc comments suggests too specific and I wanted that his examples break down in different levels of expertise.

Nothing I mentioned deals with disposability of engineers.

▲DonsDiscountGas 3 hours ago | parent | prev | next [-]

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

▲dorianniemiec 25 minutes ago | parent [-]

Or it could be just better instrumentation...

▲jeffrallen 4 hours ago | parent | prev | next [-]

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

▲oblio 6 hours ago | parent | prev [-]

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

Full slop, you mean.