The Tighter Loop

Every demonstration I have sat through follows the same shape. A prompt goes in. Twelve elevations come out. Somebody in the room says that one's interesting, and the conversation turns to how many more we could generate by Friday.

I understand why the demos are built this way. Production is legible. You can count it, put it in a proposal, defend it to a client who wants to know what the software costs and what it saves. But I have never once been on a project that failed for want of options. I have been on projects that failed because a requirement nobody restated went unexamined for four months, because an opportunity sat in plain view and no one had the room left in their head to notice it, because the thing we were solving in July was not the thing the client had actually asked for in March.

Those are not production problems. They are attention problems. And attention is the thing a critic supplies.

What a critic actually does

The best collaborator I ever had did not draw better than me. He asked, at the moment it was most annoying to be asked, whether the scheme still did what we had promised it would do. He carried the brief in his head as a live document rather than a filed one. He noticed when the plan had quietly optimized for the thing that was easiest to resolve rather than the thing that mattered most. He was not additive. He was corrective.

That role has a specific structure worth naming, because it is the structure I want from software:

• It holds the requirement independently of the proposal, so the requirement cannot drift to fit what we have already drawn.
• It asks the question that has not been asked yet, rather than answering the one on the table.
• It surfaces the opportunity: the adjacency nobody tested, the section that would pay for itself, the program that could absorb the leftover volume.
• It is willing to be unwelcome.

Nothing in that list is generative. All of it is evaluative. And evaluation is where our process is genuinely thin, because evaluation is expensive and slow and usually arrives too late to change anything cheaply.

Design is recursive; the loop is just slow

We propose, we test, we discover what the proposal was actually about, we revise. That loop is not a flaw in the way architects work. It is the way architects work. A scheme is a hypothesis, and you do not learn what you have designed until something pushes back on it.

What makes the loop slow is almost never the drawing. It is the latency of the pushback. The energy model comes back in ten days. Cost comes back after the estimator has had the set for two weeks. The code question waits on a call. The client's real priority emerges in a meeting six weeks after we committed to a massing. By the time the evidence arrives, the design has hardened around the assumption the evidence was supposed to test, and now changing it is a fee conversation.

Every increment of that latency you remove is a design decision you get to make on evidence instead of on faith. That is the whole argument. Not more schemes. More turns of the loop, at the point in the project where turning is still cheap.

This is the reframe I keep coming back to: the right question is not what a tool can produce, but how much sooner it can tell you that you are wrong.

Where the compression is real

Judged against that standard, some of what is arriving is genuinely useful and some of it is theater.

Continuous conformance is useful. A brief is a long, contradictory, human document, and we check our work against it at milestones because checking is laborious. There is no good reason that check should be episodic. A tool that can hold two hundred pages of requirements against the current model and tell me, on a Tuesday, which four have quietly stopped being true is not doing my job. It is doing the job I have been deferring.

Opportunity surfacing is useful, with a caveat. Ask what the scheme is not yet exploiting and you get a list. Some of it obvious, some of it wrong, occasionally one item that reframes the project. The caveat is that this only works if the tool has enough context to be specific. Generic advice about daylighting is noise. A note that this particular floor plate, at this depth, with this core, is leaving a third of its perimeter under-programmed is a design conversation.

Institutional memory is useful and underrated. Most firms have solved most problems already and cannot find the solution. What we call experience is largely retrieval.

The failure mode is agreement

Here is what worries me, and it is not job loss.

A critic that agrees with you is worse than no critic, because it produces the feeling of having been checked without the fact of it. These systems are trained, broadly, to be helpful and agreeable. Point one at your scheme and ask if it works, and you will very often be told that it does, in fluent and confident prose, with three supporting reasons. That is not evaluation. That is a mirror with good manners, and it will make us more certain of weaker work.

The second failure mode is subtler. A model that has read everything tends toward the center of what it has read. Ask it to improve a scheme and it will, on average, move it toward precedent. Sometimes precedent is exactly right; that is what precedent is for. But architecture advances at the edges, and a tool with a gravitational pull toward the mean will quietly sand those edges off if we let it hold the pencil rather than the mirror.

Both failure modes have the same remedy, and it is not technical. It is that we have to specify what we want interrogated, and we have to be the ones who set the criteria. Which means the criteria have to be written down. And writing down what a good building actually has to do, in language precise enough to be tested against, is a discipline our briefs mostly do not have yet.

That, I suspect, is the real work of the next few years. Not learning to prompt. Learning to state our intentions clearly enough that they can be checked.

Why delivery is where this lands first

I spend my working life inside delivery methods that already tried to solve this problem socially. Design-build and integrated delivery exist, in large part, because the feedback loop in traditional design-bid-build is too long: the builder's knowledge arrives after the design is finished, when it can only be expressed as a change order. The remedy was to put the parties in one room earlier and let the information circulate while it could still do some good.

That is the same move. Shorten the distance between a decision and the evidence about the decision. Which is why I do not think of these tools as a break from how good projects already run. They are the next compression of a loop the profession has been tightening for thirty years, and we have institutional experience with what that compression does. It redistributes authority toward whoever holds the information. When the information becomes continuously available, the question of who gets to interpret it becomes the whole professional question.

I would rather architects answer that question than have it answered for us.

The test

So here is the standard I am trying to hold, and I would like to be argued with about it.

A tool earns its place in the studio if it makes the loop between intention and evidence shorter and more honest. Shorter, so we learn while learning is still affordable. More honest, because a faster loop that returns flattery is just a faster way to be wrong.

Everything else is production: the twelve elevations, the seconds saved, the renderings in the pitch deck. Production was never our constraint.