Hi Emmanuel, I think it would definitely be useful to make the running IDE instance available as a tool for LLM harnesses to interact with.
I have been using OpenCode recently (but also other harnesses before) while using the IDE as window into the projects. Some models were running locally in a box with old gaming GPUs (via ollama atm), others use the typical providers. (there might be also news from the ASF soon for committers - not sure how much of it is public) But there are certainly some friction points with this workflow. Although I think the common case is to let the harness run everything in the background, there are certainly some convenience actions like "once finished, run 'clean verify' using the IDE instance again" or "once finished, open the diff using the IDE" or "use the default JDK configured for this project by asking the IDE instance". Potentially also via the notification system. Opening files via NB launcher works already pretty well since they land in the active instance. Using refactoring capabilities of tooling is also more efficient and can reduce a step of arbitrary length to seconds - dependant on the model and the refactoring, codebase size etc. Although this likely is better to be done by a headless service. Since the IDE instance is mostly there to interact with humans - while not needed as tool for the task itself. For example: I am not sure how useful it would be if the LLM would decide to open a refactoring window for the dev after 10 minutes of iterating on something before continuing with the next 10 minute step. (btw LLMs do a decent job generating NB's jackpot scripts which can be piped into refactoring tasks - since those are basically java syntax with extra sauce) e.g i told locally running granite4.2_8b via OpenCode to run a build on a pre existing "hello world" maven project before writing this reply and it is still contemplating how to reduce the compiler.release property since JDK 27 isn't in the env. But it looks like its nearly there - while the GPU fan is screaming from the other room. (-> would have been faster to ask the IDE where the JDK for this project is ;)) It is easy to forget how much compute it actually requires to change a few chars compared to running a tool. (I can only encourage everyone to *try* to run a local model for a trivial task on a rainy day) Although security wise this can be really quick in "jesus take the wheel" mode. Letting LLMs run maven builds without locking the pom for edits is already more than sufficient to cause trouble. Even though this is the case with or without IDE, if it can use the IDE as tool to edit the pom it effectively circumvented a harness rule. btw there are some community plugins available which let you connect to LLM harnesses and render output in a NB window e.g I found BeanBot at https://github.com/anandb/nb-complete working pretty well. Although I have to admit i use the shell (running the harness UI for OpenCode or others) most of the time. (I will be mostly helping to stabilize the NB 32 release the next days so i might not have much time to think about new features) best regards, michael On 10/14/26 15:52, ehsavoie wrote: > Hello, > I've been playing around to use Agent Client Protocol to connect a coding > agent into NetBeans. > I'm trying to expose NetBeans internal features to the agent for > refactoring or searching code. > It is a work in progress, but part of it is already on a PR [1]. > I've tested in with Github Copilot and IBM Bob so far and I find it nice > for now even if it is a bit rought on the edges. > Cheers > Emmanuel Hugonnet > http://www.ehsavoie.com > http://twitter.com/ehsavoie > > > > > [1]: https://github.com/apache/netbeans/pull/9712 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
