yeah that matches what I see, most of what we run at work is one app and one database, so the slow query log plus looking at the plan gets you like 90% of the way. I never really had the multi service case where otel pays off, I guess at some point it does, but for a small team it felt like a lot of plumbing to end up finding the same n+1 query lol
I’d add that most of the time nobody actually measured anything. at work we inherit slow sites all the time and the first guess is always “the stack”, then you profile it and it’s one query running per item in a loop or something like that. I had the same with my own side project, was sure I needed a bigger server and after measuring the problem was somewhere else completely. measuring first is boring but it’s cheaper than any rewrite I guess
on the fear part, in a healthy team the author still owns the change, the reviewer is a second pair of eyes not an insurance policy. what helped my people a lot was asking the author how they tested it and what happens if it goes wrong, if they can’t answer that’s your review comment right there. and if something breaks after you approved it, you fix it together and add a check so it doesn’t happen again, nobody serious blames the reviewer for that
from the other side, i’m the cto of a small agency and i wrote our rules for working with ai, so maybe it helps. the first one is that the author answers for the code, “the model did it” is not an explanation for anyone. asking the model to review its own diff is a first pass, not a review, the same model that got it wrong is checking itself. the way i put it to the team, ai makes producing cheaper, not deciding or verifying, if you ship double with the same error rate you get double the errors. if your company only measures volume, the atrophy is more a management problem than yours, i’d push back with incidents and rework numbers, thats the language they listen to