The three AI failure modes

At the final crit, students may use parametric software that generates whole façades in seconds. One student spends her slot showing the jury the software's newest scripts while the library the brief asks for has no plan. Another pins up twelve generated façades, each kept as it came out. A third typed the brief into the generator; asked why the stair sits where it does, she says the software put it there. The jury marks design reasoning, and whether each choice is the student's own.

At the crit	In the AI-assisted round
Demonstrating the software instead of designing the library	AI Showcase
Twelve façades, each kept as generated	Feature Marathon
"The software put the stair there"	Hands-Off
The jury marking reasons and ownership	The three scored areas
Setting the massing herself, letting the software vary the panels, culling them against the daylight brief	Directing the tool and judging what it returns

Breaks down when: a jury mostly sees the finished boards and the talk, while an interviewer watches every prompt and acceptance live. Wrong inference: "only the end result counts, so the process can be fixed in the closing talk." A crit's rules also hold for years; interview formats changed within months.

In real terms: at each acceptance, the decision inside the output should be one you made or checked.

EXH-2230 is a synthetic replay of an AI-assisted practice round: an anti-cheat alert feed for the ExamHall admin console, from a five-item brief. The re-run of the same round, a week later, is MR !2530. It then runs each accepted feed handler against a fake feed of eight alerts whose first connection drops after alert 4, on a virtual clock.

EXH-2230 replay · brief items 5 · prompts 1 (the whole brief)
  design calls 3 · stated by the candidate 0 · left to the assistant 3 (transport, reconnect, duplicate alerts)
  generated files 6, 412 lines · opened before accepting 0 · edited 0
  feed across one dropped connection: alerts shown 4 of 8 · reconnects 0 · shows "offline" and stops
MR !2530 re-run · brief items 5 · prompts 6 (one part each)
  design calls 3 · stated by the candidate 3 · left to the assistant 0
  generated files 6, 192 lines · opened before accepting 6 · edited 3
  feed across one dropped connection: alerts shown 8 of 8 · reconnects 1 · resumed after alert 4

In the replay, all three design calls were made inside the generated code and nobody stated them, so the missing reconnect path was nobody's decision. The brief went out as one prompt and came back as the solution: the Hands-Off pattern of step 4.

In the re-run, the candidate stated the three calls before prompting, asked for one part at a time and opened every file before accepting it. How a feed should reconnect is fsd-realtime-transport's; here only the counts matter.

The ledger counts events in the author's fixture. It names no pattern and cannot tell whether a stated call was a good one.