Computational design has been available to architecture for a long time and adopted by a small fraction of it. The usual explanation is cultural: architects aren’t programmers, and we like drawing.
I think the explanation was simply economic. And I think it stopped being true recently enough that most of the profession hasn’t adjusted.
What the barrier actually was
Generative design in practice meant literally writing code: scripting geometry, wiring up analysis, defining objectives, running optimisation loops, parsing results into something a designer could look at.
That put an office in an awkward position. To explore a design space you needed someone who could program. Architects who could were rare, and were usually recruited away by the people building the tools, at salaries a practice couldn’t match. Hiring a developer into a design practice meant funding a role that produced no billable drawings, which is a hard conversation to have twice.
So the capability concentrated in large practices and specialist consultancies. Everyone else did the thing that was affordable: three or four options, chosen by judgment, developed by hand.
That was a rational response to a cost structure, and it said nothing about what architects are capable of.
The cost structure is what changed. Describing a geometric relationship or an analysis loop in plain language and getting working code back removes the specific bottleneck that kept this out of ordinary practice. An architect who understands the problem (the hard, non-transferable part) can now reach a running script without spending a year learning to program first.
I want to be careful about the claim. This removes one barrier without making anyone a computational designer, any more than a calculator makes anyone a mathematician. It happens to be the barrier that was actually binding.
Why the number of iterations is the variable that matters
This is worth an office reorganising around because design quality is strongly determined by how many alternatives were genuinely evaluated, and that number has been small for reasons that had nothing to do with what was worth evaluating.
Take window sizing, which sounds trivial and isn’t.
Glazing area trades against several things at once. More glass means more daylight, which cuts lighting energy and makes the space better to be in. It also means more heat loss in winter, more solar gain in summer, more glare risk and more cost. The optimum depends on orientation, latitude, local climate, the depth of the room behind it, what’s outside the window, the thermal mass of the construction, and how the space gets used across a day.
That’s a genuine multi-objective optimisation with real physics behind it. And on most projects it gets resolved by a proportion the designer finds convincing, then checked afterwards against a compliance calculation, because doing it properly meant a specialist and a fee, and the fee wasn’t in the budget.
Done computationally, a window study is a loop. Vary the parameters, run daylight and thermal analysis, record results, look at the trade-off surface.
What comes out is the shape of the trade-off: where the sensitivity is steep and where it’s flat, and so where you can give up something cheap to buy something valuable. That’s the information a designer actually wants, and it’s almost never available.
Here’s the thing that surprises people the first time: the flat regions matter more than the optimum. If the curve is flat across a range, you’ve just been handed free choice: the whole range performs identically, so pick on the grounds the model can’t see. That’s not a machine overruling a designer. That’s a machine telling a designer where they’re allowed to be a designer.
The same applies to shading geometry, room depth, floor-to-floor height, envelope layering and unit mix. Individually each is worth a few percent. The compounding is the argument I’ve made about affordable housing.
The professional still decides
This has to be stated clearly, because the failure mode of computational design is real and I’ve seen it.
An optimiser returns what you asked for. If the objective is energy use, it’ll hand you a building that’s excellent on energy and possibly unpleasant to be in. Objective functions capture what’s measurable, and a substantial part of what makes architecture good isn’t.
So the machine ranks and the human chooses. The optimiser explores a space no person could and hands back a set of options with their trade-offs made explicit. Selecting among them (weighing the unmeasured against the measured, knowing which constraints are real and which were assumed) stays entirely professional judgment. And it becomes more valuable rather than less, because it’s now being applied to a properly explored space instead of to three options that happened to fit the programme.
The offices that do this badly will be the ones that treat the optimum as the answer. The ones that do it well will use it the way a structural engineer uses analysis: to know what’s possible and what it costs, before deciding.
The front that’s genuinely unexplored
If I had to point at one underexploited area, it’s form optimisation for compression.
Start with the observation that makes it worth attention. The structures that have survived for thousands of years are, almost without exception, compression-only. Arches, vaults, domes, masonry. The Pantheon’s dome is standing. Roman aqueducts are standing. Gothic vaults are standing, mostly without anyone doing much to them.
That’s material behaviour rather than luck. Masonry is strong in compression and weak in tension. If the line of thrust stays inside the section, no tension develops anywhere, so nothing cracks, and there’s no reinforcement to corrode. The structure sits in the state its material is naturally suited to, and there’s no degradation mechanism with a clock attached to it.
Contrast that with reinforced concrete, which gave us a century of forms masonry could never achieve, and which has a defined service life, because it works by putting steel in tension inside an alkaline medium that slowly carbonates, admits chlorides, and eventually lets the steel corrode. The corrosion product expands, the cover spalls, water gets in faster, and the process accelerates. That is the mechanism operating as designed, on a schedule.
We traded permanence for formal freedom, mostly without ever stating it as a trade.
What makes this a computational question is that compression-only form is a found geometry rather than a drawn one. Gaudí found it with hanging chain models: invert a structure in pure tension and you get one in pure compression. Frei Otto found minimal surfaces with soap films. Both were analogue computers solving an optimisation problem physically, because no other method existed.
That problem is now numerical and well-posed. Thrust network analysis and force density methods. Given a boundary and a load case, solve for a surface where the thrust line stays inside the section everywhere. Add fabrication constraints and material limits and it becomes a constrained optimisation with a real answer at the end.
The methods exist, largely in academic research. What’s been missing is offices with the capability to run them on real projects, which is exactly the barrier described above, which is exactly the barrier that moved.
The prize is buildings whose structure has no scheduled failure mechanism, in forms nobody has drawn, because until recently the search required either a physical model or a research team.
What I’d actually do
If I were setting the direction of a design office, in this order:
Pick one recurring decision and make it computational. Window sizing is the right first target: bounded, real physics behind it, immediate value, and every single project has one.
Keep the objectives explicit and written down. Half the value is being forced to state what you’re optimising for. Teams discover disagreements at this step that would otherwise have surfaced during construction, at considerably greater expense.
Build the library, not the one-off. The second project should start from the first project’s code. Without that discipline this is a hobby, and it’ll be dropped the first time a deadline gets tight.
Treat the output as evidence, not as an answer. The trade-off surface informs the decision without making it.
Try compression form on something small and real. A canopy, or a garden wall. The knowledge doesn’t transfer from reading about it, and a small built thing teaches more than a large unbuilt study.
There’s a second place this capability pays off immediately, at a much smaller scale: parametric component definitions for parts no factory will ever tool up for. Same skill and code library, with a considerably shorter feedback loop than a building.
The cost of exploring a design space moved; the value of judging it did not.
Which recurring decision in your office would you make computational first?