I've always noodled about this marketplace idea where an optimization algorithm could match your interests and a dollar amount you can afford to let you rent/buy artist's music. The optimization would maximize the purchase of the differently valued music(analogus to the weighted knapsack problem but this could have multiple solutions, knapsack is a nice way of thinking about it logically, in reality implementation may be completely different) based only on your interests, like history and dollars u have. I am wondering how might one apply a distributed systems approach without having music pirated and shotgunned all across the internet? Like how would you quickly match a person to all the available music metadata? How would you model for interest matching if the music library is spread out across multiple nodes.
I would imagine a lot of people are ok with paying 5-10$ a month instead of 15-20$ for music they like from a set of artists they like.
Vibe coding signifies a lack of control over one's own code and generally only if it's to generate ideas or throwaway. The negative connotation that goes with it is appropriate too.
In reality any project that takes 6 months means your have invested a lot of time thinking about the code, in which case LLMs become more useful for the things you care about e.g. maintainability, forcing LLMs to bend to your will, which is like saying: " I know this design is the best so just make this instead of whatever abstraction you think is better".
I have used LLMs to understand certain concepts and unfamiliar APIs. Gtk and Rust is actually a pretty funky combo.
Strong agreement
- Panicking error handling — both flag unwrap()/expect() on fallible operations (secrets, HTTP client, GStreamer). Kimi specifically calls out get_stream_uri returning String instead of Result, which I missed — good
catch.
- Excessive cloning — both note the Jellyfin client and string cloning. Kimi's phrasing ("host.to_string() on every request construction") is more specific than mine.
- Application struct overloaded — both agree it holds too many responsibilities. Kimi suggests splitting into LibraryService, PlaybackService, etc. I focused more on the RefCell exposure.
- Silent error suppression — both flag let _ = sender.send(...) and unwrap_or_default() patterns.
- Code duplication in UI — both identify the repetitive list/detail/sorter patterns. Kimi specifically calls out call_on_visible_page widget comparisons, which I grouped under the broader "5+ copies of factory setup"
observation.
- Missing HTTP timeouts — Kimi flags this explicitly. I noted it indirectly via the buffer_unordered without timeout, but Kimi is clearer.
Things Kimi caught that I didn't emphasise
- get_stream_uri returning String instead of Result — a genuine API design issue I glossed over.
- String-based signal names being error-prone with no compile-time checking — fair point, though it's idiomatic GTK4/Rust.
- glycin potentially unused — I didn't check dependency usage.
- Position polling not accounting for seeks — a practical UX observation I missed.
- /proc/sys/kernel/hostname read being cached in OnceLock — Kimi approves the caching but notes it could be done once at startup. Minor but valid.
Things I caught that Kimi missed
- Actual bugs — queue reorder off-by-one, playlist DnD index error, toast format string "HTTP {} error" never substituted, double-wrapped Result in stream_info.rs, reversed comment in shuffle logic. These are concrete
defects, not just style issues.
- Concurrency issues in depth — the Cell<bool> shuffle state race, futures::Mutex inside glib::spawn_future_local deadlock risk, queue mutation race between remove_all() and extend_from_slice().
- Signal handler accumulation on widget reuse in ListView factories — a slow memory leak.
- Main-thread blocking from synchronous library filtering in detail views.
- Image cache with no eviction — unbounded disk growth.
- bytes_to_texture panicking inside a Result-returning function — defeats the entire error contract.Not everyone is paying for LLMs, even now. So I think it is perfectly reasonable to assume good intentions, here.
Someone spent their own tokens to ponder your code and thought they'd share the result. For anyone else looking, like me, I can see that this is probably going to come up relatively clean without having to spend my own tokens, or install it, and I'm more likely to, now that I can see that.
This is fascinatingly psychotic - but for your own good you might want to shut down the agents for a bit and take a walk.