> Then you’re maintaining a stack of patches on top of the upstream until the end of time

The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness:

  Set up a nightly cron job that
  executes the prompt: fetch upstream
  changes to the <software> and
  rebase all local changes on
  top of upstream. Check that the
  software works as intended and
  replace the current version.

Maintaining a fork seems trivial for an LLM. Replaying each upstream commit against your fork is exactly what even dumb models can do without issue.

But at the same time LLMs also let you question why you’re using a dependency if it’s causing certain issues for you.

e.g. I got tired of waiting for libghostty to publish a new stable release since the one in March which would have a memory leak fix I reported, so I spent a week of getting LLMs to build my own solid pty/terminal emulator. Now I have my own and frankly I'm in a better position having done it.

That's a ridiculously massive change to our relationship with software projects.

> Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date.

I thought about this but I currently maintain a fork of about ~6 things I use on my own, none of which I have any interest of contributing upstream because it'd be out-of-scope and put a burden on the maintainers that is unrelated to their primary goal. It has been an extremely easy experience with claude to keep those tools up to date on top of upstream.

StGit/Stacked Git is a proven tool for this and has worked wonders, I can literally just ask claude to fetch upstream and reapply stg patches on top and fix each patch if they break in order. I also keep extensive description of the INTENT on the stg patches so claude can easily figure out if something is no longer relevant (ie: somewhat implement by upstream) or where to land the code/hooks. I've added features, reworked how algorithms work (pathfinding related!) and small nits I hit on daily usage.

Even on a very churny upstream (one of the projects the single dev likes to refactor alot) it's still extremely chill and doesn't take more than an hour to get it updated when everything breaks. I can't say i care enough to setup a daily cron like a sibling suggested, but it would likely work just based off of this stg experience.

It's also nice, because some of those were actual bug fixes too which i have contributed back upstream! Maintaining your personalized fork is truly reasonable nowadays.

> even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support

It seems like a great stretch to call this "slop".