AI could change the economics of architectural practice before it changes architecture itself
A few days ago, I wrote a LinkedIn post about the AI tools I would be testing if I were still practising architecture today.
The starting point was deliberately practical. I spent nearly ten years in architecture producing drawings, building models, checking schedules, coordinating enormous amounts of information and creating endless design options. A frightening amount of that work can now be done differently and, in some cases, much faster.
So I started thinking about what I would actually be testing if I went back into practice tomorrow.
BIM automation that can perform repetitive documentation tasks rather than simply tell me how to do them. AI working alongside Rhino, Grasshopper and SketchUp to make computational workflows more accessible. Feasibility tools that can test options earlier. Visualisation that uses actual geometry from a model rather than inventing a beautiful but largely useless image. Assistants that can interrogate specifications and project information. Tools that can help navigate building regulations. AI sitting inside spreadsheets and schedules, finding inconsistencies that somebody would previously have spent hours checking manually.
I wasn't particularly interested in whether AI could design a building for me. I was interested in something much less spectacular and potentially much more important to the way an architecture practice actually operates: what are we paying highly trained people to spend their time doing, and how much of that time is genuinely necessary to produce the work?
The post travelled much further than I expected. Within a couple of days it had reached almost 12,000 individual people and generated more than 15,000 impressions, with 91% of those impressions coming from outside my existing network. More than half of the audience LinkedIn could identify was working in architecture and planning. Fifty-nine people saved the post, which interested me almost more than the reach because it suggested people weren't simply reacting to the argument. They were keeping it because some of the practical information was useful.
But, as has happened with a few things I've written recently, the discussion underneath the post became considerably more interesting than the post itself.
People began talking about what they were already doing inside practices, which parts of their work they wanted technology to remove, where they didn't trust it, what it might mean for fees and staffing, and whether making production dramatically faster could eventually change what an architect's time is actually worth.
I started with a list of tools and came away thinking much more about the economics of architectural practice.
The interesting AI work happening in architecture isn't necessarily the spectacular stuff
A lot of the public conversation around AI and architecture has naturally focused on images. That makes sense. Images are visible, immediate and easy to demonstrate. You can put a prompt into a tool and thirty seconds later have something that would once have required hours of modelling and visualisation. But I increasingly suspect that some of the more consequential uses of AI inside architectural practices will be considerably more ordinary.
Mark Percival, an architect and director who joined the discussion, described using ChatGPT alongside Vectorworks and InDesign for reports, planning guidance, improving specifications, emails, turning planners' requests into clear actions and producing rendered images from models the practice had already created.
Another architect, Seth S., described using Gemini for renderings and early concepts, but one of the applications he found particularly useful was analysing the percentage of different materials across elevations, something required by some cities and an extremely tedious thing to calculate manually.
Adedamola Ajibade said his biggest gains had come through documentation and administration rather than the more glamorous AI imagery. That feels much closer to where I would be looking if I were running a practice.
There is nothing particularly revolutionary about an architect spending less time reformatting a report, searching through documents, checking a spreadsheet or repeating a modelling operation. Multiply relatively small savings across hundreds of tasks, several people and an entire year, though, and the commercial question becomes much more interesting.
RIBA's 2026 AI research suggests adoption is already moving beyond experimentation. Its survey found that 74% of practices were using AI in at least some projects, up from 59% in 2025. It also identified applications across early-stage visualisation, regulatory compliance, practice and project management and technical design, with almost three-quarters of AI users reporting productivity improvements.
That doesn't tell us how much time is being saved across the profession, whether the improvements are sustained or how they translate into financial performance. It does, however, suggest that AI is already becoming part of ordinary practice operations rather than something confined to a few experimental studios.
The useful question is therefore moving beyond whether architects will adopt AI. Many already have. What interests me is what happens to the architecture business as the technology becomes more capable and the people using it become more experienced.
Saving time and creating value are not necessarily the same thing
Imagine something that currently takes an architect eight hours can eventually be completed properly in two. Six hours have been recovered, which sounds like an obvious productivity gain. From the perspective of the business, however, the benefit depends on what happens afterwards.
The architect might spend those hours on another project, allowing the practice to take on more work without increasing headcount. The team might use the additional time to improve the design, coordinate more thoroughly or spend longer understanding what the client needs. The practice might improve its margin, shorten the programme or simply allow somebody to finish at a reasonable hour rather than working late.
There is also the possibility that the client eventually expects the same service to be delivered faster or at a lower fee, particularly once competing practices have access to similar capabilities. In that situation, the hours have still been saved, but the financial benefit may not remain with the practice.
This distinction matters in architecture because the relationship between workload, fees, costs and profitability has been difficult for a long time. RIBA's 2025 Business Benchmarking work recorded an improvement in profitability after years of stagnation, while also describing continued pressure on fees and rising costs. Its research into future-ready practice management is particularly relevant here. Between 2015 and 2024, inflation-adjusted revenue per staff member increased by less than 10% in practices with one to nine staff, despite the technological and operational changes that occurred during that period.
AI therefore arrives in a profession where productivity is already closely connected to the challenge of running a financially sustainable practice. For studio founders, that makes it important to distinguish between introducing technology, improving the efficiency of a particular task and improving the performance of the business as a whole.
Knowing that a practice has introduced six AI tools tells us very little about whether it is better off. Even demonstrating that a particular task can now be completed 70% faster only answers part of the question. I would be much more interested in what happened to the time that was saved and whether the practice was able to use it in a way that made a meaningful difference.
For a five-person studio, recovering twenty hours of production time every week could represent a substantial increase in available capacity. Whether that translates into better margins, more work, better client relationships, improved design quality or simply twenty hours of additional expectation is an entirely different matter.
What if AI makes an architecture practice more productive without making it more profitable?
There is an appealing assumption in much of the AI conversation that productivity automatically creates commercial value. Sometimes it clearly does. If a practice can deliver the same amount of work with fewer resources while maintaining its fee and quality, the immediate economics are relatively straightforward.
Architecture, however, doesn't operate in isolation. If one studio can produce something much faster, eventually another studio probably can too. Clients become aware of what technology can do, expectations change, programmes become shorter and competitors begin pricing their services differently. An advantage that initially belongs to an early adopter can gradually become the level of performance the market expects from everybody.
We have seen versions of this before. CAD made drawing production considerably faster than producing everything by hand. BIM created new possibilities for coordination, information management and responding to changes across a project. Email made communication almost instantaneous compared with letters and faxes. All of these technologies changed the amount of work practices could produce and coordinate, but they didn't collectively create a profession with enormous amounts of spare time.
As our ability to produce and manage information increased, the amount of information expected from us also grew.
AI may follow a similar pattern, although I don't think we know enough yet to say exactly how it will unfold. The technology is developing quickly, adoption remains uneven and different parts of architectural work have very different levels of complexity and risk.
RIBA's 2026 research suggests that practices using AI are already experiencing productivity improvements and positive returns, which is important evidence that the benefits aren't purely theoretical. At the same time, 59% of practices surveyed believed AI adoption would lead to staff reductions across architecture. That is a measure of expectations rather than a forecast of what will actually happen, but it illustrates how closely the profession is connecting productivity with future staffing decisions.
For a small studio, the opportunities could be considerable. A team of five capable of delivering work that previously required seven people might be able to compete for larger commissions, improve its financial resilience or remain deliberately small without limiting its ambitions. The lower cost of producing certain kinds of work could also make it easier for new practices to establish themselves.
But those same capabilities may become available to the practices competing against them. If clients and competitors eventually price the increased productivity into their expectations, some of the initial advantage could disappear.
I think this is one of the most important commercial questions facing studio founders as AI develops. It is worth understanding not only how much time technology can save, but who ultimately benefits from that saving and how long the advantage is likely to last.
Are we pricing the drawing or the decision?
One comment underneath my post pushed the discussion considerably further.
Alejandro Martin Barreiro, who works across architecture and digital strategy, wrote:
"The firms that struggle won't be the ones slow to adopt a tool, they'll be the ones still pricing the drawing instead of the decision."
I kept coming back to that sentence because it gets to something much bigger than productivity.
I don't think it should be taken literally. Architects have never simply sold drawings. A drawing contains design thinking, technical knowledge, coordination and professional responsibility, and architectural fees can be structured as percentages, lump sums or time charges depending on the project. RIBA's own fee guidance and calculator still connect fees closely to scope, resources, staff costs, billable time, overheads and the margin a practice needs to make.
But Alejandro's distinction becomes particularly interesting when the amount of production required to reach a decision begins to fall.
If I can generate twenty design options in the time it previously took to produce three, those twenty options aren't necessarily twenty times more valuable. Somebody still has to understand which options are appropriate, what the client is trying to achieve, what can realistically be built and which compromises are worth making.
If an AI assistant can retrieve every relevant clause from hundreds of pages of project information in seconds, the time required to find that information becomes less significant. Understanding which clause applies, whether it is current, how it relates to the particular project and what action should follow remains important.
The same principle applies to computational design. If AI can write a Grasshopper script that previously required specialist knowledge and several hours of work, that changes the production process. It doesn't necessarily tell the architect what problem is worth solving, whether the parameters make sense or whether the resulting geometry is appropriate.
There is a progression here from producing information, to understanding it, interpreting it, exercising judgement and accepting responsibility for the decisions that follow.
Technology appears increasingly capable of accelerating parts of the production and information stages. The further we move towards interpretation, judgement and responsibility, the more difficult the relationship becomes. That doesn't mean those activities are immune from AI or that the technology won't become increasingly useful in supporting them. It means the professional role cannot be assessed solely by the speed at which information is generated.
For architecture practices, this raises a question that extends well beyond software. If the time required to produce certain outputs falls substantially, how should a practice explain and defend the value of the expertise, decisions and responsibility behind those outputs?
That is a conversation about positioning, fees, client relationships and the business model of architecture itself.
A confident answer isn't necessarily a useful answer
Ankit Singhai, a director at Detail Design Group, made another comment that gets very close to the practical boundary between useful automation and professional judgement.
Talking about AI interrogating project information, he said:
"If the assistant can return the exact specification clause and revision, the reviewer can decide what applies."
He went on to explain that a confident answer without the source trail is considerably harder to use on a live project. I think that distinction is enormously important because it describes the difference between receiving information and being able to rely on it.
I would absolutely want an AI assistant capable of searching hundreds of pages of specifications, consultant information, schedules and project correspondence and bringing back the relevant material in seconds. But I would also want to know where that information came from, which revision it belonged to, whether it remained current and what context might affect its interpretation.
Only then could I make a properly informed decision about what to do with it.
The value of the technology in that situation is that it removes much of the time previously spent finding and organising information. It doesn't remove the need to understand the project or the responsibility attached to acting on that information.
Adedamola Ajibade made a similar point about building regulations. AI can help locate relevant information more quickly, but the professional still needs to establish what applies and whether the proposed solution is compliant.
This distinction becomes particularly important in a profession where errors can have consequences far beyond the time required to correct a drawing. An incorrect assumption can move through a project, affect other consultants, create problems during construction or lead to decisions that are expensive to reverse.
There are also questions around confidentiality, intellectual property, data handling and professional liability. RIBA has already warned practices that the risks associated with AI extend beyond copyright and need to be considered as part of how these systems are introduced and governed.
None of this is an argument against using AI. It is an argument for understanding the difference between a system that makes information easier to access and a system whose output can safely inform a professional decision.
The more confidently these tools communicate, the more important it becomes that somebody understands how to verify what they are being told.
The same shift is beginning to appear beyond architecture
One of the comments I found particularly useful came from IslaBids, a business working in preconstruction rather than architectural practice.
They described software that reads subcontractor quotations and lays out inclusions, exclusions, alternatives and line items side by side. Instead of an estimator spending a weekend manually rekeying information from thirty PDFs before they can begin comparing bids, the system handles much of the initial extraction and organisation.
Their observation was that once the comparison work has been completed, the estimator can concentrate on deciding which information matters and which suppliers to trust.
That resonated with me because it describes a very similar change to the one architects are beginning to experience.
Comparing thirty quotations is not simply an administrative exercise. The purpose of the comparison is to understand the differences, identify omissions, question assumptions and eventually make a commercial decision. Much of the work required to prepare that information is repetitive, but the decision that follows depends on experience, context and an understanding of the project.
If technology can remove several hours of preparing a comparison, the estimator has more time to examine what the comparison actually means. They may be able to investigate a suspiciously low price, challenge an exclusion or spend more time understanding which supplier is likely to deliver what the project requires.
There are similar possibilities across architecture, engineering and construction. Professional workflows frequently involve large amounts of information gathering, formatting, checking and comparison before somebody reaches the part where their experience becomes most useful.
What interests me is that AI could change the balance of time spent across those activities. Instead of trained people spending most of their time preparing information and a relatively small amount interpreting it, there may be an opportunity to reverse that relationship.
Whether practices actually use the opportunity in that way will depend on how they organise the work.
What should an architecture practice actually automate?
When I originally published the list of tools, I was thinking about specific applications that could make an architect's working day more efficient. The discussion made me question how useful a permanent list of software will be when the technology itself is changing so quickly.
Steven Mohesky, a studio director working in visualisation, challenged the idea that individual plugins would remain particularly important. His view was that increasingly capable general AI systems would be able to create scripts and functions on demand, potentially reducing the need for many of the specialist plugins architects currently rely on.
I think that is a credible possibility, although it remains a prediction rather than something we can assume will happen across every application.
Some of the tools I mentioned may look very different in two years. Others may disappear, be acquired or become part of larger platforms. Capabilities that currently require specialist software could eventually become normal functions inside Revit, Vectorworks, Rhino or the wider software environments practices already use.
That makes me more interested in understanding the underlying work than in building a strategy around particular products.
For a founder-led practice, I would begin by looking at where trained people spend their time and identifying activities that are repetitive, time-consuming and relatively straightforward to verify. Document searches, formatting, scheduling, extracting information, checking consistency and repeating established modelling operations would all be sensible areas to investigate.
But the suitability of a task for automation depends on more than whether the technology can perform it. The reliability of the output matters, as does the consequence of an error and the amount of supervision required to catch one. A tool that completes a task in five minutes but requires an hour of checking may provide very little benefit. A system that occasionally produces convincing but incorrect information could create additional risk even when its average performance looks impressive.
Seth S. raised a related commercial point in the discussion when he questioned the cumulative cost of subscribing to several AI platforms. That is easy to overlook when individual subscriptions appear relatively inexpensive. Across a practice, the licences, implementation time, training and ongoing checking all become part of the cost of adoption.
I would therefore want to measure the complete workflow rather than the speed of the AI-generated output alone. That includes preparing the information, prompting or configuring the tool, reviewing its work, correcting errors and incorporating the result into the project.
There is also a further consideration that is particularly important in architecture and which I think deserves much more attention: whether performing a task is part of how somebody develops the knowledge they will need later in their career.
That makes the productivity argument considerably more complicated.
We may be automating the work that taught us how to judge
This connects directly to something I wrote about recently in my earlier article on AI and the traditional apprenticeship of becoming an architect.
During my years in practice, I spent an enormous amount of time doing work that would now probably be described as repetitive production. Drawings, schedules, revisions, models, coordination, checking consultant information and making changes that sometimes seemed to lead back to where we had started.
There was plenty of that work I would happily never do again. Some of it was unnecessarily laborious, and I can think of countless occasions when better technology would have saved time and frustration.
But those years were also teaching me architecture in ways I didn't necessarily recognise at the time.
You gradually begin noticing when dimensions don't make sense. You understand why a junction has been detailed in a particular way and what might happen if somebody changes it. You see how one consultant's decision affects several other packages and how apparently minor changes can move through an entire building.
You also learn through mistakes, repetition and conversations with people who have more experience than you. Over time, you develop the ability to recognise that something isn't right, sometimes before you can immediately explain why.
That judgement doesn't arrive fully formed when somebody qualifies. Much of it develops through exposure to real projects and the repeated process of producing, checking, questioning and correcting information.
This creates a genuine tension for architecture practices adopting AI.
On one hand, there is a strong commercial argument for removing repetitive production work wherever it can be done more efficiently and reliably. On the other, some of that same work has historically provided the experience through which younger architects develop the judgement that practices will continue to depend upon.
RIBA's 2026 AI research suggests the profession is already concerned about this. Sixty-one per cent of practices surveyed agreed that AI would make it more difficult for early-career professionals to acquire essential skills and experience.
I don't think the answer is to preserve inefficient work indefinitely simply because previous generations had to do it. I certainly wouldn't make somebody spend half a day manually completing something a reliable system could do in ten minutes just because I once spent half a day doing it myself.
But removing that work creates a responsibility to think about how the learning happens instead.
If a junior architect no longer spends hours searching through drawings and specifications, perhaps the learning needs to happen through understanding why the information retrieved is relevant, what might be missing and how it affects the design. If AI generates the options, the architect still needs opportunities to interrogate those options, understand the constraints and explain why one solution is preferable to another.
If software checks something automatically, somebody should still understand what is being checked, why it matters and how to recognise when the result is unreliable.
In some respects, this could lead to a better form of architectural education within practice. Rather than assuming judgement develops naturally through years of repetitive production, studios may have to become much more deliberate about teaching it.
That could mean more structured reviews, greater exposure to site work, closer involvement in decisions, more time with experienced architects and opportunities for younger staff to understand the commercial and technical consequences of the work they are producing.
But none of those benefits will happen automatically simply because a practice introduces AI. They require time, attention and a conscious decision about how the next generation of architects is going to learn.
The irony is that technology may remove much of the work that made architectural practice inefficient while simultaneously making the development of professional judgement a more important management responsibility.
What I would measure if I were running an architecture practice today
I would still be testing the tools from my original post. BIM automation, computational workflows, feasibility, visualisation, project information, regulations, spreadsheets and schedules would all be areas I wanted to understand better. I would probably experiment with considerably more applications than I eventually kept.
But I wouldn't judge the success of that experimentation by the number of tools introduced or the amount of AI-generated work being produced.
I would want to understand where the practice was currently spending its time, which activities could be completed more efficiently and what the recovered capacity could realistically be used for.
That would involve looking at actual workflows rather than isolated demonstrations. If a task previously took six hours and now takes two, I would want to include the time spent checking the result and correcting anything that wasn't right. I would compare that saving with the cost of the technology and the effort required to introduce it properly.
I would then look at the effect on the business over a longer period.
If the practice had recovered twenty hours every week, had that allowed it to take on more work without increasing headcount? Had it improved profitability or reduced pressure on the team? Had it created more time for design development, coordination or client relationships? Were directors able to spend more time understanding potential clients, building relationships and developing the next generation of work?
That last point is particularly relevant to smaller founder-led studios, where the same people responsible for delivering projects are often also responsible for keeping the next projects coming.
A founder who recovers several hours of their week from administration or repetitive production has an opportunity to spend that time on activities that may have a much greater long-term commercial effect. They could develop a relationship with a prospective client, investigate a market they want to enter, improve how the practice communicates its expertise or simply give more attention to the people already commissioning its work.
There is no guarantee that recovered time will be used in those ways. In a busy practice, it is very easy for additional capacity to be absorbed by the next urgent deadline. But I think it is worth recognising that productivity gains can have consequences beyond the project or task where they originate.
I would also want to understand what was happening to the people doing the work. Were younger architects developing the knowledge they needed? Were experienced staff spending more time on the decisions where their expertise mattered? Was the practice becoming less dependent on individuals remembering where information was stored, or was it simply creating a new dependency on software nobody fully understood?
These are the kinds of questions that would tell me whether technology was improving the way the practice operated rather than simply making individual tasks faster.
AI may eventually force a different conversation about architectural fees
I don't think architecture is about to abandon percentage fees, lump sums or time charges and suddenly adopt some perfect value-based pricing model. The reality of procuring architectural services is considerably more complicated than that, and different projects require different approaches to establishing scope, managing risk and agreeing fees.
But I do think AI makes the relationship between time and value harder to ignore.
Architectural practices have to understand the resources required to deliver their services. Staff costs, overheads, utilisation and project programmes remain fundamental to whether a practice makes money. RIBA's Fee Calculator reflects that reality by helping practices establish fees through the relationship between resources, billable time, overheads and the margin required to operate sustainably.
There is nothing inherently wrong with that approach. A practice needs to know what it costs to deliver the work before it can decide what to charge.
The more difficult question is what happens when technology begins changing the amount of time required to deliver particular parts of that work.
If a service can genuinely be delivered in a quarter of the time, should the practice retain the efficiency because it invested in the systems and expertise that made it possible? Should the client benefit through a lower fee or shorter programme? Could the recovered capacity be used to provide a more thorough service without increasing the cost?
I suspect the answer will vary considerably depending on the client, the project, the level of competition and the type of service being provided.
What seems increasingly important is that architects become better at understanding and explaining the value of their contribution beyond the amount of time required to produce an output.
A drawing is often the visible result of a much more complicated process. Behind it sit decisions about design, cost, planning, coordination, buildability, compliance and the client's objectives. The value of those decisions is not always proportionate to the time it took to draw them.
An experienced architect might identify a problem in a few minutes that a less experienced team could spend days trying to resolve. A conversation early in a project might prevent an expensive mistake much later. Understanding which design option should not be pursued can be just as valuable as producing the option that eventually gets built.
None of this is new. Architects have always created value through knowledge, judgement and responsibility. What is changing is that technology may begin separating those contributions more visibly from the hours historically required to produce and communicate them.
That could create opportunities for practices to rethink how they structure their services, explain their expertise and negotiate fees. It could also create pressure if clients begin to assume that faster production should automatically mean cheaper architecture.
I think the distinction between the value architects believe they create and the value clients actually recognise becomes particularly important here.
It is not enough for a practice to understand internally why its judgement matters. The people commissioning the work also need to understand the consequences of that judgement, what it helps them achieve and why they should be prepared to pay for it.
If AI makes certain forms of production easier to obtain, that commercial understanding may become even more important.
What happens to the architecture practice when production becomes easier?
When I published the original LinkedIn post, I thought the interesting exercise was identifying the AI tools I would test before adding another person to an architecture team.
I still think that is worth doing, particularly for smaller studios where a relatively modest improvement in capacity can make a substantial difference to how the business operates.
But the discussion that followed made me realise that the technology itself is only one part of a much larger change.
If AI reduces the amount of human time required to produce drawings, documentation, schedules, visualisations and project information, practices will have choices to make about what happens to that capacity. Some may use it to improve profitability, some to compete for work they couldn't previously deliver, some to remain smaller and more flexible, and others to provide a better or more comprehensive service.
There will also be consequences that individual practices cannot control. Competitors will adopt similar technology, clients will develop different expectations and some of the productivity advantages available today may gradually become normal requirements of delivering architectural services.
At the same time, the profession will need to think more carefully about how it develops the experience and judgement that historically emerged through years of production work. Removing inefficient tasks could create opportunities for a better form of professional development, but only if practices recognise what was being learnt through those tasks and find other ways to develop it.
And somewhere within all of this sits the question of how architectural services are valued.
If the production of information becomes faster and cheaper, the expertise required to interpret it, make decisions and accept responsibility doesn't automatically become less important. In some situations, it may become more visible precisely because the production surrounding it has been compressed.
I don't think we can yet say whether AI will ultimately improve the economics of architecture as a profession. It could make individual practices considerably more productive while also increasing competition and putting further pressure on fees. It could enable smaller studios to deliver more ambitious work without becoming much larger. It could also change the types of roles practices need and the way architects develop their careers.
Most likely, several of those things will happen at the same time.
What I am increasingly convinced of is that the practices that benefit most won't necessarily be those with the greatest number of AI subscriptions or the most impressive demonstrations. They will be the ones that understand how the technology changes the work, what that means for their people and clients, and how to turn increased productivity into something that genuinely improves the business.
For me, that is where the conversation becomes much more interesting than the original list of tools.
I started by asking what I would use if I went back into architectural practice tomorrow. After listening to the people who joined the discussion, I think the more important question is how I would organise, develop and value the work of the people using those tools.
Making architectural production faster is one thing. Making the architecture practice better as a result is something else entirely.
→ Original LinkedIn discussion: If I was still practising architecture today, these are the AI tools I'd be testing before adding another person to the project team.
→ View the original LinkedIn post
By Richard Hall, Founder & CEO of Grand House