Claude for Grasshopper & Python

For a generation of architects and interior designers, computational tools sat behind a wall of syntax. You could see what Grasshopper or a Python script might do - a facade that adapts to sun angle, a script that renumbers three hundred rooms - but the cost of entry was learning to write in a language that punishes a missing colon. Claude changes the economics of that entirely. You supply the intent; it supplies the syntax. The part you were good at all along - knowing what you want the geometry or the data to do - is now the only part you strictly need.

That is genuinely liberating, and it is genuinely dangerous, for the same reason. When the friction of writing code drops to zero, the temptation is to accept whatever runs. But "it ran without an error" and "it did the right thing" are two completely different claims. A script that produces a beautiful, plausible, wrong result is worse than no script, because it looks finished. This is why the discipline reverses: less time typing, far more time reading and checking.

Think of the loop the way you would with any assistant. You direct - describe the task, the inputs you have, the output you want, and the units. Claude drafts - a few lines of Python or a GhPython snippet. You read it - not to admire it, but to follow the logic. You run it on a copy or a small sample where a mistake costs nothing. You verify - count the points by hand, check one row against a calculator - and only then use it on real work. Three of those five steps are yours. Notice how little of it is typing and how much of it is judgement - which is the whole point. The figure below is the whole lesson in one picture: Claude writes it, but you still own whether it is correct.

It helps to name why this matters so much for a designer specifically. In most professions a wrong line of code produces a crash or a garbled screen, and someone notices. In ours it can produce a beautiful, credible-looking result - a panel layout, a set of areas, a schedule of quantities - that goes forward into a drawing, a tender, or a client presentation before anyone questions it. The plausibility that makes Claude so useful is the same quality that makes an unchecked result dangerous, and only your trained eye closes that gap.

A little vocabulary makes the rest of the lesson easy, and you can hold all of it in plain terms. Rhino is a 3D modelling program well liked for free-form and complex geometry. Grasshopper is its visual programming environment: rather than typing, you wire together boxes called components on a canvas, each doing one small operation, and data flows along the wires. It lets a designer build parametric logic - change a number, watch the model update - without writing a line. GhPython is one of those boxes: a component that runs a short piece of Python you place inside it, for the moments when wiring components together gets clumsy and a few lines of code are simply clearer. rhino3dm is a separate, small library that lets Python read and write Rhino's .3dm files outside Rhino altogether - useful for batch jobs like auditing a folder of models.

You do not need to master any of these. You describe the geometry or the operation, and Claude writes the GhPython or Python. Ask for a grid of points and you get back something you can actually read:

# GhPython: build a grid of points, nx by ny, spaced sx and sy
# inputs (set on the GH component): nx, ny (int), sx, sy (float)
# output: pts
import Rhino.Geometry as rg

pts = []
for i in range(nx):
    for j in range(ny):
        pts.append(rg.Point3d(i * sx, j * sy, 0))

Even with no coding background you can follow that: two loops walk across rows and columns, and each step adds a point at a position worked out from the spacing. When you paste this into a GhPython component and set nx to 5 and ny to 8, you should get exactly forty points. That expectation - forty, not thirty-nine, not two thousand - is your first verification, and it is the habit that keeps you safe. Always ask Claude to name the inputs and outputs and to add a one-line comment per block; readable code is checkable code, and you are the checker.

Reading code is a far gentler skill than writing it, and it is the one that matters here. You are not looking for elegance; you are looking for whether the logic matches what you asked for. Four habits get you most of the way. First, make Claude annotate: ask it to add a plain-English comment to every line or block, and to explain, above the code, what the script assumes. Second, find the inputs and the output: what does it take in, what does it hand back, and in what units? Third, read the transformations in the middle: what happens to the data between input and output - is anything multiplied, filtered, rounded, or reordered? Fourth, hunt for the assumptions that could be wrong: a hard-coded number, an assumed unit (millimetres vs metres), an assumed order of items.

Here is a rhino3dm example that reads a Rhino file and counts objects per layer - a genuinely useful audit before you inherit someone else's model:

# rhino3dm: open a .3dm file and count objects on each layer
import rhino3dm

model = rhino3dm.File3dm.Read("site-model.3dm")
counts = {}
for obj in model.Objects:
    layer = model.Layers[obj.Attributes.LayerIndex].Name
    counts[layer] = counts.get(layer, 0) + 1

for name, n in sorted(counts.items()):
    print(name, n)

Read it as a sentence: open this file; for every object, find which layer it sits on; keep a tally per layer; then print the tallies. The assumptions worth questioning are visible - it expects the file to exist at that exact name, and it counts every object including ones you might consider junk. None of that is hidden. If a number looks wrong when you run it - say a layer you know is full reports zero - that is the script telling you an assumption did not hold, and you go back to Claude with the specifics. The read-run-verify sequence in the figure is the whole professional method compressed into four rows.

The single rule that separates a safe designer-coder from a reckless one is this: run new code where a mistake is cheap. For geometry that means a fresh Rhino file or a duplicated Grasshopper definition, not the live model you have spent a week on. For a rhino3dm batch job that touches files, it means pointing it at a copied folder first, never the original. Code that reads and reports is low risk; code that writes, moves, deletes or overwrites is where an unchecked script can quietly ruin an afternoon, or a week. Match your caution to what the code can destroy.

Verification is not vague suspicion; it is a concrete check you can name before you run. For the point grid, the check is a count: five by eight must be forty. For the layer audit, pick one layer you know well and confirm the tally matches what you see in Rhino. For anything that computes numbers, take one case and reproduce it on a calculator by hand. If Claude wrote a script to convert areas to a cost, feed it one room whose cost you already know, and see if the answer matches to the rupee. When the sample checks out, your confidence in the whole is earned rather than assumed.

Finally, close the loop like a professional keeps a drawing. When a script works, save it with a short note - what it does, what inputs it expects, the date, and the one result you verified against. A folder of small, trusted, commented scripts becomes a quiet superpower over a year; a pile of anonymous snippets you no longer understand becomes a liability. Claude will happily regenerate any of them, but it cannot remember which one you tested and trusted. That memory, that judgement, and that accountability stay with you - which is exactly as it should be, because it is your name on the work the code produces.