Did the AI image change the design?

A project team generates twenty facade studies before lunch. The contact sheet fills with warm brick, pale stone, oxidized metal, timber fins, deep reveals, and improbable planting. Everyone agrees the exercise was productive. Two weeks later, the BIM model contains the same facade it had before the studies began.

This is the gap inside the current claim that AI is moving architectural visualization into design thinking. Faster images can help a team see consequences earlier. They can also produce a thick cloud of attractive options with no connection to a decision. Output volume is easy to measure, so it gets mistaken for learning.

A decision log is the simplest correction. It links each generated study to a question the project can answer, records the evidence held constant, and states what changed afterward. If nothing changed, that is useful information too. The image may have confirmed the existing direction, exposed a weak question, or simply decorated a settled decision.

Begin with a question that can move the model

“Explore facade options” is not a design question. It has no boundary and no stopping condition. Ask instead: does a 600-millimeter projecting frame provide enough visual depth at noon to justify its cost? Can a darker base reduce the apparent height without breaking the material logic? Does the entrance remain legible when the canopy is shortened to clear the tree protection zone?

Each question names a variable, a reason, and an observable consequence. That structure changes how the AI study is made. The team knows what must stay fixed and what may vary. It also knows what information must return to the model if an option succeeds.

If the answer cannot alter a drawing, specification, model element, or brief, the study is probably presentation work.

Presentation work is legitimate. The problem begins when teams describe it as design research and then use image count to justify the tool. Naming the job keeps both activities honest.

The five fields in a useful decision log

1. Decision question

Write one sentence before generating. It should identify the choice and why it matters. “Should the west elevation use vertical fins or deeper horizontal reveals to control late sun while keeping views?” is specific enough to guide both images and analysis.

2. Protected facts

List what may not change: camera, massing, opening locations, floor levels, neighboring context, sun direction, approved structure, or material budget. Protecting facts prevents a more dramatic but false option from winning. Use fixed source views, depth or edge conditions, masks, and low transformation strength where appropriate, then inspect rather than assume compliance.

3. Allowed variable

Change one family of decisions at a time. If facade depth, glazing ratio, material, weather, planting, and camera all move together, nobody can tell why one image reads better. Separate geometry studies from atmosphere studies. Separate material color from joint scale. AI makes variation cheap, which makes experimental discipline more important, not less.

4. Result and confidence

Record the chosen direction, rejected directions, and how strongly the image supports the conclusion. A rendered study can reveal apparent depth, rhythm, glare, visibility, or mood. It cannot prove thermal performance, cost, waterproofing, structural feasibility, or planning compliance. Mark which conclusion is visual and which needs calculation or consultant review.

5. Project consequence

Name the artifact that changed: model revision, detail sketch, material sample request, client agenda item, consultant question, or no action. Include an owner and date. This field turns the log from commentary into a handoff.

Run a study in four passes

First, capture a baseline from the current model. It does not need to be beautiful. It needs to show the protected facts clearly and establish the camera. Archive it with the model version.

Second, generate the smallest comparison set that can answer the question. Three options are often enough: low, middle, and high values for the selected variable. A grid of thirty images invites taste voting and makes accidental differences harder to notice.

Third, review with an overlay mindset. Check silhouettes, opening edges, floor lines, material boundaries, shadow direction, and context before discussing preference. Reject any image that changed protected evidence. Do not let an appealing accident enter the vote without being identified as a new proposal.

Fourth, record the consequence during the review, not afterward. Assign the model update or technical check while the reason is still visible. Link the chosen image to the revised element. The log should make it possible for someone absent from the meeting to understand why the project moved.

Measure decisions, not generations

After a month, count studies that produced a project consequence, studies that confirmed an existing choice, studies rejected for evidence drift, and studies that ended without an answer. These four numbers say more than total images or generation time.

A high drift rate suggests the workflow needs stronger conditions, tighter masks, or lower transformation. A high no-answer rate suggests the team is asking vague questions. A high consequence rate can show real value, but inspect the consequences: changing a material swatch is not equal to resolving a circulation conflict. Weight the log by decision importance if you use it for investment decisions.

Also record the labor around generation. Include source preparation, prompt work, selection, correction, review, and translation back into the model. A ten-second result that requires ninety minutes of repair is still a ninety-minute study. The log should expose that cost without pretending conventional sketching was free.

Where the method breaks

Not every architectural question belongs in an image generator. Code, accessibility, structure, energy, acoustics, cost, and procurement require other evidence. Generated studies can frame questions for those disciplines, but visual plausibility is not technical proof.

The method also fails when the team hides image invention. If the model adds a stair, removes a column, or changes the site to make an option convincing, annotate it. The invention might be valuable, but it must become an explicit proposal that enters the normal design process.

Finally, do not turn the log into administrative theater. One row per decision is enough. Link files instead of pasting essays. The test is whether the record helps the next person act.

Our take: make the claim auditable

AI visualization can participate in design thinking when it makes consequences visible while choices remain open. That is a real shift from final rendering. It is not automatic. Without a question, protected evidence, and a return path to the project, the tool has only accelerated image production.

The decision log gives a studio a grounded way to tell the difference. It also protects authorship. The architect identifies the question, chooses what must remain true, judges the evidence, and owns the consequence. The generator proposes pixels inside that frame.

At the next pin-up, put one blank column beside the AI contact sheet: “What changes Monday morning?” If nobody can fill it, stop generating.