In partnership with

Writer RAG tool: build production-ready RAG apps in minutes

• Writer RAG Tool: build production-ready RAG apps in minutes with simple API calls.

• Knowledge Graph integration for intelligent data retrieval and AI-powered interactions.

• Streamlined full-stack platform eliminates complex setups for scalable, accurate AI workflows.

Learn more about our production ready RAG tooling here.

Computation vs. AI in AEC

Hello fellow Magicians,

I recently had a conversation with a colleague about the differences between computational methods and ML/AI methods—discussing when each is best, why you might choose one over the other, and the trade-offs involved. This topic came back to mind when I was asked an important question: Is AI always the right tool to solve problems in AEC?

The answer: No! In fact, I’d go so far as to say that AI should be the solution of last resort. It’s not the default tool for every problem. AI should only be considered when other methods fail to meet the required criteria—and even then, it should only be used under specific circumstances where it truly adds value.

Computation vs. AI

Let’s start with a definition of computation specifically for the Architecture, Engineering, and Construction (AEC) industry—especially for those outside the field.

In AEC, computation refers to the use of algorithms, rule-based logic, and programmatic methods to solve problems, automate processes, and generate designs. This can include tasks like parametric modeling, structural analysis, environmental simulations, and automated drafting. It relies on clearly defined inputs, deterministic rules, and predictable outcomes. Think of it as solving problems by breaking them down into logical steps that a computer can execute with precision and consistency.

By contrast, AI involves systems that learn from data, adapt to new information, and make predictions or decisions based on patterns—often tackling problems that are less clearly defined or where explicit rules are harder to specify.

Now that we’ve defined computation in AEC, let’s dive into how it compares to AI, when to use each, and why it matters.

When to Use Computation vs. AI

Computation is ideal for tasks where rules and processes can be clearly defined and executed systematically. Let’s explore this through the example of automating construction documentation.

Imagine you’re tasked with creating construction drawing sets for a project, which typically involves producing sheets like plans, elevations, and schedules. There are clear, repetitive rules that govern how these documents are structured and formatted, such as:

• Sheet Organization: Plans go first, followed by elevations, then schedules.

• Annotations: Dimensions, tags, and callouts must follow specific standards, such as text height or line weights.

• Schedules: Door, window, or material schedules must automatically pull data from the building model, such as dimensions or material properties.

Using rule-based computation, you can automate the generation of these documents. Tools like Dynamo for Revit, Grasshopper for Rhino, or custom Python scripts can:

• Automatically place views (e.g., floor plans or elevations) onto predefined sheet templates.

• Generate schedules by extracting data directly from the model, ensuring accuracy and consistency.

• Apply consistent annotation styles and automate the placement of dimensions, tags, and notes.

Why Computation Works Here

• Rule-Based Logic: The rules for construction documentation—like sheet ordering or annotation standards—are deterministic and easy to encode.

• Efficiency: Automation significantly reduces the manual effort required for repetitive tasks, speeding up the documentation process.

• Accuracy: Rule-based systems ensure consistency across sheets and reduce human errors, such as missing annotations or misaligned views.

When Does Computation Break Down?

Computation is incredibly effective for tasks where clear, rule-based logic can be applied. But it begins to break down when subjective preferences or highly context-dependent decisions enter the picture. Let’s explore this with an example:

Imagine a scenario where architects have different preferences regarding where to place certain annotations, like dimensions:

Initially, it may be reasonable to create a rule like all dimensions should be placed 1 inch outside of each wall on a floor plan. However this likely leads to over-dimensioning and different architects may have their own or less consistent rules they apply themselves to what should be dimensioned and when.

The challenge doesn’t stop there. These preferences can shift based on context, such as the shape or complexity of the floor plan, the drawing scale, or the project’s type. For example - you might have very different rules for what and where to dimension on an apartment floorplan with 5 rooms vs. a hospital floor with 30 or 40 rooms.

The Problem with Hard-Coding Rules

As these preferences become more nuanced and context-dependent, writing explicit rules to encompass every scenario quickly becomes a herculean task. The issues are:

1. Exponential Complexity: The number of possible outcomes grows rapidly as you add more rules to account for varying preferences and contexts.

2. Ambiguity: Preferences are not hard-and-fast rules—they’re often subjective and may vary even within the same team or project.

3. Adaptability: Static, rule-based systems struggle to adapt to new or unforeseen scenarios, such as unique building geometries or evolving team preferences.

An Architectural Problem

Complexity and ambiguity are deeply ingrained in the nature of architecture. Unlike fields where processes are strictly linear or deterministic, architecture thrives in a space where problems often have no single "correct" solution. Instead, architects must navigate competing priorities, subjective preferences, and ever-changing project contexts to arrive at solutions that balance function, form, and feasibility.

Complexity

Architectural design often involves managing a vast number of interdependent variables, including spatial relationships, structural considerations, environmental factors, and aesthetic goals. Each decision impacts the others, creating a web of complexity that must be carefully balanced. For example:

• The placement of structural columns affects both spatial layouts and aesthetic decisions.

• Environmental considerations like daylighting or thermal performance can influence façade design and material choices.

Ambiguity

Ambiguity arises from the fact that architectural problems are rarely well-defined. Stakeholders often have conflicting priorities, and the design identity is frequently driven by preference rather than strictly measurable factors. This makes decision-making more subjective and less deterministic. Consider these examples:

• Client Priorities: One stakeholder might prioritize maximizing leasable floor area, while another values open, collaborative spaces. Resolving these competing goals requires interpretation and negotiation, rather than a formulaic approach.

• Subjective Aesthetics: A client might request a design that feels “innovative” or “welcoming.” These are abstract concepts that vary widely in interpretation, depending on cultural, personal, or contextual factors.

• Unquantifiable Factors: Architectural elements like the “feel” of a space or its alignment with the surrounding environment are difficult to measure or encode in computational terms, leaving them open to interpretation.

Since architectural problems often lack clear-cut rules, we need systems that can work with uncertainty—this is where AI comes in.

AI

These architectural realities boil down to a core truth about the practice: architectural design is often driven by gut feeling, not by simply checking a required box. This gut feeling is the human body’s remarkable way of processing and reasoning over highly complex and interconnected ideas. When a design is "right," we may not all be able to articulate why—but we know it when we see it.

Handling these “I know it when I see it” problems is precisely the kind of challenge that AI systems are well-suited to address. When the rules are unclear, subjective, or even disputed, AI can learn from patterns in historical data or preferences to identify what might feel “right” without needing explicit instructions.

By analyzing vast datasets of past projects, user feedback, or contextual factors, AI can support architects by offering suggestions or uncovering possibilities that align with the subtleties of human judgment. It doesn’t replace the gut feeling—but it enhances it, helping navigate the complexities and ambiguities that are inherent in architectural design.

Striking a Balance

Computational methods and AI each have their place in AEC, but they serve different roles. Computation is an essential tool for solving well-defined, rule-based problems—where outcomes are predictable and processes can be automated with precision. AI, on the other hand, thrives in situations where ambiguity, complexity, and subjective judgment come into play—problems that don’t have a single correct answer but instead require pattern recognition and adaptability.

AI is not a universal solution, and it should not be the default tool for every problem in AEC. Instead, it should be a last resort, used only when deterministic, rule-based methods fall short. Even then, AI works best in collaboration with computation, leveraging automation where possible while bringing adaptability where necessary.

The key takeaway? AI doesn’t replace computation—it augments it. By combining the power of computation for efficiency with AI’s ability to handle nuance and ambiguity, we can create smarter, more flexible systems that allow architects, engineers, and designers to focus on what they do best: crafting thoughtful, well-balanced solutions to complex challenges.

Thanks for reading Not Magic, Just Math! If this topic resonated with you, consider subscribing for more deep dives into the evolving role of AI in AEC. 🚀