Comment by hombre_fatal
6 hours ago
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.
I too built a terminal emulator and I like it, but I wouldn't say it's easy to maintain even with LLMs. The # of edge cases is insane.
The cool thing is that you can use and adapt the tests of all major third party terminal implementations. Come up with your own invariants (brainstorm them with a smart LLM), and now every third-party test either passes, diverges (due to invariant/arch), or diverges (due to product bug).
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.