We're All Software Designers Now

Yesterday I ran an advanced workshop on Claude Code for the Revit Add-in Academy. The goal was to walk through a real workflow: plan a tool, generate a CLAUDE.md file, hand it off to Claude Code, and get a working Revit add-in out the other end. No hand coding. We built a room data reporter from scratch, start to finish, in about an hour.

What came out of that session wasn’t just a working add-in. It was a pretty clear illustration of what using AI for development is actually starting to look like, and why the copy-paste workflow most people are using today is only the beginning.

If you’ve used AI for coding at all, you know the loop. You describe what you want. The AI generates some code. You copy it and paste it into Visual Studio or Launchpad. You test it, go back, and tweak the prompt. Then you copy it again. At some point, you lose track of where you are. The session ends, and you’re not sure you made that much progress.

The bottleneck there isn’t writing code. It’s the constant context-switching between thinking about what you want and doing the work of producing it. Those are two very different jobs, and for a long time, one person had to do both.

Claude Code changes that. Not because it writes better code than the copy-paste workflow, though it does. But because it separates those two jobs in a way that actually holds. The idea is the hard part now. Claude handles the rest.

What “Building” Means Now

In a traditional software team, the product owner and the developer occupy very different spaces. The product owner defines the problem: what the tool needs to do, who it’s for, the edge cases, and what done looks like. They write user stories, answer questions, and make scope decisions. They do not write code. The developer takes that definition and handles production: choosing the architecture, writing the classes, wiring up the UI, and debugging what breaks. Two distinct roles, both essential, neither doing the other’s job.

For most AEC professionals building Revit tools, one person has been doing both. You define what you want, and then you produce it yourself. It’s a bit like a design/build firm: one entity handles both design and construction. There are advantages to that model, but it also means the same people are making decisions about what to build and then immediately getting into the details of building it. Context-switching is constant, and the two jobs compete for attention.

That’s a lot to hold at once, and it’s one reason the copy-paste AI workflow only gets you so far. You’re still the developer. You’re just getting some help writing the code.

Claude Code takes the developer seat. You describe the tool you want to build, Claude asks clarifying questions about edge cases and implementation details, you answer them, and then it builds. It creates the files, writes the code across all the necessary classes, runs a self-review, and commits the branch to GitHub. You come back and evaluate what it produced. That’s the product owner workflow, with Claude filling the developer role.

In a recent session building a Revit room data reporter, the back-and-forth planning stage surfaced things worth thinking through: should the grid allow inline editing or be read-only? Should selecting a room in the data grid zoom the active view to that room? Should batch updates wrap in a single undo transaction? These are product decisions. None of them requires you to know how a WPF data grid works.

For anyone who has held a product owner role, this is familiar territory. For anyone who hasn’t, it’s worth naming clearly: the skill being asked for here is problem definition, not code production. Those are learnable in very different ways, and for many AEC professionals, the former is already much closer to what they do every day.

The Time Constraint Reframe

One thing to know about Claude Code: it’s not super fast. Processing a codebase, thinking through a prompt, writing files in parallel, and doing a self-review pass takes time. For a moderately complex Revit add-in, you might wait ten to fifteen minutes for a first pass.

That sounds like a downside until you stop thinking about it as something you have to watch.

Claude Code has a Remote Control feature that lets you monitor and direct a session from any device, including your phone. Start a session on your desktop, then go do something else. Check in when you have a moment. Give it direction, send it off again. The session keeps running whether you’re watching or not.

In practice, this means Claude Code works while you’re in a meeting. While you’re at a kid’s soccer game. While you’re doing laundry on a Saturday morning. The actual throughput isn’t measured in minutes per session; it’s measured in what gets built across a weekend while you were doing other things.

That’s fundamentally different from the productivity most developers are used to. It’s not about typing faster. It’s about running work in parallel with the rest of your life.

What You Still Need to Know

None of this means you can walk in cold and get a working add-in on the first try. In yesterday’s Claude Code workshop, the room data reporter produced some errors, and working through them required real knowledge.

The first was a type-casting error that only appeared at runtime. Claude had collected all spatial elements from the model, including both rooms and areas, and then tried to cast them all as rooms. In a model that contains areas, that fails. Catching that error, understanding why it was happening, and knowing how to fix it required familiarity with how the Revit API handles spatial elements. Claude didn’t flag it. The model did, when the add-in crashed.

The second was a structural issue. Claude organized the generated files into a subfolder inside the Visual Studio solution. That’s a reasonable choice in general, but it conflicted with the Revit add-in's configuration, which expected the DLL at a specific path. The add-in file had to be manually corrected before Revit would load it. Again, not a hard fix, but one that required knowing what to look for.

The knowledge that matters is shifting. Less about whether you can write a FilteredElementCollector from scratch, more about whether you understand enough to know when something is wrong and why. That’s a different bar, and in some ways a more interesting one. It rewards people who understand systems and how things connect, not just people who can produce syntax.

Put it another way: Claude Code doesn’t lower the ceiling on what you can build. It raises the bar on what you need to understand to build it well.

The Upstream Shift

For AEC professionals who have ideas for tools but have always felt like coding was the barrier: the barrier is lower than it’s ever been, but problem definition matters more than ever. If you can describe clearly what you want, articulate the edge cases, and evaluate whether the output is correct, you can build. The production work is handled.

For developers who already know how to code, the value you bring is moving upstream. The people who will get the most out of tools like Claude Code are the ones who can think like a product owner, scope a problem well, and know when the output needs to be sent back for another pass. That’s not a lesser skill set. It’s a different one.

Knowing what to build was always the hard part. Now it's the only part.