Parametric design meets ML
Rules-based parametrics give you control and certainty; ML gives you discovery and surprise. The skill is knowing, for each problem, which one to reach for.
One designer wrote a rule. The other trained a model. Both built a facade — and they should never have swapped methods.
Two facade studies, same week. The first designer needs every louvre angled exactly to the sun path so the formula is provable to a client and a code official — she writes a parametric rule in Grasshopper: angle equals a function of orientation, and it's right by construction, every time. The second is exploring a strange, organic shading screen with no clean formula — she lets a generative/ML method propose forms she'd never have drawn. Both got a facade. The lesson is that if they had swapped tools, both would have struggled: rules where you needed discovery, a black box where you needed certainty.
Two engines: rules you write vs patterns the machine learned
Parametric is a rule you author; ML is a pattern it absorbed
Parametric design — the Grasshopper/computational tradition — is rules you write. You define relationships and parameters ('column spacing = span / 6', 'each unit faces the courtyard'), and the model computes the result deterministically. Change a parameter, the geometry updates, and you can always explain why it looks like that, because you wrote the logic.
ML / generative methods are patterns the machine learned from examples. Instead of you stating the rule, the model has absorbed what 'good' tends to look like and proposes outputs — sometimes ones you couldn't have specified. It can surprise you. It can also not explain itself, and it carries the plausibility-machine caveat: it produces what's plausible, not what's provably correct.
They're not enemies. Tools increasingly blend them: Hypar generates buildings from computational rules and goals; Finch does early-stage, graph-based parametric layout optimisation with instant feedback. Some workflows wrap ML inside a parametric pipeline — the rules give structure, the learned part suggests options within it.
Ask of any 'AI design' tool: is this a rule someone wrote, or a pattern it learned? The answer tells you how much to trust it.
Reach for rules when you need certainty; reach for ML when you need discovery
Rules-based parametrics win when the relationship is known and you need control, certainty and explainability: structural grids, code-driven setbacks, sun-path louvre angles, repeating units to a formula, anything you must justify to a client, an engineer or a sanction official. The output is provable and editable. If you can write the rule, write the rule — it's deterministic and it's yours to defend.
ML/generative methods win when the relationship is fuzzy, the space is huge, or you want to be surprised: exploring organic forms, generating a wide spread of plan options, finding solutions in a space too large to enumerate, learning patterns from precedent that resist a clean formula. The cost is explainability and certainty — you must verify the output, because it's plausible, not proven.
The designer's judgement is the meta-skill: read the problem, then pick the engine. Need to defend it line by line? Parametric. Need to discover something you couldn't specify? ML. Many real projects use both — rules for the parts that must be exact, learned suggestion for the parts that benefit from search.
Treat parametric and ML as two instruments, not a hierarchy. Use rules-based parametrics for everything you must justify — structural grids, code setbacks, environmental shading logic — because deterministic output is defensible to engineers and officials. Reach for generative/ML methods at concept, where exploring a large form-space fast is worth more than provability. The competence that pays is diagnosis: looking at a problem and knowing in seconds whether it wants a rule you author or a search you supervise. Hypar and Finch sit on this seam; learn where one ends and the other begins.
You may rarely open Grasshopper, but the distinction governs your AI tools too. A staging or recolour tool is the ML side — learned patterns, surprising, needs your eye to verify. A parametric joinery or modular-shelving configurator is the rules side — change a dimension, everything updates predictably. Knowing which you're holding tells you how much to trust it: the learned tool can hallucinate a product that doesn't exist; the rule-based one will always give you a buildable, if less surprising, result.
You don't need to master Grasshopper to benefit from this — you need the mental model. When you pick a tool, ask 'rule or learned?' A rule-based parametric workflow (Finch-style layout optimisation) gives you control and repeatability with a gentler learning curve than coding from scratch; an ML/generative tool gives you reach and surprise but demands verification. Start with the rules side for anything you must explain to a client, and add the learned side where exploration pays. The judgement to choose is worth more than fluency in either.
Hypar
Computational / parametric building generation
Generates buildings from rules and goals — the parametric tradition at building scale, with optimisation; firm-priced. Deterministic and powerful where you can author the logic; the rules you write bound what it can produce.
Finch
Graph-based parametric layout optimization
Early-stage, graph-based layout optimisation with instant feedback as parameters change. Strong rules-based exploration; it optimises arrangement to your logic, not legality, so pair it with your own code checks.
Grasshopper (Rhino)
Visual parametric design environment
The reference rules-based, computational design tool — deterministic, explainable, the base many ML plug-ins extend. You author every relationship, which is its strength (control) and its cost (you must know the rule).
Stable Diffusion / generative methods
Learned, pattern-based generation
The ML side: learned patterns propose forms and images you couldn't specify. Surprising and broad, but plausible-not-proven and hard to explain; verify outputs and never treat them as deterministic.
“ML and generative AI have made parametric, rules-based design obsolete — why write rules when the machine can just learn the answer?”
They solve different problems, and rules-based parametrics are often the better choice. When a relationship is known and must be defended — a structural grid, a code setback, a sun-path louvre angle — a rule you author is deterministic, editable and explainable, which a learned model is not. ML wins where the space is fuzzy or huge and you want discovery, but it trades away certainty and explainability. The mature workflow uses both, each where it's strong; neither retires the other.
Workshop — the rule-or-learned diagnosis drill
The skill this lesson builds is fast diagnosis: given a design problem, do you reach for a rule you author or a model that searches? You'll run a real shading-screen problem through both lenses and feel exactly where each engine is the right tool.
Free: paper or a doc for the diagnosis; optional Grasshopper/Finch for the rule side and any image AI for the learned side.
Take this brief and split it into RULE jobs vs LEARNED jobs:
BRIEF: design a perforated facade screen for a west wall, hot climate
DECISIONS TO MAKE:
1. louvre/perforation angle vs sun path
2. overall structural module + fixing grid
3. the screen's aesthetic pattern / motif
4. minimum opening size for airflow (code/comfort)
5. an unexpected, organic visual language to explore
For EACH decision write: [RULE] author a parametric rule
[LEARNED] let an ML/generative method propose- 1Tag each of the five decisions [RULE] or [LEARNED]. The provable, code-driven ones (angle vs sun, structural grid, minimum opening) almost always want [RULE]; the exploratory motif wants [LEARNED].
- 2For one [RULE] decision, write the relationship in plain English as if it were a parametric definition — e.g. 'louvre angle = f(orientation, latitude)'. Notice you can explain and defend every output.
- 3For the [LEARNED] decision, prompt an image AI for the organic motif. Notice it surprises you — and that you cannot fully explain why it produced that form.
- 4Now deliberately swap them: try to get the image AI to give you a code-exact louvre angle, and try to write a parametric rule for 'surprising and beautiful'. Feel both fail.
- 5Write your diagnosis rule in one line: 'Author a rule when I must defend the output; let the model search when I want to be surprised.' That sentence is the transferable skill.
- 6List two real tasks from your current project and tag each [RULE] or [LEARNED] — the habit, applied.
You’ll walk away with
A worked split of one real problem into rules-based and learned sub-problems, plus a one-line diagnosis rule you can apply to any future 'should I use parametric or AI?' decision.
One quick test, if you have a few minutes.
- 01Take any 'AI design' tool you already use and decide: is its core a rule someone wrote, or a pattern it learned? Notice how that single answer predicts whether it'll be deterministic or surprising — and how much you must verify.
Parametric design is rules you author — deterministic, explainable, the right tool when you must defend the output. ML/generative methods are patterns the machine learned — broad and surprising, the right tool when you want discovery, at the cost of certainty. The durable skill isn't fluency in either; it's diagnosing, for each problem, which engine fits.
Parametric = rules you write (control, certainty, explainable); ML = patterns learned (discovery, surprise, verify-required). Rules win for code-driven, defensible, repeating logic; ML wins for fuzzy, huge, exploratory spaces. Hypar and Finch sit on the seam; mature workflows use both. Diagnose the problem, then pick the engine.
What is the difference between parametric design and AI/ML in architecture?
Parametric design is rules you author: you define relationships and parameters (column spacing, setbacks, louvre angles) and the model computes a deterministic, explainable result. ML and generative AI are patterns the machine learned from examples — they propose outputs you may not have specified, which is powerful for discovery but plausible-not-proven and hard to explain. Parametric gives control and certainty; ML gives reach and surprise. They are complementary, not rivals.
When should I use parametric design instead of AI?
Reach for rules-based parametric design whenever the relationship is known and the output must be defensible — structural grids, code-driven setbacks, sun-path shading angles, repeating modules, anything you'll justify to an engineer, client or sanction official. The result is deterministic and editable. Use ML/generative methods when the space is fuzzy or huge and you want discovery — exploring organic forms or generating a wide spread of options — accepting that you must verify what it gives you.
Do I need to learn Grasshopper to use AI design tools?
No. You can use ML-based tools (image generation, floor-plan generators, staging) with no parametric coding at all. But understanding the parametric mindset — that some design logic is best written as explicit rules — makes you far better at choosing tools and knowing how much to trust each one. The valuable skill is the diagnosis 'rule or learned?', not fluency in any single environment; tools like Finch even give you rules-based optimisation with a gentler curve than Grasshopper.
_With rules and learned methods in hand, we zoom out to the very front of a project — testing a raw plot's potential in hours with site, massing and feasibility AI._