Dash0 acquires Polar Signals

Last updated:

Read the Overview

Headline spend, adoption, and cycle time, where merged pull requests slow down between coding and merge, and recommended actions written from those numbers.

The Overview is the front door to AI SDLC Insights. It carries the five headline numbers, a short list of recommended actions, and three views that appear nowhere else in this form.

AI SDLC Insights Overview showing total spend, active users, cycle time, average cost per user, the share of assisted pull requests, and flow through the pipeline

What the Overview Shows

Headline numbers

  • Total spend: What model usage cost in the selected range, compared against the previous period.
  • Active users: Developers whose harness emitted telemetry in the range.
  • Cycle time: First commit to merge, at the percentile you pick. See Cycle time.
  • Avg. cost per user: Total spend divided by active users.
  • Share of assisted PRs: The share of pull requests opened in the range that an AI coding agent assisted.

Flow through the pipeline

Merged pull requests move through four stages, and this view shows how long they sit in each one at the selected percentile:

  1. Coding
  2. Awaiting review
  3. In review
  4. Awaiting merge

The stage with the longest wait is called out as the worst jam. Hovering a stage explains what it measures and how many pull requests are in it right now. Awaiting review, for example, runs from ready for review to the first thing that unblocked the pull request: a review by someone other than the author, or an approval by anyone, an automated reviewer's included.

Each dot is a pull request, colored by PR type. Use Pause to stop the animation and read the distribution.

The Recommended actions card, tagged AI generated, sits under the flow chart. It reads the measurements on the page and turns them into two to four findings, one row each:

  • Severity: Risk for a number moving the wrong way at a cost, Watch for something to keep an eye on, and Opportunity for headroom nobody is using.
  • Title: What the finding is about, in a few words.
  • Tab tags: The tabs that hold the evidence, such as Cost or Productivity. Select a tag to open that tab with the same time range, filters, and percentile.
  • Action: The step to take.

The findings use the same time range, filters, and percentile as the rest of the page, and compare each number against the previous range where they can.

Select a finding to open it in a side panel:

  • Recommended action: The action from the row.
  • Why: The evidence, quoting the numbers the finding rests on.
  • Based on: Only the measurements this finding cites, with the previous-range value where there is one.
  • See it in: A link to each tab that holds the evidence.
  • Show all measurements: Every measurement the findings were written from, with the ones this finding cites highlighted.

See what data was used for these recommendations, at the bottom of the card, opens the same full list at any time, with the range, percentile, and number of filters it was measured over.

The card generates its findings when the page loads, and the same measurements always return the same findings. You get a new set when you change the range, filters, or percentile, when a measurement moves by more than about 10%, or after 24 hours. While a new set is generated, the previous findings stay on screen, dimmed.

If too few measurements have data, the card shows "Not enough measured data in this range to recommend anything." Widen the time range or clear a filter.

To tell Dash0 whether a finding helped, hover its row and select the thumbs up (Useful) or thumbs down (Not useful). The rating is sent to Dash0 with the finding's text. See Data Privacy & Redaction.

Note

A language model writes the findings, and the card says so: "Written by a language model. Check a number before you act on it." The model sees only the measurements in the full list, so every number in a finding should appear there. Check it there, or on the tab the finding links to, before you act on it.

Assisted vs non-assisted cycle time

Three bars at the selected percentile: all pull requests, the ones an AI coding agent assisted, and the ones it did not. This is the closest thing to a direct answer on whether agent-assisted work ships faster.

Note

Read this comparison as a description, not a verdict. Agent-assisted and unassisted pull requests are not randomly assigned. Teams reach for agents on particular kinds of work, so some of any gap reflects which changes got an agent rather than what the agent did to them. The PR type breakdown on the Productivity tab is the place to check whether the mix explains the difference.

Investment distribution

Merged pull requests grouped by PR type, showing where engineering effort actually went. The Productivity tab carries the same chart alongside Where the work goes, which splits sessions by harness, activity, model, or team.

How to Use the Overview

Find the jam before optimizing the wrong thing. Coding time is the stage teams assume they are improving with agents, but the worst jam is frequently awaiting review. Shipping faster then depends on review capacity, not on model choice.

Check reach before reading cost. A high total spend with few active users means concentrated usage, which is a different conversation than broad adoption at the same price. Read total spend and active users together.

Check a recommendation before you act on it. Open the finding and read Based on. If the measurements behind it do not match what you know about the team, the tab tag takes you to the chart where you can check.

Treat the assisted comparison as a starting question. If assisted pull requests merge faster, check on the Productivity tab whether they are also smaller or more heavily weighted toward one PR type.

Further Reading