Parametric design and its wall of entry
Parametric design promises something simple: to generate an architectural system from the description alone of the mathematical laws that govern it. In practice, it has so far remained the preserve of those who could build complex scripts — which assumes real depth in mathematics and visual programming. Between the architectural intent and the whole structure of components that produces it lies a long, tedious apprenticeship, and it is what makes the tool a non-starter for most.
Having watched a great many architects experiment with Claude lately, I wanted to test the tool myself — and above all to look for concrete use cases: saving time, and iterating more easily across several design options. Two systems guided my first steps, a brick mashrabiya and a bamboo screen. Both exceeded my expectations, but not for the reasons I had imagined.
The reversal: you don’t ask it to draw, you ask it to write the rule
This is the one idea to take away from this post, and it took a few days to formulate.
The whole method follows from a three-layer distinction that parametric design already draws on its own. The intent is mine, exclusively: the parti, the effect sought, the topology. The rule falls to the agent: the code that turns that intent into geometric law. The instance is produced by Grasshopper: the geometry itself, regenerable at will.
Every time I asked Claude to produce geometry directly, the output was rather disappointing. Every time I asked it to write the law that produces the geometry, it was excellent. Claude is not yet a seasoned modeller, but it is an outstanding writer of mathematical and geometric rules.
That reversal brings a second one, more technical but just as structuring: the code does not live inside the Grasshopper file. A `.gh` file is a binary — unreadable, and impossible to version usefully. The code lives on disk, in Python files referenced externally by a single script component. Grasshopper goes back to what it does best: an interface, letting the user play with the script’s inputs and showing the result in the Rhino viewport. The Python scripts are what carry all the geometry.
As for the MCP bridge, it serves two very precise purposes and no more: reading the canvas and its errors, and capturing the viewport. MCP is an organ of perception, not of writing. That is probably the main difference between a demo and a production workflow.
First case: the brick mashrabiya
For the first test I picked ground where I could judge without indulgence: reproducing the result of a script I had built by hand a few months earlier. A network of perforated bricks whose opening widens as you move away from one or several attractor points. A dynamic, irregular wall whose drawing emerges from the gradual play between modules.
I took the time to set up the working infrastructure before writing a single prompt: project tree, permanent rules, and above all an interface contract — the frozen list of the component’s inputs and outputs, with their types, units, ranges and access modes. The document looks bureaucratic; it settles upfront the leading cause of silent failure in parametric work, data trees. A definition that returns nothing is almost always an item/list/tree access problem.
I also wrote the acceptance criteria, quantified and script-verifiable: maximum gap between modules, each brick bearing on two bricks of the course below, resolve time. Without them, an agent improves indefinitely. With them, every iteration ends in a clear verdict.
Once that frame was set, the results came quickly: within a few dozen minutes the workflow was operational and the geometry met my expectations. The time invested in setting up paid for itself within the first hour — the original script had taken me several hours to produce.
Second case: the bamboo screen, drawn then described
The second test asked a different question. No longer “can the agent translate a written rule?”, but “can it read an annotated sketch and draw clear geometric intent from it?”
So I replayed the experiment on a screen of orthogonal bamboo with linear spacing, starting from an annotated drawing rather than from text. The result, once again, was striking.
The split that works: text specifies, image qualifies, geometry constrains. Roughly 80 % text at the specification stage — and the ratio flips at validation, where the machine’s eye is far better at critique than at generation. You generate, capture the viewport, set the capture beside the reference, ask for the gap analysis, then correct the Python scripts accordingly.
The script library, or why the second project starts higher
This is the point that separates a demonstration from a method.
From one parametric project to the next, the same geometric operations return: attractor fields, falloff curves, remapping, surface tessellation, bonding patterns, fabrication checks, schedules. Without a library, the agent reinvents these primitives on every project.
By capitalising on the sub-scripts the mashrabiya had yielded, the screen did not start from zero: it composed from a base already proven. The gain compounds, and the setup reinforces itself. It is that library, not the ephemeral prompts, that holds the real value of the apparatus.
A second accelerator, less visible: pure computation functions can be tested outside Rhino. Written separately from the geometric layer, they are verified in plain Python, in a second, without opening the software. Logical debugging no longer needs a single round trip. Over a full session, the time saved can be considerable.
What to take away
You don’t ask an agent to draw, you ask it to write the rule that draws. The code lives on disk, never inside the Grasshopper file, which goes back to being an interface. The MCP bridge perceives — canvas, errors, viewport — it does not write. The interface contract and the quantified acceptance criteria are written before the first prompt: it is the most profitable half-hour of the project. A dimensioned sketch beats a photorealistic render. And the library of primitives, which grows with every project, is the only asset that does not erode.