Visualizing the keyword detection pipeline

I’m not happy with the accuracy of the magic words detection system. It work half of the time, sometimes better, sometimes worse depending on the word. This make casting longer spells quite troublesome.
Debugging why a specific word wasn’t detected is hard, debug prints can only get you so far.
So I decided to go on a crazy sidequest and build a gui tool, that will help me debug this. I spent over 2 hours designing the concept, and over 10 implementing it, and it’s around 40% ready.
The tool will display 8 strips / plots, and each plot will display some data, all on a shared timeline on the bottom, that will update live as the audio is processed.

• Strips 1, 2, and 4 will display waveforms of the audio at different processing stages.
• Strip 3 will show Voice Activity Detection score (which is used to filter out non-speech).
• Strips 5, 6 and 7 will display detected IPA tokens, accumulated text buffer, and detected words respectively.
• Strip 8 will display latency stats, which will help in optimizing it.

This way I will be able to easily see, “oh, this phoneme wasn’t detected” or “oh, VAD cut out this word” or “oh, some mess accumulated in the buffer” and tweak my algorithms.

AI - it’s bad, or is it?

Despite looking quite simple on the surface, the app is still quite an undertaking. And it’s just a debugging tool! A thing to help me get the main goal done! I don’t want to spend too much time on it.
So I considered using AI as a tool (NOT vibecoding). I hate vibecod(ing, ers), and I’ve always steered off AI, because very often I wasn’t satisfied with the output quality. I take pride in writing good code. But recently I’ve been trying out OpenCode here and there (on free models), and was quite surprised with it’s capabilities. Sure, it’s still often slop, but a one you can quite quickly correct, and sometimes be more effective if used correctly.

AI - is it helpful?

So I decided to do an experiment - can carefully planned AI usage help me write the debugging tool quickly?
I started off by designing the functionality of the tool - I described the idea in detail to MiMo-V2.6-Flash, and asked it to interrogate me about as many details as possible and needed. I had to answer 35 questions, some of which were quite observant, picking me on nooks and crannies. After that a markdown file describing the design was written, and then went through few corrections.
Next up, in a new session I asked MiMo to create a bullet point outline of steps needed to be done to implement the tool specified in the design file. Then one by one I went over each bullet point, asking the just released LongCat 2.5 (which has a bigger ctx window) to ask me questions, and formulate an implementation plan of it, present it to me, I gave corrections, and the point in file was replaced. This way I ended up with a second markdown file - an implementation plan.
This took way too long, and was really boring. So, finally coding time. I do it like this:

• Ask opencode to implement a step of the plan
• Review the diff in vscode
• Remove fluff and slop manually, make sure all new code is good quality.
• Give feedback if I something doesn’t work like expected, or also fix it manually.
• After it’s good - commit
• Repeat for the next step

It’s still not super fun, but at least I’m touching the code now, so much better already. And it is efficient! I believe it definitely would take me longer, if I wasn’t using AI. So the morale is: If you want fun, or doing something important - do it manually. If you want to do something quickly and get it out of the way less important.

Here is a screen of how it is looking now: the general shape is in place, but there is no plots yet.