edited
As an experiment I have recently been asking Claude (the regular free version, not the professional Claude-coding version) to read and write NDBX files. The results are impressive.
Claude is very skilled at coding in Python, but knows nothing about Nodebox. However, a Nodebox file is just an XML file, and Claude can parse it and use its coding skills to understand what's going on pretty well. It can also scan the internet for documentation (which is minimal) and can learn from Nodebox files you share with it.
The first time I tried this it made a few quite understandable mistakes. I had to explain to it that Nodebox geometry is center-oriented, not corner oriented, so 0,0 is in the center of the canvas and all shapes are centered by default. It assumed that colors were a property of each shape node, so I had to tell it about the colorize node. Claude learns quickly so these basic lessons did not take long.
Normally Claude resets its weights to baseline after each conversation and does not remember past conversations. But you can ask it to take notes about what it learned about Nodebox. If you do that you don't need to re-teach it each time.
Tonight I tried a more ambitious experiment. I uploaded a demo file with a few related subnetworks from my library and asked it to analyze the nodes of interest and look for inefficiencies. It did this and immediately spotted a particular sub-subnet that I had already suspected.
It then offered me a choice between a fairly simple change that would provide a quick improvement, or a complete rewrite. I chose the latter.
Claude can write Nodebox as well as read it. After much thought it finished a complete rewrite of the core subnet and suggested we try that first before installing it in the other more complex subnets. It then output an NDBX file with the revised demo.
(I was using the Claude app on my iPad but was easily able to airdrop the file to my Mac for a test run.)
The demo loaded with a few minor issues (which I'll mention below). But the rewritten subnetwork itself was a bit of rats nest. Claude placed new nodes pretty much at random, so there were connections winding all over the place making the network hard to read. So I asked Claude to do a better job with this.
First I told it to make sure connections always flowed downhill. So if node A outputs a link to node B, node B should be placed somewhere below node A. Claude was able to re-arrange all the nodes to follow this rule and that was a big help.
Then I asked it to try to minimize the number of crossing link lines. This is a hard problem to do at scale, but after some puffing and panting, Claude did it! The resulting network was MUCH more readable. (It explained that it had been optimizing to reduce total link lengths, but would instead reduce crossings from now on.)
The few remaining errors were simple but show the kind of things Claude needs help with:
- In order to tell whether a section of a path was a line or a curve it counted the points by doing a pointCount lookup. But that lookup returns a Java datatype so you have to run it through an integer node before Nodebox can use it. This is a very obscure problem that even most human Nodebox coders might not have caught.
- It needed to use a running_total node but wasn't sure if that node started at 0 and ended with the penultimate subtotal, or started with the first value and ended with the final sum (both versions are possible and I have a node in my library that does one of them). It added extra code so that it would work either way but shared its uncertainty. I explained that the Nodebox version of this node starts with 0; Claude then removed the unnecessary failsafe code.
- When fixing those issues failed to make the subnet work correctly, it asked me if feeding a T value of 100% to the point_on_path node would correctly return the endpoint of a path. I explained that this was a Nodebox bug. It works for closed paths, but for open paths incorrectly returns the starting point (I have another node in my library to fix this issue). Armed with this insight it constructed a workaround and the demo then ran correctly - and MUCH faster!
As you can see, these are minor issues that are easily fixed and remembered. So after just a few tutoring sessions, Claude is now pretty good and both reading and writing Nodebox files.
Amazing.
But this proof of concept left me feeling a bit sad.
I enjoy coding in Nodebox. I like solving these little problems myself. Having Claude do it for me takes all the fun out of it. Even just knowing that Claude COULD help me code takes at least some of the fun out of it.
Floris has already shown that you can also use Claude or other AIs to write modules in Python to do things that are very hard to do in Nodebox. He and I have perfected several such nodes that are now in my library, but I use them sparingly. Once you start down this path you may as well just code everything in Python.
I'm not alone in feeling some existential angst about this. Some mathematicians are starting to wonder what the point of doing math is if ChatGPT can solve all the great outstanding problems. Many coders are not happy being demoted from senior developers to Claude code-checkers. And as for artists - don't even get me started.
So what have we learned here?
- Claude can read and write Nodebox even though it's a visual language.
- If you get stuck on a Nodebox project, Claude can help get you unstuck.
- Using Claude might make you sad.
Discuss.