How should architecture firms measure AI adoption?
Count the tasks offered to AI, the outputs accepted after review and the project decisions those outputs changed. A project-level percentage hides whether AI supplied one disposable mood image or carried a full visualization package. Task-level reporting shows where the tool saves work, creates rework or simply appears in the file history.
A July roundup from visualization studio Maverick Frame contains a wonderfully awkward number. Its founder says AI is used in close to 100 percent of the studio's projects, then adds that its share can range from one percent to the whole image. Both claims may be accurate. Put together, they show why “projects using AI” is a rotten denominator.
The claim appears in Maverick Frame's 2026 AI rendering guide, which also describes a mixed stack of 3ds Max, Corona, aggregators, ChatGPT, Magnific and Topaz. That description is more useful than the headline percentage because it locates AI in particular jobs. The percentage merely says that the technology left a fingerprint somewhere.
Why does the project percentage mislead?
An architecture project is a container the size of a small weather system. It can hold feasibility, massing, drawing coordination, specification work, visualization, approvals and endless communication. Marking the entire container “AI used” because a concept board included one generated image is like marking a building “timber” because the reception desk is oak.
The metric also rewards trivial contact. Run one prompt, reject the output and the project still qualifies. Use ComfyUI for two weeks, repair every facade drift by hand and it qualifies in exactly the same way. A binary project count cannot distinguish productive work from a ceremonial encounter with a chatbot.
A project-level adoption rate measures presence. A practice needs to measure contribution.
This is not an argument for surveillance or keystroke theater. It is an argument for choosing a unit that resembles the work. ArchiGen's audit of AI time-saving claims makes the same distinction about hours: a faster first image is irrelevant if correction and approval consume the gain. Adoption needs the same accounting discipline.
Use three counters, not one percentage
| Counter | Question | What it reveals |
|---|---|---|
| Task exposure | Which defined tasks were attempted with AI? | Where staff believe the tools might fit |
| Accepted output | Which results survived review and entered the work? | Where the tools produced usable value |
| Decision effect | Which accepted results changed a documented choice? | Where AI affected design or delivery |
Task exposure is the widest measure. A team might offer AI a facade mood study, a planting variation and a specification summary. Record the attempt even when the result is rejected. Failed attempts matter because they consume time and show where the tool's promise exceeds its fit.
Accepted output is narrower. The render appears in a client deck, the summary enters a checked work note or the inpainted planting survives visual QA. Acceptance must follow human review. Otherwise a folder of generated options looks like adoption while the project team quietly rebuilds everything elsewhere.
Decision effect is the hardest and most valuable counter. Did an image move the team toward brick rather than metal? Did a daylight summary change an opening? Did a generated alternative make the client reject an option? The earlier ArchiGen guide to an AI visualization decision log gives this effect a place to live.
What belongs in a task ledger?
Keep the ledger blunt. Name the task, project stage, input, tool and version, operator time, review time, disposition and reason. Add a link to the accepted output or rejection note. Do not ask staff to compose miniature case studies after every prompt. A useful record should take less than a minute when the task closes.
The disposition needs more than “success” or “failure.” Use accepted, accepted after repair, reference only and rejected. “Accepted after repair” is especially important. It catches the charming habit of calling an AI output finished while Photoshop, Blender or the renderer quietly pays its debts.
Pair the ledger with the evidence bundle described in ArchiGen's tool shortlist evidence packet. The ledger tells you frequency. Inputs, contact sheets and correction records explain quality. One without the other invites a dashboard that is beautifully exact about the wrong thing.
How do you compare adoption across teams?
Do not rank teams by the largest AI percentage. That creates an incentive to break one ordinary action into six “AI tasks” or to send unsuitable work through a model for the badge. Compare patterns instead.
A concept team may expose many low-stakes tasks and accept a modest share. A technical team may expose few tasks and accept most because the use case is narrow. A visualization team may accept many outputs but spend heavily on repair. Those profiles describe different work. None is the universal maturity curve that a software vendor would like to sell.
Normalize by a stable local unit: visualization briefs completed, design options reviewed, drawing packages issued or research notes approved. Then report AI-assisted tasks beside the total. “Eight of 31 visualization tasks used AI, five were accepted, two changed a decision” can be challenged and improved. “AI touched 92 percent of projects” can only be admired from a distance.
Do not turn measurement into an alibi
A task ledger will not prove authorship, legality or competence. It will not tell a principal whether an image misrepresents the design. It merely replaces a foggy adoption claim with operational evidence. Quality review, disclosure and responsibility remain where they were: with the people issuing the work.
Vendor and studio surveys also need plain labels. “Used AI” might mean a text assistant drafted an email. “Generated with AI” might mean a single masked repair. “AI-led” might mean the source image, material treatment and finish all came through models. Publish the definitions beside the percentages or keep the percentage in the drawer.
The same caution applies to project stories. A studio saying AI appears in nearly all its work is offering a meaningful signal about ubiquity, especially when it also admits that the share varies radically. Treat that as a starting question, not a benchmark your firm must chase.
What should a quarterly report say?
Lead with the work, not the software. Name the two or three tasks where acceptance rose, correction time fell or a decision became clearer. Name one task where the tool failed repeatedly. Report the version because model behavior moves. Report review time because speed without checking is merely haste wearing a lanyard.
Then choose an action. Standardize a repeatable task, run a controlled trial or stop offering a poor-fit task to AI. The point of measurement is a better workflow decision, not a larger number for the practice meeting.
A project is too large to be a checkbox. Count the work.
Evidence note: this analysis uses Maverick Frame's “Best AI Rendering Tools for Architectural Rendering,” published 6 April and updated 4 July 2026, accessed 20 October 2026. The studio-use statement is attributed to founder Dim Kuzmenko and remains that studio's claim. ArchiGen did not audit its project records or run a product trial for this article.