Cursor Profile Should Measure Engineering Outcomes, Not Just Usage

Cursor Profile Should Measure Engineering Outcomes, Not Just Usage

I really like that Cursor has started exposing usage analytics (models used, tokens, agents, streaks, etc.). It’s useful for understanding consumption, but it feels like we’re only measuring how much Cursor was used, not how valuable it was.

Current analytics answer questions like:

  • How many tokens did I consume?
  • Which model did I use?
  • How many agents ran?
  • What’s my streak?

Those are interesting, but after a few days there’s not much you can actually do with that information.

What I’d love to see is Cursor evolve from usage analytics into engineering intelligence.

  1. Code Survival Analytics

Instead of just showing “generated 5,000 lines of code,” show what happened to that code.

For example:

  • % of AI-generated code accepted
  • % merged into main
  • % still exists after 30/60/90 days
  • % reverted or deleted shortly after

Code that survives is a much better signal of quality than code that was merely generated.

  1. Best Model Per Repository

Different repositories have different needs.

Maybe Claude performs best in a large backend codebase, while GPT performs better in a React frontend.

Imagine Cursor learning:

  • Best model for Repo A
  • Best model for Repo B
  • Fastest model for small edits
  • Highest merge rate for large refactors

Instead of choosing models manually, Cursor could recommend them based on historical success.

  1. Task-Level Model Performance

Not every model excels at every task.

It would be useful to know things like:

  • Best model for debugging
  • Best model for writing tests
  • Best model for refactoring
  • Best model for documentation
  • Best model for SQL
  • Best model for infrastructure code

Over time Cursor could learn this automatically from successful completions.

  1. PR Impact

Connect Cursor usage with Git history.

Instead of:

Generated 2,000 lines

Show:

  • Merge rate
  • Average review comments
  • Number of edits before merge
  • Time from generation → merge
  • Review approval rate

That tells us whether the generated code was actually useful.

  1. Prompt Insights

Cursor sees millions of prompts every day.

It could surface insights like:

  • Prompt patterns with the highest acceptance rate
  • Prompt styles that consistently require multiple follow-ups
  • Most effective prompting patterns for different repositories

This would help developers improve how they work with AI.

  1. AI Weak Spots

Show where Cursor repeatedly struggles inside a repository.

For example:

  • Authentication: 92% success
  • API layer: 94%
  • Legacy module: 31%

If developers constantly reject AI suggestions in one area, that’s valuable information.

It may indicate poor documentation, heavy technical debt, or code that’s difficult even for AI to reason about.

  1. Time Saved (Estimated)

Instead of only showing tokens, estimate engineering impact.

Examples:

  • Estimated hours saved
  • Bugs fixed with AI assistance
  • Tests generated
  • Documentation written
  • Refactors completed

Even rough estimates would be far more meaningful than raw token counts

Why this matters?

The current analytics are mostly about usage.

The next step is analytics about outcomes.

I’d much rather know:

  • Which model works best for my repository
  • Which AI-generated code actually ships to production
  • Where AI saves me the most time
  • Where AI consistently struggles
  • Which prompts produce the best results

Those insights would help developers continuously improve how they use Cursor, instead of simply tracking how many tokens they consumed.