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.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.
And even if you aren't that robust about it, terminal apps are the sort of ideal vibe-coded app since, using it daily, you are giving it a constant real world test that uncovers issues to be fixed incrementally.
Is neovim over tmux over ssh glitching? LLM can fix it.
Is codex or claude code overwriting lines in the TUI, maybe due to alt screen, but it also happens in other major terminal apps? LLM can figure out why and whether you can come up with better general architecture to fix it.
Is there behavior you wish you had but no other terminal app supports? LLM can add it.
You can end up with a far better product than what you would find in the wild, and it's a fun sort of work.
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.
It seems like a great stretch to call this "slop".