Comment by nunez
4 hours ago
I really don't think that's enough. You understand the product but not the process.
This is okay as an end user who only cares about features but can be disastrous when something goes wrong and your only hope is to prompt an LLM that might or might not be (a) available or (b) not read into the context of the codebase.
The scope of the problem worsens when you consider that many teams STILL don't own what they write and have SREs serve as their first-line. These folks NEED to know how the hot paths of the services they support work without the memory or tools that your Claude account has. This is much much harder to do on a codebase that's a billion SLOC for no reason with inconsistent code style and questionable tests littered everywhere
I think that writing the code OR having written a lot of code in the past is the only way to REALLY understand what's going on.
Good SREs can support a service without being familiar with the details. They use generic mitigations (e.g. rollback to a know good release, request an emergency quota increase, etc) to quickly stop the bleeding without needing to understand the root cause. Later the SWEs who understand the code can debug at their leisure. Having a deep understanding of the service obviously helps but is not essential. I expect agents are already applying these generic mitigations at bleeding edge companies but do not have firsthand experience as an SRE to confirm.