Your most reliable documentation isn't in Confluence. It's in git blame.
Every commit message, every PR description, every code review comment tells a story. "Fixed race condition in session handler that caused duplicate billing events." "Reverted auth change — breaks SSO for enterprise clients." "Refactored payment provider selection to support multi-region."
These aren't just commit messages. They're the institutional memory of your engineering team. And nobody reads them.
The Wiki Is Always Wrong
Every team has tried documentation. Confluence pages. Notion wikis. README files. Architecture Decision Records. The pattern is always the same:
New developers read the docs, trust them, and make incorrect assumptions
Someone adds a banner: "This page may be outdated"
Nobody updates it. Nobody deletes it. It rots.
The fundamental problem: documentation requires active maintenance, and maintenance requires motivation. Engineers are motivated to ship features, not to update wikis.
What Your Git History Actually Contains
Your version control system has been faithfully recording everything your team has done for years. It contains:
Decision History
Every PR description explains why a change was made. "We switched from Redis sessions to JWT because Redis was a single point of failure during the AWS us-east-1 outage." This is an Architecture Decision Record that nobody had to write separately — it was captured as part of the natural development workflow.
Regression Patterns
Your git history knows which files cause the most reverts, which changes tend to break things, and which areas of the code are fragile. "The last 3 changes to the webhook handler all caused production incidents." This is risk intelligence that no wiki captures.
Expertise Mapping
Git blame shows who wrote the code. PR history shows who reviews it. Commit frequency shows who actively maintains it. Together, these create a map of who knows what — automatically, without asking anyone to fill out a skills matrix.
Feature Boundaries
Change coupling analysis — which files tend to change together — reveals the actual feature boundaries in your codebase. Files that always change in the same PR belong to the same feature, regardless of what directory they're in. This is architecture truth derived from behavior, not from outdated diagrams.
Evolution Patterns
How has the codebase evolved? Which areas are growing? Which are stable? Which are being actively refactored? Git history is a time-series dataset of your codebase's evolution. It tells you where the code is heading, not just where it is.
The Bus Factor Problem
Every engineering team has knowledge concentration risk. Two or three people who understand critical systems deeply. When they're on vacation, those systems don't get touched. When they leave, the knowledge walks out with them.
The traditional solution: make them write documentation before they leave. But they're leaving — they're not motivated to write docs. And even if they do, static documentation can't capture the judgment calls, the "I tried X but it didn't work because of Y" knowledge that experienced engineers carry.
The better solution: extract knowledge from the artifacts they already created. Every PR they reviewed, every commit they made, every code review comment they wrote is a piece of their expertise captured in the system. The question is whether you can surface it when someone else needs it.
Practical Knowledge Extraction
1. Change-Coupled Files
Run a simple analysis: which files change together in the same commits? This reveals hidden dependencies and feature boundaries.
2. Hotspot Analysis
Which files have the most commits AND the most authors? These are collaboration hotspots — areas where knowledge is distributed. Files with many commits but few authors are knowledge concentration risks.
3. PR Archaeology
For any file, surface the last 5-10 PRs that modified it. The PR descriptions, review comments, and linked issues contain the context that future developers need.
4. Expertise Graph
Build a graph of who-knows-what based on authorship and review history. When a developer needs to understand the payment system, instantly show them: "Sarah wrote 60% of this code, Mike reviews most changes, and the last significant refactor was in PR #847."
5. Regression Memory
For any file or feature, surface past incidents. "This function was involved in 2 production incidents in the last 6 months. Both were related to null handling in the response parser."
From Knowledge Extraction to Knowledge System
Individual knowledge queries are useful. But the real power is turning your codebase into a queryable knowledge system.
"What does the auth flow do?" → traced answer with file references, not a stale wiki page.
"Who should review changes to the billing service?" → expertise graph, not a guessed CODEOWNERS file.
"What will break if I change this function?" → dependency analysis, not a developer's best guess.
"Has this been tried before?" → PR history showing previous attempts and why they succeeded or failed.
This is what Glue builds. Not documentation — a knowledge system derived from the most reliable source of truth your team has: the code itself and its history.
Keep Reading
Tribal knowledge loss is the silent version of the Understanding Tax. When knowledge lives in heads instead of systems, every departure and every vacation creates a productivity crater.
Glue extracts tribal knowledge from git history, PR descriptions, and code review comments — turning your codebase into a queryable knowledge system. This is pre-code intelligence: making institutional memory accessible before developers start coding.