djx22

I believe voice transcription should be something you can run privately on your own machine and should be free for anyone to use. It's becoming increasingly easy to build one with Claude but getting it right isn't quite that easy unless you know what you're doing. This is a no BS type of app, does one thing and one thing only: press some hotkeys and get your voice transcribed. No bloat.

It’s a tool until you start outsourcing the thinking to it. Then it’s not a tool, it’s literally the only thing that can work on the codebase. I agree it’s a tool I don’t agree with “using it well takes skill”. I’d reword that to “knowing when to use it takes discipline”.

Sorry about that, didn't mean to attack the person behind it. But anyone can build such an app within a day by prompting Claude.

I think what I was more alluding to was the engineering value such a project brings. But once again, sorry about the messaging.

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.

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.

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.

similar experience, yes. I cancelled my subscription.

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?

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.