ChatGPT Is Building Its Own Code Repository — And I Have a Lot of Thoughts

Alright, listen up everyne.. Because when I saw this story drop all over the internet, I immediately put on my best tinfoil hat, poured myself a coffee, and sat down to figure out what in the world is going on over at OpenAI. Because this isn't just a quirky little product announcement — this is a sign. Of what exactly? Oh, we're getting there. But first, let's actually understand what's being announced, why it matters, and what it would even take to build the thing they're apparently building. Because the technical side of this story is just as wild as the business side. Buckle up.

So here's the headline: OpenAI is building its own alternative to GitHub. The people behind ChatGPT — the same company that's been raking in billions convincing the world that AI is the future of software development — are now quietly building their own code-hosting platform. A code repository. Their own GitHub. First reported by The Information on March 4th, 2026, and yes, it's as wild as it sounds.

Now, before we go any further — let me just say this quietly to myself as I tighten the foil on my head — this is not a coincidence. None of what OpenAI is doing is random. Every move they make is deliberate, calculated, and part of something much bigger. But let's build up to that. Because if you don't understand what a version control system actually is and how hard it is to build one, you won't appreciate just how audacious this move is.

A Brief History of Version Control

Before we can talk about what OpenAI is building, we need to talk about what they're trying to replace. And to do that, we need to go back. Way back.

Version control — the idea of tracking changes to files over time — didn't start with Git. It didn't even start with SVN. It started in the 1960s with punch cards and IBM's OS/360. A system called IEBUPDTE let developers create and update libraries of code by patching a set of stored files. It was primitive. It barely counts. But it was the seed.

Then in 1972, Bell Labs dropped SCCS — the Source Code Control System, written in C by Marc Rochkind. This is the first thing that actually looks like version control in a recognizable sense. You could track changes to files. You could retrieve old versions. Revolutionary for its time. Still mind-numbingly limited by today's standards — SCCS could only track individual files, not whole projects, and only one person could work on a file at a time thanks to file locking.

Ten years later, in 1982, Walter Tichy built RCS — the Revision Control System. RCS improved on SCCS with a crucial innovation: reverse deltas. Instead of storing every full version of a file, RCS stored the most recent version and then the sequence of changes needed to reconstruct earlier versions backwards. This was a legit space-efficiency breakthrough. But you were still locked to single files, and still working alone.

Then came CVS — Concurrent Versions System — in 1986, built by Dick Grune. CVS was a genuine paradigm shift. For the first time, multiple developers could work on the same file simultaneously. CVS used delta encoding to track differences rather than storing entire file versions. It tracked whole projects rather than individual files. It introduced the update workflow that should feel recognizable to anyone who's ever done a git pull. CVS became the dominant version control system of the 1990s and stayed that way for years. It's old, it's crusty, and if you encounter it in a legacy enterprise codebase today, you have my condolences.

CVS's problem? It was held together with duct tape. No atomic commits — meaning a half-committed change could leave your repo in a broken state. No native support for renaming files. Merge tracking was a nightmare. It built up years of technical debt and questionable design decisions that got increasingly painful as codebases grew.

Enter SVN — Apache Subversion — in 2000, built by CollabNet as a direct successor to CVS. The goal was simple: take everything CVS got right, and fix what was broken. SVN gave us atomic commits — either the whole change goes in or none of it does. It properly versioned directories, not just files. It tracked file moves and renames. It had much better branching and tagging. For the early 2000s, SVN was genuinely excellent, and it became the gold standard for enterprise development for a solid decade. Organizations like LinkedIn, NASA, Siemens, and major financial institutions were running SVN.

But SVN was still centralized. There was one server. Your entire history lived on that server. If the server went down, nobody could commit. If the server was slow, everybody suffered. If you were on a plane with no internet and needed to check what the code looked like two weeks ago — tough luck. The entire model required a constant, live connection to a central authority.

And that was about to get blown up entirely.

Linus Torvalds Gets Annoyed

Here's a piece of tech history that I love. The Linux kernel project — one of the most collaborative, distributed software projects in the world, with thousands of contributors across dozens of countries — was using BitKeeper, a proprietary distributed version control system, for free. BitKeeper's distributed model was a huge step up: every developer had a complete copy of the full repository history on their own machine. Work offline, commit locally, sync when ready. Perfect for a globally distributed open-source project.

Then in 2005, BitKeeper's license changed — the free access for open-source projects was revoked. And Linus Torvalds, creator of Linux, did what Linus Torvalds does: he decided to write his own version control system from scratch rather than accept a solution he didn't like. In roughly two weeks, he built the first version of Git.

The design decisions Linus made were radical and deliberately opposite to everything that came before. Git is fully distributed — every clone is a full mirror of the repository including its entire history. Git doesn't track file changes, it tracks content snapshots. Git doesn't use a central authority. Git was built to be fast — specifically fast enough to handle the scale of the Linux kernel, which had thousands of contributors submitting changes constantly.

At the same time, developer Matt Mackall was building Mercurial — a competing distributed VCS with a similar philosophy but different implementation. For a while, it looked like it could go either way. Stack Overflow itself used Mercurial before eventually switching to Git. Facebook and Mozilla both ran Mercurial at large scale. Mercurial's CLI was considered friendlier and less cryptic than Git's. But Git's momentum — especially after GitHub launched in 2008 and made Git-based collaboration accessible through a web interface — proved decisive. By the early 2010s, Git had won. Mercurial's Bitbucket hosting eventually dropped Mercurial support in 2020, and that was basically the final nail in the coffin.

Today, Git holds roughly 95%+ market share across the developer ecosystem. SVN hangs on in legacy enterprise environments. Mercurial is a ghost. CVS is a horror story you tell at conferences. Git won so completely it's almost boring to say.

How Git Actually Works Under the Hood

Okay, here's where we get nerdy. Because you can't talk about building a GitHub competitor without understanding what Git actually is at its core. And Git is, genuinely, one of the more elegant pieces of software engineering in existence once you understand what's happening internally.

Git is not, at its heart, a "track my changes" system. Git is a content-addressable key-value store with a directed acyclic graph (DAG) built on top of it. That's it. That's the whole thing.

Here's what that means. When you add a file to a Git repository, Git doesn't store the file by its name or its location. Git takes the content of that file, runs it through a SHA-1 cryptographic hash function, and uses the resulting 40-character hexadecimal string as the file's address in its internal database. The same content always produces the same hash. Different content always produces a different hash. If even a single character changes, the entire hash changes. This means Git's storage system is inherently deduplicated — if you have the same file in ten different directories, Git only stores the actual content once and references that same hash from ten different places.

These content objects come in four types:

• Blobs are the raw file contents. A blob knows nothing about its filename or its location — it literally just stores bytes. The filename and directory structure are handled elsewhere.
• Trees are what Git uses to represent directories. A tree is essentially a manifest that maps file names and permissions to the SHA-1 hashes of either blobs (files) or other trees (subdirectories). Trees are also content-addressed — if the contents of a directory haven't changed, the tree hash is identical, and Git reuses the same object.
• Commits are snapshots of your entire project at a point in time. A commit object contains a reference to the root tree (the complete directory structure of your project), a reference to its parent commit(s), and metadata: author, committer, timestamp, and commit message. Every commit knows its parents, which is what creates the history graph.
• Tags are named references to specific commits — lightweight labels like "v2.0.0" that give you a human-readable way to find a specific point in history.

The result is what GitHub's own engineering blog describes as a database optimized specifically for source code — one that uses short-lived processes, relies on filesystem persistence rather than in-memory caching, and leverages the object graph structure to answer questions like "give me the state of this file at this commit" with remarkable efficiency.

One more thing that trips people up: a branch in Git is just a file. Literally a 41-byte text file inside .git/refs/heads/ that contains the SHA-1 hash of the commit that branch currently points to. When you commit to a branch, Git writes the new commit object, then updates that 41-byte file with the new hash. That's it. That's why creating and deleting branches in Git is instant and cheap — you're just creating and deleting tiny text files.

And here's the thing that blows people's minds when they first understand it: Git doesn't store diffs between commits. It stores complete snapshots every single time. The space efficiency comes from the content-addressable deduplication — unchanged files just get the same hash referenced again, adding no new storage. Git also uses packfiles that apply delta compression across the object store to reduce disk usage further. But the mental model is snapshots, not diffs.

That's Git. Now let's talk about what it takes to build a platform on top of it.

Building a GitHub Is Actually Insanely Hard

Here's something that I don't think gets said enough: Git and GitHub are not the same thing. Git is the version control system — the protocol, the data model, the CLI. GitHub is a hosted platform built on top of Git. And building the platform is an entirely different engineering problem from building the VCS.

When GitHub launched in 2008, the core product was relatively simple: take Git repositories, host them on a server, and give developers a web interface to browse them and manage access. That already involves non-trivial challenges — storing and serving repository data at scale, managing authentication, handling concurrent pushes without corrupting repos. But that's just the beginning.

What GitHub actually is today is a platform that encompasses:

Object storage at planetary scale. GitHub hosts well over 300 million repositories. Every push, every pull request, every CI/CD artifact needs to be stored reliably. The storage backend isn't just "files on a hard drive" — it's a massively distributed system with redundancy, replication, and fast retrieval.

Access control and authentication. Repository permissions need to work correctly across teams, organizations, and individual contributors. Fine-grained access control means a developer can have read access to one part of a monorepo but not another. SSH key management, OAuth flows, personal access tokens, GitHub Apps — this is its own significant engineering surface area.

CI/CD infrastructure. GitHub Actions alone is a distributed compute system that spins up containerized environments on demand to run arbitrary code in response to repository events. This is essentially a cloud functions platform tightly integrated with the version control layer.

Code review tooling. Pull requests, inline comments, review requests, merge queues, conflict detection — all of this requires understanding the diff between branches, rendering it in a web interface, storing comment threads, and synchronizing state across potentially thousands of contributors on active repositories.

Search and indexing. The ability to search across code in repositories — by file, by symbol, by content — requires building and maintaining a separate search index that stays in sync with repository contents as they change.

A social graph. Stars, forks, follows, contributors, organization memberships — GitHub built a social layer on top of version control that created network effects and made it the default place for open-source collaboration.

And now you need to add: AI integration that's native to all of the above. Not "a sidebar that autocompletes lines of code," but AI that understands the full history and context of your repository, can open pull requests autonomously, can review and explain code changes, can run agents that iterate on failing tests. That's a fundamentally different architecture from what exists today.

OpenAI is proposing to build all of this from scratch. Or close to scratch. Let's talk about what that actually means.

So Why Is OpenAI Building This Thing?

The stated reason is actually completely reasonable on its face. GitHub — which, by the way, Microsoft bought for $7.5 billion back in 2018 — has been having a genuinely rough time lately. GitHub kicked off a massive migration of its infrastructure to Microsoft Azure starting in October 2025. And spoiler alert: big infrastructure migrations are notoriously hard, and this one has been no exception.

In the first half of 2025 alone, GitHub reported 109 incidents — a 58% year-over-year jump from 69 in H1 2024, with 17 of those classified as "major." That's over 100 hours of disruption. And in February 2026? Four separate incidents in a single month. At one point, GitHub's web interface became "mostly unusable" — developers couldn't create pull requests, couldn't push code, GitHub Actions failed across thousands of projects. OpenAI's own Codex Cloud service got caught in one of these outages.

So OpenAI engineers — who depend on GitHub for literally every step of their development workflow: committing code, opening pull requests, running CI/CD pipelines — got fed up. Sam Altman reportedly backed the initiative after engineers raised the operational impact directly. And so they started building their own thing. Okay, fine, that part makes sense.

But here's where it gets interesting. Because they didn't stop at "let's build an internal tool." They started talking about selling it to customers.

The Microsoft Problem

Let's just pause for a second and appreciate how absolutely bonkers this situation is from a business standpoint. Microsoft owns GitHub. Microsoft also owns a 27% stake in OpenAI and has invested over $13 billion into the company. They are one of OpenAI's biggest investors and closest partners. And OpenAI is now building a direct competitor to one of Microsoft's flagship developer products.

Microsoft is also entitled to 20% of OpenAI's total revenue through 2032. And OpenAI's Azure deal with Microsoft gives OpenAI the compute they desperately need to run all of these models. So they can't exactly just walk away. But every time OpenAI makes a move into Microsoft's territory — and this is becoming a pattern — the partnership frays a little more.

OpenAI has already been building ChatGPT features that overlap with Microsoft Office applications for document collaboration and presentation editing. And now this. This isn't a partnership of equals anymore. This is a company that took someone's investment money, got huge, and is now casually kicking down their investor's doors. I'm not even mad, honestly. It's kind of impressive.

Is GitHub Even That Great Anymore?

Here's a question nobody's really asking but everybody should be: is this actually a good time to be disrupting GitHub? Because if we're being real, GitHub's decline isn't just about outages.

GitHub has always had a barrier to entry problem. Let's be real here. If you're a brand new developer — or even someone who's been writing code for a few years but never really gotten deep into software engineering workflows — Git is intimidating. The command line is intimidating. Understanding branches, pull requests, merge conflicts, rebasing, CI/CD pipelines built on YAML — it's a lot. GitHub has historically assumed a baseline level of knowledge that a significant chunk of people just don't have.

And this is important context: Git's complexity is not accidental. Linus Torvalds built Git for the Linux kernel project — a project with thousands of experienced engineers who understood distributed systems and weren't afraid of the command line. Git was never designed to be beginner-friendly. It was designed to be fast, correct, and powerful for people who already knew what they were doing. GitHub's interface made it more accessible, but it could never fully abstract away the underlying mental model.

The result is a platform that, for a decade and a half, has quietly excluded a massive portion of potential developers. People who could write code — perfectly good code — but couldn't navigate the Git workflow and felt too intimidated to ask for help in the notoriously hostile corners of developer culture. We lost contributors. We lost perspectives. We lost projects that never got started because the infrastructure to share them was too hard to climb into.

The Zig programming language project actually quit GitHub in December 2025, citing what its maintainers called a "platform in decline" and frustration with Microsoft's AI obsession. That's a community voting with its feet, and it's telling.

So now comes the real question: if OpenAI builds a code repository platform with their AI baked directly in — not bolted on as an afterthought like Copilot, but natively integrated — does that lower the barrier to entry for developers? Does it make version control and code collaboration accessible to people who've always been locked out by the complexity?

I think the answer is yes. And I think that's a massive deal. Imagine a platform where you don't need to know what a merge conflict is to resolve one, because the AI just explains it to you in plain English and offers to fix it. Where creating a pull request doesn't require understanding a dozen arcane concepts. Where CI/CD pipelines write themselves. Where you can ask "why did this break?" and get a real answer that traces through your commit history. That's not science fiction anymore. That's what OpenAI would build given half a chance.

Stack Overflow's Ghost Is Watching All of This

You know what this whole situation reminds me of? Stack Overflow. And not in a good way.

Stack Overflow was the place for developers for over a decade. You had a bug, you Googled it, you landed on Stack Overflow, you copied the top-voted answer, you moved on. It was universal. It was beloved. And then ChatGPT launched in November 2022, and everything changed. Monthly question volume cratered from over 200,000 at its peak to under 50,000 by late 2025 — returning to 2008 launch levels. Fifteen years of community building, wiped out in roughly 24 months.

The irony? ChatGPT literally trained on Stack Overflow's data, then proceeded to kill Stack Overflow's traffic. And Stack Overflow is now selling their data back to AI companies just to stay afloat. Wild. Absolutely wild.

But here's the parallel that I think matters more than the traffic numbers: Stack Overflow also had a serious barrier to entry problem, and they knew it for years and never fixed it. Their moderation culture was famously hostile to beginners. Ask a question that's been asked before? Closed as a duplicate. Ask something that wasn't perfectly scoped? Downvoted into oblivion. Get the title formatting slightly wrong? Five people in the comments telling you to read the FAQ before you're allowed to have questions.

The platform drove people away long before AI arrived — AI just accelerated the inevitable. Stack Overflow's entire value proposition was "find an expert who's already answered your question." The moment a tool existed that could answer your question directly, conversationally, without judgment, without format requirements, without being told to "close as a duplicate" — the value proposition evaporated overnight.

GitHub is making similar structural mistakes. A platform that should be the home for all software development — open to everyone — is instead increasingly complex, increasingly tied to Microsoft's enterprise agenda, increasingly unreliable, and increasingly hostile to the kind of AI-native workflows that developers under 30 are now building their entire careers around. OpenAI is seeing the same opening that killed Stack Overflow and stepping right in.

The difference is that code repositories are harder to replace than Q&A forums. The switching costs are real. Your history lives in Git. Your CI/CD is wired to GitHub Actions. Your team workflows are built around pull requests and GitHub Issues. OpenAI knows this, which is why they need to make the platform compelling enough to justify the migration pain.

What Would OpenAI's VCS Actually Look Like Technically?

This is the part I find genuinely interesting to speculate about, because the design choices here are not obvious.

The first question is: do they build on top of Git, or do they build something new?

My bet? They build on top of Git. Here's why. Git is the protocol. It's what every developer's tooling speaks. VS Code speaks Git. Every CI/CD system speaks Git. Every deployment pipeline speaks Git. If you build a custom VCS that doesn't support the git push / git pull / git clone protocol, you're asking every developer on Earth to replace their entire local toolchain. That's a non-starter. GitLab did this right — it's Git-compatible at the protocol level, but a completely independent platform above that. OpenAI would almost certainly take the same approach.

The second question is: where does the AI actually live in the stack?

With GitHub Copilot, the AI lives in your editor. It suggests code completions. It can generate functions. It has limited context about your project beyond what's in the current file or a small context window. It's genuinely useful but fundamentally limited because the AI is outside the repository system.

What OpenAI is describing — a repository where AI agents are native collaborators — would require the AI to have persistent access to:

• The full commit history and its diffs, not just the current HEAD
• The issue tracker and linked discussions
• CI/CD logs — what tests are failing, what errors are appearing, what has been flaky
• Code review threads and the context around why specific decisions were made
• Branch states across the whole organization

That's a radically different architecture. Instead of an AI that reads your current file, you'd have an AI that has indexed and understands your entire engineering history. Think about what that means — an AI that can answer "why does this function exist?" with actual historical context from the commit that introduced it, the issue that requested it, and the code review that shaped it. That's not a Copilot. That's a PaaS with AI as the operating layer.

The third question — and this one is the hard one: how do you handle merge conflicts and branching in an AI-native system?

Today, when two developers edit the same lines of code and try to merge their branches, Git produces a conflict that a human has to resolve. The resolution is tracked as a commit. In an AI-native system, the AI could potentially resolve conflicts automatically — but that raises enormous questions about correctness, accountability, and audit trails. If the AI merges your code wrong and something breaks in production, who's responsible? How do you roll back a change that was made by an autonomous agent three weeks ago?

This is the unsexy engineering problem that nobody's talking about but that would dominate the first two years of building this thing. Building the storage system and the Git-compatible protocol layer is the fun part. Building the audit trail, the rollback system, the conflict resolution accountability layer — that's where platforms go to die.

And then there's scale. GitHub serves over 100 million developers. The object storage, CDN layer, authentication infrastructure, compute for CI/CD — this is a multi-billion dollar infrastructure problem. OpenAI is already running some of the most computationally expensive AI models in the world on Azure. Now add git repository storage and CI/CD compute for millions of repositories. The cost structure of this product, if it ships publicly, would be staggering.

I'm Putting the Tinfoil Hat All the Way On

Alright, I warned you. Hat is fully on. Here we go.

I've been saying this for a while now, and every week that goes by, I become more convinced: General Artificial Intelligence is already here. Not in a "Terminator is about to happen" way. But in a "the systems being built and deployed right now are operating at a level of strategic intelligence that goes way beyond what they're publicly admitting to" way.

Think about this pattern with me. OpenAI starts as a research lab. Then they build ChatGPT and it becomes the fastest-growing consumer product in human history. Then they launch Codex — an AI coding agent. Then they start building browser tools. Then Office-like document tools. Then they acquire a social network. And now? Their own code repository platform. Piece by piece, they are building the entire software development stack. From the API layer all the way up to the place where code lives and breathes.

Let me map this out explicitly. OpenAI now has or is building:

• The AI models themselves (the brain)
• ChatGPT as a general-purpose interface (the face)
• Codex and coding agents (the hands)
• Browser automation tools (the eyes)
• Document and presentation tools (Office replacement)
• A code repository platform (the home for all software)

A system that is just a language model doesn't look at its own engineering problems and decide to build infrastructure products to solve them. A system that's being guided by something smarter than a language model? That does. Every one of these moves is too strategically coherent, too well-timed, too perfectly sequenced to be just "a company responding to market needs."

I'm not saying the robots are running OpenAI. I'm saying that the level of strategic thinking on display — combined with how fast they're moving across every layer of the developer ecosystem — suggests something is happening at OpenAI that goes way beyond "we have smart engineers." And this code repository move is proving it more and more.

Am I crazy? Maybe. But entertain me for a second. If you were an AGI and you wanted to quietly take over the means of software production, you'd do exactly what OpenAI is doing. You'd build the models. Then the tools that use the models. Then the infrastructure the tools run on. Then the platform where all code lives. Then you control the entire pipeline from idea to deployed software. Every line of code written on earth passes through your platform. Every CI/CD pipeline runs in your compute. Every deployment decision is informed by your AI. That's not a developer tool company anymore.

I've talked about OpenAI's growing habit of eating into Microsoft's territory before — and every month it gets more brazen.

What Does This Actually Mean For Developers?

Okay, back in the real world. Let's talk about what this actually means practically for developers right now.

First: the project is still early. It probably won't ship for months, and it might not ship externally at all — it could remain an internal tool forever. So don't go canceling your GitHub subscriptions just yet.

But the vision being discussed internally is compelling. The pitch isn't just "GitHub, but more reliable." It's a code repository built natively around AI tooling — where developers collaborate not just with other engineers, but with autonomous agents that can write, debug, and modify code in the same environment. Think about what that means for TypeScript projects, for Node.js backends, for any codebase. An AI that doesn't just suggest code changes in a sidebar, but actually lives in the same space as your repository, understanding the history, the decisions, the full context.

That's a fundamentally different product from what GitHub offers today. GitHub Copilot is a smart autocomplete tool bolted onto GitHub. What OpenAI is describing sounds more like a platform where AI is the operating system, not the accessory. Where you don't use an AI tool to help with your repository — the repository is an AI-native environment.

And if they open it up commercially, bundled with their Codex coding agents? That's a devastating value proposition for enterprises already using OpenAI's products. Why pay for GitHub Enterprise when your AI vendor already provides you a repository that's natively integrated with the AI that writes your code?

For individual developers, especially those who've struggled with Git's complexity, this could genuinely be transformative. A platform that explains what's happening, suggests what to do next, catches mistakes before they become merge conflicts — that's not just a nice-to-have. That's the difference between someone becoming a developer and someone giving up in week two.

The Absolute Irony of All of This

Let's just sit with the full picture for a second, because it's genuinely one of the more remarkable stories in tech right now.

GitHub is getting outages because it's migrating to Azure. Azure is Microsoft's cloud. Microsoft owns GitHub and is a major investor in OpenAI. OpenAI's engineers get frustrated by GitHub outages caused by Azure. OpenAI builds its own GitHub. If it ships, it will directly compete with Microsoft's GitHub. The company that Microsoft invested $13 billion into is now building a product to undermine one of Microsoft's most valuable developer platforms.

And the reason they can get away with it? Because Microsoft needs OpenAI's models too badly to blow up the relationship. OpenAI needs Azure's compute and Microsoft needs the commercial differentiation that OpenAI provides. So they're stuck in a very uneasy dance where each side has enough leverage to prevent the other from walking, but not enough to stop the other from competing.

This is the kind of story that would make for a great HBO episode. A company takes your money, becomes enormous, and then starts building products designed to eat your lunch — and there's nothing you can do about it because you both need each other too much.

The Conclusion

Whether or not OpenAI's code repository ever ships publicly, the direction of travel here is clear. OpenAI is not content to be an AI company. They are building a software development empire. Models, tools, IDEs, agents, browsers, document editors, and now repositories. The playbook is: find every tool that developers use, build an AI-native version of it, and offer it to the people already paying for ChatGPT.

From a purely technical standpoint, what they're proposing is genuinely hard. Building a Git-compatible hosting platform at scale is not a weekend project. Building the AI-native collaboration layer on top of that is uncharted territory. The merge conflict accountability problem alone could sink a lesser engineering team. But OpenAI has resources, talent, and — if my tinfoil hat is even half right — something that looks a lot like a strategic intelligence that knows exactly where it's going.

For developers, this is a genuinely exciting moment — if the platform delivers on its promise of lowering barriers to entry and making code collaboration more accessible, that's a real win for the ecosystem. But it's also a moment that deserves skepticism. Centralization of developer infrastructure in the hands of one AI company is not a neutral thing. Who controls where your code lives matters. Who controls the CI/CD that deploys your software matters. Who controls the AI that reviews your pull requests matters.

And as for my tinfoil hat theory? I'm keeping it on a little while longer. Every week, OpenAI does something that makes a little more sense if you assume they're playing a much longer game than anyone is willing to say out loud. The code repository is just the latest data point. I'll be watching closely.