Code analysis vs process analysis: why your code tools won't tell you if your team is in trouble

You had a simple worry — is the team building my product actually doing good work? — so you went looking, and the internet handed you a dozen tools that "understand your codebase": Sourcegraph, Sonar, a wave of AI code explainers. You open one, and it's for engineers. It reads the code. It doesn't answer your question. That isn't you missing something. Those tools do code analysis. What you were looking for is process analysis — a different thing entirely.

The two get lumped together because both "analyze a repository," so it's easy to conclude the problem is already solved and every option is a variation on the same idea. It isn't. Code analysis and process analysis look at different objects, are built for different readers, and hand back different things. Here's the distinction in plain language, why a code tool structurally can't tell you whether your team is in trouble, and how to tell which one you actually need.

Code analysis reads the code itself — its structure, bugs, and style — and is built for developers, to find what to fix (Sourcegraph, SonarQube, linters). Process analysis reads the work around the code — who owns what, whether changes get reviewed, whether tests keep up — and is built for the people accountable for the code but not writing it, to surface the questions worth asking. They're complementary: one tells your engineers what to fix; the other tells you what to ask.

What is code analysis?

Code analysis inspects the source code as it exists right now. Static analyzers and linters (SonarQube, ESLint) scan for bugs, security holes, and style violations. Code-search and code-understanding tools (Sourcegraph and the newer AI explainers) help you navigate a large codebase, find where something is defined, and explain what a function does. They're genuinely useful, and they share three traits: the object they examine is the code itself, the reader they're built for is a developer, and the output is findings and answers — things to fix or facts about the code. If your job is to write and maintain the software, these are for you.

What is process analysis?

Process analysis works one level up. Instead of the code, it reads the record of how the code came to be — the git history: who authored which parts, whether changes were reviewed by a second person, whether tests moved alongside features, how long branches stayed open, how much of the month was new work versus redoing old work. The object is the behavior around the code, not the code. The reader is the person accountable for the software but not writing it — an owner, a founder, an investor, a client paying an agency. And the output isn't a fix or a fact; it's a short list of questions worth raising: "why is all the payment code owned by one person?", "should these PRs have shipped without tests?"

Why can't a code tool just tell me if my team is healthy?

Because health isn't a property of the code — it's a property of the process, and the code in front of you doesn't record it. A single snapshot of the source can look immaculate while being written entirely by one person who's about to quit, merged with no review, and shipped without a single test. None of that fragility is visible in the code itself; it's only visible in the history of how the code arrived. A code analyzer, however good, is reading the wrong layer to answer your question. It can tell you the code is clean. It can't tell you the bus factor is one.

What does the difference look like on a real repository?

Say your team ships a payments refactor. A code-analysis tool reads the result: the new code is well-structured, has no obvious bugs, passes the linter. Green across the board. A process-analysis read of the same change looks at how it happened: the branch was open for twelve days across four force-pushes, one reviewer, and not one file under tests/billing/ changed. Same repository, same commit — but the second read surfaces the question the first can't even see: should the most sensitive part of the product have shipped that way? That's the gap. Clean code and a healthy process are not the same claim.

Do I need both?

Usually yes, and they don't compete — they serve different people. Your developers should have good code-analysis tools; that's their trade. But if you're the one accountable for the product without reading it day to day, a code tool won't serve you, because it's answering a question you didn't ask. Process analysis is the read built for your seat: it gives you an independent view of how the work is going, in language you can act on, without a developer translating. One keeps the code clean; the other tells you whether to be worried — and what to ask about at the next review.

Isn't this just git blame, or GitHub Insights?

It uses the same raw material — the git history — but so does a novel and a phone book both use the alphabet. GitHub Insights and activity dashboards count things: commits per week, lines added, contributor rankings. Those are vanity metrics — they confirm activity is happening, not whether it's healthy. Process analysis isn't more charts; it's the interpretation those charts skip: turning the history into the few questions that actually matter this month, framed for a non-technical reader, with the exact commits and PRs behind each one so you can trust it.

Isn't reading the process a form of surveilling my developers?

It depends entirely on intent, and the intent here is the opposite. Process analysis done right never ranks people or scores individuals — the output is questions about the work (is knowledge too concentrated, are tests keeping up), not a leaderboard of who committed most. Used to grade or discipline people, any tool becomes surveillance; used to ask better questions and understand your own project, git history is just the primary record of what was built. The judgment stays human. If a signal could only be used to rank a developer, it doesn't belong in the report.

Where do I start?

The fastest way to see what process analysis actually produces is to look at a sample report — a real, anonymized run showing the questions it surfaces and the commits behind them. If you'd rather start with the thinking, the guide on how to tell if your dev team is doing good work without being technical covers the same signals from the non-technical stakeholder's seat. That's the view PulseRepo is built for: not another tool that reads your code, but one that reads how your team works on it.

Frequently asked questions

Is code analysis the same as static analysis?

Static analysis is one kind of code analysis. "Code analysis" broadly means any tool that inspects the source code itself — static analyzers and linters (SonarQube, ESLint) that look for bugs and style issues, plus code-search and code-understanding tools (Sourcegraph, AI explainers) that help navigate and explain a codebase. What they share is that the thing they examine is the code as it exists now, and they're built for developers.

Can Sourcegraph or Sonar tell me if my dev team is healthy?

Not really — that's not what they're for. They inspect the code itself, for engineers, to find what to fix or how something works. Team health lives one level up, in the process: whether knowledge is spread across people, whether changes get reviewed, whether tests keep up. A snapshot of clean code can be written by a single person about to quit, merged with no review — and a code tool can't see that, because the risk is in the history of how the code arrived, not in the code.

What is process analysis, in one sentence?

Process analysis reads the git history — the record of how the code came to be — to surface how the work is going: who owns what, whether changes are reviewed, whether tests move with features, what looks unusual. It's aimed at the person accountable for the software but not writing it, and its output is questions worth asking, not a fix or a score.

Do I need both code analysis and process analysis?

Usually yes, because they serve different people. Your developers should have good code-analysis tools — that's their trade. But if you're accountable for the product without reading the code day to day, a code tool answers a question you didn't ask. Process analysis is the read built for your seat: an independent view of how the work is going, in language you can act on. One keeps the code clean; the other tells you whether to be worried.

Is process analysis just engineering metrics like DORA?

It overlaps but isn't the same. DORA and similar metrics summarize delivery performance as numbers (deploy frequency, lead time) for engineering leaders to optimize. Process analysis aimed at a non-technical stakeholder does something different: instead of a dashboard of numbers, it produces plain-language questions — "why is all the payment code owned by one person?" — each backed by the specific commits and PRs behind it, so you can act without interpreting a metric.

Isn't reading the process a form of surveilling my developers?

It depends on intent, and here the intent is the opposite. Done right, process analysis never ranks or scores individuals — the output is questions about the work (is knowledge too concentrated, are tests keeping up), not a leaderboard of who committed most. Used to grade or discipline people, any tool becomes surveillance; used to ask better questions about your own project, git history is simply the primary record of what was built. If a signal could only be used to rank a developer, it doesn't belong in the report.

Which one do I actually need?

If your job is writing and maintaining the software, you need code analysis. If your job is being accountable for software other people build — as a founder, owner, investor, or client of an agency — you need process analysis, because it answers the question you actually have: is the work healthy, and what should I ask about? Most teams end up wanting both, pointed at the two different readers.

Keep reading