The Code I Write Today Might Be Reviewed by an AI Agent Tomorrow

Last week I spent twenty minutes writing a commit message. Twenty minutes. For a three-line bug fix.

A year ago I would have typed fix bug, smashed enter, and moved on with my life. But I've been thinking a lot lately about something GitHub's former CEO Thomas Dohmke said in a recent interview about where developer tools are headed: 2026 is going to be the year of "repository intelligence" — AI agents that don't just autocomplete your next line, but understand the entire history of your codebase. The relationships between files. Who changed what, when, and why. The reasoning that never made it into the code itself.

Which means the sloppy fix bug commit I would've written last year is going to be the exact thing some future agent trips over when it's trying to figure out why my function exists.

So yeah. Twenty minutes on a commit message. And I think it was worth it.

What "Repository Intelligence" Actually Means

The easiest way to understand the shift is to think about what today's AI coding tools can and can't do. Copilot and Claude are brilliant at the local context — the file you have open, maybe a few related ones. But ask Copilot "why does this service use a custom retry wrapper instead of the standard library one?" and it has no idea. The answer lives in a Slack thread from eight months ago and a PR description nobody reads anymore.

Repository intelligence is the idea that AI should have access to all of that — the commit history, the PR discussions, the issue threads, the review comments, the author patterns — and use it to reason about code the way a senior engineer does. Not "what does this function do" but "why does this function exist, and what happens if I change it." GitHub is already rolling pieces of this out with Copilot coding agent, which can take an issue, plan a fix, open a PR, and iterate on review feedback. Claude Sonnet 4.5 and the Agent SDK are pushing in the same direction — long-running agents that can work across an entire repo for hours at a time.

If you've used any of these tools seriously, you already know the failure mode: they are only as smart as the context you give them. Garbage history in, garbage suggestions out.

The "why" vs "what" problem

Every senior dev I've worked with eventually hits you with some version of this: "the code tells you what it does. The commit history and docs are supposed to tell you why." For humans that's a nice principle. For AI agents reading your repo, it's load-bearing. An agent can read your code and figure out what it does on its own. It literally cannot figure out why you chose this approach over the alternative unless someone, somewhere, wrote it down.

Why Juniors Should Care More Than Anyone

Here's the uncomfortable truth I keep coming back to: senior devs already write good commits, good PR descriptions, and good comments. Not because they're saints, but because they've been burned enough times by their own past sloppiness to know better. Juniors — and I'm including myself here — usually haven't had that lesson beaten into them yet.

Which means when repository intelligence lands for real, senior engineers get a quiet, free upgrade. Their past work is already legible to AI. And juniors get the opposite — years of wip, fix, and addressed pr comments commits haunting every file they touch.

I've been applying to co-ops and summer positions, and my GitHub is basically my resume. If a hiring manager in six months points a code-review agent at one of my repos and asks "is this person's work high quality?" — the agent's answer is going to depend almost entirely on whether my history is readable. Not on whether the code compiles. Not on whether the tests pass. On whether future-me (or future-AI) can reconstruct my thinking.

That's a terrifying thought. It's also kind of liberating, because it means the path to looking more senior isn't "grind more LeetCode." It's "write like someone else is going to read this, because they actually will."

What I've Actually Changed

I don't want this to be one of those posts where the advice is "just be better." So here's what's concretely different about how I work now compared to six months ago.

Commit messages are a first draft of documentation. The format I've settled on: one line describing what, a blank line, then 2–4 sentences describing why. The "why" section answers the question "what were the alternatives and why didn't I pick them?" Sometimes the answer is "this was the only thing that worked" and that's still valuable — it tells a future reader that the obvious approach didn't work, which saves them from reinventing the same wheel.

PR descriptions are for the agent, not just the reviewer. I used to write PR descriptions assuming a human teammate would read them with full context. Now I write them assuming a reviewer — human or AI — might open the PR cold, six months from now, and need to understand not just what changed but what problem this was solving. That means linking the issue, quoting the relevant error message, and explaining any non-obvious decisions.

Comments explain decisions, not mechanics. If the code is doing something weird, I don't write // increment i. I write // we skip index 0 because the API returns a sentinel row. The first comment insults the reader. The second one saves them (or their AI agent) a trip to the API docs.

I let AI write the first draft of docs, then rewrite it. This sounds contradictory but it isn't. Claude is genuinely good at producing a reasonable first pass of a README or a function doc. But it only knows what the code does, not why you wrote it. So I let it do the boring structural work, then I go back and inject the context only I have. The result is better than either of us would produce alone, and it takes about half the time.

A little test I do now

Before I merge anything non-trivial, I ask Claude: "based only on the diff and the commit message, explain why this change was necessary." If the answer is wrong or vague, that's a signal my commit message is under-documented — and if an AI can't figure it out from what I wrote, neither will future-me at 2am debugging prod. It takes ten seconds and it's caught me being lazy more times than I want to admit.

The Honest Take

I'm not fully sold on the repository-intelligence hype. We've heard "this is the year AI agents change everything" a few times now, and the reality usually lands somewhere between the marketing and the backlash. I wrote about agentic AI hitting the trough of disillusionment already, and I still think that's roughly where we are.

But here's the thing — even if repository intelligence takes another two years instead of arriving in 2026, writing cleaner commits and better PR descriptions is a pure-upside habit. It helps your teammates today. It helps future-you debugging your own code at 2am. It makes your GitHub more legible to the hiring manager who doesn't have time to read every file. And if the AI-agent-reviewing-your-code future does arrive, you're already ready for it.

The downside case is "I wrote slightly nicer commits for no reason." The upside case is "my entire body of work is AI-legible while everyone else is scrambling to retroactively document theirs." I'll take that trade every time.

Closing Thought

The developers who thrive in the next few years aren't going to be the ones who write the most code. They're going to be the ones whose code is the easiest for other intelligences — human or otherwise — to understand, trust, and build on.

That's a skill you can start practicing on your next commit. Not in 2026. Not when GitHub ships the next version of Copilot. Tonight.

Go write one commit message that your future self, or a future AI agent, will actually thank you for. It takes five extra minutes. It might be the highest-leverage five minutes of your week.