Agentic instruments for the design studio — supplying the logics, language, and data behind a design judgment, and leaving the judgment to the student.
84 instruments live · 11 benches · built with Claude Code
Design thinking is already an iterative system — ask questions, gather information and expertise, then form that material into built and unbuilt proposals. That loop is exactly the disposition agentic AI tools reward, which makes the studio the natural place to learn them. I’ve built Good Tools — a set of studio instruments made with Claude Code, each supplying the logics, language, and data behind a judgment while leaving the judgment to the student — covering site analysis and design, precedent research, skills coaching, drawing and 3D production, critique, studio memory, and, primary among them, accessibility (RAP). They’re taught inside studio sequences and a short series of agentic-coding workshops, in a “trust but verify” stance that values iteration and edge-case hunting over fluent-sounding answers.
The same eleven words run down the left menu and through this page — Site through Studio, with Misc holding the one thing that isn’t an architecture instrument. Each word opens its bench of tools, listed best-developed first. The menu shows the core tools by default; its bottom switch opens the rest.
Read the ground and its climate — terrain, earthwork, weather files, the figure-ground.
Precedent and research — context for any image you find, catalogued into a growing project library.
Living systems over time — succession, planting, a drawing that grows, a century of change.
Gardener · Ecolounges · Palimpsest · Resonator · +1 more
Make and shape geometry — describe it, form-find it, test it against the forces.
Eco-Architect · Conjure · Assayer · Swarm · +2 more
Structure and assembly — form-finding, trusses, stairs, screens, the wall section.
Represent and make — projection, camera, light, the print shop, laser and print prep.
Fabricator · Lens · Viewer · Graphics · +19 more
Prove it — program, daylight, sound, wind, comfort, carbon, sightlines, framing.
Diagram Studio · Acoustician · Daylighter · Scoreboard · +12 more
Words about the work — the charter you start from, a defensible thesis, adoptable critics.
Skills tutoring, the trail map and code snippets.
Coach · Toolsmith · Skills Map · Python Scripts / Rhino + GH
The whole process, the class record and its infrastructure — the archive wall, QR drops, your own trace.
Every instrument at once: the catalog, grouped by the same words · about & disclaimer
The headline tools, each with what it does and a note on where it runs. Open any one of them from its title; fuller context is in the statement below.
Turns a real parcel into citable evidence — sun path, prevailing wind, climate, zoning and code, hydrology, history — so a student’s site claims are sourced, not asserted. Hard data is free and cited; AI judgment is tagged for the student to verify. The measured ground, exported clean to Rhino before anything gets designed on it.
Runs as — a web app; pulls open climate, terrain, and zoning data, exports Rhino-ready files.
A drawing that grows. A real stand — individual trees competing for light, dying, seeding in — inks its own crowns through a mark grammar the student authors, so the simulation and the drawing never drift apart. Three versions switch in one page: grow it, let its lineages evolve, then make it honest — an ensemble of futures drawn as an uncertainty band, per-stem kill odds, and cited trait ranges. A stylized teaching model of succession, and explicit about being one.
Runs as — a client-side simulation in the browser; public, no API cost.
The studio’s shared memory for references. A student drops in an image they found and gets it identified and contextualized — architect, project, the moves worth borrowing, related plans and photographs — and it accrues into a searchable class library of images and texts, tagged and cross-linked. It began as a local app over the filesystem (Obsidian-compatible) and now runs in the toolkit, so the archive is shared and every identification stays inspectable rather than locked in someone’s chat history.
Runs as — a web app in this toolkit (sign-in); grew out of a local, Obsidian-compatible filesystem app.
A pin-up wall with memory, built to replace Miro for weekly process work. It’s organized the way the studio actually runs — sections per TA, rows per student, columns per day — so the week’s drawings are legible at a glance, peers can react and comment, and the metadata underneath shows who’s engaging and who’s gone quiet. Designed for real load: hundreds of students posting every week.
Runs as — a web app with a backend (Supabase) and accounts.
Push massing and watch the physical consequences move: rotate the building and solar gain shifts; raise it and wind exposure and views change. Encode design intent as testable rules, then round-trip the same constraints to Rhino 8 / Grasshopper. It makes the link between form and forces legible while a scheme is still soft.
Runs as — a zero-build web app; exports native Rhino 8 + Grasshopper python.
The Radical Accessibility Project: making architectural production work without sight. It drives Rhino from the command line, generates tactile drawings (PIAF swell paper) and 3D-printed reliefs, reads plan and section aloud as spatial audio, and writes structured alt-text. Built local-first and open-source so anyone can replicate it, and developed with a blind co-researcher, its primary user. The constraints it surfaces sharpen spatial description for every student, not only blind ones.
Runs as — local + CLI, open-source · repository
A review partner, explicitly not a verdict. It adopts a critical persona — tectonic, social, formal — to give the lay of the land and surface blind spots, and it helps build the case for review: pulling a project down to a defensible thesis, sequencing the drawings that prove it, and interviewing the student for the questions a jury will ask. One synthetic position among many — weigh it against human critics, never substitute it for them.
Runs as — LLM behind a proxy; each persona is a system prompt.
A tutor that refuses to just hand over the answer. A student asks how to do something — loft a surface in Rhino, set up a sheet in Revit, structure a portfolio spread — and it first asks them to commit to an attempt, then responds to that, correcting and extending rather than lecturing into a vacuum. Tuned with real expertise per skill, so the dialogue stays specific. The point is to make students articulate their thinking before the tool fills the gap.
Runs as — LLM chat behind a proxy, or campus Illinois Chat.
A trail map of 2D and 3D skills from beginner to advanced. Each step opens a tutorial video and the shared concept notes, with “builds on / leads to” links and a hand-off to Coach when a student gets stuck. It charts what to learn and in what order; Coach is the tutor for the learning itself.
Runs as — a static map + video library; no sign-in.
The capstone of the authoring ladder — the statement’s promise made concrete. A student describes the parametric instrument they wish existed and Claude writes its program on fenced rails; the student then drives the sliders it chose, reads the annotated code, edits and re-runs it, and keeps the instrument in a personal library. Authoring a small tool is the fastest way to learn what a tool is — and where to stop trusting one.
Runs as — Claude behind a server proxy writing sandboxed programs; sign-in required.
A bench of single-purpose widgets for the parts of studio production that currently mean opening Photoshop and remembering a workflow: thresholding and vectorizing a scanned or rendered drawing, using a live camera as a scale and reference overlay, and prepping geometry for laser cutting. Each does one job and gets out of the way.
Runs as — vision models for cleanup, deterministic paths for fabrication.
On-ramps for students moving from model to machine and to the web: generating and explaining Rhino / Grasshopper Python, dropping a model into a shareable Three.js viewer for the portfolio site, and dialing in 3D-print and PIAF presets — with short, task-shaped tutorials that assume you’ll deviate.
Runs as — Rhino-coupled, plus a static web viewer.
Students are forming the ability to discern and find the sophistication needed to justify their designs in an era where we design not just with more compassion but in an environment saturated with data. Whether they draw on an increased understanding of site-specific environmental forces, conduct more thorough historical precedent analysis, or bring more voices, both human and nonhuman, to drive creative form generation, students are striving to give language to their work. As design studio teachers, we strive to level up their reasoning, synthesis, and analysis of both a given real-world site, the people who inhabit or inhabited it, and the invented buildings and systems to be placed on it.
AI tools — specifically agentically coded tools — can give them the logics, language, and data to make more sophisticated judgments, and can let them take on computational analysis in ways that were out of reach until this year. Design thinking remains a curious iterative system built around the asking of questions, the gathering of information and expertise, and then the forming of that data into built and unbuilt forms or systems of whatever variety. This way of thinking perfectly aligns with the pedagogy of teaching people to relate to this new way of computing; the loop of proposing, testing, and revising is the same one you run whenever you direct one of these tools. LLMs are just this: the new generation of computers, and the studio is a natural place to learn them.
I will both demonstrate to the students in class how to vibe-code the more sophisticated tools I’ve built (which I’ll give them access to) and, together with them, vibe-code simpler tools and algorithms for their own design formation and decision-making that they can use directly in their studio projects. I foresee these becoming as ubiquitous as the proprietary software our students already engage with in school and in the profession. I believe they should learn to move quickly and embrace these tools; to iterate often in a “trust but verify” stance that pushes them to find edge cases and failure modes; and to engage in creative brainstorming with these tools in a fluid but skeptical manner. I intend to introduce these during class studio sequences, and I will probably also run a series of agentic-coding-for-design workshops, as it will likely take a few sessions to get students — and colleagues — up to speed. (To colleagues graduating from chatbots to Claude Code or Codex who want more control over the inputs, outputs, memory, and behavior of their models, I’m glad to help, and I’d point you first to the concept of an agent harness.)
The main outcome and learning objectives are the same as in any design studio: to make sure students level up their explanation of both the final architectural design and the process of arriving at it. Teaching students to work with AI follows many of the same basic tenets as teaching them to become resilient designers, which is why building these tools should reinforce the core of the studio rather than compete with it. The tools are a set of studio instruments, detailed in the examples above — a Surveyor for site analysis and an Eco-Architect for design with context, a Coach to tutor production and a Skills Map to chart the skills, a precedent Librarian, a studio Archivist, a Critic for critique and portfolio, and a bench of 2D and 3D production tooling. Primary among them, and the throughline of my research, is the Radical Accessibility Project, which makes architectural production work without sight and is where I practice the verify half of “trust but verify” at the highest stakes. All of these are in some stage of production, fully built with Claude Code.
How do we reinforce design thinking while teaching AI literacy? Specifically: how do we teach students to iterate, to hunt for edge cases, and to judge when to productively offload cognition to a tool versus when to double down on the old-school, analog repetition that actually builds the neurons?
For colleagues thinking about doing the same. None of this requires being a programmer; it requires being willing to direct one.
These tools weren’t typed out by hand. They were built with Claude Code — an agentic coding tool you direct in plain language from the command line. The difference from a chatbot is control: instead of copying snippets out of a chat window, the agent reads your files, writes code, runs it, sees the errors, and fixes them, in a loop. You stay the author and editor; the agent does the typing. That is what vibe-coding means in practice, and it is why a studio teacher can ship working tools without a CS degree.
The single most important thing to understand is that these aren’t one app. They fall into a few buckets, and the bucket — not the idea — decides how, and whether, you host it.
| Kind of tool | Where it runs | Why |
|---|---|---|
| Static web | Any static host — Vercel, Netlify, GitHub Pages (free) | No saved data, no secrets; it just runs in the browser. |
| LLM-backed | A web page plus a tiny serverless function | The API key can’t live in browser code — the function holds it, proxies the calls, and caps spend. |
| Local app | A small Node / Python server on your own machine | The filesystem is the source of truth (Obsidian-compatible); nothing to host at all. |
| Web app + backend | A frontend host plus Supabase (Postgres, auth, storage) | Needs accounts and saved data — e.g. hundreds of students posting weekly. |
| Rhino-coupled | Distributed as a script, run inside Rhino / Grasshopper | It drives desktop software; an MCP server bridges the agent to Rhino. |
The “runs as” line under each tool above tells you which bucket it is in.
Any tool that calls an AI model has a key, and that key is money. It can never sit in code running in a student’s browser — someone will find it and run up the bill in a weekend. The fix is a thin server function between the student and the model that holds the key, limits the rate, and sets a hard spend cap. The same layer is where FERPA lives: the moment a tool stores student work or sends it to an outside model, you owe students an honest account of where it goes. There’s also an equity edge — a shared campus key is fair but costs the department; asking students to bring their own is cheaper but regressive.
The build method is the same stance I want students to learn: get something running, then deliberately try to break it — the weird input, the empty case, the edge it wasn’t designed for. The agent is fast and confident and often wrong, so its output is a first draft to be checked, never a final answer. Once you outgrow the chat box, the next concept is the agent harness: the scaffolding — memory, the tools it’s allowed to call, the rules it must follow — you wrap around a model to make its behavior predictable instead of improvised.
The practice behind the toolkit, some honest thoughts about AI in a studio, and where your work lives.
All Means Works is an umbrella design + research practice and platform by John Clark, an architecture educator at the UIUC School of Architecture. The 26 Summer AI Workshop is one initiative under it. The Design Toolkit — this site — is its set of studio instruments: tools for reading a site, keeping a reference library, growing a landscape, shaping and testing form, drawing, fabricating, and talking about the work. Each instrument supplies the logics, language, and data behind a judgment while leaving the judgment to the student.
The menus group every instrument by what it does — Site through Learn — or browse all tools on one page, grouped the same way and filterable by tag.
Some tools here compute real methods — solar geometry, span tables, climate files, pin-jointed forces. Others ask an AI to reason or write. Both kinds simplify the world to teach you something about it, and both can be wrong: a model is a smaller, more legible version of reality, never reality itself. Each tool tries to say out loud what it doesn’t know — read those notes, they are part of the lesson.
Nothing on this site is engineering, code compliance, or construction documentation. These are teaching instruments. Before anything is built, priced, or relied on, verify it with a licensed professional.
AI is a confident collaborator, and confidence is not correctness. The position this toolkit takes: the AI proposes, you decide. The tools are built with Claude Code in a “trust but verify” stance that values iteration and edge-case hunting over fluent-sounding answers, and the tools that grade your guesses — paint the daylight, draw the cut, predict the shadow — exist to sharpen your judgment, not to replace it. The most valuable thing you make here is not a rendering or a number; it is your own reasoning, on the record.
So use these instruments the way you’d use any instrument: with your eyes open, against your own intuition, and alongside humans — your critics, your classmates, your own hands. When a tool and your gut disagree, that disagreement is the most interesting thing in the room. Chase it.
Most tools run entirely in your browser — nothing you load leaves your machine. The ones that spend an AI call ask you to sign in first, and each signed-in run is logged to your own trace, visible only to you, so your process is something you can look back on and print for review.
Questions, corrections, or a tool you wish existed? jsclark2@illinois.edu
The tools above run in this toolkit and their own repos. Use the left menu — the same eleven words — to open them.