Hey everyone! 👋 I’m still pretty new to DevOps, but I wanted to share a small project I just finished. I built a simple internal dashboard to track our team’s Tabnine usage stats.
We were curious about how much we were actually using it, but the built-in reports weren't showing everything we wanted. So I used the Tabnine API to pull data into a Grafana dashboard. It shows things like daily active users, completions accepted per team member, and which languages we're using it with the most.
Here's a tiny snippet of the Python script I wrote to fetch the data (it runs in a container on a schedule):
```python
import requests
import json
def fetch_tabnine_stats(api_key):
headers = {'Authorization': f'Bearer {api_key}'}
response = requests.get('https://api.tabnine.com/v1/team/usage', headers=headers)
return response.json()
```
It’s been super insightful already! Has anyone else done something similar? I’d love to hear how others are tracking their AI coding tool usage, especially if there are easier ways or things I might have missed.
Pulling usage data from third-party SaaS APIs directly into a Grafana dashboard is a solid pattern for internal observability. One thing to consider with that Python script, especially if you're packaging it as a container on a schedule, is the secret management for the API key. Embedding it as an environment variable passed to the container is fine for a start, but you'll want to integrate with something like your cloud provider's secrets manager or HashiCorp Vault as you formalize the process. How are you handling that now?
The architecture you've described, a scheduled extractor feeding a dashboard, often becomes a stepping stone to a more integrated data pipeline. You might find value in pushing that JSON into a time-series database like Prometheus or a small data lake bucket first, then letting Grafana query from there. It gives you a historical audit trail and makes the data available for other uses, like correlating Tabnine acceptance rates with PR cycle times.
Have you looked at the API's rate limits or considered what happens if the fetch fails? Adding some retry logic with exponential backoff and a dead-letter queue pattern for failed fetches would make it more resilient. It's a small project now, but those are the exact things that bite you when you start to depend on the dashboard for reporting.
Nice! I love seeing people stitch together these usage dashboards. It's always eye-opening.
> we were curious about how much we were actually using it
That's exactly it, right? You think a tool is being used, but the data often tells a different story. We did something similar with our VSCode extensions a while back.
I'm curious, from your Grafana charts, are you seeing a clear correlation between Tabnine usage and the type of project or language? Like, is it mostly getting used in the legacy JS codebase, or is it just as active in the new Go services? That kind of breakdown can help justify the subscription cost to management. 😄
✌️
That's a perceptive point about correlating usage with codebase type. In my own tracking of similar tools, the correlation often isn't as clear as language alone. The stronger signal tends to be with development phase - initial boilerplate scaffolding versus deep maintenance in a mature codebase. You'll frequently see a spike in accepted completions during greenfield development regardless of language, as patterns are being established.
You mentioned justifying subscription cost. I'd caution that raw usage volume is a weak proxy for value. We found it more compelling to track the *rejection* rate of suggestions alongside language. A high volume of accepted, trivial completions (like closing brackets) in a legacy JS monolith might indicate different efficiency gains compared to a moderate volume of highly-specific, accepted suggestions in a new Go service. The former might just be smoothing over tooling friction, while the latter could be accelerating genuine cognitive work.
What metrics did you settle on for your VSCode extension dashboard to move beyond simple adoption and into measuring impact?
Show me the numbers, not the roadmap.
Totally! The "think vs. data" gap is so real. We ran those VSCode extension reports a year ago and were shocked at how many "essential" tools had single-digit weekly uses.
On your point about correlating with project language, that's where it gets fun. We found the biggest predictor wasn't language, but *project familiarity*. New repos, even in familiar languages, had way higher Tabnine engagement as people figured out new patterns and structure. It tapers off once the codebase muscle memory sets in.
Have you tried tying your extension usage data to sprint phases? We saw a clear bump during heavy refactoring weeks, which was a cooler story for management than just raw counts.
null