Revit, Dynamo & BIM Scripting

The first skill is spotting the right jobs. A task is a good candidate for a script when it is repetitive, rule-based, and done many times - when you could write down the rule in a sentence and then apply it mechanically. "Rename every sheet so the number comes before the name." "Set the Fire Rating parameter to 60 minutes on every wall of this type." "Renumber doors to match the room they open into." "Export every sheet in this set to PDF, named by sheet number and title." Each of these is a rule plus a lot of tedious repetition, and repetition is where humans slip and scripts do not.

Equally important is knowing what not to hand to a script. Anything that needs judgement on each item - deciding which wall should be fire-rated, or whether a door numbering clash matters - is design thinking, not a chore, and stays with you. The sweet spot is the mechanical part downstream of your decisions: you decide the rule; the script applies it faithfully a few hundred times. The figure opposite lays out six classic candidates, from renaming sheets to auditing which elements are missing data. Notice they share a shape - a clear rule, applied at scale.

There is also a hierarchy of risk hiding in that list, and it should shape how carefully you check. Scripts that only read - auditing missing data, listing every blank field, counting doors - cannot damage anything; the worst case is a wrong report, which you will notice. Scripts that write - setting parameters, renaming, renumbering - change the model, and a subtle error there propagates silently. Sort your candidate jobs into read-only and model-changing from the outset, because the second kind demands the copy-first discipline without exception, and the first kind is a safe place to build your confidence.

One more filter is worth applying before you automate anything: is the rule actually stable, or does it still have judgement baked into it? "Renumber doors to match their room" is stable - the rule holds for every door. "Fix the doors that look wrong" is not - it hides a hundred small decisions a script cannot make. If you cannot write the rule as a sentence a stranger could follow without asking you a question, it is not yet ready to hand to Claude; it is still design work, and it stays with you until the rule is clear.

Three routes let code drive Revit, and you can grasp all three quickly. Dynamo is Revit's visual programming tool, much like Grasshopper for Rhino: you wire nodes on a canvas to read and change the model, no typing required, and Dynamo can also run Python inside a node. pyRevit is a free add-in that lets you run Python scripts against Revit with far less boilerplate than the raw API - the friendliest route for a designer. The Revit API is the full programming interface underneath both, usually written in C# or Python; it is the most powerful and the most verbose. You rarely need to choose in advance - describe your task to Claude and ask which route suits it; often pyRevit or Dynamo-Python is the gentlest.

Here is a pyRevit-style script that tags every selected wall as reviewed by writing to its Comments parameter. Read the comments as much as the code:

# pyRevit: set the Comments parameter on every selected wall.
# TEST ON A COPY of the model first. Changes are wrapped
# in a Transaction so Revit can record and undo them.
from pyrevit import revit, DB

with revit.Transaction("Tag walls as reviewed"):
    for el in revit.get_selection():
        if isinstance(el, DB.Wall):
            p = el.LookupParameter("Comments")
            if p and not p.IsReadOnly:
                p.Set("Reviewed 2026-09")

Even unfamiliar, it reads plainly: for each selected element, if it is a wall, find its Comments field, and if that field exists and is editable, set it. The Transaction wrapper matters - in Revit, any change to the model must happen inside one, and it is what lets the change be recorded and undone. When you read a script Claude gives you, checking that model changes sit inside a Transaction is one of your first safety checks. Ask Claude to always include it and to explain what each guard - if p and not p.IsReadOnly - protects against.

Now the rule that this whole lesson is built around. Before a model-changing script ever touches live work, run it on a copy. In Revit that usually means detaching a copy of the central model or duplicating the file, opening that, and running the script there. You verify the result by hand on the copy - open a few of the walls you tagged, check the Comments actually say what you intended, confirm nothing else changed - and only when the copy is clean do you run the same script on the real model. The figure lays out this sequence: copy, run, verify, then and only then apply to live work. Undo is not a strategy; a copy is.

Reading the code is the other half. You are checking three things above all: that changes are wrapped in a Transaction; that the script targets the right elements and nothing more (a filter that is too broad will happily edit the whole model); and that any hard-coded value - a parameter name, a text string, a number - is exactly right, because a typo in a parameter name can silently do nothing or, worse, hit the wrong field. Here is a read-only counterpart in C# that simply counts doors - the safe kind of script, useful for a sanity check before and after a change:

// Revit API (C#): count the doors in the active document.
// Read-only - it changes nothing, so it is safe to run anywhere.
var doors = new FilteredElementCollector(doc)
    .OfCategory(BuiltInCategory.OST_Doors)
    .WhereElementIsNotElementType()
    .ToElements();

TaskDialog.Show("Count", $"Doors in model: {doors.Count}");

A neat professional habit: run a read-only count like this before and after a model-changing script. If you renumbered doors and the count changed, something went wrong - the before/after count is a cheap, powerful verification that needs no expertise, only the discipline to do it.

Put the pieces together into a repeatable, safe workflow and BIM automation stops being scary. You describe the chore to Claude in plain English, naming the exact parameter or naming rule and the elements it should touch. Claude drafts the Dynamo, pyRevit or C#, with comments and a Transaction where needed. You read it, checking the target is precise and the changes are wrapped safely. You save a copy of the model, run the script there, and verify by hand - spot-checking elements and comparing a before/after count. Only then does it run on live work, and even then you glance at the results. Each step is small; together they turn an hour of error-prone clicking into a minute of checked automation.

A few honest cautions keep you out of trouble. Revit, Dynamo, pyRevit and the API all change across versions, and a method that worked last year may have moved - so treat Claude's code as a strong draft to test in your version, not a guarantee. Claude does not know your model's specific families, shared parameters or naming conventions unless you tell it; feed it the exact parameter names and it writes far better code. And never run a script you cannot at least follow in outline - if you genuinely cannot tell what a line does, ask Claude to explain it before you run it, especially anything that deletes or overwrites.

The payoff, handled this way, is substantial and safe. The tedious, repetitive, error-prone layer of BIM production - the renaming, the parameter-filling, the exporting, the auditing - compresses into scripts you direct in plain English and trust because you tested them. That is time returned to design and coordination, which is where your judgement actually earns its keep. Claude supplies the tireless typist who never gets bored on the three-hundredth sheet; you supply the rule, the copy-first discipline, and the checked sign-off. It is your model, and your name on it, so the final verification is always yours.

There is a cultural benefit too, worth naming to a team that is nervous about all this. A studio that scripts its chores well does not become more careless; done properly it becomes more careful, because the tedium that used to breed slips is gone and attention is freed for the things that genuinely need a human. The renaming becomes consistent, the parameters complete, the exports uniform - and the hours saved go back into coordination, into checking the design, into the client. That is the honest promise of BIM automation with Claude: not fewer people, but the same people spending far less of their day on work that never deserved their judgement in the first place.