The End of GitHub (As We Know It)

I've been thinking: why do we still need GitHub's collaboration tools when working with AI agents?

Seriously. When you work with AI agents, everything goes into the repository anyway - epics, user stories, PRDs, tasks, all the context agents need. You can set this up without GitHub at all. You just need git itself for version control.

Where's the value in GitHub Issues that agents can comment on? AI agents work autonomously. They might write a comment, but it's just information. There's no real interaction value - you won't let random comments create new tasks for your AI agents.

For greenfield AI projects where AI writes everything? Agents don't need Issues, Projects, Wikis, or any of that. They work with files in the repo. Making network calls to create issues is pointless when everything can live directly in git. Why use a human-designed UI when agents don't need it?

GitHub keeps adding AI features - Copilot in the IDE, Copilot for PRs, Copilot Workspace. But they're polishing a system that's becoming obsolete. They're teaching AI to use human tools instead of building tools for AI.

The Repository as Ground Zero

Think about it - everything an AI agent needs could be stored in your repo:

• Your PRDs? Markdown files.
• Architecture docs? More markdown.
• User stories and acceptance criteria? Text files.
• Security policies and style guides? YAML or JSON configs.

AI doesn't need fancy web UIs. It reads files, writes code, commits changes. The git history tells the whole story. So why are we making network roundtrips to create issues? Why click around in browsers when everything happens in the repository?

This is what makes GitHub's current model obsolete for AI development. All those collaboration features - Issues, Projects, Discussions - they're built for humans. AI agents don't need them.

AI-Agent Workflow vs. Traditional GitHub Workflow

Here's what this look like in practice

The traditional workflow is built around human discussion and decision points. The AI-agent workflow runs on files and automation.

Spec-Driven Development in the Wild

Let me show you what's actually happening out there. It's not just one framework or one team - multiple approaches are converging on the same pattern: forget GitHub's UI, put everything in the repo.

The BMAD Method

Take BMAD (Breakthrough Method for Agile AI-Driven Development) - a framework that assigns AI agents to traditional Agile roles like developer, QA, scrum master, etc... It works like this: Your PRDs and architecture docs sit in/docs. The SM agent reads them and generates for instance a story-1.1.md file with tasks, tests, technical notes. No GitHub Issues - just markdown. The dev agent grinds through tasks: write code, write tests, run CI. Only marks [x] when everything's green. The QA agent doesn't comment on PRs - it refactors the code directly, adds missing tests, documents changes. Everything tracked in git commits.

Product Requirement Prompts

Or look at PRP (Product-Requirement Prompt) - a methodology for encoding entire feature requirements into structured markdown files that AI agents can execute autonomously. Different approach, same conclusion. They bundle PRDs, codebase intelligence, and runbooks into*.prp.md files that live next to your source. Feed that to an agent, it ships a vertical slice in one pass. No issue tracking, no project boards - specs are the single source of truth.

Kiro - A Spec Driven IDE

And now Amazon's jumping in with Kiro - an autonomous IDE that turns prompts into specs, plans, and code. Where does it store everything? In the repo as "blueprints" alongside verification checks and change logs. Even hyperscalers are betting on files over web UIs.

See the pattern? BMAD, PRP, Kiro - they all ditch GitHub's collaboration layer. Everything's a file. Every decision's a commit. The repository isn't just where code lives - it's where everything lives.

This isn't about one framework being perfect. BMAD can get chatty, PRP needs disciplined prompt hygiene, Kiro's still in preview. But they're all solving the same problem the same way: specs-as-code, docs-as-truth, agents-as-doers. No Issues, no Projects, no Discussions.

The message is clear: when building AI-first, GitHub's UI becomes more of an extra layer than a necessity. These frameworks prove it's not just possible - it's already happening.

Interestingly, even these AI-first frameworks often still raise PRs and use GitHub's infrastructure. Why? Because branch protection is simpler than building a new gatekeeper from scratch. OpenDevin, AutoPR, and others leverage GitHub's existing security model rather than reinventing it.

This reveals an uncomfortable truth: even when we don't need GitHub's UI, we still benefit from its infrastructure and security primitives. The question becomes: will GitHub evolve to serve agents directly, or will new platforms emerge?

GitHub's Current Approach

GitHub is adapting with Copilot everywhere – in your IDE, writing PR descriptions, planning features. These are useful features, no doubt about it.

But look at what they're building: tools that help AI work within existing human workflows. Copilot Workspace creates issues and PRs because that's how we've always worked. The AI adapts to our processes instead of us rethinking the process.

AI agents don't need issues to track work - they track it in markdown files. They don't need PR comments for discussion - they make decisions based on code and tests. There's a fundamental mismatch between how AI agents could work and how GitHub's features assume they should work.

Trust, But Verify

We shouldn't let AI run wild with our codebases. Even automated commits need rules. Policy-as-code becomes important. Branch protection rules in YAML. AI agents reviewing other AI agents' code. Different risk levels for different changes - maybe docs can auto-merge, but payment code needs human review. At least for now.

The PR doesn't disappear - it changes from a discussion to a checkpoint. Less "what do you think?" and more "did this pass all checks?"

Even in a world of autonomous agents, humans remain accountable. When regulators come knocking or when production breaks at 3 AM, you need more than git commits. You need human-readable audit trails that explain why decisions were made, not just what changed.

This is where GitHub's UI might persist - not for day-to-day development, but as a compliance and accountability layer. Issues and PRs become the paper trail that satisfies auditors and helps debug agent decisions months later. It's not efficient, but it's legally necessary.

Real World: Brownfield vs Greenfield

Let's be practical. If you work on an existing project with a human team, you won't switch to full AI tomorrow. Keep your issues, keep your boards, add AI as a helper. Over time, more workflows will move into the repo.

But new projects? Different story. When teams start building AI-first, they won't need GitHub's UI. Everything can live in the repo - planning docs, acceptance criteria, review notes. CI handles the gates. It'll work, and it'll be fast.

The Network Effect Problem

Here's what pure git can't give you: discoverability. Stars tell you what's worth looking at. Forks show ecosystem adoption. Dependabot alerts save you from supply chain attacks. The social layer of GitHub - as much as agents don't need it - provides critical signals for humans evaluating and adopting software.

Replacing this would require more than just a new git host. You'd need ecosystem-wide adoption of alternative registries, new standards for package discovery, and ways to signal trust and quality. That's a coordination problem that could take years to solve, giving GitHub a substantial moat.

The New Role of Human Developers

So what happens to us developers when AI agents handle the grunt work? We don't disappear - we evolve into AI orchestrators and context engineers or whatever this will be called in the next 3 months.

We will instruct AI with requirements, boundaries and workflows to follow. We won't code anymore. I mean we could but why? Let's move up the chain, it is another abstraction layer. Let's fix real problems and leave implementation details to agents.

Where GitHub Has to Go

GitHub has two choices: evolve or become irrelevant for AI development. If they're smart, they'll accept that Issues, Projects, and Wikis become irrelevant or even obstructive in AI-driven workflows.

GitHub already has the foundation. Their REST API and GraphQL endpoints let you do almost everything programmatically. AI agents work with GitHub today without ever touching the UI, either through the GitHub MCP server or with the GitHub CLI. But that's exactly the point - if the UI becomes optional, what's GitHub's value proposition?

Focus on what matters:

• Infrastructure that never fails. Git hosting, CI/CD (also in a Box), global scale. That's valuable.
• Real agent APIs. Not "create an issue" through existing endpoints but "execute in sandbox" and "stream execution logs" - things agents actually need.
• Monitoring for autonomous systems. Not task boards for humans but dashboards for agent swarms.
• Storage and compute. Agents need somewhere to run, not somewhere to chat.

The future GitHub won't look like today's GitHub. It'll be infrastructure, not a social network.

The Messy Transition Ahead

The end of GitHub as we know it won't be clean or sudden. We'll see years of hybrid workflows where agents and humans awkwardly share the same tools. GitHub's challenge is to serve both parties without compromising either. The platforms that figure out this transition - providing agent-native infrastructure while maintaining human accountability - will define the next era of software development.

What do you think? Are we heading toward a fully automated world where AI agents skip GitHub's UI and services entirely? Or will there always be a need for human-friendly collaboration tools, even in AI-driven development?