This approach seems kind of backwards to me. Why try to detect everything except the thing you're trying to remove instead of either sampling a few uhs and ums and treating them as noise to be silenced (with a sharp crossfade to the noise floor that doesn't interrupt speech flow) or finetuning a model to detect them specifically for full automation?
That's been happening to me more often too recently. I find that, for a growing number of simple problems, reinventing the wheel is faster and more efficient than importing a mature, fully-featured dependency.
I'm not saying intuition has no place in decision making, but I do take issue with saying it applies equally to human colleagues and autonomous agents. It would be just as unreliable if people on your team displayed random regressions in their capabilities on a month to month basis.
On the topic of Zed itself as a VSCode replacement - my experience is mixed. I loved it at first, but with time the papercuts add up. The responsiveness difference isn't that big on my system, but Zed's memory usage (with the TS language server in particular) is scandalous. As far as DX goes it's probably at 85% of the level VSCode provides, but in this space QoL features matter a lot. Oh, and it still can't render emojis in buffers on Linux...
Reports of people losing data and other resources due to unintended actions from autonomous agents come out practically every week. I don't think it's dishonest to say that could have catastrophic impact on the product/service they're developing.
There's some good feedback in the GitHub issue on the subject, seems to happen on slightly newer versions of the kernel than the one you've tested on and affects other distros like Arch as well. I'll keep an eye on the discussion and test again once updates are ready.
> after using it for months you get a ‘feel’ for what kind of mistakes it makes
Sure, go ahead and bet your entire operation on your intuition of how a non-deterministic, constantly changing black box of software "behaves". Don't see how that could backfire.
If your API can run on the edge, you can get a database, function calling and user auth on Supabase's free tier. For a full Node.js runtime, Vercel's free tier is still a good option (if you don't need observability), again paired with Supabase for data.
If you can stretch "free" to "under €100 per year", then a cloud server from e.g. Hetzner will give you full control on a budget.
It's the same with the "Star Wars" brand - the biggest chunk of revenue comes from merchandise and licensing, not the movies/shows. Lucas famously became a billionaire by securing merchandising rights in his original contract, not because of the cultural impact of the franchise.
Congratulations, that's an impressive achievement. I've successfully evaded learning anything about Kubernetes this far, but I guess this is a good opportunity to see what I've been missing.