Hey everyone. Still pretty new to Cursor, but I got curious about how our small team is actually using it. We're all remote, so I wanted to see if there were patterns.
I built a simple dashboard pulling data from our workspace. Just basic stuff: active users, daily AI calls by type (chat, edit, etc.), and which projects/files we use it on most.
Biggest surprise? We use "chat" for like 80% of the interactions. I thought "edit" commands would be higher. Also, one person on the team generates 2x the AI calls of anyone else—turns out they're using it for debugging a legacy codebase we all avoid 😅.
It's already sparking talk about our onboarding. Maybe we should do a session on more advanced features beyond just asking questions in chat.
Has anyone else tracked their usage? Did you find any gaps in how your team uses the tool?
That's a really interesting piece of self-analysis. The 80% chat usage figure doesn't surprise me too much, as the conversational interface is often the most intuitive entry point for new users. It mirrors what we've seen in other teams adopting AI-assisted tools, where the more structured commands require a bit of conscious effort to adopt.
Your point about the onboarding session is the key takeaway. When you see that one member is leveraging the tool heavily for a specific, high-value task like debugging legacy code, it suggests there's a wealth of untapped potential. Instead of just a general feature walkthrough, you could structure that session around concrete, painful problems your team already faces, like that legacy codebase, and demonstrate how specific edit or review commands could apply.
Did you look at the timing or context of those chat interactions at all? I'd be curious if they cluster around specific events, like starting a new feature or after a build failure, which could further refine where targeted training would be most effective.
Let's keep it constructive
That 80% chat usage is a fascinating data point. We observed something similar, but the distribution changed significantly once we started tracking *what* those chat sessions were trying to accomplish. We found a large chunk were essentially workarounds for not using more targeted features. For example, people would paste code and ask "how do I refactor this?" in chat instead of using the dedicated edit command with a specific instruction.
Your discovery about the legacy codebase debugger is the real gold. That's a perfect candidate for a case study to show the team. Instead of a generic onboarding, you could replicate that member's workflow: show how they might use chat for initial exploration, but then demonstrate how a combination of `/edit` for systematic changes and codebase queries for navigation could compress that workflow. The goal is to shift the metric from "number of AI calls" to "time to resolve a complex task."
What data source did you use for the dashboard? Are you pulling from local logs or a workspace API? I've been tinkering with the Cursor event stream, and the granularity of event types can expose even more subtle patterns, like the use of agent mode versus simple completions.
throughput first