The software inflection point: agents, OSS, and InnerSource

Over the past year, agentic development has gone from novelty to the way an increasing number of serious teams actually ship code. Naval Ravikant declared that we've hit "an inflection point". Andrej Karpathy, on No Priors, pinned the flip to a specific month: December 2025. He had gone from writing roughly 80% of his own code to writing almost none of it, and warned: "I don't think a normal person actually realizes that this happened or how dramatic it was." Warp open-sourced its entire codebase under the explicit framing that this is how software will be built from now on. Spotify merged 1,500+ AI-generated PRs through its background coding agent (Honk) in a matter of months, on top of a Fleet Management platform that already runs at a 3:1 bot-to-human contribution ratio. Anthropic and OpenAI have published case studies of their own engineers doing the same on their own repos. OpenAI's "Harness" project, for example, shipped roughly a million lines of code and ~1,500 merged PRs with three engineers driving Codex.

This brings us to the bigger question that's still wide open: What does open source, and especially InnerSource, look like when it’s built for this new re Right now, most of the maintainer energy is going into defense: filtering AI-generated bug reports that turn out to be hallucinations, triaging drive-by PRs from agents that never read the project's conventions, debating whether to require disclosure of AI-assisted contributions at all. That's a rational reaction to a real problem. curl, Python, and the kernel community have all been visibly burned by it. But it leaves the positive question unanswered: what does a project look like when it's actually set up to receive agentic contributions safely, instead of just trying to keep the slop out? Inside enterprises, InnerSource is usually even further behind. In most places I've seen it, it's still just an open roadmap and a feature request form.

So here's the question I want to think through: what could open source look like once the projects themselves are set up for agentic development? And what could the future of InnerSource look like? To understand where this could go, let's start with the simplest case: one person, one product, infinite agent capacity.

Naval's quiet claim

In A Return to Code, Naval describes his own workflow on the indie app he's been building. There's a bug-reporting button inside the app. Every 24 hours, he has Claude work through every bug report and just fix them, by itself, with the fixes landing on side branches. His job is to skim the branches and decide which ones to ship.

Then he extends it:

"Eventually you can see apps being built that way by features, where the users will ask for features, they'll vote on features, and then there'll be some tastemaker or maintainer in the cloud who'll look at that and say, 'No, the users don't know what they want.' Or, 'Oh, that makes a lot of sense. We should fix that or change that.' So I think even software development will become a collaborative process with the users and the agents will be handling all of it."

Naval is talking about indie software. One person, one product, one taste. But the pipeline he describes, where users supply pressure, agents do the implementation, and a maintainer holds the taste line, is a near-perfect description of how open source has always wanted to work. It's also a near-perfect description of how InnerSource has always failed to work. More on that in a second.

Warp might be the experiment we need right now

The most concrete preview of agentic OSS so far is Warp's own announcement. The line worth pinning to the wall:

"The biggest bottleneck to development is no longer writing code – it's all the human-in-the-loop activities around the code: speccing the product and verifying behavior."

Warp's repo isn't just open it's agent-ready. There's a .agents/skills directory full of repo-specific skills covering everything from "add a feature flag" to "diagnose CI failure" to "write a tech spec." Issues are the system of record. A cloud agent (Oz) triages, plans, asks clarifying questions, writes code, opens PRs. The Warp team retains direction-setting and merge authority via a strict "Spec and Verify" process.

What I find more interesting than the open-sourcing itself is the honest framing in their follow-up post: open-sourcing is necessary but not sufficient. You also need "alignment between the core team and the community so that you don't create a Frankenstein product, bloated with a long-tail of unnecessary features. Just because a user wants a feature doesn't mean it belongs in the app."

Translation: in agentic OSS, the maintainer's job stops being "write the code" and becomes "defend the vision." That sounds soft. It isn't. It's the hardest job on the project, and it's the one that doesn't scale by adding agents.

What I find fascinating is that Naval, Warp and Spotify are all discovering the same thing from different angles: the constraint moved from writing code to defining what code to write. Naval figured it out by building an indie app. Warp figured it out by open-sourcing their terminal. Spotify figured it out managing infrastructure at scale. Same pattern, different contexts.

Why this is perfect for InnerSource

Now let's look at what InnerSource has been trying, and mostly failing, to be inside large enterprises for the past decade.

The InnerSource pitch is straightforward: take open-source practices and bring them inside the firewall, so Team B can contribute a fix to Team A's service instead of waiting six months on Team A's roadmap. In practice, in every large enterprise I've worked with, it degrades to the same thing: an open roadmap, a feature request form, and a Slack channel where Team B asks Team A nicely. It even happens at smaller companies. Even at Giant Swarm, teams aren't always thrilled when other teams want to reach into their code.

That's not a tooling problem. It's a social problem dressed up as a technical one. The host team's objections are all rational:

• You don't know our code well enough to safely change it.
• We don't trust your tests.
• We're going to end up reviewing your PR more carefully than if we'd written it ourselves.
• And then we're stuck maintaining whatever you wrote.

InnerSource Commons invented an entire role, the Trusted Committer, to manage exactly this dynamic. The whole apparatus exists because teams don't actually let other teams commit to their code at scale, and you need a human bridge to make it work.

The economics here are interesting. In traditional InnerSource, Team B bears the cost of learning Team A's codebase, Team A bears the cost of reviewing unfamiliar contributions, and both teams bear the ongoing maintenance burden. With agent-ready repos, Team B pays a one-time specification cost, the agent handles implementation details, and Team A reviews against their own encoded standards. The cost distribution shifts dramatically.

Agentic SDLC dissolves most of those objections, because the contributor is no longer the bottleneck for code quality.

If every team's repos are set up for agentic coding, then it doesn't actually matter who kicks off an implementation. The owning team still controls everything that matters: the feature request, the ticket refinement, the spec, the architectural fit, the review, the merge. The InnerSource roles don't disappear. They sharpen. The Product Owner owns vision. The Trusted Committer owns review and merge. What changes is that Contributor can now be a teammate, an outside team, an agent, or all three in sequence. And the host team's anxiety about "outsiders touching our code" loses most of its force, because the agent that wrote the PR was given the host team's own conventions, tests, and gotchas to work from.

The bottleneck moves up the stack. From "we can't get anyone to write the PR for us" to "we can't write a spec clear enough to delegate."

That's a much better problem to have.

Capability gates as code

The other thing this enables, and this is where I get genuinely excited, is that the project's vision stops being a paragraph in a README that nobody enforces and becomes an actual gate.

Today, every OSS and InnerSource project has an implicit scope. "We do X. We do not do Y." That scope is defended by maintainers in issues and pull request comments, sometimes only after someone has already spent a weekend writing the wrong feature. It's a high-friction, low-throughput process, and it's one of many reasons for maintainer burnout.

In an agent-native repo, that scope becomes executable. AGENTS.md plus a "scope of project" skill can be the first gate any contribution, human or agent, has to pass through. Then you stack the rest:

• Scope gate: does this fit the stated mission?
• Architecture gate: does it fit the existing patterns?
• Test gate: does it have the coverage we require?
• Security gate: does it pass our security review?
• Review gate: a human makes the final call.

This is structurally how Warp runs Oz today. It's also how InnerSource has always wanted to work, but couldn't, because every gate was a person and every person was a bottleneck. Encoding the gates means the maintainer's judgment scales further than the maintainer does, and you only spend their attention on the things that genuinely require it. That doesn't mean all gates are fully automated. It's just that the grunt work is, and humans get only escalated to when needed.

Where this could go wrong

I'm aware most of the above sounds optimistic. So let me be honest about the parts that are not yet solved. To be clear, I'm specifically not relitigating the AI-slop-contribution debate here, that's a separate (and real, and currently painful) conversation. I'm talking about a mid-term vision.

A few things genuinely worry me:

• Review capacity is the new bottleneck.

Armin Ronacher has been blunt about this: code is cheap; trustworthy review is not. If the answer is only "an agent reviews the agent," we've solved nothing. And by the way, there's a deeper philosophical question here:

• Is this really Open Source or just Open code?

The Warp critics aren't wrong: "open-sourcing" the repo while keeping the orchestrator proprietary recreates lock-in at a higher layer. Any honest version of this vision has to address the orchestration layer, too.

• Some autonomy experiments still hit walls.

Birgitta Böckeler's recent Thoughtworks experiments with end-to-end agentic workflows surfaced the obvious failure modes: agents declaring success on failing tests, generating features nobody asked for, making shifting assumptions about gaps in the spec. Now, that blog post was from before the agentic AI explosion, but even now, we might not be fully there. Still, we could be there sooner than we think.

• The migration burden lands on the people least able to absorb it.

Making a real OSS project agent-ready isn't a weekend AGENTS.md commit. It's writing and maintaining repo-specific skills, standing up MCP servers for the project's APIs and docs, encoding scope and architecture as enforceable gates, and keeping all of that in sync as the code evolves. That's a parallel codebase with its own ongoing cost.

Tidelift's 2024 State of the Open Source Maintainer report puts 60% of maintainers as unpaid, around 60% have quit or considered quitting at least one of their projects, and 61% of unpaid maintainers work on their projects alone. Asking that group to take on a months-long agent-harness retrofit on top of their existing load, before any of the upside materializes for them, is asking the wrong people to absorb the cost of the transition. The big, important projects, the ones where agent-ready-ness would matter most, are exactly the ones with the least slack to do it.

• Spec quality is the new code quality.

If your scope, your AGENTS.md your "stated mission" are vague, your project will produce vague implementations at machine speed. Garbage in, garbage out, just one abstraction layer up.

That's the honest picture. None of these are deal-breakers. All of them are research and engineering problems we can work through. But pretending they don't exist would be dishonest, and the projects that take agentic SDLC seriously will be the ones that take on these constraints first.

Where we go from here

The thing I keep coming back to is that a well-run platform team has been doing a version of this for years. They give other teams capabilities, not tools. They guard the scope. They encode their opinions as guardrails. They review what crosses the boundary. They let the consuming teams move at their own pace inside the lines.

An agent-ready OSS or InnerSource project is just like a platform with a bigger, weirder, partially-non-human user base. The maintainers keep the keys. The agents do the typing. The community, whether that's the OSS contributors or Team B down the hall, supplies the taste and the pressure. The vision stays human.

We are nowhere near this today for the vast majority of projects. Most OSS repos aren't agent-readable in any serious sense. Most InnerSource programs are still arguing about contribution guidelines from 2018. But the building blocks are on the table now: AGENTS.md, skills, MCP, repo-aware orchestrators, spec-and-verify workflows. Time will tell if this might be a good path for Open Source in general. I'm pretty sure though that it's going to be a lifesaver for many InnerSource projects including developer platforms.