While lots of efforts went into expecting LLMs to use the right nodes with the right parameters in the right order, did any dev try to give the LLM the freedom to create Python nodes on the spot that exists only in the realm of a single workflow?
In my opinion this could unblock KNIME in offering any visual workflow on the spot where each node offers settings only for what is required by the user.
While this could be limited only to Python libraries available in the default environment, it would also offer great flexibility in how the workflow looks to the needs of the user: number of nodes, color, amount of parameters, icons, making truly open for innovation
You’re absolutely right about the upside: giving an LLM more freedom to synthesize task-specific logic can be very powerful and would unlock a lot of flexibility in what could be done with workflows.
At the same time, where and how this freedom is introduced matters a lot.
KNIME already allows AI-generated logic in places where the risk is low and the semantics are clear—most notably in Expression nodes. These are side-effect free, operate on explicit inputs, and have well-defined behavior, which makes it reasonable to let the system generate expressions automatically.
A deliberate design choice in KNIME is to prefer existing, well-known nodes wherever possible. Using established nodes increases trust and understandability: users know what a node does, what its guarantees are, and what kind of behavior to expect just by looking at the workflow. That shared understanding is a big part of why KNIME workflows work well as collaborative and long-lived artifacts.
Dynamically generated Python nodes change that balance:
Python is imperative and side-effect capable, which raises safety and governance concerns.
A lot of logic gets hidden inside code, making workflows harder to reason about at a glance.
Maintenance, reuse, and handover become more difficult when behavior lives in workflow-local, ephemeral code.
That said, I can absolutely imagine this kind of dynamic code generation as a stopgap in the future—e.g. to bridge temporary gaps in node coverage or unblock very specific use cases. But I would not see it as the primary building block for workflows. For that role, predictable, well-understood nodes (and components composed of them) remain the stronger foundation.
So yes—flexibility is a real and acknowledged benefit. The challenge (and opportunity) is introducing it in ways that complement existing nodes, rather than replacing the properties—predictability, transparency, and trust—that many users rely on.
I agree, yet out there today devs extending widgets/components/extensions to a platform (repo) use:
prompts explaining an LLM how the platform works and how something can be added to it
strict CI tests to test basic failure
update CI testa for new modules being added (also performed by an LLM)
Maybe it won’t be super fast the first run, but the subsequent for the customisation of things like dialogues will be.
This is like hiding behind a UI a template repo of a knime python extension with all the prompts similarly loaded by cursor, copilot or Claude code.
This would clearly be something for new generation of users who are used to prompt to get anything done (rather than memorize a list of nodes and their settings)
While I haven’t tried this with Python yet, I did successfully develop a native node (a Xero connector) using Kilo Code. The goal was to create a simple component that returns an access token.
Although it functioned correctly, the user experience for a non-developer is not the best one. One advantage held by a competitor (the one with the pink logo) is that their workflows are entirely JSON-based. This makes it significantly easier for AI to generate workflows. Furthermore, because everything is JSON, sharing nodes with teammates is seamless. I can simply copy-paste a node into Gemini or ChatGPT to troubleshoot issues, something that is currently difficult, if not impossible, with KNIME.
To improve prompt-based workflow building, I believe KNIME should focus on making node settings more accessible to AI and improving documentation.
@angel_g I wonder if it could be an approach for Phyton based nodes. If an AI might be more familiar with this. Although I have not tried it myself and I have not explored how to actually integrated such a self developed node into knime.
