Missing context:
[Cable is a] PyQT GUI application to dynamically modify PipeWire and WirePlumber settings at runtime, such as quantum, sample rate, audio profiles, latency offset, services restart and more. It features side-by-side, MIDI matrix and graph style connections managers (uses Python Jack Client so will not list Pipewire items), pw-top wrapper, simple ALSA mixer and jack_delay GUI.
More missing context:
The app was made with heavy usage of various LLMs.
This is often a concern for me, too, but the developer of Cable has been honest about their LLM usage. From what I’ve seen, they listen to feedback from users, test the code, and regularly maintain it with frequent updates. I have not heard users voicing any significant quality issues. Users generally speak positively of its functionality and usefulness. Given it is not an overly complex piece of software, and having seen the care the developer has put into the program, assistance from LLMs is not a deal breaker for me. There are vibe-coded programs that I wouldn’t touch, but Cable isn’t one of them. I understand others may not feel the same way, and that is perfectly fine. I’m just handing out my two cents.
You’ve hit on a clear distinction here: the YOLO / vibe code project vs. a project where the assisant serves a human-envisioned design.
I’ve avoided the use of LLM coding assistants for quite a while (I’m 40+ years into getting paid to write software at this point), I’ve finally, reluctantly begun to experiment with them. My experience is mixed, but a great deal more useful and pleasant than I expected.
The Cable developer (magillos) is using the LLM to implement a design which they clearly understand well: the key identifier is that they are able to keep the software moving forward, fixing bugs and elaborating features without breaking what already worked. The contrast is the “over the wall” release of code which seems to do something useful, followed by utter crickets in response to bug reports, questions, or feature requests: the vibe coder doesn’t have a clear enough grasp on how the software works to do useful maintenance on it.
For my own use: working with the code-oriented LLM is kind of like pair-programming with an eager, talented, and un-jaded teenager: the apparent attitude matches such folk who’ve never had to live with the painful consequences of their own, too-hasty design and implementation choices. Letting such an assistant tackle a task of any size without deep feedback and intensive review is a recipe for disaster.
OTOH, where they truly shine, compared even with very senior developers (myself included), is in their willingness to keep the docs for a project up in sync with code changes. There is basically no inducement, not love, money, or fancy-spirit-of-choice, that will get a human developer capable of understanding the code to do that work reliably over time. Yes, I’m sure there are exceptions, but they are rarer than suspenders on snakes.
I agree. LLM can be used successfully but many restraints need to be in place first. If one thinks they can ask AI to “build me a program in rust that does this” then yeah, they will probably get something that kinda works, but nothing that is sustainable. If ones works with LLM as a designer and knows that proper paths to follow (this is a learning process for both the programmer and the AI) and good outlines (with defined variables) of what it needs to do, then yeah, you can have good success with LLM. You must start with some working code and build on that. One piece at a time. Then one must understand the resulting code then build on that piece by piece. It’s a process for sure. I have found LLM can rename variables or even totally go airy at times! So one really needs to understand the code it produces, then order corrections…or make them manually.
Anyway, this new release of Cable works very well. Nice job!