AI Beyond Renderings — Six Places Where It Actually Saves Time in a Practice

A year ago I wrote here about AI tools in design work: visualisations, rendering, copilots. Since then, most of the time we clawed back came from places that have little to do with designing. Paperwork, correspondence and reading other people’s documents, which is the two or three hours a day nobody puts in a fee proposal. One change made the difference: connecting the model to the drive holding the practice’s documents, instead of starting every conversation from nothing.

In short

• A model with access to your earlier contracts and descriptions writes in your style and with your clauses, not in the averaged language of the internet.
• Three things pay off fastest: the first draft of a letter, pulling parameters out of zoning documents and planning decisions, and a site-visit note generated from a recording.
• On the plot, AI genuinely shortens the search for a viable siting, but it will not draw the site plan and it will not sign it.
• One rule applies everywhere: generate prose, not data. Figures, plot numbers and legal references get checked at the source.

The practice drive as the model’s memory

Most people use AI like this: open a chat, describe the problem, get an answer that is correct and alien. Then rewrite it in their own voice and wonder what the point was.

That changes the moment the model has access to a folder of your own documents. Claude and ChatGPT both offer drive connectors and projects with a fixed set of files that stays available across conversations. I put twenty of our contracts in there, a dozen technical descriptions, and two years of correspondence with planning offices. Since then I don’t ask for “an architect’s contract”, I ask for a contract based on the ones we have already signed.

Three tasks that repaid the setup in the first week:

• A contract from meeting notes. I dictate what we agreed: scope, stages, deadlines, fee. I get a version built on our own earlier wording, with our clauses on mid-project changes and site supervision. I read and correct instead of writing from scratch.
• The technical description. From notes and project data I get a skeleton in the style that has already passed through the planning office.
• A first draft of a letter to the authority. The model finds a similar case from last year in the archive and answers with the same logic. It is still only a draft, but I start from something rather than from a blank page.

This works under one condition that comes back in every section below: I ask for language, not for numbers. The passages with data I write myself.

Incoming documents: zoning extract, utility conditions, decisions

The folder a client hands over usually looks the same: the zoning plan extract, connection conditions from two utilities, sometimes a planning decision, plus a geotechnical report. Reading all of it properly is the first afternoon of the project.

Now I hand the set to the model and ask for a table of parameters: built-up ratio, biologically active area, building line, permitted height and roof pitch, access conditions. Then for the more interesting part: a comparison of those parameters against our concept, with the places where the two diverge.

Two notes from practice. Poorly printed scans are read worse by the model than by a person, so with a blurry extract verification takes as long as reading it yourself. And every figure that later goes into the project gets checked against the source document. I treat the summary as an assistant’s note, never as a finding.

Site visits and meetings

Of the whole list this one has the best ratio of gain to risk, because the material is your own and checking it takes a minute.

I record the conversation on my phone, with the other side’s consent. After a site visit or a client meeting I upload the recording and ask for three things: the decisions made, the changes that need pricing, and the questions nobody answered. The last list is often the most valuable, because those are exactly the things that evaporate in conversation.

I send the summary to the client the same day. Since we started doing it, an entire category of disputes disappeared — the ones that begin with “but we said that…”. A dated email with the agreed points works better than two people’s memory three months later.

The plot: what AI can compute and what it cannot sign

Four different things are currently sold under the heading “AI will place your building on the plot”. They are worth separating before you buy a licence or promise anything to a client.

Site analysis and massing options. Parametric design tools compute sunlight, shading on neighbours and massing proportions across a dozen variants at once. That genuinely shortens the stage where you used to produce three options because there was no time for more. Here the technology delivers.

Siting that complies with the plan and building regulations. Distances from boundaries, the building line, roof pitch and biologically active area. A model can explain all of this correctly and get it wrong just as convincingly, because it knows neither this plot nor this particular plan until someone gives them to it. The liability stays with the designer either way.

The site development plan as a document. The drawing on a surveyor’s base map, with the site balance, that goes to the authority. An architect with a licence draws it and signs it. No generative tool available today replaces that.

Visualising the developed plot. Surfaces, greenery, mood. Here AI is strong and you can put it in front of a client in a meeting. It is also the only one of the four that sells as a separate service, which is why it returns in my next piece on what to offer clients.

What I don’t hand over to AI

The line runs in one place: the model generates text, not knowledge about your project. Everything that counts as data comes from documents or from a system.

So I don’t delegate figures and identifiers. Built-up area, plot number, land register precinct, volume, the client’s details — typed by hand or pulled from a database. I don’t delegate legal references either. An invented article of a statute looks exactly like a real one, and in a letter to an authority it costs you credibility.

Confidentiality is a separate matter. Powers of attorney carry clients’ national ID numbers, contracts carry their addresses. Before you connect anything to the practice drive, set up a business account with training on your data switched off and read what the provider’s terms actually cover. A free chat on a personal account is not a place for client documents, not even once.

The practical rule we keep on a single page: you may upload what would end up at the planning office or on the practice website anyway, plus your own document templates. Personal data and clients’ finished projects stay out of the prompt.

How to start in a week

If you want this running without turning it into a quarterly project, this order is enough:

1. Open a business account with one provider and switch off training on your data in the settings. One provider for the whole practice, not three subscriptions in three people’s hands — otherwise nobody knows where client documents ended up.
2. Collect a folder of templates: contracts, technical descriptions, letters to authorities, standard client replies. Twenty files will do.
3. Connect that folder as a source and pick one process to start with. Meeting notes are my recommendation, because the effect shows on day one.
4. Set a verification rule and keep it: figures and legal references are checked by a human, always.
5. After a week decide whether the process stays. If it doesn’t save an hour a week, drop it and take the next one.

One thing remains that no model will settle. A permit application and a power of attorney need the client’s, the plot’s and the authority’s data in the same shape every single time, not text written from memory. In our office those documents are built from project data in ArchiFlow, so the plot number in an application comes from the project record rather than from whatever the model found plausible. I wrote more about what an office needs from its software.