Hello everyone.
I’ve been experimenting with a workflow where AI models (ChatGPT / Cursor / Claude etc.) can understand and reason about EXISTING Grasshopper definitions properly.
Not just screenshots or isolated node groups —
I mean understanding the actual procedural logic, graph architecture, dependencies, clusters, scripts, and workflow strategy of a real GH project.
Right now, when working on larger Grasshopper systems, I often want to ask AI things like:
-
“Is this whole procedural approach mathematically indirect?”
-
“Is there a cleaner/professional way to solve this?”
-
“Am I using helper geometry where I should directly work in UV space?”
-
“Can this architecture be simplified?”
-
“What are experienced computational designers doing instead?”
The problem is:
AI usually fails on these types of questions because it does not truly understand the existing GH definition.
And manually explaining a large graph every time is unrealistic.
So instead of explaining the graph manually, I started building a custom semantic exporter inside Grasshopper using IronPython.
The exporter reads the LIVE GH document directly and exports:
-
component graph topology
-
component-to-component connections
-
recursive clusters
-
Python component source code
-
lightweight semantic JSON
-
dependency structure
Current workflow:
Grasshopper (.gh)
→ custom semantic exporter
→ graph.json + separate .py script files
→ VS Code / Cursor / GPT / Claude
The important part is:
I am NOT trying to perfectly reconstruct .gh files.
The actual goal is:
making existing procedural definitions understandable enough for AI systems to reason about the procedural strategy itself.
For example:
Instead of manually writing:
“this cluster creates helper geometry, morphs it onto another surface, then uses closest-point mapping to rebuild wave curves…”
…I want AI to infer that automatically from the exported graph structure and scripts.
Because many important questions are architectural questions, not local component questions.
Examples:
-
“Is this workflow mathematically correct?”
-
“Is this unnecessarily indirect?”
-
“Would professionals solve this differently?”
-
“Is there a cleaner geometric strategy?”
-
“Am I fighting the geometry kernel instead of using the proper domain?”
The exporter currently works surprisingly well already.
It exports:
-
~170+ components
-
recursive clusters
-
graph topology
-
Python scripts
-
semantic graph structure
So now I’m curious how experienced users/developers are approaching this problem.
Questions:
-
Are professionals already doing something similar for AI-assisted Grasshopper development?
-
Is exporting a semantic graph JSON actually the correct direction here?
-
Is there a better SDK-level way to expose:
-
graph topology
-
parameter relationships
-
clusters
-
procedural dependencies
-
execution semantics
to AI/code-analysis systems?
- Has anyone built:
-
graph introspection tools
-
AST-style systems
-
semantic exporters
-
procedural graph parsers
for Grasshopper before?
-
How are advanced users handling AI-assisted debugging/review/refactoring for large existing GH definitions?
-
Is there a more “proper” architecture than custom semantic exporting for this kind of workflow?
Would love to hear how experienced computational designers or plugin developers would approach this.
ghAI integration.gh (10.9 KB)
this script write .json at this address ‘C:\GH_AI’
you can change.
