Flickr user Andreas Wecker via Creative Commons License

In many service-based industries, workers have found themselves supplanted by algorithms. Accountants have given way to personal finance software, travel agents have been displaced by websites, and taxi drivers are poised to face off with self-driving cars. In a recent interview with NPR, Andrew McAfee, co-director of the Initiative on the Digital Economy at MIT, predicted, “Twenty or 40 years from now, we will not need the labor of a lot of the people alive in order to have a very, very productive economy.”
So if a computer can do our taxes, drive our cars, and book our holidays, could it also design our buildings?

Mies van der Rohe's Seagram Building was the subject of a Boolean formulation in a 1972 paper from the University of Cambridge.
Flickr user Miguel Angel Labarca via Creative Commons License Mies van der Rohe's Seagram Building was the subject of a Boolean formulation in a 1972 paper from the University of Cambridge.
This question isn’t new. In the 1960s, as computers were first applied to the field of architecture, a number of researchers began devising ways to automate building design. Their work focused on optimizing floor plans to reduce walking times—a legitimate concern for a time when people had to hand-deliver documents. Books such as The Automated Architect by Nigel Cross (Methuen, 1977) detailed how computers were perfectly suited for performing the tedious calculations to quantify travel time between rooms. Perhaps, researchers postulated, computers could eventually optimize floor plans based on other factors.
This research would largely prove to be a failure. Although computers could optimize floor plans based on walking distances, it turns out—to no architect’s surprise—that walking distance has little effect on the success of most buildings. Despite the researchers’ faith in quantitative building science, quantifying aspects of architecture, such as constructability, was nearly as impossible as accounting for qualitative characteristics, such as context, aesthetics, and spatial experience.
Eventually the issue of walkability was largely solved not through architecture, but through the invention of email and cellular technology. But the idea of automating architecture lives on. The rise of big data and cloud-based computing has renewed the notion that computers can tackle the complex task of design.
Autodesk and Google are two of several technology companies pursuing the potential of automated design. During the keynote presentation at Autodesk University last year, ​Autodesk chief technology officer Jeff Kowalski said his company is “developing a CAD system that learns the same way we do, by referencing mechanical engineering textbooks, and building codes, and part catalogs, and even by observing real-world examples.” In his nine years as CTO, he said, “This is the biggest, most fundamental change that I’ve ever seen coming our way.” 
Fully aware that he was speaking to a room full of architects, Kowalski added that his company’s system would only be designing “starting points”—a companion to designers, rather than a competitor … for now, at least. (Autodesk hasn’t publicly released any tools that Kowalski discussed, but Project Dreamcapture appears to be one hint.)
In 2011, Google began a similarly ambitious project. Housed in the secretive Google X laboratory, which has incubated Google Glass and Google’s self-driving car, Project Genie set out to reduce construction costs by 30 to 50 percent, and shorten construction schedules by 30 to 60 percent. Within a year, the project was spun off into a company and rebranded as Flux. To date, Flux has publicly revealed two tools: a website where developers can pick a plot of land and see all of the zoning laws governing that land (the current test site is Austin, Texas); and a modeling interface where parametric buildings are automatically adapted to site constraints. By connecting the dots, one can imagine a tool by which a developer could have Flux automatically design a building for any site.

Flux screenshot
Daniel Davis Flux screenshot

Again, should architects worry? Not in the short term.
Even with the Great Recession, the number of people employed as architects has increased 25 percent in the past 15 years.​ (This doesn’t mean that computers haven’t affected the job market. Architectural drafters, for instance, have seen no job growth in the same timeframe, presumably due to technology or outsourcing.)

At the start of the millennium, the U.S. had 20,000 more architectural drafters than architects. Since then, this number has slowly decreased, indicating the elimination of these jobs from the economy, possibly by technology or outsourcing.
U.S. Bureau of Labor Statistics / Case Inc. At the start of the millennium, the U.S. had 20,000 more architectural drafters than architects. Since then, this number has slowly decreased, indicating the elimination of these jobs from the economy, possibly by technology or outsourcing.

As history has demonstrated, the profession of architecture is difficult to automate. University of Oxford researchers Carl Frey and Michael Osborne have estimated that architects are one of the least likely professions to be automated in the next 20 years. They give architects a 1.8-percent chance of being automated, compared to a 93.5-percent chance for accountants, and an 89.4-percent chance for taxi drivers. Architects, they say, must be able to negotiate and innovate—two skills that computers struggle with. While the products from Autodesk and Flux have promise, they take a narrow view of architecture that fails to address these more complicated, more human skills.
In many ways, the inability to automate architecture hones in on the divide between people and machines. Yes, computers can quantify walkability and glean zoning regulations in Austin. But it is—for now—impossible to get computers to think creatively, manage multidisciplinary teams, and do many of the other day-to-day tasks. Architects themselves are vital despite the fact that computers are assuming many of their menial and repetitive tasks. What remains is the core competency of the architect, which is defined not in terms of what an architect is, but in terms of what a computer can’t do.
Note: This article has been updated since first publication.