AI in Architecture: A Practical Field Guide for Practice Leaders

AI, AEC, pyRevit, practice
5 October 2026

AI in Architecture: A Practical Field Guide for Practice Leaders

According to a series of studies, AI is now part of our workflows - as architects, structural, mechanical engineers. We seem to be reaping the benefits, but there are still some considerations to be made. This guide is our view on what's worth adopting, what could be taken with a grain of salt, and what you might potentially want to build yourselves.

Where the industry stands, here is what we know

We have gathered the information from a number of studies on the use of AI in practice as of today. The surveys align on one thing: most firms now use AI, but few have changed how they design or document buildings.

  • UK: 74% of practices use AI on most projects, up from 59% a year earlier. 57% report a positive return, but only 17% say their designs are better (RIBA AI Report 2026).
  • US: 75% of AEC firms use AI, about 20 points more than last year. Only 29% have high confidence in the data their AI tools run on (Unanet AEC Inspire 2026).
  • Visualisation: 60% of about 800 architects have tried AI, mostly for images. 70% say the output needs supervision (Chaos & Architizer, 2026).
  • Early adopters: 68% saved at least $50,000, yet only 27% of the 1,000+ firms surveyed used AI in mid-2025 (Bluebeam AEC Technology Outlook 2026).

We should treat the above numbers with some caution as the originators have a vested interest in pushing AI to the front - most of these surveys come from companies that sell AI, or at least have incorporated an AI layer and are now marketing around it. What we can attest is the drive toward AI adoption.

Previously we (Deyan Nenov) wrote about the hidden costs and how to think about AI in The Cost of AI. This current post is its practical companion: a field guide that could support decision makers in choosing where a practice spends its time and money.

Where AI pays off today

Some of this information was already covered, and as before, our test is simple and common sense - use AI when it is a magnitude faster and you can definitively stay on top of the results. The examples below are some handy ways of thinking about this.

Scripting and automation

Tools: general AI assistants (Claude, ChatGPT, Copilot).
Why it works: code either runs or it doesn't, so errors surface fast.
Guardrail: test on a copy of the model and review before sharing (see below).

Research and summarising

Tools: general AI assistants with web search.
Why it works: hours of reading can be saved on deep research.
Guardrail: open the sources; never cite a summary you have not checked personally.

Formatting and restructuring documents

Tools: general AI assistants, Autodesk Assistant in Revit.
Why it works: repetitive, low-risk, easy to proof.
Guardrail: a person signs off every issued document.

Image enhancement and presentation visuals

Tools: Veras in Enscape/V-Ray, D5, Nano Banana Pro.
Why it works: turns an existing model into a mood or atmosphere in minutes.
Guardrail: label as illustrative; never use as a submission image, or make sure your client relationship won't suffer from it.

Drawing checks and comparison

Tools: Autodesk Drawing Compliance Review and Change Analysis, Bluebeam Max.
Why it works: AI here only marks for review, but a person makes the decision.
Guardrail: treat it as a second pair of eyes, not a sign-off.

Creating a complex, holistic application build on novel or unique use case

Tools: 3rd party tools that use frontier models connected through MCP and APIs (Revit, APS, ACC), wrapped in robust, tested software.
Why it works: AI makes new workflows possible that no off-the-shelf product covers, joining steps and tools that never talked to each other.
Guardrail: this is software engineering, not a script. Architecture, testing, security, support and long-term running costs all apply, so it's not something we'd recommend building in-house. Bring in a specialist partner.

We can see that this is consistent with the vector of the general market currently - check, compare, potentially alter and augment, but not as far as drawing creation is concerned. And the explanation is simple - this is where AI shines and is reliable.

Where AI costs more than it saves

The below would be examples of use cases that, while looking good on paper, simply carry too much associated risk.

  • Design authorship. AI is built on the collection of existing corpus of human creativity, existing being the key word here. Only 17% of UK practices say AI made their designs better.
  • Images that must be "just right". Image models still invent details and lose consistency between views. Architizer's review of Nano Banana Pro is clear: the model is fine for ideas, but not for planning submissions.
  • Full drawing sets from a prompt. And tools that promise this exist. This is also a prime example of AI replacing a segment where traditional automation already paves the safest possible way (shout out to our own TinyTools).
  • Compliance as a yes/no. Here, liability is the main thing to watch for. If you feel comfortable apologizing to Australia for hacking their Medicare, then this may still be worth your while.
  • Client and project data in consumer tools. 42% of firms cite data security as their main barrier (Bluebeam). This is also where your existing NDAs and the general GDPR guidelines can come back to haunt you.
  • Correspondence that carries your name. Emails and letters are where relationships live, and believe it or not, we humans are better pattern recognition machines than any AI, by and large.
  • Open-ended usage billing. Credits and metered agents make costs hard to predict - this is particularly important. This is a relatively new billing paradigm and one that we don't have intuition for. Surprise costs have been reported on numerous occasions, so this is the one to keep a very close eye on.

Build in-house: small scripts, managed properly

The biggest win we see is AI-written code. An architect who knows the problem can now describe it to an AI assistant and get a working Revit automation in a flash. Renaming sheets in a particular fashion, checking specific parameters, exporting schedules "just the way I want it", placing tags (ok, this one is a bit tough): these are all tasks that can be difficult to generalize and might not come from a vendor. The democratization we see in other sectors is in full swing for the AEC as well!

For the most part, the issues around custom script building revolve around maintenance, usability and scalability. We know that 3rd party solutions (Orchestra) exist which allow centralized repository for Dynamo, and hopefully we will see this supported natively one day (it has been a roadmap item for a while), so version control and central sharing is something that Dynamo can work with.

pyRevit also solves most of this. It is free, open source, and runs Python (and now C#!) inside Revit. Each script becomes a button on a shared ribbon tab, and the whole toolset can live in one Git repository. That gives you version history, review and one-click updates for the team.

How we suggest setting it up:

  1. One shared extension. Create a practice pyRevit extension in a Git repository. You can follow our YouTube guide which remains valid to this day.
  2. Read before write. Start with tools that report (audits, counts, exports). Add tools that change the model once the team trusts the process.
  3. One transaction, one undo. Wrap every change in a single named transaction so users can undo it in one step.
  4. A second pair of eyes. Someone other than the author reviews each script before it reaches the ribbon. AI can help with the review too.
  5. An owner per tool. Each button has a named owner, a one-line description and a tested Revit version.
  6. Test on a copy. Never run a new tool on a live central model first.

(We have recently had the pleasure of working with Pascall + Watson to help with consolidation of their outstanding pyRevit toolbar which is a material for another blog post in the near future, stay tuned!).

Buy, don't build, when the job needs heavy compute, cloud services, or regular updates against new Revit releases. Rendering, document intelligence and clash detection belong here. The same goes for complex applications built around a novel use case (see above): this is where someone like us earns their keep.

Watch this space: Autodesk now ships an official Revit MCP server (tech preview, Revit 2027). It lets AI assistants such as Claude query a live model, and now also offers a "Trusted-Write" mode (Revit 2027.2 and later) where you review every change the AI makes. Start with read-only queries, then move to write once your team trusts the process.

Leverage tools under your subscription: It is another way of saying "make your dollar work harder". There are a lot of amazing features that already ship with Revit, or are part of your AEC Collection - Forma is seeing a massive amount of attention and is a (set of) tool you should explore if you haven't already.

Fix your data before you scale

AI is only as good as the model and documents it reads. Only 29% of firms have high confidence in that data (Unanet), and 52% still use paper during design (Bluebeam).

Before investing in a dedicated AI product, check the basics. Are your Revit templates consistent? Are parameters named the same way across projects? How good is your drawing register, your TIDP? A Dynamo or pyRevit audit script can help you find these answers, and what you find there will probably give you a better idea than any sales pitch.

A 90-day starting plan

  1. Weeks 1 - 2: Rally the troops. Gather your volunteers. Nominate your generals. Above all, finding the right people to champion this process in-house is the key to success.
  2. Weeks 3 - 6: Pick two tasks. Choose two repetitive, soul-crushing tasks that are staple to your design and documentation process. Give automation a go, and measure the hours before and after.
  3. Weeks 3 - 8: Set up a folder of Dynamo scripts, or the shared pyRevit extension. Move existing scripts into it and give each one an owner.
  4. Weeks 6 - 10: Audit your data. Run read-only checks on templates and parameters across live projects.
  5. Weeks 10 - 12: Review. Collect your keepers, drop the rest and set a budget for usage-based tools (understanding Claude/OpenAI business tiers is the name of the game).

And, if it wasn't already obvious - invest in the people, too. 61% of UK practices worry AI will make it harder for junior staff to learn the job (RIBA). Pair juniors with the tools and with a senior who checks the output; that is how both get better.

A short glossary of AI terms

  • Frontier model - the biggest, most capable general-purpose AI models of the day (Claude, GPT, Gemini and co). Expensive to build, expensive to run, and what most AI features are calling under the hood.
  • Token - the unit AI models read and write in, roughly three-quarters of a word. You pay per token, in and out. Not to be confused with Autodesk Flex tokens, which are a billing currency.
  • Context (window) - how much a model can "hold in its head" at once, measured in tokens. Bigger context, bigger bill.
  • Inference - running a model to get an answer. This is the compute you pay for every time you hit enter.
  • Agent - an AI that doesn't just answer but acts: calls tools, edits files, loops until the job is done. Burns far more tokens than a chat, but can replace hours of manual, multi-step work.
  • MCP (Model Context Protocol) - an open standard that lets AI models plug into software like Revit. The protocol is free; the servers built on it may or may not be.
  • API - the door software uses to talk to other software. Increasingly, the door has a turnstile.
  • Usage-based (consumption) pricing - paying for what you use instead of per seat. Fair in theory, hard to budget in practice.
  • Credits / Flex tokens - vendor currencies you prepay to cover usage. Mind the expiry date: Autodesk Flex tokens expire 12 months after purchase.
  • AI wrapper - a product that puts a chat box over existing functionality or over someone else's model.
  • Vibe coding - building software by describing what you want to an AI and iterating, rather than writing every line yourself.
  • Hallucination - when the model confidently makes something up.

Sources