Why is current generative design software so underwhelming? This is the question I posed to a speaker several years ago at a Design Futures Council seminar in Sydney. It was somewhat of a provocation (who me?), but it came from a deep scepticism about the so-called future of design. Startups across the globe were claiming they were using Artificial Intelligence (AI) to design buildings, and they had the .ai domain to prove it. But from what I could gather – artificial or not – there wasn’t much intelligence about the design output. Change was undoubtedly coming. But would AI’s big bang enter us into a world of post-Cambrian architectural diversity or become a Weapon of Mass Architectural Destruction?
The great tech delusion
The year was 2019, and vertically integrated companies like Katerra and WeWork were being hailed as unicorns and the future of the AEC industry. Startups were solving the housing crisis by developing generative design software to ‘optimise’ designs. And Autodesk was relentlessly marketing how generative design was the future – merely define your design goals, press run, generate thousands of options, and simply pick the best one. Our digital future certainly looked promising, but the road there would be anything but smooth.
Fast forward a few years, and Katerra and WeWork spectacularly imploded into supernova stardust. Architects rejected en masse generative design solutions that were as under-baked as a Nicholas Cage film. And Autodesk discovered that the challenge with generative design has nothing to do with the software infrastructure and everything to do with the core algorithms generating the design. The great tech delusion had begun.
The startup canvas
While many looked to Autodesk, Katerra and WeWork to ascertain where the industry was headed, a proliferation of newly established startups emerged with their own take on the matter. Some are focused on free and open-source software. Some are creating a web-based BIM modeller. Some are focused on creating an enhanced 2D user experience. Others see a future where designs are authored in virtual reality. Some are interested in developing the infrastructure for others to create their own tools. Some are focused on Modern Methods of Construction. And someone, somewhere, is in stealth mode, boiling the ocean and working on all of the above simultaneously.
Generative Design
But arguably, it is Generative Design that has best captured the industry’s attention. There is undoubtedly delight in pushing and pulling a shape and seeing the building’s layout flex in real-time, a digital plasticine where the user can play without needing to resolve the so-called ‘boring’, ‘mundane’ and ‘time-consuming’ details. (Note, I use the term generative design here to define any software that generates a design parametrically, such as ‘configurators’, as opposed to the strict definition, which includes some form of analysis and a feedback loop.) But generative design’s Achilles heel is twofold.
Firstly, for users wanting to create their own logic, the term generative design software is a misnomer as it provides the infrastructure for comparing and evaluating solutions, not the actual code to generate the design. In other words, to generate something, you must code it first. Autodesk’s promise of generating a thousand design options via a single click was a fallacy. There was no magic generative design button.
Secondly, for users wanting an out-of-the-box solution, the software vendor’s algorithm was a black box. It does what it does and nothing else. Put simply, you get what you get, and you don’t get upset. And herein lies the challenge for the AEC industry to move forward. If architectural logic needs to be codified – either by ourselves or via a software vendor – what should be codified?
Biases in algorithmic decision making
Most software development starts with a laudable goal, often to advance some aspect of our lives. Facebook, for example, aimed to connect people to one another. Twitter was merely a platform for sharing short messages. And Snapchat enabled private, person-to-person photo sharing. But as we now know, there can be unintended consequences. Readers will be familiar with the Cambridge Analytica scandal, where they illicitly harvested personal data from Facebook accounts to influence election voter behaviour. Twitter is awash with hate speech, misinformation and trolls. And Snapchat’s filters and visual effects have spawned a new body dysmorphia disorder, known as Snapchat dysmorphia, whereby people seek out cosmetic procedures to replicate the altered images they present online. So what does all of this have to do with architecture?
An algorithm is merely an opinion formalised in code.
Cathy O’Neil
Despite the term algorithm implying some irrefutable logic, an algorithm is merely an opinion formalised in code.1 It can, therefore, be prone to errors and biases, just like a fallible human. The mathematician, data scientist and author Cathy O’Neil highlights these potential dangers in her book, ‘Weapons of math destruction: How big data increases inequality and threatens democracy’. After years of developing algorithms for software companies, she saw how many mathematical models encoded human prejudice, misunderstanding, and bias into opaque software systems. She terms these harmful kinds of models Weapons of Math Destruction.
Weapons of Math Destruction
Weapons of Math Destruction typically originate as a means to optimise some process. However, as O’Neil’s research shows, these models are frequently overly simple, sacrificing accuracy and insight for efficiency.2 Poisonous assumptions are camouflaged by math and go largely untested and unquestioned. This becomes hugely problematic, especially when run at scale, as designed to do, as they become standardised, unaccountable, and a stand-in for the truth.3
Readers may be familiar with the documentary, Coded Bias, which highlighted racial biases in facial recognition technology. Some may argue that the algorithm simply didn’t have sufficient data points to train the model accurately. And this is true. But the problem was that the underdeveloped algorithms were being used at scale by governments and law enforcement agencies to conduct mass surveillance. What was possibly just a software bug to begin with became systematised bias and discrimination when applied at scale. In other words, its shortcomings were amplified to such an extent that the technology had the potential to do more harm than good.
Design oversimplification
The parallels with generative design are substantial. Architectural design is complex. Every decision has a knock-on effect and competing requirements that must be negotiated. Despite this complexity, there have been few attempts to codify this complex, interwoven decision matrix. Instead, the design problem is oversimplified. At best, the software optimises a single design goal in isolation. For example, it may create cookie-cutter floorplates to optimise the Gross Floor Area or the number of apartments but without considering any other design drivers. At worst, the software solves a problem that no one ever has needed to solve – like optimising solar radiation by twisting a tower or creating a parametric pizza to show generative design’s potential.
Unintended consequences
In the early days of new software, no one cares too much about unintended consequences; The technology is novel and represents progression to conventional methods. In fact, raising concerns or voicing criticism is frequently interpreted as ignorance or general resistance to design technology. If you are not with us, you must be against us! There is, of course, a fine line between technological myopia, the tendency to underestimate the potential of tomorrow’s applications by evaluating them in terms of today’s enabling technologies, and critically evaluating the effectiveness of today’s technology. But generative design’s over-simplification of the design process and black box nature, if run at scale, can potentially become a Weapon of Mass Architectural Destruction.
Weapons of Mass Architectural Destruction
To illustrate this phenomenon, how often have you heard a student in a design crit claiming their design has been optimised by XYZ software without further explanation? It may or may not be accompanied by a look of, “the computer produced it, so stop bugging me with all these questions”. More accurately, the student is saying that they downloaded a plug-in or script, ran it to optimise a single design criterion, and accepted the novel result. Yet they cannot verify if the result is accurate or explain how it was produced. In their mind, the mere act of using software to create the design is justification enough.
Now imagine this thought process applied at scale on real projects. But this time, instead of generating novel design optimisations like twisting a tower to reduce solar radiation, it is replaced by unknown design drivers buried deep in the black box algorithm. Whatever biases and limitations inherent in the algorithm are now applied systematically to all projects. Depending on the bias, this could be for the betterment of the industry or its destruction. But how would you know which it is?
Creating transparency
Eric Raymond, the open-source software advocate, stated that “given enough eyeballs, all bugs are shallow”.4 What Raymond is advocating, of course, is transparency – the disclosing of information to ensure accuracy. This may sound excessive, but consider a recent study of genetic papers published in leading scientific journals found that 20% of them have errors attributed to Microsoft Excel formatting settings.5 It was only through the culture of transparency common in the scientific industry that those errors were discovered. And this, of course, is the argument used by open-source software advocates in architecture. How can we rely upon software such as Autodesk Revit when its inner workings and development roadmap are so opaque? If Revit makes errors with simple area calculations, how can we trust it with more advanced automation routines?
Given enough eyeballs, all bugs are shallow.
Eric Raymond
Algorithmic regulations
In some industries, such as automated credit score calculation, algorithmic regulations are already emerging to uphold ethics. Should the same apply to architectural algorithms? It is not as farfetched as one would think. In Geographical Information Systems (GIS), datasets frequently come with a data quality statement so that the user understands where the data came from, its accuracy, coherence, interpretability and accessibility. And in Building Information Modelling (BIM), we have concepts such as Level of Development (LOD) and Level of Information Needed (LOIN) to describe the accuracy of the model. So why not a similar concept for architectural algorithms?
Whether we needed a formalised system or not is open for debate. But in any case, the software must make explicit any assumptions and oversights. Much like an expert knowing the boundary of their expertise, knowing what your algorithm can’t tell you is just as important as knowing what it can.6
Limits of expertise
Like many others, my LinkedIn feed has been awash over the past few months with enthusiasts testing the latest AI advancements such as ChatGPT, Midjourney and the like. This has been an exciting time for AI as the public finally has tangible proof of what AI has promised for decades. But interestingly, it has also raised concerns about the data used to train the models. For example, users of ChatGPT discovered that it had limited knowledge of world events post-2021. And AI-generated imagery is shrouded in concerns about copyright infringement.
But much like Spotify’s disruption of the music industry, these are teething issues that will be eventually resolved as we come to terms with the new technology. But more profoundly, these teething issues shine a very bright light on the need for transparency, especially for professionals. In highly regulated industries such as architecture, engineering or further afield, financial services, it is imperative that the user understands what the software is outputting. Unlike the aforementioned student, whose defence is based on “the computer did it, so it must be correct”, the professional has no such defence. We cannot abdicate our professional responsibility, at least not yet.
Modernism and the culture of efficiency
Algorithms, we must remember, are “constructed not just from data but from the choices we make about which data to pay attention to – and which to leave out.”7 As we’ve seen, more often than not, the focus becomes metrics that can be easily quantified and optimised. The prioritisation of efficiency over other drivers translates all too easily into architecture, where optimisation has become a synonym for maximising profits – “the contractor value engineered the design to improve the building’s value for money”, or “the Net Saleable Area was optimised by reducing unnecessary circulation.” How did architecture reach this point where efficiency trumps good design as the key metric of success?
Algorithms are constructed not just from data, but from the choices we make about which data to pay attention to – and which to leave out.
Cathy O’Neil
Efficiency as a design driver is a concept that emerged out of Modernism, the dominant architectural style post World War II. It emphasised functionalism, purified architectural form, clean structure, and a lack of ornamentation. Phrases such as “form follows function” (Louis Sullivan, 1896), “a house is a machine for living in” (Le Corbusier, 1923 ), and “less is more” (Mies van der Rohe, 1947) echoed around the world. Despite being around a century old, our approach to efficiency as a design driver has mostly stayed the same. Read through the comments section of any online architectural magazine, and you’ll see countless examples of pundits denouncing anything remotely ‘inefficient’ as ethically corrupt.
Beyond efficiency
Efficiency clearly has a part to play in architecture, but it cannot, and must not, be the sole driver. The fast food chain McDonald’s is economical, highly efficient and hugely successful. But as Morgan Spurlock discovered in his Super Size Me documentary, we also know it’s not good for us. Bigger doesn’t mean better. Faster doesn’t mean better. Only better means better. How, then, do we define better?
Frank Gehry famously claimed that “98 per cent of what gets built and designed today is pure shit.” If true, what represents the two per cent of good architecture? Sometimes the search for efficiency is camouflaged by some social agenda like “solving the housing crisis”. But anyone who has lived in or visited a London housing estate will attest when efficiency is housing’s sole architectural driver, the results are profoundly depressing and can have significant social consequences that last generations.
Clearly, there is more to architecture than optimising efficiency. So why, then, the proliferation of generative design algorithms where efficiency is the primary and sole metric? Because it is easily quantifiable, and someone, somewhere, can claim that they made the building more efficient. But at what cost? When we reflect on architectural experiences that bought us delight, we tend to speak of uplifting spaces, unexpected moments of interest, or a sense of community. We don’t talk about the wall-to-window ratio of our budget motel.
Starting point or anchor?
To return to the beginning of the article, when I posed the question, “why are generative design solutions so underwhelming?” the speaker responded that the solutions generated should be seen as a starting point for the design process – an underlay with which to trace over, modify, and create a better design solution. And intuitively, this makes sense. There is just one problem with this, one that is well understood in sales and marketing but not necessarily in architecture.
Years ago, I was talking to a friend who worked at Zaha Hadid Architects. I was curious to understand how they negotiated space planning with organic circulation routes. He explained that if you start with a platonic solid, say a box, it becomes conceptually tough to break its shape. The box wants to stay more or less a box. Instead, if you start with floor surfaces, you can begin to bridge these surfaces together in novel ways. The spatial volume is then free to emerge without predefined geometric constraints.
What my friend was describing here, without probably knowing it, is a well-known cognitive bias called anchoring. Anchoring is the tendency to rely too heavily on, or anchor to, a past reference or one piece of information when making a decision. In his explanation, the box was acting as an architectural anchor. It was the starting point upon which all other decision was based – and it severely constrained the solution space. Much like the Tesla’s logo uncanny similarity with an intrauterine device (IUD), certain things, once seen, become really hard to unsee. Generative design software has the potential to become a Weapon of Mass Architectural Destruction if they anchor an architect to a suboptimal design solution. And this stagnation is a genuine concern if the algorithm focuses solely on efficiency.
Towards new metrics of success
Computers are useless. They only give you answers.
Pablo Picasso8
Any promising new invention will have its naysayers; the bigger the promises, the louder the nays. In late 1994, Time magazine explained why the internet would never go mainstream claiming the internet “was not designed for doing commerce.”9 How wrong they were. The intention of this article is not to criticise previous attempts which have paved the way forward but rather a call to arms for the industry as a whole to aim higher.
Jeff Hammerbacher, a Former Facebook engineer, famously quipped that the “best minds of my generation are thinking about how to make people click ads.”10 This distinct lack of priorities and squandering of talent can also be witnessed in the AEC industry. Instead of tackling wicked problems to drive the industry forward, some of the industry’s greatest minds are focused on solving low-hanging problems like batch-placing views of sheets.
The hard truth is that efficiency alone will not solve our problems. What we need are better solutions. Better will mean different things to different people, but unequivocally, what it means is that we need new metrics of success. We must move beyond architectural anchors and reframe generative design as a tool to propel us into a world of post-Cambrian architectural diversity. To achieve this, we need better algorithms to tackle the astronomically huge combinatorial relationship between multiple competing design variables. The aim is not to post-rationalise outdated design methods but to evolve our thinking and understanding to achieve innovative solutions.
Conclusion
Technology is humanity’s accelerant, but we must decide where to accelerate. Do we want to create Weapons of Mass Architectural Destruction or tools to bring us into a world of post-Cambrian architectural diversity? If it is the latter, we must move beyond efficiency as the primary driver to where transparency and ethics become centre stage.
References
1 O’Neil, C. (2016). Weapons of math destruction: How big data increases inequality and threatens democracy. Penguin Books, London, p.53.
2 O’Neil, C. (2016). Weapons of math destruction: How big data increases inequality and threatens democracy. Penguin Books, London, p.21.
3 O’Neil, C. (2016). Weapons of math destruction: How big data increases inequality and threatens democracy. Penguin Books, London, p.7.
4 Raymond, E. (1999). The Cathedral and the Bazaar: Musings on Linux and open source by an accidental revolutionary. O’Reilly Media.
5 Ingraham, C. (26 Aug 2016). An alarming number of scientific papers contain Excel errors. The Washington Post.
6 Luca, M. et al (2019). Algorithms need managers, too. In Harvard Business Review 10 must reads on AI, analytics, and the new machine age. Harvard Business Review Press, Boston, pp.29-38.
7 O’Neil, C. (2016). Weapons of math destruction: How big data increases inequality and threatens democracy. Penguin Books, London, p.218.
8 William, F. (1964). Pablo Picasso: A composite interview. The Paris Review. Issue 32, Summer-Fall 1964.
9 Elmer-Dewitt, P. (25 July 1994). Battle for the soul of the internet. In Time magazine.
10 Vance, A. (15 Apr 2011). This tech bubble is different. Bloomberg Business.
