Part 1 — Mining lifecycle patterns from git history
⚡ TLDRWhat: A CLI tool (hermes-harness) that mines git history for recurring failure/fix patterns and makes them searchable across repos. “Has this failure happened before?” → answer in milliseconds.
How: Reads full git history → extracts reverts, file coupling, topic clusters → compresses each pattern into a 128-dim vector → cosine similarity search. No AI at query time.
Who it’s for: Tech leads and platform engineers managing 3+ repos who’ve said “we fixed this last quarter” and couldn’t find the ticket.
Try it: npm install -g hermes-harness && hermes-harness seed-query “your error”
Contribute: github.com/vystartasv/hermes-harness
The narrow band this fits into
This tool is useful in exactly one scenario: you have multiple repos that share failure patterns, and you can’t keep track of them in your head.
That’s it. If you’re a solo dev with one repo, your memory is enough. If you never revisit old tickets, the hints are noise. If every bug is novel with no precedent, you won’t find matches.
The shape of a team that needs this:
3+ repos in active development (different stacks, same org)
Recurring failure classes — auth timeouts, dependency conflicts, CI flakiness, config drift
Tribal knowledge problem — the person who fixed it last time has moved on or forgotten
Ticket boards with resolved items nobody reads
The tool doesn’t predict novel failures. It connects the dots between the ones you’ve already seen and fixed.
A few years ago, Yann LeCun published A Path Towards Autonomous Machine Intelligence. The core idea: an intelligent system doesn’t need to model every pixel of the world. It needs a world model — a compressed representation that predicts what happens next and flags what’s surprising.
Most people read that paper and thought about self-driving cars.
I read it and thought about git log.
The problem
Every project I’ve worked on has the same memory problem. You fix a bug, close the ticket, move on. Three months later, the same class of failure hits a different repo — different stack, different team, same root cause. Nobody connects them because nobody searches across repos for lifecycle patterns.
We have code search (Sourcegraph, GitHub Code Search). We have error tracking (Sentry, Datadog). We have observability (Grafana, Honeycomb).
We don’t have history search — the ability to ask “has this failure pattern happened before?” and get answers from every repo, every ticket, every commit across your entire organization.
The JEPA insight
LeCun’s Joint Embedding Predictive Architecture compresses high-dimensional observations into a latent space where prediction happens. Pattern → vector. Predict in vector space. Flag when prediction doesn’t match reality.
A git repository isn’t code. It’s a history of state changes — commits, reverts, file co-changes, ticket reopens. Every revert is “we tried X and it didn’t work.” Every reopened ticket is “the first fix was incomplete.” Every pair of files that always change together is “these are coupled.”
That’s a world model. It’s already there. It just needs to be compressed and made searchable.
What I built
hermes-harness mines git history for lifecycle patterns and compresses them into a searchable world model.
npm install -g hermes-harness
# Query across 11 pre-indexed public OSS repos
hermes-harness seed-query “dependency version conflict”
# → 48% match: “Playwright version roll” (playwright-go)
# → 28% match: “dependency bumps and fixes” (chatbot-ui)
# Mine your own repos
hermes-harness mine-git
Enter fullscreen mode
Exit fullscreen mode
The extraction pipeline:
Read full git history — subjects, bodies, files, parents, dates
Extract — revert chains (pure signal: “we tried this and it didn’t work”), file coupling (latent architecture), topic clusters
Compress — each pattern becomes a 128-dim word-count vector (no GPU, no API, pure arithmetic)
Query — cosine similarity across all vectors, results in milliseconds
No AI at query time. Once trained, the entire model fits in 200KB and runs on a $5 VPS.
The seed
I ran it against 11 public repos: LangChain, Next.js, Svelte, Vite, Supabase, n8n, Biome, and others. 21 patterns surfaced from ~2,200 commits.
The seed is sparse. That’s the point. It’s a demonstration that the mechanism works — not a finished product. The model needs data.
Credit where it’s due
The conceptual foundation comes from Yann LeCun’s work on world models and the JEPA architecture:
The implementation is trivial by comparison. I just replaced neural embeddings with word-count vectors and pixels with git commits. The insight isn’t the code — it’s that every repo already contains a world model. The code just extracts it.
How you can help
The world model gets better every time someone runs the harvester against a repo they care about. If this concept fits your narrow band:
Clone your favorite OSS repo and run hermes-harness seed-harvest
Export the patterns with hermes-harness seed-export and open a PR
Mine your own repos — private, local, no data leaves your machine
Write a new miner — Slack channels, calendar events, browser history — the same pattern applies to any system with state changes and repetition
The architecture is designed for contribution: one JSON file per world, a shared vocabulary, cross-repo search that doesn’t care where the patterns came from.
What’s next (the series)
This is Part 1 of a series on world models built from everyday data:
Part 2: Mining ticket boards for lifecycle patterns (reopens, incomplete fixes, root causes)
Part 3: Cross-repo querying — when a pattern in LangChain helps debug a Supabase issue
Part 4: Beyond code — calendars, Slack channels, browser history as world models
Package: npm i -g hermes-harnessCode: github.com/vystartasv/hermes-harnessContributing: CONTRIBUTING.md
Leave a Reply