If you run a small team, you already have a coding-agent bill and a nagging question you can't answer cleanly: is this actually making us faster, and who should get more of it? On July 20, 2026, AWS shipped the dashboard for exactly that question. Amazon CloudWatch Coding Agent Insights gives engineering leaders visibility into how AI coding tools are driving value across an organization — and it does it by reading metrics the agents already emit, not by adding another agent of its own.

If you remember one thing, make it this: coding-agent usage just became standard telemetry — observable next to your uptime, and portable because it rides OpenTelemetry.

What it actually does#

Coding Agent Insights is a purpose-built CloudWatch view built on OpenTelemetry metrics emitted by your coding agents, presented alongside your existing CloudWatch operational data. That last part is the quiet upgrade: agent activity stops living in a separate vendor console and starts sitting next to the latency, error-rate, and cost dashboards your team already watches.

It ships reading three agents at launch:

The three decisions it's built for#

AWS is unusually direct about the questions Coding Agent Insights is meant to answer, and they map one-to-one onto choices a founder actually makes:

  1. Which teams would benefit from expanded access? Instead of handing out seats to whoever lobbies hardest, you can see where usage and value line up.
  2. Where are agents accelerating delivery? The pitch is a delivery-acceleration signal per team — the difference between "engineering says it helps" and a number you can point at.
  3. How do you right-size token budgets across departments? One consolidated invoice tells you nothing about where the tokens went. Per-department telemetry does.

That's the whole value proposition in one line: it turns "is this worth it?" from a standup anecdote into an operational metric.

The interesting move isn't the dashboard. It's that coding-agent spend is being treated like any other production signal — measured, attributed, and right-sized — instead of an unexamined line item.

Why the OpenTelemetry choice matters more than the dashboard#

The headline is a CloudWatch feature, but the durable part is the plumbing. Because Coding Agent Insights is built on OpenTelemetry rather than a proprietary format, the measurement layer is vendor-neutral. Switch a team from Copilot to Claude Code, add Codex for a project, or change agents entirely next quarter, and the metrics keep flowing over the same OTLP stream. You are not rebuilding dashboards every time the coding-agent market reshuffles — and in 2026 it reshuffles constantly.

It also means you don't have to live inside AWS to get the benefit. The same OTLP stream that feeds CloudWatch can point at whatever observability backend you already run. AWS built the convenient front door; OpenTelemetry is the reason you're not locked to it. That's the same "measure the agent, don't marry the vendor" logic behind pointing your coding agent at the cheapest capable backend.

What to do this week#

If your team already runs Claude Code and you're on AWS, this is close to free signal: the telemetry exists, and turning on the view costs you an afternoon. Availability is all AWS commercial regions except UAE, Bahrain, and Israel (Tel Aviv) at launch.

If you're not on AWS, take the pattern, not the product. Wire your coding agents to emit OpenTelemetry, point it at your existing observability stack, and start attributing token spend and delivery lift to teams. The lesson of this launch is that "how much is the coding agent worth?" has graduated from a quarterly argument to a live metric — and the teams that measure it will be the ones who can defend the spend, or cut it, on evidence. That fits the larger shift we've been tracking all week: agents are in production now, and the tooling has moved from capability to accountability.