Open source has been part of how we work at Crunchloop for as long as we've been writing software. Not as a marketing strategy or a hiring signal. As a default. The tools we depend on are open source. When something breaks or is missing, the natural move is to fix it upstream.
What changed in the last few months isn't the impulse. It's the capacity.
More Problems Became Reachable
AI didn't make us want to contribute more. It made contributions that used to be out of reach suddenly feasible. Not because the problems got easier — because the ramp-up cost dropped.
Consider the range of what we touched in a single month: node:http socket handling in Bun, stored generated columns in Prisma's Rust engine, cgroup settings in Bottlerocket's SDK, PostgreSQL array support in Azure's Data API Builder, function coverage in WebKit. Different languages, different architectures, different domains. A small team doesn't get to touch all of those without something shifting in how the work gets done.
The shift is context acquisition. Understanding a large, unfamiliar codebase used to take days before you could even locate the right file. AI compresses that. You can map an architecture, trace a code path, and form a hypothesis in a fraction of the time. That doesn't mean the fix writes itself — but it means you get to the fix faster, and you get there with enough understanding to know whether what you're doing makes sense.
The Responsibility Didn't Shrink
Here's the part that matters: generating a pull request is now trivially easy. Anyone can paste an issue into a prompt and get a diff. That's precisely why the bar for what constitutes a real contribution has to go up, not down.
Every contribution we push goes through the same process. Reproduce the problem. Write a test that fails. Fix the issue. Verify the test passes. Figure out if the change warrants end-to-end coverage. Read the project's contributing guidelines. Look at how existing tests are structured. If we're touching an area we don't fully understand, we ask maintainers for guidance in the PR — not after we've already forced a direction.
We don't hide the fact that AI is part of how we work. There's no reason to. The question isn't whether AI was involved. The question is whether the contributor understands what they're submitting and can stand behind it.
The Maintainer Problem Is Real
The other side of this is harder to talk about.
If AI makes it easy to generate contributions, it also makes it easy to generate noise. Maintainers are already stretched. Now they face a growing volume of pull requests where some percentage are AI slop — superficially plausible diffs from people who don't understand the codebase and won't be around to follow up.
We've seen this firsthand. PRs with concrete reproduction steps, failing tests, and detailed explanations still sit for weeks. Not because the maintainers don't care — because their attention is a finite resource that's being diluted by volume. The signal-to-noise ratio in open source inboxes is getting worse, and AI is a contributing factor.
This creates a tension with no clean resolution. The same tool that enables more legitimate contributions also enables more low-effort ones. And maintainers have no reliable way to tell them apart at a glance.
Contributors have to carry more of the burden of proof. That means tests, reproduction cases, clear explanations of what breaks and why. It means doing the work that makes a maintainer's review easier, not harder. It means treating their time as the scarce resource it is.
The Fork Question
When your PRs sit in that queue, you still need the fix. That's where the pragmatic question lives.
We invested significant time building a custom Bun binary. We're moving to Bun to skip the build step entirely and ship single-binary applications — a real architectural win. But some of the upstream fixes we need are sitting in open PRs. The runtime works for us with those patches applied. Without them, it doesn't.
So we forked and built our own. Not because we wanted to — because waiting wasn't an option.
This is going to become a more common pattern. As AI enables teams to go deeper into their dependencies, they're going to hit more cases where the fix exists but the merge doesn't. The question is whether the ecosystem develops better mechanisms for this. Easier ways to maintain patched forks. Better tooling for tracking divergence from upstream. Some path between "wait indefinitely" and "maintain a permanent fork."
We don't have answers here. But we think it's worth naming the problem.
The Bet
AI is making open-source contribution more accessible. That's a fact, and on balance it's a good thing. More people can fix the tools they depend on instead of working around bugs or waiting.
But accessibility without responsibility just creates noise. Contributing to a complex project used to be genuinely hard — hard enough that most teams never tried. AI lowered that barrier, and that's worth something real. What it didn't lower is the standard. Understanding the problem, proving the fix, respecting the maintainer's context — that part still takes the same care it always did. You just get there faster now. And faster is only good if you don't skip the steps that matter.