DEV Community

Cover image for The Feed Is Coming for GitHub
Naman Jain
Naman Jain

Posted on

The Feed Is Coming for GitHub

Before reels/shorts became mainstream, the common agreement about social media was that the moat was the network effect (friend’ s graph). The valuable thing about Facebook was that your friends were on it, and the friends-of-friends data sitting across all those profiles was an asset nobody thought could be replaced. You opened the app and you went to people’s profiles, walls, the network.

Then the feed (Algorithm) arrived. It started as a convenience layer on top of the graph: here's what happened today, what is trending, what people are posting about, in one place. But over a few years the relationship inverted. The algorithm became the product, and the graph became one input among many that the algorithm uses to decide what to show you. The graph never went away. It just stopped being where the value lived. Your profile, your friends and your likes, posts, comments are now consumed at the internal API layer; the algorithm is their customer.

This keeps happening to systems everyone assumed were permanent as many people are writing about. The clearest case in the enterprise is the CRM. Salesforce and HubSpot won because they owned the database: every call note, every contact, every reason a deal stalled lived in one place, and the cost of leaving climbed every year. That hasn’t changed. What’s changed is that a layer of agents now sits on top: research bots that brief a rep before a call, tools that listen to meetings and write structured notes back into the CRM, an orchestration layer that decides what the rep should look at first. The CRM didn’t die. It became an input to the thing the rep actually opens in the morning.

I think GitHub is next.

Value Chain

Why GitHub won

GitHub is the system of record for code. It has been the obvious, indisputable answer for fifteen-plus years, and the reasons are the same ones that made the CRM sticky. The code lives there. So do the pull requests, the issues, the review history, the CI runs, the CODEOWNERS file; years of accumulated operational context about how a codebase came together. Open source colonized it, which pulled in everyone else. Microsoft paid $7.5 billion for it in 2018 because owning the place where the world’s code lives is one of the great franchises in software

And GitHub did what every dominant platform does: it expanded outward from the database. Actions, Packages, Codespaces, Advanced Security; each new module built on the same spine, each one raising the cost of leaving. Every tool in the marketplace is, in effect, paying rent for the right to plug into GitHub’s data.

The reason the database won is worth stating plainly: code had to live in one place because the human working on it could only look in one place at a time. Concentration was a feature. The gravity came from accumulation.

What changes when the user is an agent

That premise is breaking. The thing increasingly working on the code isn't a human who can look in one place at a time. It's an agent that can look everywhere at once.

To a coding agent, GitHub is a database. A very good one; trusted, well-integrated, a decade of context, but a database. The agent doesn't need the PR review UI, the issues board, the merge-queue interface. It needs structured state it can read and write with low friction. The carefully designed human workflows on top become what an old profile page became after the feed: still there, no longer the point.

And an agent has no trouble pulling from GitHub and the issue tracker and Slack and the design files and the CI logs and production telemetry at once, then reasoning across all of it before it does anything. In the human era, value pooled wherever the data was. In the agent era, value pools wherever the reasoning happens. The layer that reads across every source and decides what to do. That layer treats GitHub as infrastructure.

The switching cost moves with it. “All our code is in GitHub” was the lock-in for fifteen years. “All our decisions, our coordination, our institutional context live in our agent layer” is the lock-in for the next fifteen. GitHub also sees this clearly, which is why it’s racing to build the intelligence layer inside its own walls, Copilot, a coding agent that goes from issue to merge, an MCP registry. It’s the same move Salesforce made: bring the AI inside, keep the value from migrating out. Whether it stays inside their walls is the open question.

The thing GitHub doesn’t store

Here's the gap. GitHub records the artifacts: the diffs, the merged PRs, the final state of the code. It does not record the decisions that produced them.

The thing that steers a codebase isn't the code; it's the decisions. "Auth is JWT, fifteen-minute expiry." "We renamed /login to /session." "Nothing new writes to that table." Those decisions live in people's heads, in Slack threads that scroll away, in docs that went stale the week they were written - and no agent ever reads any of it. GitHub only learns a decision happened after the conflicting code has already merged. By then it's a bug, not a heads-up.

What Github does not store

This gets acute the moment more than one agent is involved. Two developers point two agents - maybe Claude Code, maybe Codex, maybe Gemini - at the same system. Agent A renames an endpoint. Agent B, with no idea, keeps calling the old one and ships it. Agent A decides the token scheme; Agent B invents a different one. Nobody coordinated because there was nowhere to coordinate. The system of record holds the code. It holds nothing that lets these agents stay in sync before they act.

Where this points: Lockstep

This is the layer I’m building. Lockstep is the shared decision record every agent reads before it does anything.

When an agent starts a session, the first thing it gets is a briefing: here’s what changed since you were last here, here’s what’s binding; highest blast radius first, so the change that breaks three downstream services surfaces and the cosmetic rename stays quiet. Only then does it write a line of code. Rules files like AGENTS.md and decision docs like ADRs both help, but they’re written once and read rarely; neither carries a fresh decision from one agent to the next before the second one acts.

If that sounds familiar, it should. That briefing is the feed » the prioritised, one-place-to-look surface the VP of Sales now opens instead of a raw account list. Except the user is an agent, the inputs are decisions and contract changes instead of accounts and signals, and the output is code that doesn’t conflict. It works with any MCP-compatible agent, because a coordination layer has no reason to care which vendor is doing the typing; the same way the feed never cared which friend posted.

Lockstep Feed

GitHub keeps the code, for all the reasons it always has. But the value is moving up a layer » to the thing that reads across the whole record and decides what happens next. The friend graph never went away. The CRM isn’t going anywhere. Neither is GitHub. They’re becoming inputs.

The next decade of developer tooling gets built one layer up.

Top comments (0)