Your repo isn't a codebase anymore

Here’s what just happened to public GitHub repos:

That curve counts public repos containing a file called AGENTS.md, CLAUDE.md, COPILOT-INSTRUCTIONS.md, or one of their cousins — instructions written for AI coding agents and AI-augmented editors to read. About 7,000 such repos existed in May 2025; a year later, roughly 153,000 do. A 22× rise in twelve months.

I noticed this because I tried to share an agent-generated report with a client one day and realised I had no clean way to do it. When I looked at the five repos I spend most of my day in, their shape was wildly different from the repos I was working in five years ago.

An increasing share of what lives inside a repo today is no longer code. Repos used to be for developers and used to contain mostly code. Now repos are being used by everyone (read: vibe coder) and not just for code.

Repo 2.0

A repo today has three layers.

Code — still there, more of it, increasingly generated rather than written. This is the part everyone has absorbed.

Harness — anything else the agent uses to execute a workflow. Prompts, skills, memory, instructions, planning documents, MCP server configs, hooks, slash commands, sub-agent definitions — and the dozen other ways people give context and tools to an agent. Mitchell Hashimoto coined “harness engineering” and there’s a big non-code part to this engineering.

Outputs — anything the agent produces, transient or permanent. Audits, reports, summaries, structured content, generated data. Code output used to be captured as logs and structured data stored in databases. Neither lived inside the repo. That isn’t true anymore — especially when the agent runs locally, its outputs land where it ran, not in a cloud database somewhere else. A salesperson running an agent to build and enrich a list of prospects, then send out the outreach, isn’t going to set up a database. The file ends up inside the repo. I know you’re probably thinking — who commits all of that? I do. Quite a few other people do too.

Three layers, all sitting in the same Git tree.

This is where your agents live and work

Agents live inside the same repo they work in. No work-life balance for them. The harness is how the agent is configured to do that work; the code running in the local environment is the agent at work; and the outputs are what falls out of doing it. Everything ends up in the same Git tree as the code, because that’s where the agent was running when they came into existence.

I know plenty of people will look at this and say it isn’t right — that this isn’t what repos are built for, that this isn’t how anyone should be doing things. Maybe they’re right. The fact remains that this is how people are building today. I’m not making a case for whether the pattern is correct; I’m making the case that this is a pattern.

Once you’re working this way, the files accumulate by inertia. The audit report the agent just wrote. The CSV it just compiled. The planning doc it produced before the work. The eval transcript it logged after. The updates in instructions. You get the gist.

This is where the tooling stops working

Code editors were built to write code. Git was built to version it. GitHub (and others) let developers collaborate on code at scale. Over the last decade these three layers got tighter and smoother. Your editor knows about your branches, your branches know about your reviews, your reviews show up next to the diff. It is a beautifully integrated stack for one specific job: devs writing code together.

Repo 2.0 by contrast is like a poorly-oiled self-running machine. That’s why friction shows up.

Code editors aren’t good at viewing non-code. They were built to write code, and they’re excellent at it. Folders of agent-generated markdown are a worse fit — preview panes exist, but they’re for spot-checking one file, not for browsing fifty. Karpathy’s answer in his LLM-wiki writeup is to layer Obsidian on top of the folder, and a lot of people have landed in the same place independently:

The native viewing experience for the artifacts that now make up most of the repo is bad enough that the pragmatic answer is to install a second app to read them.

Tables are worse still. A concrete example I hit weekly: I’ll ask the agent to pull rows from a few sources — a GA4 export, a database, scrape stuff from the web — clean them up, and produce one sheet. The result lands as a CSV in the repo, a few thousand rows. Now I want to spot-check it. Open the file in VS Code or Cursor and you get a wall of comma-separated text. Install the obvious preview-as-table extension and it renders the first few hundred rows, then chokes — sluggish scroll, no working sort, columns that bleed past the pane. The next obvious answer is to open the file in an external viewer (Numbers, Excel, a Jupyter notebook), at which point you’ve left the workspace where the agent that produced it lives. Any feedback I have (“row 1,847 looks wrong, the source field is empty”) has to make a manual round-trip through prose to reach the agent.

Sharing breaks down outside the developer/PR shape. GitHub’s collaboration model assumes you are sending a coherent code change to another developer for review. In an agent-workplace repo, you maybe want to send one specific artifact — a generated report, a markdown summary, a planning doc — to one specific person who probably doesn’t have a GitHub account.

The example I hit twenty times a week: I work with agents to generate audit reports for clients. The agent’s context, prompts, and harness live in a repo, so the report lands in the repo too. And a lot of the time I’m running the agent on my laptop from my phone. In a previous version of this workflow I would have run code in the repo, copied the numbers into an Excel file, and dropped them into a Word document or a deck the client could read, comment on, sign off on. The work lived in so many places that the final report became the source of truth. Now everything happens in the same repo and I’m not sure what to send. I can’t share the repo — it has other clients’ work, my private prompts, and context I don’t want anyone else to see. If I paste the markdown into a Google Doc, the client’s comments live in the Doc, not in the repo, and the agent can’t read them. That leaves me copy-pasting comments back to the agent. That defeats the whole point of having the agent run the process. I want the agent to handle the small logistical loop so I can focus on the high-value work: giving it better context, applying judgement to improve the output.

The unit of sharing has fragmented. People used to share repositories or pull requests. Now they share skills, prompt files, single CSVs, individual reports, modular pieces of code meant to be loaded into another agent. None of that is what Git or GitHub was built around. My global skills folder is symlinked to a standalone repo so my team can use the same skills. The LLM wiki is symlinked to iCloud storage so that my Obsidian iOS app can access it; the rest of the harness is not shared.

What needs to exist

What needs to exist is a bridge.

On one side is the repo, where the work happens. The agent’s context, harness, and outputs all live there.

On the other side is the entire layer of collaboration tools we’ve built over the last decade. Google Docs, Sheets, Slides. Notion. Loom. Linear. Figma. The places where people actually work on non-development tasks together, share, review, and sign off on things.

Between the two: nothing. Today the only way for an artifact to cross from one side to the other is for me to manually move it, and the only way for feedback to come back is for me to manually paste it. The bridge between the workplace and the collaboration layer is the thing that doesn’t exist.

Concretely, that bridge has to answer questions like:

• When the agent writes a markdown file, how does someone who needs to review it actually read it?
• When the agent produces a CSV, how does a reviewer point at row 1,847 and tell the agent something is wrong, in a way the agent can read?
• When something in the repo updates, how does the person who cares get notified — outside the pull-request flow? PRs are where developers collaborate on code; they aren’t where work-collaboration happens.
• When two or more agents are working in or across repos, how do they hand off to each other in a way the human can audit?

None of these are answered by code editors + Git + GitHub today. None of them are answered by Google Docs or Notion either, because those products don’t know the repo exists.

The pattern isn’t unique to agents-and-repos. Code editors used to be the GUI for whatever development was happening underneath them; CLIs became the de facto GUI for the agentic version. Neither is the right shape for what work has become. a16z’s speedrun fund put out a request for startups to build the GUI for agents, saying: “we’re still in the MS-DOS era of agents today.” Anthropic launched Claude Cowork, essentially a lite version of Claude Code with an actual GUI that’s not the CLI (but isn’t much better imo). The work can keep happening where it does. The interaction layer is what changes.

If I had to bet: GitHub won’t ship the bridge. The answer is going to come from independent tooling. Multiple small products, a few of which get widely adopted. Obsidian is one of the candidates: people already install it on top of agent repos as a reader, and the team is hiring (the recently posted engineering role would be a ~33% jump on a current team of three). It will cover some of the use cases.

The bridge in full is bigger than what one product can solve, and the shape of future collaboration is still being built out as agents become more commonplace in the everyday workforce.