Runtime is where code tells the truth. Are you listening?

On September 24, some 10,000 developers will gather at WeAreDevelopers Americas 2026 in San Jose to discuss the future of software development.

Everyone’s trying to understand how their jobs and responsibilities are changing in the age of AI. With so much code generated by AI, how can you trust what you’re shipping to production?

At Dynatrace, we believe observability is what turns AI output into something you can actually trust in production. That starts with runtime intelligence inside the places developers already work: the IDE, the terminal, CI, and the workflows where AI assistants now sit beside them. Observability can’t just report that something broke. You need to know why and what your code is actually doing. Developers, AI assistants, and coding agents need the same live context so they can reason from real system behavior instead of guesses.

We’re heading to WeAreDevelopers to give you a chance to experience this firsthand. You can see how live runtime context supports debugging, AI observability, instrumentation, and agent-assisted development, then try Dynatrace and Bluebox for yourself at the hands-on stations. The goal is to help you leave with a clearer way to connect the code you ship with the systems your users experience.

Let’s take a look at a few of the scenarios we’ll be exploring.

Bring runtime context into your developer workflow

You roll out a new feature on Monday. By Tuesday morning, people are arguing about whether it exists. Support has screenshots from users who can see it. Other users swear it’s gone. Nothing looks obviously wrong. The deployment succeeded and the feature flag is enabled.

A few years ago, this is where the scavenger hunt would begin. You’d bounce between deployment tools, feature management platforms, logs, traces, dashboards, and source control, trying to stitch together a timeline from fragments. Maybe you’d find the answer. Maybe you’d spend half a day proving that the obvious suspects weren’t guilty.

Now you can approach the same problem from inside your IDE. Through MCP, Dynatrace brings live runtime context directly into the tools where developers and AI assistants already work. Instead of hunting for clues across half a dozen tabs, you can use natural language questions: Which requests see the feature? Which services are involved? What changed? You can see through the complexity and find the answer: One service is serving a stale configuration cache from an earlier release. Some requests see the new flag value. Others don’t.

That’s the value of runtime intelligence in the developer workflow. You can spend less time managing tools and more time understanding what the system is actually doing and fixing it. Developers and AI assistants work from the same live context, using real logs, traces, dependencies, and runtime signals to move from symptom to root cause without leaving the flow of development.

Trace AI behavior from prompt to production

Your team’s AI code review bot has been catching bugs for months. Then one morning it starts approving everything, from broken code to security issues a junior engineer should have caught. Technically, the service looks healthy, but its behavior is off.

AI systems fail in ways traditional applications don’t. Prompts change. Models get swapped. Context windows overflow. Tool calls break. Responses drift. Traditional observability and monitoring tools weren’t built for this.

With AI observability, you can trace the entire path of a request from prompt to production. One trace reveals the culprit: a recent template change stopped passing repository context to the model. The bot wasn’t reviewing code anymore. It was reviewing almost nothing.

Dynatrace captures prompts, model calls, token usage, evaluations, and downstream application behavior in a single trace, helping developers understand AI systems with the same confidence they expect from the rest of their software.

Debug running applications and instrument from the source

A service starts throwing intermittent errors in production. Not enough to trigger alarms. Just enough to annoy customers. You find the code path, add a few log statements, and deploy. The errors disappear. Great news, until you realize the bug isn’t fixed. The extra logging changed the timing just enough to hide it.

This is where many debugging sessions go sideways. The traces stop at one service. The logs show symptoms but not causes. Everybody has part of the story, but nobody has the whole thing. Before you can fix the problem, you need better telemetry.

That’s why we’re showcasing OpenTelemetry instrumentation at the source. When telemetry is captured where the code runs, every request carries the context needed to understand what happened as it moves through the system. Pair that with live debugging, and you can inspect running applications without redeploying code or scattering temporary log statements through the codebase.