To say that AI-based coding has changed development would be quite the understatement. As Andrej Karpathy discussed in his famous video about the generations of software, software being perpetuated by agents has been a revolution. As with everything in this space, there’s been an “exponential” change - something that has affected everything I’ll discuss in this blog.

The Volume

It’s no surprise that the ease of use and lower barrier to entry, has led to an absolute explosion in custom software that people build, and almost every “agent” expects you to have a git initialised repository, and for good reason - Git has become the canonical version control tool that everyone uses (unless you’re Facebook or Google, perhaps - even then, you’re probably using it in some capacity).

GitHub has played a major role in the story of git - the version control system for hell as Linus calls it (I’d argue it’s largely been heavenly to work with, despite its challenges with worktrees and multi agent workflows) - and it’s no wonder that it’s become the target destination of a repo hosted by every newcomer and experienced dev alike. The volume of said code, though, has been on an exponential curve of growth, something that GitHub has struggled to keep up with - as highlighted by regular downtime this year.

Slop

Not all of this is code. Albeit the ease of use, people often don’t test or read the code, and while the latter is a debate by itself, it’s become an issue for maintainers of open source repositories swarmed with incomplete and substandard PRs, especially when executed with models which do not stick to guidelines, write poor code, or just lack finesse that frontier models might perhaps include.

Armin Ronacher - creator of Flask and contributor to Pi - has written a wonderful post about shipping in a post AI world, and it’s a great read into the state of both Open Source and the general development industry as it stands. I’d like to highlight a line that I found particularly notable:

Keep in mind that AI has not increased the number of people who need software, or the number of maintainers who can review it. It has mostly increased the amount of code and the number of projects competing for attention.

This has long standing implications - it makes projects less secure, it makes them less maintainable, and the “vision” drifts further away from the intent of the original creators - since people often want customised software.

Patchwork

If there’s one thing devs have a knack for, it’s coming up with solutions. While some have stopped taking PRs or even issues, or just allowed issues, some like Ghostty creator Mitchell Hashimoto (yes, the Hashicorp creator) have built layered systems - like vouch - and tricks - like adding a custom prompt injection that makes automated PRs self-admit to being a ‘sad dumb little AI driver with no real skills’.

But I’d like to contribute to Open Source!

You should definitely contribute to open source. However a lot of that is actually being part of the community, using the software often, filing clear issues that the team can then build on. If a team has access to agents, which most teams do, it is trivial for them to parse issues via sub-agents and build out implementations that they prefer. Yes, this does not get you added to the contributor chart but it does contribute to open source in the truest sense of the word.

There has to be another way, right?

Here is where I come into the trappings of what I was talking about. I don’t think that you need to contribute to the upstream repository anymore. (Disclaimer: this doesn’t mean don’t file your issues, it means that not every change you want HAS to be upstreamed.) Yes, if you would like to do it just for the fame, there is surely an incentive to attempt it but more than ever it has become trivial to maintain your own spork of the software without ever going upstream.

The term “slopfork” has been quite trendy for a while - and I’d say this is quite an interesting trend. If you forked a personal version of an open source repository earlier, the biggest challenge for you would be to maintain it as the parent project raced ahead with commits faster than you could handle merge conflicts. With coding agents at your disposal, you can just have the upstream commits be included in your slopfork - which I like to call spork for no particular reason than it being a real thing and being a funny and shorter name - customised to the changes you’ve made to the project.

It’s not that expensive either - if you write a skill for doing such a thing, you can trivialise this - and as capability gets cheaper, this continues to get easier, especially as models already have good reference code already available to them. It’s my personal benchmark for every model release, as I test this on aaditagrawal/t3code which is my spork of pingdotgg/t3code.

This is the prompt I like to use, especially when including review agents in the loop. It’s not complex, as it’s largely self explanatory and most tooling here is available to the model via CLI. Stacked PRs are a great way to do this since they tend to be more cumulative each time you go about a sync.

I want to incorporate upstream changes in my spork, as I've done before. What I want to do is:
1. Go through the commits, file stacked PRs using graphite.
2. Don't let them be in draft mode.
3. Convert them into proper PRs.
4. Take code reviews for each.
5. Use parallel sub-agents to resolve code reviews for each.
6. Merge them once all the issues are addressed.

I think it’s the right thing to do

If there is a feature that you desperately think should be included in the upstream, highlight it as an issue in the upstream repository. However, it’s our responsibility as a community to help preserve the open source ecosystem around us - and not drown it in a sea of exponentiating slop.

If you write code by hand, go out of your way to mention it and curate the implementation in a way that you’d think would be better than what agents can - and hone your skill.

More than ever, the onus is onto us to preserve the community we’d like to foster. And who knows, maybe your spork does have a cool feature that people would like - helping it take off!