oobo
Git layer that preserves the why behind AI-written code
Start new thread
Teddy

oobo - Git layer that preserves the why behind AI-written code

by
oobo
•
Oobo is Git for agents (and humans). It enriches your repo with additional context about AI usage, helping agents and teams understand why something was built, how decisions were made, and what happened around the code, not just in the final diff.

Add a comment

Replies

Best
Teddy
Maker
📌
We built Oobo because AI is writing more and more of the code, but almost none of the context around that work is preserved in a useful way. You see the final diff, maybe a commit message, but not what the agent was trying to do, why a decision was made, what changed during the process, or how a human and one or more agents got to that result. That started feeling like a real gap. The idea evolved into a Git decorator because we didn’t want to replace Git or force people into a brand new system. Git already owns the code history. What was missing was the extra layer of context around AI usage and build decisions. So Oobo became a way to enrich normal Git workflows with that missing context, making it easier for both agents and humans to understand what happened around the code, not just the code itself.
Denis Akindinov

How does Oobo capture and structure AI decision context without significantly increasing repository size or slowing down existing Git workflows?

Teddy
Maker

Great question @mordrag, three design decisions make this work:

1. Git runs first, Oobo enriches after. Oobo sits in front of git as a transparent proxy (alias git=oobo). When you run git commit or oobo commit, the real git binary executes first and completes at full native speed. Only after a successful commit does Oobo attach metadata such as session links, attribution, token counts. If anything goes wrong with the enrichment step, the commit still succeeds. Oobo never blocks git.

2. Metadata lives on a separate orphan branch, not in your code history. Anchor data is written to an orphan branch (oobo/anchors/v1) using low-level git plumbing commands, so your working tree, index, and code history are never touched. Each anchor is a small JSON file (~1-2 KB) keyed by commit hash. It doesn't show up in git log, doesn't affect diffs, and doesn't bloat your main branch. Entries are sharded by hash prefix (similar to git's own object storage), so concurrent agents writing anchors never create conflicts.

3. Heavy data stays local by default. Full transcripts, search indexes, token analytics, and cross-project queries all live in a local SQLite database, not in the repo at all. Only lightweight metadata syncs through git. Transcript sync is opt-in (we call it "transparency mode") and even then, transcripts are redacted before they leave your machine.

The net effect: a typical commit adds maybe 50-100ms of overhead and a few KB to a branch you'll never look at directly. Your git log, your diffs, your CI are all unchanged.