Posted on August 25, 2026 by Adriana Villela | OTel Community Manager & CNCF Ambassador) and Diana Todea | OTel Docs Approver & CNCF Ambassador It’s no secret that developers are increasingly being asked to shift left. It seems there’s always something new to shift left on. And now developers are being asked to shift left on observability. This means that in addition to all the other things developers must do, they must also take the extra step of instrumenting their application code with OpenTelemetry, to help make it observable. Why should developers care about observability ?
After all, isn’t observability the domain of SREs? Additionally, what’s the point of adding instrumentation to application code if it only seems to benefit SREs? If you’re being asked to instrument code, you may be thinking: how much extra time will this add to my workload ? After all, application instrumentation involves adding traces, logs, and metrics to your code, making it more observable. This means more code to maintain, introducing complexity, bugs, and technical debt. While that’s true, let’s look at how observability benefits developers.
Nobody loves spending hours and hours trying to chase down a nasty bug. Faster debugging means that developers can finish working on a feature faster and ship it faster. Instrumenting code can expose slow paths, hidden retries, and weird edge cases which can be addressed before the code ever hits production. Micro services are everywhere , and working with them means dealing with many moving parts, with often unpredictable behavior. Observability helps developers understand exactly what’s going on within and between services.
Like it or not, AI is being used for software development, and the quality of the code it produces varies (translation: some of it is utter crap). Making code observable helps untangle the web of not-so-great code. Understanding how observability helps developers is the first step. Next comes instrumentation , the process of translating interesting things into telemetry signals. Developers are lazy by nature, and that’s a good thing. That’s what drives them to automate things and come up with innovative solutions to gnarly problems.