TL;DR:

  • AI coding tools are now sophisticated enough that understanding how you’re using them matters as much as using them
  • A cluster of new tools tracks suggestion acceptance rates, session replay, and AI-written vs human-written code at the line level
  • GitHub Copilot’s enterprise analytics, Cursor’s usage insights, and dedicated tools like Swimm and Monoculture give different views into the same question
  • The data is most useful for teams trying to calibrate AI autonomy settings and identify where AI makes rewrites more likely — not for measuring individual developer performance

There’s a measurement gap at the centre of AI-assisted development. Most teams using Copilot, Cursor, or similar tools can tell you subjectively that they feel faster. Some can point to velocity metrics that look better. Very few can tell you which specific parts of their codebase are largely AI-generated, where AI suggestions are routinely edited or rejected, or whether their AI tool usage is actually correlated with the code quality metrics they care about.

That gap is starting to close. A cluster of tools — some new, some recently expanded — now give developers and engineering managers genuine visibility into how AI coding assistance is actually being used, at a level of detail that goes well beyond “suggestions accepted this week.”

What AI Session Observability Actually Tracks

The core capability is line-level attribution: being able to look at a piece of code and see whether it originated from an AI suggestion, was typed directly, or was AI-suggested and then edited before acceptance. This sounds straightforward but requires integrating at the editor plugin level, which is why dedicated tooling has emerged rather than this being a built-in feature everywhere.

Beyond attribution, the more useful tools also track:

Suggestion acceptance rate by file type and context. If you’re accepting 80% of AI suggestions in boilerplate TypeScript interfaces but 15% in business logic, that’s actionable information — it tells you where the AI is genuinely helping versus where it’s generating suggestions you’re mostly deleting.

Refactor churn rate. This is subtle but important. AI-generated code that gets accepted and then rewritten within a few days — sometimes called “AI churn” — is a sign that the suggestion wasn’t actually fit for purpose, even though it was accepted. Tracking this separately from clean acceptance gives a more honest picture of AI contribution quality.

Session replay. Some tools record the sequence of edits in a development session, including which AI suggestions were shown, which were accepted, and what changes followed. This is primarily useful for debugging your own usage patterns — spotting whether you have a habit of accepting suggestions and then immediately editing them, or whether you’re spending significant time navigating suggestions before finding one worth keeping.

Context window utilisation. For teams using AI tools that take the full file or codebase as context, tracking how much of the context window is actively relevant to the suggestions being generated helps identify whether you’re getting full value from context-aware features or whether the model is effectively working with a tiny slice of what you’re providing.

The Main Tools in 2026

GitHub Copilot’s enterprise analytics dashboard is the most widely deployed option, partly by default for organisations already on Copilot Business or Enterprise. It gives aggregate acceptance rates, suggestion counts, and active user counts at the team level. What it doesn’t give you is per-file attribution, churn tracking, or anything below the aggregate level that would let you understand where the AI is contributing.

Cursor has added a usage insights view that’s more granular — you can see acceptance rates per project and per file type, and it surfaces cases where suggestions were accepted but immediately followed by manual edits (a proxy for the churn signal, even if it doesn’t call it that). This is relatively new and still maturing.

Swimm, primarily known as a code documentation tool, added AI contribution tracking as part of its developer knowledge layer. The interesting angle here is that Swimm links contribution data to documentation coverage — you can see whether AI-generated code has the same doc coverage as human-written code, and flag gaps. For teams where documentation is already a priority, this is a natural extension.

Monoculture (a smaller tool that’s been gaining traction in teams with explicit AI governance concerns) focuses specifically on the attribution and churn problem. It runs as a lightweight editor extension and produces reports that distinguish AI-originated, human-originated, and collaborative (AI-suggested, human-edited) code. The primary audience is teams that need to answer compliance or audit questions about AI tool usage, or that are running internal studies on AI productivity impact.

What the Data Is Actually Good For

The temptation when you have developer productivity data is to use it to measure individuals. That’s the wrong application, and most of these tools are explicit about not supporting that use case — partly for ethical reasons and partly because the data doesn’t actually support individual performance conclusions in any meaningful way.

Where the data is genuinely useful:

Calibrating AI autonomy settings. If your acceptance rate in a particular context is below 20%, that’s a signal that either your prompting approach isn’t working or the AI tool isn’t well-suited to that context. You can adjust — use a different model, improve the system prompt, or just stop spending mental energy reviewing suggestions in that area.

Identifying high-churn areas. If AI-generated code in a particular part of your codebase is consistently being rewritten within a week, that’s worth investigating. Sometimes it means the AI is generating plausible-but-wrong code in a domain it doesn’t have good training signal for. Sometimes it means the context being provided is insufficient. Either way, it’s a specific problem to fix rather than a general “AI isn’t helpful” conclusion.

Onboarding and tool adoption. Teams rolling out AI coding tools to developers who haven’t used them much get value from aggregate acceptance rate data as a proxy for whether adoption is happening and whether developers are actually engaging with suggestions rather than dismissing them by default.

Estimating AI contribution for retrospectives. Some teams find it useful to include an AI contribution estimate in sprint retrospectives — not to judge performance but to calibrate expectations for future sprints and identify whether productivity improvements are sustainable or whether there’s a ceiling being approached.

The field is moving fast enough that the tools available today are likely to look fairly basic in another 12 months. But if your team is serious about AI-assisted development and currently has no data on how it’s actually being used, starting with Copilot’s built-in analytics or adding Monoculture for more granular tracking is a reasonable first step.