Your git history is a detailed record of how you work. Commit frequency, the size of your diffs, when you code and when you don’t, how often the code you write gets changed shortly after you write it, whether your commits are tightly scoped or sprawling: all of it is there, going back to whenever the repo was created.
Most developers don’t think about it this way. Commits are a version control mechanism, not a self-portrait. But the data is there whether you’re paying attention to it or not, and at the level of engineering managers and CTOs, some people are paying attention.
What the patterns show
Commit rhythm shows when you’re in flow and when you’re not. A developer who commits steadily throughout the day with moderate-sized diffs is working differently from one who batches commits at the end of a session in large bursts. Neither pattern is inherently better, but both are visible, and both say something about how work is being approached.
Churn rate shows whether your code holds up. Code you write that gets significantly rewritten within a few weeks has a high churn rate. Code that stays in the codebase and gets built on has a low one. This is one of the cleaner signals in git history: it doesn’t care how confident you sounded in standup. It reflects what actually happened to the code after you wrote it.
Commit scope and message quality show something about how work is being organised. Commits that bundle five unrelated changes with a message that says “updates” are not telling the same story as commits scoped tightly to a single change with a message that explains the reasoning.
The AI dimension
AI assistance adds a layer to this picture. Developers using AI tools are, on average, producing larger diffs, higher gross output, and higher churn rates. Those patterns are visible in the history.
Understanding your own AI-assisted output — specifically whether your AI-assisted commits churn faster than your human-authored ones, and whether there are particular types of work where AI assistance holds up well or poorly — is information you’re better off having before someone else draws conclusions from it. The git history is being read. Having your own interpretation of it, grounded in the same data, puts you in a different position when the conversation about AI adoption and code quality comes up.
Why this matters for developers, not just managers
Most of the conversation about engineering metrics sits at the manager level: tools sold to managers, dashboards built for manager views, reports sent to leadership. The developer’s perspective tends to be reactive.
The argument for developers paying attention to their own git history is that it’s their data. It describes patterns in their work that are worth understanding on their own terms: where they’re effective, where AI assistance is genuinely helping, where the code they write tends to hold up, and where it tends to generate future work for them or their colleagues. That understanding has value independently of whether a manager ever looks at a dashboard.
Scryable gives developers visibility into their own commit patterns, churn rates, and AI-assisted output alongside their human-authored baseline. Get early access.