Where Is Open Source Heading in the Agentic Era?

Key takeaways

—

Software development used to have built-in back pressure: changes came at a pace and size that reviewers could keep up with. AI agents have broken that balance.

—

Ghostty, tldraw, Godot, curl and GitHub itself spent 2026 building new controls to cope. Enterprise teams face the same problem behind their firewalls.

—

Open source funding is under pressure too: AI assistants are replacing the documentation visits that many projects depend on for revenue.

—

The strongest responses are about accountability rather than bans, as with the Linux kernel’s AI policy, which says only a human can sign off a patch.

—

Context files and specs guide agents, but they don’t check the result at the PR or keep a project’s decisions consistent over time.

—

The new bottleneck is reviewing design intent, not writing code. rkito addresses it by keeping three ledgers (Steering, Architecture and Code) in agreement, and it’s free for open source, for life.

Until agents arrived, software development had built-in back pressure.

A large change was usually well understood long before it became a pull request. It had been discussed, designed and argued over in issues, mailing lists and design docs. PRs arrived at a pace and size that reviewers could keep up with. Contribution volume and review bandwidth were in balance.

That balance is gone. An agent can produce a plausible, well-formatted PR in seconds, for anyone, against any repository. Review capacity hasn’t grown to match.

This isn’t a doom piece. Open source isn’t dying. But it is being pushed into a new shape faster than most people expected, and the projects that come out of it well will look different from the ones that went in.

1. The flood is real, and the platforms have responded

The loudest signal of 2026 has been maintainers saying “enough.”

—

Ghostty. In August 2025 Mitchell Hashimoto began requiring contributors to disclose any AI use in pull requests. Within weeks, about half of Ghostty’s PRs included a disclosure. In January 2026 he went further: AI-assisted PRs are now accepted only for issues the team has already accepted, drive-by AI PRs are closed without discussion, and contributors who repeatedly submit poor AI-generated work are banned. He was clear that this isn’t an anti-AI position. Ghostty itself is “written with plenty of AI assistance.”

—

tldraw. Steve Ruiz began auto-closing all outside pull requests. He found that his own rough, AI-drafted issues were being fed into other people’s agents and coming back as low-quality PRs, with “AI doing both sides of the work.”

—

Godot. On June 30, 2026 the Godot Foundation announced a stricter contribution policy. It bans autonomous agents, vibe coding and substantial AI-generated code, and allows AI only for small tasks such as code completion or regex. The foundation said AI contributions “have the added pain of being demoralizing,” because reviewers no longer feel they are mentoring the next generation of maintainers.

—

GitHub. The platform shipped tools to match. In February 2026 maintainers gained the option to disable pull requests entirely or limit them to collaborators. On June 17 GitHub added a cap on how many PRs a user without write access can have open at once, and on August 6 made that cap configurable across a whole organization.

“The rise of agentic programming has eliminated the natural effort-based backpressure that previously limited low-effort contributions.”
— Mitchell Hashimoto, Ghostty

Researchers now have a name for this: “AI-DDoS.” A 2026 study of 294 repositories and more than two million PRs and issues found that PR volume rose through 2025 while merge rates fell.

This isn’t only an open-source problem. Enterprise teams face the same thing behind their firewalls. Agents generate more PRs than architects can review, design drift builds up quietly, and senior engineers become full-time reviewers. Open source simply felt it first, because anyone in the world can open a PR against a public repository.

Takeaway

The bottleneck has moved from writing code to reviewing it. Generating a PR takes seconds. Deciding whether it fits the project still takes a human who understands why the project is built the way it is.

2. Security triage broke first

Before pull requests became the problem, security reports did.

curl ran a bug bounty from 2019. Over its lifetime it confirmed 87 real vulnerabilities and paid out more than $100,000. Daniel Stenberg said that for years, more than 15% of submissions turned out to be confirmed vulnerabilities. In 2025 that fell below 5%, as confident-sounding, AI-fabricated reports poured in. curl ended the bounty on January 31, 2026.

“The main goal with shutting down the bounty is to remove the incentive for people to submit crap and non-well researched reports to us. AI generated or not.”
— Daniel Stenberg, curl

curl still wants real reports, including ones found with AI help. The problem isn’t AI itself but the ratio of real findings to noise. Anyone maintaining widely used infrastructure now faces the same thing: AI multiplies the number of reports coming in, but not the number that are correct.

3. The economics are under pressure

Many open-source projects fund themselves through people who visit their docs, file issues and discover their paid products. AI assistants now answer those questions directly, so the visits, and the revenue that came with them, are disappearing.

In January 2026 Tailwind Labs laid off 75% of its engineering team. Adam Wathan said docs traffic was down about 40% from early 2023 and revenue was down close to 80%, “despite Tailwind being more popular than ever.” Developers no longer visited the docs because their assistants wrote Tailwind code for them, and the docs were where people discovered Tailwind’s paid products.

A few weeks later, economists at CEU, Bielefeld University and the Kiel Institute published “Vibe Coding Kills Open Source” (arXiv 2601.15494, also a CEPR discussion paper). Their model explains the pattern. When an agent chooses and assembles packages for a developer, nobody reads the docs, files the issue or stars the repo. Usage keeps rising while the engagement that maintainers depend on falls away. The authors conclude that sustaining open source at its current scale “requires major changes in how maintainers are paid.”

Jeff Geerling put it more bluntly in February: “AI is destroying Open Source, and it’s not even good yet.”

4. The productivity story is messier than the marketing

It’s worth being honest about what agents actually deliver. In July 2025 METR published a randomized controlled trial with 16 experienced open-source developers working on their own mature repositories. With AI tools allowed, tasks took 19% longer, even though the developers believed they had been about 20% faster.

In February 2026 METR said it was redesigning the study, because so many developers now refuse to work without AI that recruiting a fair sample had become difficult. That is a telling result in itself.

The fair reading isn’t that AI makes developers slower. It’s that on large, complex codebases full of unwritten context, AI output has to be checked, and checking takes time. It’s the same review problem again.

5. Open source is writing the rules for agents

This is where the picture becomes more hopeful. Open source is being disrupted by agents, but it is also where the norms for working with them are being set.

Accountability, not bans. In April 2026 the Linux kernel adopted an official policy on AI coding assistants. AI agents must not add “Signed-off-by” tags, because only a human can certify the Developer Certificate of Origin. The policy asks contributors to disclose AI help with an Assisted-by: AGENT_NAME:MODEL_VERSION tag, and the human submitter is responsible for every line. The message is simple: use AI, but a human owns the decision. Kubernetes now requires contributors to disclose AI use and to verify AI-generated changes “through code review, testing, and personal understanding,” and is trialling AI review tools in several sub-projects.

Open standards for the agent stack. In December 2025 the Linux Foundation launched the Agentic AI Foundation (AAIF), with Anthropic’s Model Context Protocol, OpenAI’s AGENTS.md and Block’s goose as founding projects, and with backing from Google, Microsoft, AWS, Bloomberg and Cloudflare. By April 2026 it reportedly had more than 170 members. On September 14 it launched its first certification (MCPA), and AGNTCon + MCPCon North America takes place in San Jose on October 22–23.

“The companies that compete on AI models are collaborating inside the Agentic AI Foundation to build the plumbing that makes agents work together.”
— Jim Zemlin, Linux Foundation

Context files and specs are a start, but they don’t solve the problem. AGENTS.md, CLAUDE.md and similar files are now standard in serious repositories; Ghostty ships one, and many projects added one this year. Spec-driven development goes further: tools like GitHub’s Spec Kit and AWS’s Kiro have agents write a specification first and then implement it. Both are genuine steps forward, and both have serious limits.

—

They’re advice, not enforcement. A context file tells an agent what it should do. Nothing checks that it did. An agent can misread it, ignore it or run out of context window before reaching the relevant line, and the PR still arrives looking fine.

—

Intent ends up scattered and contradictory. Design intent is now spread across READMEs, ADRs, wikis, context files and specs, often inconsistent with each other. Agents have to reconcile it on every prompt, loading ever more of it into context, which drives up token costs.

—

A spec looks forward, not backward. It describes where one change should go. It doesn’t check that the resulting pull request stayed within the approved design. Implementation drifts from the spec, and nobody finds out at the PR.

—

Specs don’t scale across teams or across time. One author writes a spec, but real design decisions need input from security, operations, product and compliance, as well as from other contributors. And every new spec author has to know everything that went into previous specs: what was decided, what was rejected, and where specs contradict each other. In a project with hundreds of contributors and years of history, nobody can hold all of that in their head, and an agent can’t either.

—

Nothing records the current state. Specs pile up as a history of intentions. There’s no single, approved record of how the system is built now, so there’s nothing reliable to check a new change against.

Context files and specs tell an agent where to go. They don’t confirm that it got there, and they don’t keep the project’s accumulated decisions consistent. That takes a durable, reviewed record of design intent, checked automatically on every pull request.

So where is it heading?

Put these developments together and five directions stand out.

Trust becomes the scarce resource.

Vouching systems, PR caps, disclosure rules and “accepted issues only” policies are all attempts to rebuild the back pressure that agents removed. Contributors with a track record will count for more. Anonymous drive-by PRs will count for less.

Review needs automation that understands intent, not just syntax.

Linters, tests and SonarQube-style checks answer “does this code work?” Maintainers are overwhelmed by a different question: “does this change fit how and why the project is built?” Today only people can answer that, and there aren’t enough of them.

Design intent has to be written down and versioned like code.

Architectural knowledge that lives in a maintainer’s head, or is scattered across context files and specs, can’t keep up with agent-speed contributions. Projects will keep their rules and their architecture as versioned records, change them only through deliberate, human-approved decisions, and check every code change against them automatically.

Funding has to follow usage, not traffic.

Tailwind showed how fragile traffic-based funding is. Expect experiments with usage-based redistribution (a “Spotify for open source” was proposed in response to the Vibe Coding paper), more sponsorship from companies that depend on open source, and more foundation-backed stewardship.

Open governance becomes a competitive advantage.

The agent stack is being standardized in the open, under the Linux Foundation. Projects that publish their contribution rules, AI policies and architectural standards give both people and agents a clear path to contributing well.

Where rkito fits

We think points 2 and 3 above are the central problem of agentic engineering. Agents can produce pull requests far faster than people can review them, and open-source maintainers are feeling it first. Our answer is not to ask people to review faster. It’s to change what people have to review.

rkito treats every project as three ledgers that have to stay in agreement:

Steering Ledger (SL)

The rules and the reasons.

The design intent a project has agreed to, most of which can’t be worked out from the code alone. For example:

Architecture Decision Records

“ADR-012: We chose event sourcing for the billing domain and rejected CRUD tables, because every change must be auditable and replayable.” The code shows what was built. The ADR records why, and which alternative was ruled out.

Policies

“Customer data never leaves the EU region.”
“Only permissively licensed dependencies (MIT, Apache-2.0, BSD); no copyleft in the core library.”
“Anything that handles credentials needs a second maintainer’s approval.”

Principles

“Prefer boring, well-understood technology over novel frameworks.”
“The CLI must keep working offline.”
“Within a major version, backward compatibility beats elegance.”

Commitments

“Breaking changes to the public API require a deprecation period of one minor release.”
“Every supported platform ships in every release.”
“p99 latency on the query path stays under 50 ms.”

Structural rules

“Storage adapters must never depend on the HTTP API layer.”
“Plugins talk to the core only through the published extension interface.”

Adopted baselines

OWASP Top 10, AWS Well-Architected or ISO 27001, adopted as-is or adapted to the project.

Architecture Ledger (AL)

The approved design.

The current, approved state of the project’s systems, components, interfaces and boundaries: the design as it actually exists and has been agreed.

Code Ledger (CL)

The code.

What is in the repository, and what every pull request proposes to change.

Code shows what a system does, not why it was designed that way: the ADRs, the policies, the rejected alternatives, the promises made to users. That’s exactly what agent-written PRs break. The Steering Ledger makes that knowledge explicit, versioned and enforceable.

The Steering and Architecture ledgers change only through human-approved Change Intentions. Anyone can propose a change to them: a contributor, a maintainer or an agent. The proposal is captured as a Change Intention (CHI) in a familiar Git-style workflow: branch out, draft the change, open it for review, merge. The approval step is human-only. Agents can help write design intent, but they can’t approve it.

The Code Ledger is audited automatically on every pull request. rkito’s Continuous Design Audit checks each PR against the approved Steering and Architecture ledgers. There are two possible outcomes:

—

The PR conforms. It fits the approved design and rules, so it moves on to normal code review without taking up an architect’s time.

—

The PR introduces a design change the ledgers don’t support. The PR is blocked, and rkito automatically drafts a CHI describing the design change the code implies. The design question becomes explicit and reviewable, instead of slipping in through a diff.

The better workflow reverses the order. When a developer or an agent intends to change the design, they open the CHI first, a human approves it, and only then does the PR arrive, already consistent with the approved design.

Why this scales review

Most pull requests don’t change the design. They fix bugs, add tests, update dependencies or implement features within existing boundaries. Yet maintainers still read every one of them, looking for the few that quietly change the architecture, and that is exactly the work the AI-PR flood has made impossible.

The three-ledger model splits that work in two:

—

Design decisions are rare, deliberate and reviewed by people, through CHIs.

—

Checking code against design is frequent and automated, through the audit on every PR.

Human attention goes to the few changes that actually alter how the project is built. Everything else, whether written by people or agents, is checked automatically against intent the maintainers have already approved. Approved design intent becomes the new back pressure, and the door stays open.

Agents benefit too. Through rkito’s MCP-based session protocol, a coding agent can load the relevant Steering and Architecture context, and confirm that an approved CHI exists, before it writes any code. The PR it produces has already been checked against the rules it will be audited on.

Our commitment to the open-source community

Open source is where the norms for agentic engineering are being worked out. The Linux kernel settled on the “Assisted-by” tag, Ghostty on mandatory disclosure, and the Agentic AI Foundation on MCP and AGENTS.md. Maintainers carry the heaviest review load in the industry, mostly unpaid, and they shouldn’t have to pay for tools that lighten it.

So rkito makes a simple commitment: the full platform, free for open source, for life.

Everything, not a cut-down tier.

Qualifying projects get the whole platform: Steering Ledger, Architecture Ledger, Change Intentions with human-only review, and the Continuous Design Audit on every pull request. It’s the same platform paying teams use.

Unlimited members.

Every maintainer, reviewer and contributor on your project can take part in design review, however large the community.

No trial period and no pressure to upgrade.

The program doesn’t expire and doesn’t nudge you toward a paid plan. It stays free for as long as your project qualifies.

Simple, self-service eligibility.

You need a public repository and a recognized open-source license. There’s no sales call, and you revalidate once a year yourself.

Your governance stays open.

Open-source projects on rkito publish their Steering artifacts (ADRs, policies, principles, patterns and Lenses) openly. Anyone can browse them without an account, and other projects can adopt them instead of writing their own rules from scratch.

Open source gave the software industry its foundations. As agents take on more of the work of writing code, keeping the reasons behind that code visible, reviewable and shared matters more than ever, and we want to help the community do it at no cost.

rkito Labs: see it on your project first

So at rkito Labs we’re doing the work up front. We pick open-source projects, mirror their repositories and run rkito’s Continuous Design Audit on them: capturing their Steering intent, building their Architecture Ledger and auditing real pull requests against both. The goal is to show what design-intent review looks like on a real codebase with real contribution traffic, not a scripted demo.

Want to see it on your project before you adopt it? Email us at [email protected] and we’ll set up a demonstration on your repository.

Have a feature idea or feedback? We build in the open too. Open a request at github.com/rkito-Inc/feature-requests.