Isn't that kinda expected with a new software release, that it doesn't have a 100% feature parity?
My experience with LLM technologies is it does make generating the code a really quick part. It may be reasonable to take much more time to specify things up front (rather than emergently as you would by hand). -- I mean, if you've got a well crafted description of what you want, you'll be able to get a working program MUCH quicker with an LLM, today, compared to writing it out by hand.
Would it really be surprising/shocking if an LLM was able to rewrite (most) features from an existing software, to a new software?
It seems like the reality today is, we've gone from a maintained software in a niche ecosystem with happy users, to a more fragmented one where everyone has an LLM write their own half-baked one.
Try doing that with Elfeed2.
Vi/Nvi2 users can almost do the same with Unix pipes and apertium/translate-shell/some lingva CLI translating tools for the whole document/regex selection/lines, a la Emacs. So can sfeed users, where depending on the feed they can pipe the plumbers' output (or just hack the scripts) to any other translating tool:
git://codemadness.org/sfeed
Heck, a few years ago I could reuse Telega.el's (Telegram client) translating functions for non-Telega buffers translating some text guide in the spot. So, did the blogger actually win something?