Agentic coding workflows

[David Healey]

I can see cost being a massive restriction for using agents regularly. I've just burned through my limit with Claude Pro in a couple of hours. Now I have to wait for the lockout to reset in a few hours before I can continue or I have to switch to PAYG, and I'm already 12% through my weekly limit.

[Bart]

@David-Healey said in Agentic coding workflows:

I can see cost being a massive restriction for using agents regularly.

Try Google's Antigravity with the Gemini 3 Flash model set to Fast.
It's near the quality of their Pro models but with significantly more free limits.

Claude Sonnet models have typically been the best I've experienced, but the gap is small now, even for Google's Gemini 3 Flash model, which people are actually preferring; just be prepared for it to once in a while randomly write 100 lines for a 5 line piece of code.

Claude's pricing is ridiculous.
I would be very hesitant to pay a subscription for any AI model when my input is training it, unless it happens to ultimately demonstrate consistent error free value.

[Christoph Hart]

And on a tagent slightly, but one of the biggest hurdles to writing complex projects in HISE is just how many languages and approaches you need to take command of. In C++ I can focus on JUCE and C++. In HISE, I need to learn HISEscript, C++, SNEX, simple markdown, and even css. This is a barrier to speed.

Yup, I understand that, however nobody forces you to use CSS or markdown :) On the other hand, the LLM has no problem using different languages (assuming that I solve the knowledge gap problem to HiseScript and make the CSS parser a bit more standard conform), so I would say that if you don't understand CSS you can still use it through an LLM.

That's where it's been most obviously unusable for me; if I'm spending half the time reiterating the same basic Hise scripting errors back to the LLM, that's too much time and tokens wasted to achieve anything substantial. It's mostly the frustration of it that kills the motivation to continue, otherwise it has great potential!

Yes that is basically LLM integration 101: remove the friction point that it mixes up HiseScript and Javascript. I'm pretty confident that I'm 80% there with the MCP server and the latest models, but this will be an iterative process that will take some time.

But I agree that if HiseScript turns out to be a burden (hallucinates Javascript) instead of a opportunity (allow a fast & tight feedback loop) for LLMs then there will be smoother workflows from competitors, so this is a key problem for me to solve.

[gorangrooves]

@Christoph-Hart When I started using ChatGPT to help me scale and optimize scripts in HISE over 2 years ago, I foresaw the very thing you are describing now as the future of HISE. I never got around to writing a post of my vision.

I didn't come to HISE because i wanted to learn coding. I had to grasp coding in order to make the instruments I wanted to make. Whatever is the most practical approach to archive a goal is the one I use.

I am delighted to hear about this new direction and the progress you are making. The more of a seamless, logical, frictionless, straightforward experience you make for us using HISE, the better the platform is. I'll code what I can when I have to, but I'm not here to code.

Ai has been an indispensable help for me with web stuff as well, helping me troubleshoot, fix, clean and optimize things.

Good on you, Christoph, for moving into this direction.

[Bart]

@Christoph-Hart said in Agentic coding workflows:

I'm pretty confident that I'm 80% there with the MCP server and the latest models

Hi Christoph.

Is there something ready to test regarding this?

With simple instruction for use with Google's Antigravity if possible..

[Christoph Hart]

@Bart yes the MCP server and LSP servers are fully functional, but I‘m only using Opencode with Claude here so I can‘t say how it works with Googles toolkit.

[Sifres]

@Christoph-Hart

Really nice work man! Gonna play around with it. Its already mouthing me off on button placement

[dannytaurus]

@Christoph-Hart How are you finding Opencode? I'm trying out a few but haven't landed on one I like best yet.

Cursor: love the chat history and better context management, but steering messages are janky
Claude Code: like the simplicity of single terminal window but not really the resulting view
Codex: love the split chat/diff layout and it has chat/task history too, best so far for me

Haven't tried Opencode yet. Looks a lot like Claude Code in layout and style.

[David Healey]

@dannytaurus I'm also thinking of trying the integration in Zed
So many choices, so little time.

[Lindon]

@David-Healey @dannytaurus .. Im just going to wait until you all decide what the best one then use that....

[Christoph Hart]

I actually haven't tried anything else than opencode - it sometimes crashes after sessions but that's the only thing that annoys me, the rest is close to perfection for my taste.

I just noticed that anything lower than Opus 4.6 or equivalent models from competitors is complete trash for almost every task I threw at it - a notable mention goes out to GLM5, which they advertise as a replacement to opus-type models but it spectacularly failed with a simple and deterministic refactoring job.

[HISEnberg]

I finally had a chance to dig into the new setup this week and my head is still spinning with the possibilities. I agree with Christoph that there is something almost uncanny about Opus 4.6 (I'd add Sonnet 4.6 which I use for most tasks) when it comes to writing Hisescript and editing the source code. Next best models which I find produce useful enough results are GPT-5.4, and Gemini's new multimodal embedding model has piqued my interest as well.

It's still early days of trying out different workflows but what does everyone's setup look like currently? Are you still using the HISE script editor or do you find working out of a separate IDE more convenient at this point? I've been using Visual Studio for the most part launching Claude Code or Codex in Terminal. Admittedly, I still find HISE script editor too useful to completely separate with it...

On another, note how are you all getting along with specific HISE projects at this stage? One thing I am noticing is how much more aggressive Claude code can be on token usage if you don't prompt and direct it right. Previously I would consolidate all necessary information (Scripts, xmls, Dsp Files, scope of work, bug checklist, etc.) along with specific examples, API documentation, or source code from HISE, and create a new project with an LLM. This seems to have the added benefit of keeping the model more focused, faster, use less resources, and most importantly, retain memory. The main drawbacks are lack of project/HISE context and lack of writing to project.

So the MCP server approach does allow for read/write to the project and clearly performs significantly better, but requires careful prompting and project context to avoid significant token usage. Figuring out the right balance between comprehensive context and efficiency is the real challenge for me moving forward. I imagine this just boils down to reformatting my setup to include the right sort of skill, tools and spawning subagents in the right context.

I'll have to try out opencode as Chrsitoph suggests and using this to make edits to the HISE source code are next on my bucket list as well!

[Christoph Hart]

@HISEnberg I'm trying to optimize the MCP server for token usage and it's highly more efficient than a web search of eg. the HISE docs - eg. the current scripting API enrichment pipeline that maxes out my 200$ claude max subscription within a few days creates a highly concise LLM summary for each class that strips all the fillers that humans need to parse text.

The MCP resources are also structured in a nested hierarchy - so there is a general coding style doc, a coding style documentation for LAF / ScriptPanels, etc. and you can instruct the LLM to only pull in the resource it needs for the job.

Are you still using the HISE script editor or do you find working out of a separate IDE more convenient at this point?

Funnily the side-effect of writing a LSP server that the LLMs can use to lint HiseScript was that vibecoding a VS-Code extension is pretty trivial - it can just reuse the same logic and all the heavy lifting (shadow parsing - multi-error diagnostics etc) is already implemented. As much as I love my little code editor in HISE, I think its days are numbered - it's just too tempting to pull in the industry standard code editors and the missing runtime inspection and integration with HISE was the only thing holding it back.

I'm currently also toying around with a TUI interface that connects to HISE with a REPL - from there you can just do stuff like :switch_project MyProject or builder add SineGenerator to Container - same concept: stuff that the LLM can use to remote control HISE can also be packaged into a nice experience for the human.