I Built a Local-First Git Analytics Tool (Without AI) — Here’s Why

Stoyan Korudzhiev — Wed, 17 Dec 2025 09:18:41 +0000

Exploring what Git history can tell us about how we work — without uploading data, dashboards, or black boxes.

For most of my career, Git history was something I used, not something I analyzed.

I’d inspect logs when debugging, skim commits when reviewing PRs, or glance at contribution graphs occasionally — but I never treated Git history as a meaningful signal about how I actually work over time.

That changed when I started feeling increasingly uncomfortable with modern developer analytics tools.

The problem with most developer analytics

Many tools promise deep insights into productivity and focus.
The pattern is usually the same:

Upload your data
Process it remotely
Return a dashboard
Add AI-generated interpretations

Even when these tools look polished, they often feel disconnected from how developers actually reason about their work.

As developers, we care about:

Inspectability
Determinism
Owning our tools and data

But with analytics, we often accept:

Opaque scoring
Cloud-only pipelines
Insights we can’t easily trace back to raw data

That led me to a simple question:

Do we really need AI and cloud processing to understand our own Git history?

Git history is already a rich signal

Git is more than version control.
It’s a chronological log of decisions.

Every commit contains information about:

Scope and size of changes
Frequency of context switches
Where effort accumulates
How work evolves over time

When viewed longitudinally, this becomes a surprisingly strong behavioral signal — without needing prediction or classification models.

And crucially:
this data already exists locally.

A strict constraint: everything runs locally

I decided to explore this idea under one hard rule:

All analysis must run locally.
No AI models.
No cloud processing.
No data leaving the machine.

This wasn’t an ideological stance against AI — it was about trust and clarity.

If an insight couldn’t be explained directly in terms of commits, timelines, and diffs, it didn’t belong.

Building GitGlow as an experiment

That experiment eventually turned into a tool I called GitGlow.

Initially, GitGlow was just a way to explore repositories differently:

Time-based commit activity
File-level change patterns
Visual timelines instead of flat logs

But once I started using it on my own projects, I noticed things I hadn’t consciously tracked before:

Long refactor-heavy periods with little outward progress
High churn in specific files over time
Changes in work cadence depending on project type

None of this felt “smart” or predictive — it was simply surfaced more clearly.

Observation instead of profiling

One thing I wanted to avoid was turning analytics into judgment.

GitGlow doesn’t try to label developers or score productivity.
Instead, it focuses on neutral observations, such as:

Clustering of changes
Shifts in commit size distribution
Changes in activity regularity

These are signals, not conclusions.

Because everything runs locally, the experience feels closer to introspection than monitoring.

What I’m still figuring out

This approach raises open questions I’m still exploring:

How much history is enough to make patterns meaningful?
Where is the line between insight and over-interpretation?
Which signals are genuinely useful, and which are just interesting?

I’m intentionally moving slowly here.

Tools that analyze how people work require a high trust bar — and trust is easier to lose than to build.

Why I’m sharing this now

This isn’t a product launch.

I’m sharing this because I think there’s room for developer tooling that is:

Local-first
Calm by default
Inspectable

Built around observation, not prediction.
If nothing else, this experiment changed how I look at my own Git history.

The signal was already there.
I just needed to stop outsourcing the interpretation.

GitGlow exists today as a working experiment, and I’m continuing to explore where this direction leads. GitGlow

Forem: Stoyan Korudzhiev