Observability First Development with SLOs - how to align tech to business goals and ship AI generated code with confidence

How to align tech to business goals and ship AI generated code with confidence.

AI is writing more of your code. Releases are faster and more frequent, and "is this one safe to ship?" gets asked more often than any team can answer by hand. Observability first development flips the order: decide what reliable means for the business before the code exists, and let that number judge every release.
That number is an SLO. In 45 minutes we will go from an empty screen to a working Service Level Objective on a real service in Dash0, and show what changes once reliability is a target the whole organization reads, instead of an argument between engineering and the business.
What we'll cover

• Observability first development: setting the reliability target before you build, and why that matters more as AI writes more of the code

• Translating business goals into SLOs: from "checkout has to work" to a target, an error budget and a burn rate everyone understands

• Defining one live: PromQL expressions over telemetry you already send, and what Dash0 builds underneath

• Shipping with confidence: deployment events on the SLO view so you can see which release spent the budget, and burn-rate alerts that treat a slow leak and a fast fire differently

• Making it stick: which services deserve an SLO, what target to set, and the mistakes that kill SLO practice

• Open Q&A, bring the awkward questions

Who it's for: SREs, platform engineers, engineering managers and product leaders who want reliability as one shared number, and any team shipping AI generated code that needs a way to tell fast from reckless.