Checking the HISE Source with AI?
-
@clevername27 I think you have more faith in AI than I do.
-
HISE is a big codebase with a variety of dependencies, I think the risk of hallucination & context-rot is a lot bigger than your average JUCE plugin.
There's also a lot of templated functions, specific versions of things like JUCE and the C++ version HISE uses which LLMs usually don't "keep in mind".
Also GLM4.7 has noticeably outperformed Claude & GPT 5.2, at least in my own tests
I'm sure Christoph uses some of these tools occasionally, but I think if he started depending on them for the short-term benefit we'd probably end up with a lot more bugs in the long term
-
@clevername27 I've been fixing a few isolated bugs lately, with the help of Claude in Cursor.
From doing that work, I can say with a degree of certainty, that it's not a good idea to let any AI go wild fixing bugs in the whole codebase right now.
Meat Beats: https://meatbeats.com
Klippr Video: https://klippr.video -
I've been reviewing & merging some of the pull requests from Danny yesterday and I really appreciate the work here which filled a lot of blind spots that I didn't see.
That being said the fixes I merged are on surface level at best - usually one liners that remove a quirk in the HISE UX or a simple bug fix or simple additions that work within a very tight scope. Again, these really nice and I'm sure it removes a lot of pain points for many people.
I haven't merged a few of those on the other hand - mostly because they interfere with something that causes backwards compatibility or are potentially problematic in use cases other than the one that is immediately addressing the problem (eg this one here). Merging those require a lot of testing & different edge case handling so you can imagine that the time to find & fix the bug (regardless of whether AI was used or not) is about a tenth of the time to actually test whether this is a safe change.
Now the idea of just letting AI slop take over and completely butcher the HISE codebase "in a matter" of hours is a frightening thought - not only would I loose authorship over the codebase so it becomes a black box to everybody, we can safely assume that the AI definitely does not have the "gut feeling" of recognizing "problematic" fixes like the one linked above vs. unproblematic ones (the ones I merged yesterday). Also I'm pretty confident that this won't be solved by the next iteration of LLM models.
Someone has created a HISE language model for the AI coding models that understands the HISE language, with all with its quirks and edge-cases.
While I see the benefit of AI in enhancing the documentation to make it more approachable (and we're experimenting with different things there too), the idea of a LLM model that spits out HiseScript code is a bit contrary to the entire concept of HISE. If you want to vibecode your way to a plugin, just use JUCE with a webview, these are two mature codebases with lots of existing code examples so that the LLM output is much more robust.
-
@Christoph-Hart Agreed, backwards compatibility in HISE is something I'm not very familiar with, still being fairly new to the codebase, and it's something AI has literally no idea about.
-
@Christoph-Hart said in Checking the HISE Source with AI?:
If you want to vibecode your way to a plugin, just use JUCE with a webview, these are two mature codebases with lots of existing code examples so that the LLM output is much more robust.
Well said, whether you meant is sincerely or sarcastically!
People are vibe coding fully-functional iOS apps in hours now, instead of months.
-
@Christoph-Hart I appreciate that, and thank you for your detailed response. But I already built the model, and it has been working perfectly. It finished the plugins I was unable to finish going back a year (because the functionality I needed was undocumented), and it has since written two other highly-complex plugins. You have to create a model (and I use the term loosely) for HISE, first; out of the box, the existing coding models are of little value for HISE development.
-
@dannytaurus I can say with a great deal of certainty that I already created it, and I haven't written a single line of code, since. I don't mean to be snarky; it's just the certitude I'm responding to. I wish you the very best in your efforts.
-
@clevername27
You created an AI model that generates the complete code for a complex plug-in, and since then you haven't had to write a single line yourself? Does that mean you didn't have to change anything in the code generated by the model? Am I understanding that correctly? -
@clevername27 Just to be clear - I was talking about using AI to knock out bugs in the HISE codebase en-masse. Building a plugin is an entirely different endeavour.
Glad to hear you've got such a great model working for that.
I agree about the undocumented stuff, by the way. Giving the AI the full codebase then querying it on features and techniques can be extremely effective.
Meat Beats: https://meatbeats.com
Klippr Video: https://klippr.video -
You have to create a model (and I use the term loosely) for HISE, first; out of the box, the existing coding models are of little value for HISE development.
Interesting, how did you do that? Did you use a pretrained model or just added some context data? I did some experiments where I fed it a JSON formatted output with all code examples from the doc codebase, but I used a very simple local LLM to check it so the results were subpar.
