It's because vibe coded apps have flooded the internet. This one is no exception. The feedback loop is now real: LLMs train from github on their own produced slop which they feed into the apps people build and publish on github to show off their "skills". In 2 years from now LLMs will become dumber and dumber as the rate of quality code vs. slop will be greatly imbalanced so, naturally, the more slop you have the more probable is that the LLM will use it for its answers. The death of software engineering is real.
I’ve been a software dev for 15 years. Def not trying to show off my skills This is just a little side-project. I have no plans to monetize it. Totally - much of this is vibecoded. It’s been fun building and customizing this for myself rather than paying wisprflow, and thought other people might find it useful
the loop is going to be interesting as we produce orders of magnitude low signal code, how do Labs comb through everything to train on the true contributions since last training run?
I wonder if one way to monetize certified "skill" will be to syndicate / license your provably well software engineered / tasteful AI engineered code back to the Labs for a fee
You may want to look into different models that are more accurate and maybe an AEC layer to remove background noise. Or at the very least a RNN de-noiser on the mic channel. Also, you may want to stream audio to the model instead of holding it all in memory and transcribe at the very end as that can potentially allow you to take the app much further than it is now.
I see Claude implemented a very crude upsampling/downsampling algorithm, which is what LLMs usually do when prompted to handle such a problem. But I would suggest restraining the model from implementing DSP processing on their own and instead use battle tested libraries. You can use rubato's FFT Resampler.
Audio processing is genuinely a hard engineering problem, LLMs usually don't get it right. If you decide to get deep into it, the knowledge you'll get is very rewarding.
Actually, this paper shows that the LLMs create a lot more slop and degradation of the code after the first prompt. https://arxiv.org/html/2603.24755v1.
So iterating with the LLM will simply make it to produce worse and worse code.
Not sure what everyone's experience is but I find 5.6 Sol to be a great liar. Reported success on a half done job and left things in a broken state after having quite a few back & forth followups on the initial prompt to clarify the plan. Didn't experience this with 5.5. Opus 4.7 and below sometimes did it but they fixed it in Opus 4.8. So, overall, the initial experience has made me think that this model will be a lot more stressful to work with just because the level of trust that it actually completes the task is now much much lower.
in my experience running models that have been heavily quantized(q4) or altered to some extent has never made me say “wow, this is so amazing”. On the contrary, the model ended up in the thrash bin after a few prompts.
I have an RTX 6000 PRO with 96GB, and what I can run comfortably is Qwen 3.6 27B or MoE, Gemma 4 31B. This is as far as it goes when you run the model at full precision and maximum context length.
They perform well and you can use them for coding, doing research on the internet and what have you. So if you do the math and you see yourself spending more than the $2400/year to Anthropic, then it might make sense to get one of these cards but accept the quality drop. Otherwise, will humans even be coding in 5 years from now?
what you maybe forget here is the use case for people and businesses who can not send the data to 3rd party due to privacy/contractual reasons. This is what I'm looking at, we're bound by strict policies for data sharing outside of our premises.
yes, I understand the usecase. Where I'm coming from is quantized vs. unquantized. 4bit quants are lobotomizing the model heavily to the point that it's better to invest in some capable hardware than keep fighting the limitation. Refurbished server grade hardware is accessible. For the price of an RTX 6000 PRO you could probably get much more VRAM but 1-2 generations older.
Don't let AI write code for you unless it's something trivial. Instead use it to plan things, high level stuff, discuss architecture, ask it to explain concepts. Use it as a research tool. It's great at that. It's bad at writing code when it needs to be performant or needs to span over multiple files. Especially when it spans over multiple files because that's where it starts hallucinating and introducing abstractions and boilerplate that's not necessary and it just makes your life harder when it comes to debugging.
Imagine if every function you see starts checking for null params. You ask yourself: "when can this be null", right ? So it complicates your mental model about data flow to the point that you lose track of what's actually real in your system. And once you lose track of that it is impossible to reason about your system.
For me AI has replaced searching on stack overflow, google and the 50+ github tabs in my browser. And it's able to answer questions about why some things don't work in the context of my code. Massive win! I am moving much faster because I no longer have to switch context between a browser and my code.
My personal belief is that the people who can harness the power of AI to synthesize loads of information and keep polishing their engineering skills will be the ones who are going to land on their feet after this storm is over. At the end of the day AI is just another tool for us engineers to improve our productivity and if you think about what being an engineer looked like before AI even existed, more than 50% of our time was sifting through google search results, stack overflow, github issues and other people's code. That's now gone and in your IDE, in natural language with code snippets adapted to your specific needs.
IME it’s actually really terrible at discussing architecture. It’s incredibly unimaginative and will just confirmation-bias whichever way you are leaning slightly more towards
