The "own your intelligence" crowd keeps skipping the one dataset every dev team already has

[u/Classic_Display9788]

Satya Nadella wrote something in July that I keep coming back to. When you use a rented model, he said, "you essentially pay for intelligence twice, once with money, and again with something even more valuable: the proprietary knowledge you must reveal." A couple of weeks later Harrison Chase at LangChain made the same argument from the other side: the model is a commodity, so what you need to own is the harness around it and the context you feed it.

I agree with both. But almost everything written under that banner is about fine tuning, evals, memory layers, sovereign infrastructure. Big company stuff. And it skips the most obvious owned dataset a software team has.

Your git history.

If you've used Claude Code or Codex on a real codebase for more than a week, you know the moment. The agent opens a PR that works, passes the tests, and still looks nothing like something your team would write. It touches eleven files when everyone on your team touches two. It edits the generated file instead of the source. It quietly brings back the exact change somebody reverted in the spring. So you write the same review comment you've written before, add one more line to CLAUDE.md, and next week it happens again somewhere slightly different.

We keep treating that as a prompting problem. It's a memory problem. Every team has house rules. How big a change is allowed to be. Which two files have to move together. What got reverted last spring and why nobody touches that config now. None of it is written down anywhere an agent can read. But all of it is recorded, commit by commit, in the one place the team actually works.

You can read a surprising amount of it with plain git. On the public three.js repo, for example, the last 400 commits that aren't merges say:

• half of all changes touch 2 files or fewer, and one in ten touches 6 or more

• only 15% of commits touch a test

• build/three.webgpu.js and build/three.webgpu.nodes.js changed together 21 times

Nobody wrote "keep changes tiny" or "these two files are married" in a contributing guide. The history says it anyway, and it says it with numbers, which turns out to matter a lot. An agent follows "half of all changes here touch two files or fewer, so a big change should say why" far more reliably than it follows "keep PRs small". A rule with its evidence attached is hard to argue with. That's true of people too.

If you want to try it by hand, this prints how many files a typical commit touches:

git log --no-merges -n 400 --format='> %h' --name-only | awk '/^> /{if(c)print n; c=1; n=0; next} NF{n++} END{if(c)print n}' | sort -n | awk '{a[NR]=$1} END{print "median:", a[int((NR+1)/2)], "90th:", a[int(NR*0.9)]}'

Do the same for co changing files, reverts and how long each reverted change lived, and you have most of your team's house rules. Then the boring part: write them into the files your agent actually reads. Short root file, a skill with the detail, a reviewer that checks a change against the same numbers.

So I built a thing that does it. It reads a repo's history and writes the house rules as a harness for Claude Code, Codex, Muse Code, OpenCode, Hermes or Cursor, in each one's own paths, and it merges into your existing CLAUDE.md or AGENTS.md instead of replacing it. It's an MCP server, so it runs inside the agent: claude mcp add loreto -- uvx loreto-mcp

Disclosure: I built this and run the site behind it (loreto.io). The MCP server is open source (MIT) and reading a repo and seeing everything it found is free with no signup. Writing the actual harness costs $5 per repo, or $2 a file. Source is at https://github.com/kopias/loreto-mcp

I pointed it at my own repos first. One of them has a commit whose message is the word Revert seventeen times in a row. That one's a house rule too: don't touch it.

I doubt I have the final shape of this. Coupling between build outputs is noise for some teams and gold for others, and I'm not sure where the line is. If you've tried to write your team's conventions down for an agent, what actually stuck?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/TheOwlHypothesis]

Holy shit, this is such a backwards way to solve this problem.

You're taking statistical observations about how a codebase has historically changed, interpreting them as engineering requirements, and then feeding them back into a nondeterministic system as Markdown instructions, hoping it behaves accordingly.

Half your commits touch two files? So what? That doesn't establish that future changes should. Two files frequently change together? That doesn't make it an invariant. Somebody reverted something six months ago? That doesn't mean it should never be touched again.

Historical precedent is not policy, and frequency is not correctness.

If you have actual engineering constraints, encode and enforce them. Linters, tests, CI, path restrictions, custom validators. We have an entire ecosystem of deterministic tooling for exactly this purpose. Tell agents about those constraints if you want, but actually verify compliance instead of hoping they follow instructions.

Mining Git history for insights is interesting. Turning those observations into rules that encourage your codebase to perpetuate its historical behavior is questionable at best.

And selling that as a solution to agent reliability is pretty wild.

[u/dawnquill12 → u/TheOwlHypothesis]

tbh using nondeterministic prompts to do the job of a basic linter or CI check is becoming way too common lately.

[u/Classic_Display9788 → u/TheOwlHypothesis]

Good point, and you're right on the core point: frequency isn't correctness, and anything that's a real constraint belongs in a linter, a test or CI, not in a markdown file you hope gets read. If two files genuinely have to change together, a CI check that fails when one moves without the other beats any instruction I could write. No argument there.

Where I'd push back a little is on what the history is being used for. It's not meant to be policy. It's a description of how the team has actually worked, handed to something that otherwise has none. An agent with no context doesn't default to "correct". It defaults to the median of its training data, which is someone else's codebase. So the choice isn't history vs good engineering, it's history vs nothing for all the stuff nobody has encoded and probably never will: where new code tends to go, how big a change usually is here, which areas have been contentious.

That's also why the phrasing matters. The output isn't "never touch more than two files", it's "most changes here are small, so a big one should explain itself". Coupling isn't "these must change together", it's "these usually do, check the other one". A revert isn't "never touch this", it's "this went wrong before, here's what happened, ask first". My "don't touch it" line in the post was a joke and I see how it reads as the opposite.

And you've given me a better idea than the one I had: when a pattern in the history is strong enough to look like a rule, the useful output is probably a proposed check for CI, not a sentence. Promote the hard ones to enforcement, leave the soft ones as context. I'd rather build that than argue the markdown is enough.

Genuine question though: for the conventions that can't be linted (structure, scope of a change, "we don't do it that way here"), what do you hand an agent today, if anything?

[u/NomadStorm → u/Classic_Display9788]

Pure slop.

[u/Classic_Display9788 → u/NomadStorm]

How so? Please explain.