Ambient Git Learning:
your commit history as AI knowledge

Think about what a git log actually contains. Every commit message is a compressed summary of a decision: what changed, why it changed, and (sometimes) what would have happened if it hadn't. The diff tells you what; the message tells you why. Together, they're a narrative history of every meaningful change your team has made.

Deploy commits capture exactly when things went to production and what was in them. Hotfix commits mark the moments when something broke badly enough that normal process was bypassed. Merge commits show which features took how long. Revert commits are particularly rich — they mark places where something went wrong enough to undo.

This is a goldmine of operational knowledge. But it's completely invisible to AI coding assistants. They start every session with no knowledge of what your team has deployed, what broke last week, or what patterns have emerged over months of real-world usage.

The word "ambient" is deliberate. Most knowledge-capture tools fail because they require effort at the moment of least availability: when you've just fixed a hard bug and you're tired. You intend to document it. You don't.

Ambient Git Learning works differently. When you end a session — something you already do — the AI looks at the workspace, reads the recent git log, and extracts lessons automatically. Commits become Brain entries. The deploy history becomes searchable context. Hotfixes become severity-flagged lessons.

You don't write the lessons. You don't categorize them. You don't decide what's worth saving. The AI does that, and you can review and refine later if you want. The default is: do nothing extra, and the Brain learns anyway.

Not all commits are equal. A typo fix and a production incident hotfix have very different informational value. Ambient Git Learning uses commit classification to weight lessons appropriately:

• Deploy commits — captured as deployment lessons with the exact changed files and timing. Next time you ask your AI about the deploy process, it has recent real history to draw on.
• Fix/hotfix commits— stored as higher-severity lessons. The Brain knows these mark places where something went wrong; it surfaces them proactively when you're working on related code.
• Refactor commits — captured as architectural context. Over time the Brain builds a picture of which parts of the codebase have been actively evolving and which have stabilized.
• Revert commits— the most informative of all. A revert is explicit evidence that something was wrong. These become warning lessons that the AI can surface when you're about to make a similar change.

One specific pain point this solves: deploy history as AI context.

When something goes wrong in production, one of the first questions is "what changed?" Developers run git log, check the deploy timeline, correlate commits with incidents. The AI assistant has no idea any of this happened.

With Ambient Git Learning, the Brain has a running record of recent deploy activity. When you start an incident investigation session, the briefing includes relevant deploy history automatically — without you having to manually explain that there was a deploy at 2pm, here are the commits, here's what changed. The AI already knows.

A reasonable concern: does this mean your commit messages and diffs are being sent somewhere?

The short answer: only what you explicitly allow. Ambient Git Learning reads the git log summary (commit messages, files changed, timestamps) to generate structured Brain lessons. The lesson content is what's stored — not raw diff output, not commit metadata beyond what's needed for the lesson.

All data is stored in your private Brain instance, running on EU-based servers. Nothing is shared with third parties or used for training. If you're running a self-hosted Brain instance, the data never leaves your infrastructure.

The most interesting property of Ambient Git Learning is that it compounds. After a week of use, the Brain has a record of a week's worth of commits. After a month, a month. After a year, the AI has access to a year of operational history — who deployed what, what broke, how things were fixed.

This creates a qualitatively different kind of AI assistant. Not just one that remembers the last session, but one that has genuine long-term institutional memory. The kind of knowledge that usually only comes from years of experience on a codebase — accumulated automatically, without anyone having to manually curate it.