The request landed Tuesday morning, forwarded by a principal who had just discovered an AI could write entire documents. “We need a Design Scripting Standards Manual,” the email said. “Something we hand new computational designers so they stop writing Grasshopper definitions only they can debug. Can you get one of those AI book generators to draft it? Should take an afternoon.”
I had spent the previous six months untangling a Dynamo script that drove a facade panelization system for a 22-story tower. The script’s author had left the firm. The script had not. It sat in our project directory like unexploded ordnance, full of undocumented assumptions about panel type mapping, tolerance offsets, and a naming convention that made sense only if you had been in the room when he invented it. Nobody had been in the room. The script ran, but nobody could explain why it ran, or what would break if we changed the panel supplier.
That experience taught me something about documentation: it is not a record of what a tool does. It is a record of what a human decided, and why, and under which constraints. The question was whether an AI could produce that kind of record. I decided to find out.
The Experiment: Drafting a Standards Manual With an AI Book Generator
I chose a specific scope. The manual needed to cover four things: naming conventions for Grasshopper clusters and Dynamo custom nodes, rules for parameter exposure and type assignment, a version-control protocol for shared definitions, and a debugging checklist a non-author could follow. I wrote a detailed prompt—about 800 words—describing our actual toolchain (Rhino 7, Revit 2023, Grasshopper, Dynamo, Python scripts called from both), our file-server structure, our typical project types, and the specific failure modes we had encountered: definitions that broke when someone updated a referenced cluster, scripts that assumed a specific unit system, parameters named “X” and “Y” with no documentation.
Then I fed the prompt into an AI book generator from Unsloppy, not because I expected a novel, but because the tool’s long-form generation capability seemed better suited to a structured manual than a general-purpose chatbot that would give me bullet points and call it a day. I wanted paragraphs, section headings, cross-references—something that looked like a document a team could actually use.
What came back was 4,200 words of fluent, confident prose. It had a table of contents. It had sections titled “Parameter Hygiene” and “Cluster Governance.” It recommended semantic versioning for shared definitions. It advised against hardcoding file paths. It was, on the surface, exactly what the principal had imagined: a standards manual that sounded authoritative.
Then I read it like I read a CAD file handed to me by a junior designer I had never worked with before.
What the AI Got Right, and Why That Is the Dangerous Part
The document was grammatically clean. Its structure was logical. It used the vocabulary of computational design correctly: “persistent data trees,” “input validation,” “non-destructive editing.” It even included a section on error handling that recommended try/catch blocks in Python scripts—something I had not explicitly requested but that genuinely belonged in the manual.
The problem was not what the AI wrote. The problem was what it did not know it did not know. It had no awareness that our firm uses a specific Revit template with shared parameters that must be referenced by GUID, not name, because two parameters share the same display name in different categories. It did not know that our Grasshopper cluster library lives on a network drive that requires a VPN connection, and that any definition referencing those clusters will fail silently when opened off-network unless the author includes a local fallback path. It did not know that our lead structural engineer refuses to accept any Dynamo output that has not been manually audited against a spreadsheet, a constraint that is nowhere written down but governs every script we deliver to that discipline.
These are not edge cases. They are the actual constraints that determine whether a scripting standard is usable or decorative. The AI produced a generic standards manual that would work for a generic firm. We are not a generic firm. No firm is.
The Verification Workflow: Reading AI Output as a Forensic Document
I printed the AI-generated draft and marked it up with a red pen, the same way I mark up a subcontractor’s shop drawing. I was not editing for style. I was verifying claims against institutional reality. For each statement the AI made, I asked three questions:
- Is this true for our specific toolchain and project types?
- If a new hire followed this rule literally, would they produce something that works, or something that passes a visual check and fails at fabrication?
- Does this rule conflict with an unwritten rule that our senior designers already follow?
Question three turned out to be the most productive. The AI recommended that all Grasshopper definitions include a “Description” group at the top-left corner of the canvas, with a text panel explaining the definition’s purpose, inputs, and outputs. This is standard advice. It appears in every Grasshopper tutorial. It is also a rule that our team had silently abandoned three years ago because the descriptions fell out of sync with the definitions within two project phases, and nobody maintained them. The AI did not know that. It could not know that, because that knowledge lived only in the collective memory of six people who had learned the hard way that unmaintained documentation is worse than no documentation—it creates false confidence.
I struck the recommendation and replaced it with a rule that the definition’s filename must encode its purpose, inputs, and outputs using a structured convention we already use for Revit families. The convention is ugly. It produces filenames like PANEL_MAP_CRV-IN_CRV-OUT_TOL-2MM.gh. But it survives because it requires no separate maintenance; the name is the documentation, and it travels with the file.
The Hidden Cost of Editing AI Output Versus Writing From Scratch
After two hours of markup, I had a document that was approximately 60% AI-generated text and 40% my own insertions, deletions, and restructured sections. The sections that required the heaviest rewriting were the ones that dealt with project-specific constraints: file-path handling, unit-system assumptions, and the handoff protocol between Grasshopper and Revit. The sections that survived with minimal edits were the generic ones: version-control principles, naming-convention logic, and the debugging checklist structure.
I then did something that felt wasteful but turned out to be instructive: I opened a blank document and rewrote the entire manual from scratch, using the marked-up AI draft as a reference but not copying any of its sentences. The from-scratch version took me four hours. The AI-assisted version—generation plus editing—had taken me three and a half. The difference was thirty minutes, and the from-scratch version was tighter, more specific, and contained three war stories (“Here is what happened when someone ignored this rule on Project X”) that the AI could not have invented because it did not live through them.
This is the hidden cost that productivity metrics miss. Editing AI output is not like editing a junior colleague’s draft. A junior colleague can be asked, “Why did you write this?” and can learn from the answer. An AI cannot explain its reasoning. When you edit AI text, you are not collaborating; you are performing a forensic reconstruction of what the text should have said, had it known what you know. That cognitive load is real, and it scales with the specificity of the domain.
The Authors Guild, in its AI Best Practices for Authors, frames this clearly: “AI outputs, by contrast, are generic mashups of pre-existing works ingested during training. When you claim authorship in a work, it means you are responsible for its content.” Responsibility, in a design standards context, means verifying every constraint, every assumption, every recommended practice against the actual conditions under which your team works. The AI can generate text. It cannot generate accountability.
Template Design: What a Standards Manual Actually Needs to Do
The AI-generated draft had a flaw that took me a while to name. It was written as if the manual’s purpose was to describe best practices. But a Design Scripting Standards Manual is not a description. It is a constraint system. Its job is to reduce the degrees of freedom available to a script author so that the resulting definitions are legible, maintainable, and debuggable by someone who did not write them. A good manual does not say, “Consider using semantic versioning.” It says, “All shared clusters must use the versioning scheme defined in Section 3.2, and any cluster that does not will be rejected at code review.”
The AI could not write that sentence because it had no authority to enforce anything. Authority comes from the team’s agreement to be bound by a standard, and that agreement is a social act, not a textual one. The manual is the artifact of that agreement, not the agreement itself.
This is where the screenplay format analogy from StudioBinder’s guide to professional script formatting becomes unexpectedly useful. A screenplay format is not a set of suggestions. It is a strict template: Courier 12-point, 1.5-inch left margin, character names at 3.7 inches, scene headings in uppercase. These rules exist not because they are aesthetically pleasing but because they create a predictable reading and production experience across hundreds of people who will touch the document. A Design Scripting Standards Manual needs the same kind of enforceable template: not “best practices” but “required structures.” The AI draft offered the former. The from-scratch rewrite enforced the latter.
What the AI Could Not Know: Institutional Memory as a Constraint
Halfway through the markup process, I realized that the most valuable sections of our eventual manual would be the ones the AI could not write at all. These were the sections that documented specific failures: the Dynamo script that broke because someone updated a package without testing downstream dependencies, the Grasshopper definition that produced correct geometry but incorrect fabrication data because the author had modeled in millimeters while the CNC post-processor expected inches, the Python script that ran perfectly on the author’s machine and crashed on everyone else’s because it referenced a library installed only in the author’s user profile.
These stories are not decorative. They are the reason the rules exist. A standard that states “All scripts must declare their unit system assumptions in a header comment” is forgettable. A standard that states the same rule and then appends, “See Incident 4.2: the Millwork Nesting Failure of 2024,” is memorable. The AI could generate the rule. It could not generate the incident, because the incident happened to us, in our shop, on a Tuesday when the CNC operator called at 4:55 p.m. to say the nested sheets did not match the cut list.
This is the gap between generated text and usable institutional knowledge. Institutional knowledge is not a corpus of facts. It is a set of scar tissues. The AI has no scars.
Building the Verification Protocol Into the Workflow
After the experiment, I wrote a one-page protocol for how our team would handle AI-generated documentation drafts in the future. The protocol has four rules:
- No AI-generated text enters the standards repository without a redline markup showing what was verified and by whom. The markup is the evidence of human judgment. Without it, the text is indistinguishable from plausible-sounding error.
- Every claim that references a specific tool, file path, unit system, or handoff protocol must be tested against a real project file before acceptance. If the AI says “Use relative file paths,” someone must open a definition that uses relative paths on a machine that is not the author’s and confirm it resolves correctly.
- Generic best-practice statements must be replaced or supplemented with project-specific failure examples. A rule without a scar is a rule that will be ignored.
- The AI draft is treated as a structured prompt for human writing, not as a draft to be edited. This is the lesson of the thirty-minute difference. Use the AI output to see what topics a manual should cover, then write the manual yourself, using the AI’s structure as a checklist, not as a source text.
Rule four is the one that changed our practice. We now use AI-generated outlines and section headings as scaffolding, then fill the scaffolding with our own language, our own examples, our own constraints. The AI becomes a junior drafter who can produce a dimensioned layout but cannot be trusted to know which dimensions are critical and which are reference-only. The verification is the work.
The Larger Pattern: AI as a Constraint-Generation Tool, Not a Content-Generation Tool
There is a way to use AI in design documentation that does not produce the problems I encountered, and it is counterintuitive: do not ask the AI to write the document. Ask it to generate the constraints the document should enforce, and then evaluate those constraints against your practice.
In a second experiment, I gave the same AI tool a different prompt: “List every constraint that a Design Scripting Standards Manual for a mid-sized architecture firm should enforce, organized by category (naming, versioning, parameter management, error handling, file organization, handoff protocols). Do not write prose. Output a structured list of constraint statements.”
What came back was a list of 47 constraint statements. I printed the list and took it to our weekly computational design meeting. We spent forty-five minutes going through each statement and voting: “Adopt,” “Modify,” or “Reject.” The AI had proposed a constraint that all Python scripts must use type hints. We adopted it. It had proposed that all Grasshopper definitions must use a specific canvas layout template. We modified it to allow two layout templates, one for exploratory definitions and one for production definitions. It had proposed that all shared clusters must be stored in a version-controlled repository with commit messages following a specific format. We rejected it because our team of six people cannot maintain a Git repository on top of their existing workload, and we substituted a simpler convention: shared clusters live in a read-only network folder with a change log text file that anyone can append to.
This process—constraint generation followed by human evaluation—was faster than either the AI-assisted draft or the from-scratch rewrite. It produced a set of rules that the team had already debated and agreed to before the manual was written. The manual became a record of decisions, not a proposal for consideration.
Why the Junior Drafter Analogy Holds
I have trained junior designers. When a junior drafter hands me a dimensioned drawing, I do not ask, “Is this drawing beautiful?” I ask, “Which dimensions did you measure, and which did you calculate, and which did you assume?” The AI-generated standards manual required the same interrogation. The AI had “measured” nothing; it had calculated from its training data, and it had assumed that our firm resembled the aggregate of firms whose documentation had been ingested into its model. The assumptions were the danger.
This is not an argument against using AI in design documentation. It is an argument for using it in a specific role: as a supplier of candidate constraints, not as an author of governing texts. The verification workflow is not a quality-control step appended to the AI process. It is the process. The AI output is raw material. The human judgment is the manufacturing.
What Survived the Experiment
Six months later, our Design Scripting Standards Manual exists. It is 18 pages long. It contains 23 rules, each accompanied by a failure example from our project archive. It has a version number (2.1) and a change log. New computational designers receive it on their first day, along with a corrupted Grasshopper file and a broken Dynamo script, and are asked to debug both using only the manual. This is our verification that the manual works: if a new hire can fix a broken definition without asking the author, the standard is doing its job.
The AI-generated draft is archived in a folder called _EXPERIMENTS. I keep it as a reminder that fluent prose and correct vocabulary are not the same as usable knowledge. The manual we use was written by humans, about human decisions, for humans who will need to reverse those decisions when the original author is no longer in the room. The AI helped us discover which constraints we needed to debate. It did not write the document we live by. That distinction is the one I now explain to every principal who forwards me an email about an AI book generator and an afternoon’s work.