Welcome to ArchitectureLM

Technology is the answer, but what was the question?

— Cedric Price, lecture, 1966

A render leaves the office. It travels into a client pack, sits beside the fee proposal and the area schedule, and by the time it is on a screen in a boardroom, nobody in the room could say which parts of it a person drew. Nobody asks, either. The practice's name is on the sheet, so the practice answers for all of it.

Price was asking about computers and prefabrication. The question has aged well enough to be irritating — the answer has arrived again, faster and far more convincing, and what it answers is still unstated. One honest version of the question is who is responsible for the drawing when a machine helped make it. That is the version this site is built on.

ArchitectureLM is a publication and a reference for architects in practice. It covers artificial intelligence the way a good journal covers a new structural system or a change to the regulations: as something you will have to work with, price, defend to a client, and eventually be responsible for. Not as a spectacle, and not as a threat.

It is written for architects who are experts in architecture and novices in this. That asymmetry is the normal condition, not a deficiency. You do not need to know how a model is trained in order to run a practice. You do need to know what it will not do reliably, what it costs per seat, and what your insurer would make of it once somebody finally asks.

Capability is mostly settled. Accountability is not.

Most coverage of AI in architecture is a capability race: what the newest system can render, generate, or automate, updated monthly and stale by the time you have read it. Capability moves fast enough that chronicling it is close to pointless. It is also not the question that decides whether a practice adopts anything.

The deciding question is accountability. When work is produced with a machine somewhere in the loop, responsibility does not evaporate — it moves. It moves toward whoever signed, whoever specified, whoever did not check. Software companies are precise about what their products make and notably vague about who carries the consequences when the output is wrong.

That frame shapes everything here: what gets covered, what gets left alone, and the tone of both.

Two halves: the writing and the reference

Articles are filed in six Spaces, each one a part of practice rather than a category of technology.

• Practice & Accountability — adoption inside firms and the question underneath it: billing, contracts, workflow, staffing, and who is answerable when the output is wrong.
• Delivery — running the project with AI in the loop: programme, cost, coordination, RFIs and submittals, site, and handover.
• Language & Documents — the written work of practice: specs, reports, planning submissions, briefs, client correspondence, and reading code documents.
• Urban & Landscape AI — city-scale tools, masterplanning, feasibility, and site analysis at scale.
• AI Rendering & Visualization — diffusion models, massing-to-render workflows, and the tools turning geometry into imagery.
• BIM & Computation — computation acting on the model: Revit and ArchiCAD automation, code checking, Grasshopper, and optimisation.

Follow the one that matches your week and ignore the rest.

Underneath the writing sits a reference layer, kept as two separate lists on purpose: Tools and Models. A model is to a tool what a structural frame is to a building — several very different buildings can stand on the same frame, and you cannot judge the frame by the cladding. Two products with different interfaces, prices, and promises are frequently the same model wearing different facades. The comparison fails in one place, and the failure is the useful part: frames do not improve monthly. Models do, which is why a tool you dismissed in spring deserves a second look by autumn.

News is filed the way a practice files drawings — NEW, RELEASE, UPDATE, FOR INFORMATION. The marker is half a joke and entirely a filing system. Anything that matters this week appears there in three sentences, with a judgment attached.

What you will not find here

Unattributed vendor claims. If a company says its tool renders a scene in ninety seconds, you will read that the company says so, until someone has sat and watched it.

Statistics without a primary source. Numbers reported secondhand get cut, even when they would make the better headline. A hedged true sentence beats a confident borrowed one.

Hype vocabulary. Nothing on this site revolutionizes, disrupts, or unlocks anything. Where something genuinely changes, the change gets described in hours, fees, or drawings.

Either prophecy. Not the replacement panic, and not the "it's only a tool" shrug. Both are ways of declining to think about the actual problem, which is more specific and more boring and considerably more urgent than either.

Where to start

Read whatever is on the front page; nothing here assumes you read anything else first. If you want one thing, take the newsletter — the pieces worth the time, and nothing between them.

And when something here is wrong — a price, a version number, a capability claim that does not survive contact with your project — say so, and it gets corrected in public. A publication about machines that state things confidently should be careful about doing the same.