How Leading Architecture Firms Are Moving AI From Pilots to Everyday Practice

August 12, 2026

TL;DR

AI implementation is becoming an organizational challenge, not simply a technology decision.
Flad Architects, NBBJ, and Stantec are taking three different routes to adoption: strategy-led implementation, employee-driven experimentation, and direct integration into project practice.
Governance, communication, culture, and human oversight matter as much as the tools themselves.
The clearest value today comes from targeted use cases that augment professional teams.
Long-term success depends on turning useful experiments into repeatable firm-wide capabilities.

About This aec+tech Talk

This article draws on a recent aec+tech Talks session about how architecture firms are moving AI from experimentation into practical workflows and enterprise strategy. The discussion featured Ali Nasiri, Director of Computational Design at Flad Architects; Mona Hashemi, Design Technology Leader at NBBJ; and Brendan Mullins, Principal and Design Computing Discipline Leader at Stantec.

aec+tech Talks is an ongoing series bringing together AEC leaders and technology practitioners to examine the ideas, tools, and organizational changes shaping the industry.

Artificial intelligence is already disrupting architecture, but not always in the ways firms expected.

The conversation often focuses on the latest rendering model, chatbot, or automation platform. Inside architecture practices, however, the harder questions are less glamorous. Which use cases deserve investment? Who decides which tools are safe? How should firms protect client information? What happens when an AI system produces a convincing but incorrect answer? And how do organizations help employees adopt tools that are evolving almost weekly?

These questions framed the discussion and highlighted that there is no single roadmap for successful AI adoption. Drawing on their experiences at Flad Architects, NBBJ, and Stantec, each speaker described a distinct, ultimately complementary, approach to implementing AI at scale.

Each firm arrived at AI implementation through a different route. Together, their experiences reveal how architecture practices can move from curiosity to capability without losing sight of professional judgment, design quality, or business value.

Mona captured the urgency of the moment in a single sentence:

"Shape the disruption or it shapes you."

Architecture Firms Are Moving From Curiosity to Capability

Architecture is no stranger to technological change. CAD, BIM, computational design, visualization, and digital fabrication have all transformed practice, although the industry has often adopted them later than other sectors.

AI presents a different challenge because its capabilities are expanding faster than most firms can evaluate, approve, and deploy them. That is easier said than done, especially for firms trying to balance innovation with project delivery.

Ali explained that Flad initially considered AI part of its computational design practice. Over time, the firm recognized that it could not remain inside a single technology group. AI affects design, BIM, visualization, data, communication, project management, research, and business operations. It is better understood as a broader layer that connects tools, processes, and people.

At NBBJ, Mona described a similar evolution in responsibility. Her work began with individual experiments in large language models and image-generation tools. The conversation later shifted from what designers could test to how those experiments could become a reliable firm-wide capability.

That progression, from experimentation to capability and finally strategy, is increasingly visible across the industry. Perhaps the most important takeaway from the discussion is that AI maturity is no longer defined by the number of tools a firm tests. Increasingly, it is defined by how successfully those tools become part of everyday practice.

*The evolution from CAD and BIM to computational design and AI shows how architectural practice has progressively absorbed new digital capabilities.*

There is No Single Starting Point for AI Adoption

One of the most useful insights from the panel was that successful adoption does not always begin in the same place.

Flad: Strategy First

At Flad, implementation begins with a roadmap. The firm considers its philosophy toward AI, policies, business goals, budget, resource allocation, readiness, and the potential long-term value of each use case.

Before committing to a project, the team uses a go-or-no-go evaluation process. If the opportunity moves forward, the firm determines whether to build the solution internally or use an existing product, followed by piloting, communication, deployment, and training.

Ali distilled Flad's philosophy into a simple principle:

"AI implementation should begin with a strategy, not tools."

This protects the firm from selecting technology first and searching for a problem afterward.

NBBJ: Experimentation and Communication First

NBBJ followed a more bottom-up path.

Employees and leaders began testing emerging tools before the firm had a complete AI strategy. Designers, project architects, project managers, and other staff brought their experiences and requests into open conversations. Weekly sessions allowed employees to share what they were trying, where they were seeing value, and what problems they wanted AI to address.

Those discussions gradually informed the firm's strategy.

This approach illustrates an important distinction: experimentation does not have to wait for a perfect roadmap. It can help create one, provided the firm establishes communication between practitioners, technology teams, and leadership.

Stantec: Practice First

At Stantec, Brendan emphasized embedding technologists directly within project delivery.

His design computing team consists largely of licensed, design-oriented professionals who remain active on projects. The goal is to avoid a model in which a technology specialist arrives briefly, performs an impressive demonstration, and disappears.

Instead, technology leaders need to understand project pressures, communicate with principals and project managers, and solve problems that matter to practitioners now.

For large organizations, this practice-led approach also helps prioritize investment. With new AI products appearing constantly, firms cannot adopt every platform or pursue every promise.

Strategy Still Determines What Can Scale

Although the firms began differently, all three eventually encountered the need for strategic structure.

Architecture firms must decide:

Which workflows are worth improving?
What outcome would make an AI initiative successful?
Who owns implementation and support?
Should the solution be built internally or purchased?
What information will the system access?
How will employees be trained?
How will the firm measure value?

Without these decisions, experimentation can remain fragmented. Employees may create separate subscriptions, upload information into unapproved platforms, duplicate each other's work, or lose trust after disappointing results.

Strategy does not need to eliminate exploration. It should turn useful exploration into repeatable capability. In many ways, this is where architecture firms are beginning to separate experimentation from long-term transformation.

AI Adoption Is a Change-Management Problem

The technical setup may not be the hardest part.

Mona identified culture as one of the main factors determining whether AI adoption succeeds:

"One of the hardest parts of AI adoption is not the technology itself. It's actually the people."

Employees may be curious, skeptical, excited, or concerned about what AI means for their roles. Senior leaders may test a tool once, receive a poor answer, and conclude that the technology is useless. Others may expect one prompt to transform an entire workflow.

Both reactions create problems. In reality, most firms are somewhere in between, curious about AI but still figuring out how to use it responsibly.

Firms need realistic communication about what AI can do now, what it may do later, and where professional expertise remains indispensable. Internal champions, training sessions, shared examples, and open discussion can help employees understand AI as a developing capability rather than an instant replacement for established practice.

Brendan also stressed the importance of communication skills within technology teams. Specialists must be able to explain why a principal, project manager, or designer should care, not merely demonstrate what the technology can produce.

Governance and Trust Must Grow With Capability

As AI becomes integrated into project work, governance becomes inseparable from adoption.

The panel raised concerns around client confidentiality, intellectual property, data ownership, enterprise security, accuracy, hallucinations, code interpretation, generated scripts, human review, and QA/QC.

Brendan shared an example involving Copilot. The system successfully found and cited relevant code sections, yet interpreted them in a way that conflicted with both his team and their code consultant.

That distinction matters. Retrieving the correct source does not guarantee a professionally sound conclusion.

Ali framed the issue through the difference between deterministic and non-deterministic tools. A deterministic calculation produces the same output from the same input. Many traditional formulas, schedules, and computational definitions behave this way. Generative AI systems may produce different answers when given the same prompt repeatedly.

That variability does not make them unusable, but it changes how they must be reviewed.

AI outputs affecting safety, compliance, contracts, technical performance, or design intent require oversight from qualified professionals. Confidence, fluency, and polished language should never be mistaken for correctness.

Where Architecture Firms Are Seeing Real Value Today

The strongest current use cases discussed by the panel were not attempts to automate entire architectural practices. They focused on targeted areas where AI can support existing teams.

At NBBJ, examples included visual storytelling, material exploration, data analysis, interactive dashboards, research, zoning and standards discovery, meeting summaries, and project-specific knowledge assistants.

The firm also developed an internal marketing chatbot that helps teams retrieve information from previous projects when preparing pursuits and presentations.

At Flad, AI sits alongside simulation, automation, generative design, optimization, space planning, adjacency analysis, performance analysis, and computational workflows.

*NBBJ demonstrated how AI is already supporting visual storytelling, research, analytics, dashboards, and intelligent assistants across architectural workflows.*

At Stantec, Brendan described AI-assisted space planning, real-time solar and environmental analysis, drawing interpretation, rendering, code research, and faster development of custom tools through prompt-assisted programming.

The common thread is augmentation. AI helps teams retrieve knowledge faster, test more options, reduce repetitive work, and build specialized tools with less development effort.

Prompt-Generated Tools Are Changing Who Can Build

One of the most memorable examples came from Stantec's experiments with vibe coding.

Designers with limited traditional programming experience were beginning to produce space-planning tools through prompts. Tasks that once required long Grasshopper definitions or carefully constructed scripts could appear much faster.

Brendan described the sensation conversationally:

"Things are just starting to poof into existence on our desks."

It was one of the lighter moments in the discussion. The comment drew smiles from the other speakers because it captured something many AI users have experienced recently: watching useful tools appear almost instantly from a simple prompt, while still wondering how much of the underlying logic they truly understand.

That speed is powerful, but it introduces a new tension.

Experienced computational designers are accustomed to understanding what every node or line of code does. AI-generated scripts may compress that logic behind a curtain. A tool can become more accessible while simultaneously becoming less transparent.

The result is not a reason to avoid AI-assisted development. It is a reason to strengthen testing, documentation, review, and accountability.

The ability to generate a tool is not the same as proving that it works reliably.

*AI-assisted coding is enabling architects and computational designers to build specialized tools, analysis interfaces, and visual workflows more quickly*

Faster Delivery Does Not Simply Mean Lower Fees

AI is also changing client expectations.

Brendan noted that some owners are already asking why projects are not dramatically faster or less expensive now that AI tools are available.

The assumption is understandable but incomplete.

If a team can generate a visualization or design option faster, the client may request more alternatives. Faster analysis can lead to more iterations. Better access to information can raise expectations for evidence and responsiveness. Time saved in one task may be reinvested in exploration, coordination, or decision-making.

Mona argued that firms need to communicate this distinction:

"It's not just about time saving. I think it's about bringing value."

AI's contribution should not be measured only by how many hours it removes. It can also improve the quality, breadth, and speed of decisions.

Architecture firms will need to explain that value clearly before the market defines AI only as a reason to reduce fees.

From Individual Productivity to Enterprise Augmentation

Mona described the next stage as moving from individual employees using AI to work faster toward an enterprise-augmented firm.

In that model, AI does not rely solely on public tools. It begins to work with the organization's own project knowledge, processes, data, and ways of working.

This could include:

Project-specific knowledge assistants
Search across contracts and meeting records
Access to past project intelligence
Internal research systems
Firm-approved visualization platforms
Customized workflow tools

The greatest obstacle may not be the model itself. It may be the condition of the firm's information.

Architecture practices often hold valuable project data in disconnected files and systems. Once a project ends, much of that knowledge becomes difficult to retrieve or reuse. Building enterprise AI therefore requires improvements in data structure, access, governance, and operational responsibility.

Few architecture firms are currently equipped to train and maintain their own foundational AI models. The more realistic near-term path is to use secure enterprise platforms, retrieval systems, and targeted customization around the firm's information.

Build Trust Before Chasing the Moonshot

The panel did not present a single formula for AI adoption, and that may be its most useful conclusion.

Flad demonstrated the value of a strategy-led roadmap. NBBJ showed how experimentation and employee communication can shape strategy from the bottom up. Stantec emphasized solving real project problems and earning trust through practical results.

All three approaches eventually meet at the same place.

Firms need governance, leadership, communication, training, human oversight, and a clear connection between technology and professional practice.

The firms moving most effectively are not necessarily those subscribing to the greatest number of tools. They are the ones building systems that help employees experiment safely, learn collectively, and turn isolated successes into repeatable workflows.

As Ali concluded:

"AI adoption is not a technology problem. More than anything, it's an organizational transformation problem."

The opportunity is significant, but architecture firms do not need to solve the entire future of AI today. They need to identify what their practitioners can use responsibly now, and build the trust, infrastructure, and organizational capacity to grow from there.

Learn more about the firms in this discussion

To learn more about NBBJ, visit their page on aec+tech or explore their work on the official NBBJ website.

To learn more about Stantec, visit their page on aec+tech or explore their work on the official Stantec website.

To learn more about Flad Architects, visit the official Flad Architects website.

Want to join the next conversation? See what's coming up on the aec+tech Events page.

Niknaz Aftahi is the founder of AEC+Tech. This article was produced from an aec+tech Talks session featuring Flad Architects, NBBJ, and Stantec, and independently edited for the AEC+Tech community.