Before You Read a Single Line of Code, Git Already Knows Where It Hurts
A small set of git commands can reveal a codebase's riskiest files, its bus factor, and its crisis patterns — all before you open an editor. As AI tools reshape how developers write code, this old-school diagnostic habit using git log, git shortlog, and commit analysis is quietly becoming more important, not less.
Most developers, when handed an unfamiliar codebase, do the obvious thing: they start reading files. Maybe they open the README, poke around the directory structure, grep for a function name. It's intuitive, and it's almost always the wrong place to start.
Piechowski.io outlines a different approach: five git commands that extract a diagnostic picture of any project from its commit history alone. No code reading required. The commands surface churn hotspots, contributor concentration, bug clusters, and team confidence patterns. Together, they function like a triage scan — pointing you toward the files that actually matter and away from the ones that just look important.
It's a deceptively simple technique. But in a moment when AI coding assistants are generating more code faster than ever, and when the question of developer productivity has become genuinely contested, the ability to quickly assess a codebase's health is turning into a core skill.
The Five Commands That Reveal Codebase Health
This approach centers on commands that most developers already have access to but rarely use systematically.
The first, and arguably most revealing, lists the 20 most-changed files in the past year using git log piped through sort and uniq. As the post puts it: "The file at the top is almost always the one people warn me about. 'Oh yeah, that file. Everyone's afraid to touch it.'" High churn alone isn't a red flag — active features change often.
But high churn on a file nobody wants to own creates what the author calls "codebase drag": every change is a patch on a patch, blast radius is unpredictable, and engineers pad their estimates because they know the file will fight back.
The second command, git shortlog -sn --no-merges, ranks contributors by commit count. If one person accounts for 60% or more of commits, that's your bus factor — the number of people who could leave and cripple the project. (Glue — Bus Factor Explained: Definition, Formula & Fixes) Cross-referencing that list against a six-month window reveals whether the dominant contributor is still active. If they're gone, the post recommends flagging it to the client immediately.
Additional commands identify files that appear disproportionately in bug-fix commits, map author ownership across the codebase, and detect periods of crisis-level activity. The post references a 2005 Microsoft Research study that found churn-based metrics predicted defects more reliably than complexity metrics alone. (Microsoft Research — Use of Relative Code Churn Measures to Predict System Defect Density)
None of this requires specialized tooling. It's standard git, standard Unix pipes, and a few minutes of terminal work.
Why This Matters More in the Age of AI-Generated Code
There's a reason this kind of pre-code analysis is resonating right now. AI coding tools are producing code at unprecedented speed, but the question of whether that speed translates to genuine productivity gains is far from settled. (Dear Diary: A randomized controlled trial of Generative AI coding tools in the workplace)
METR's February 2026 update describes significant challenges in measuring AI's impact on developer productivity. Their earlier study, using data from early 2025, found that AI tools caused a 20% slowdown in task completion among experienced open-source developers. When they attempted a larger follow-up experiment starting in August 2025, they ran into selection bias: developers increasingly refused to participate if it meant working without AI, skewing the results. METR noted that based on participant conversations, "it is likely that developers are more sped up from AI tools now — in early 2026 — compared to our estimates from early 2025," but acknowledged their data was "only very weak evidence for the size of this increase."
This uncertainty matters. If AI tools are generating more code but we can't reliably measure whether it's better code, the ability to diagnose codebase health from its history becomes a critical check. Churn analysis doesn't care whether a human or a model wrote the code. It just tells you which files keep breaking.
The risk is compounding. A GitHub issue filed against Claude Code illustrated one of the stranger failure modes of AI-assisted development: a developer discovered that an automated tool was running git reset --hard origin/main every 10 minutes in their project, wiping local changes. The root cause turned out to be a separate locally built tool using GitPython, not Claude Code itself, but the incident highlights how automated workflows interacting with git can create unexpected chaos. When AI agents are making commits, running resets, and managing branches alongside human developers, the commit history becomes both more important to monitor and harder to interpret.
The Psychology of Starting With History
There's a subtler point embedded in the pre-code diagnostic approach that goes beyond tooling. It changes how you think about a codebase before you form your first impressions.
Reading code cold is a bit like walking into a meeting with no context. You notice what's in front of you — the naming conventions, the architecture patterns, the obvious code smells. But you miss the dynamics. Which parts of the system are stable and which are in constant flux? Where has the team been confident, and where have they been afraid?
Commit history answers those questions. A file with 300 changes and 15 bug-fix references tells a different story than a file with 300 changes and zero. A module maintained by a single developer for three years tells a different story than one with 20 contributors and no clear owner. These signals shape how you allocate your attention, which is arguably the most important decision when onboarding to a new project.
This five-command approach is essentially a structured way to build a mental model of a project's risk landscape before cognitive biases from reading the actual code kick in.
Tooling Is Catching Up — Slowly
Platform vendors have started building some of these insights into their products, though the coverage remains uneven. GitLab's 18.6 release in late 2025 emphasized a redesigned UI focused on productivity, part of a broader push across DevSecOps platforms to surface analytics and visibility features alongside code management. Value stream management and analytics dashboards are becoming standard, but they tend to operate at the project or pipeline level rather than the file-by-file diagnostic granularity that makes the terminal approach so useful.
Meanwhile, AI is also moving into the commit process itself. Tools like gac, an LLM-powered commit message generator, aim to produce more meaningful commit messages by analyzing code changes with a language model. Better commit messages would, in theory, make the kind of history-based analysis described above even more powerful — if the messages accurately describe what changed and why, the signal in git log gets richer.
But there's a tension. As more of the development workflow becomes automated, the commit history risks becoming less legible to humans. If AI agents are making dozens of small commits with generated messages, the patterns that a developer would spot in a manual git shortlog could get buried in noise.
What Comes Next
The pre-code diagnostic habit is a low-tech intervention in an increasingly high-tech workflow. Its value isn't in the commands themselves — any experienced developer could reconstruct them. It's in the discipline of looking at history before looking at code, and in treating the commit log as a first-class source of project intelligence.
As AI tools generate more code and automate more of the development pipeline, the developers who thrive will likely be the ones who know how to step back and ask the right questions of the systems they're inheriting. Five git commands won't solve a broken codebase. But they'll tell you where to look, and that's usually the hardest part.
