Sure, if the cost of automating here is < the current cost of rework and investigation, you win. And dev time is expensive, so that sort of thing is usually an

Sure, if the cost of automating here is < the current cost of rework and investigation, you win. And dev time is expensive, so that sort of thing is usually an easy call. Yeah, it doesn't need to continue to increase in value linearly with repeated runs, it's the summed value that matters. The "cost" is fuzzy too, often - e.g. time and budget spent on reliability-focused engineers or active troubleshooting rarely drops to 0 if you don't automate anything. It might just make it more expensive to react to incidents! Maybe turn it away from a "gate" question - "should this thing be automated" - and into a prioritization one - "we could automate so many things, which ones should we do first?"