Coding Terms Every AEC Pro Should Know in 2026

You told Claude to write a Revit script. It worked. You ran it, sheets got renamed, and you felt like a wizard for about forty-five seconds. Then you tried to change something, and the error message read like a ransom note written in another language.

This is the new normal in AEC. The code is the easy part now. AI can generate it faster than you can describe what you want. But the vocabulary around the code, the terms that show up in error messages, documentation, and every YouTube tutorial, is what actually trips people up.

I wrote a companion post on AI terminology last week. This one covers the other side: the programming and software development terms you'll run into when you start vibe coding, building Revit add-ins, or just trying to understand what the AI wrote for you.

The format is the same as the AI terminology post. Each term gets a definition, an AEC-specific example, and a note on why it matters. There are six sections, roughly ordered from "stuff you see first" to "stuff you appreciate later."

Reading Code: What You're Looking At

These are the terms that show up the moment you open a code file. You don't need to master all of them before writing your first script, but recognizing them keeps you from feeling lost when Claude hands you 200 lines of C#.

Syntax

The rules that define how code must be written in a given language. Every semicolon, curly brace, and parenthesis has to be in the right place, or the code won't run.

Example: In C#, every statement ends with a semicolon. Forget one, and Visual Studio lights up with red squiggles before you even try to run anything. It's like forgetting a period at the end of a sentence, except the computer refuses to read the rest of the paragraph.

Why it matters: When AI generates code for you, syntax errors are rare. When you start editing that code yourself, they're the first thing you'll hit. The good news is that your code editor catches most syntax errors instantly.

Variable

A named container that holds a value. You create a variable, give it a name, and store a value in it, such as a number, a piece of text, or a reference to a Revit element.

Example: string sheetNumber = "A-101"; creates a variable called sheetNumber and stores the text "A-101" in it. Later in the code, you can use sheetNumber wherever you need that value instead of typing "A-101" over and over.

Why it matters: Variables are the most fundamental building blocks of code. Once you understand that a variable is just a labeled box holding a value, large chunks of any script start making sense.

Method (a.k.a. Function)

A named block of code that performs a specific task. You "call" a method by name, and it runs its instructions. Methods can accept inputs (called parameters) and return a result.

Example: wall.get_Parameter(BuiltInParameter.WALL_BASE_OFFSET) calls a method named get_Parameter on a wall element. You pass in the parameter you want, and it returns the value.

Why it matters: Methods are how code stays organized. Instead of writing the same 20 lines every time you need to do something, you put those lines in a method and call it by name. When you see parentheses after a word in code, you're almost always looking at a method call.

Class

A template that defines a type of object, including what data it holds and what it can do. You don't use the template directly. You create instances of it.

Example: In the Revit API, Wall is a class. A specific wall in your model is an instance of that class. The class defines the properties of a wall (height, base offset, type) and the operations you can perform on it (delete, move, get geometry). Every wall in the model follows the same blueprint but has its own values.

Why it matters: The Revit API is organized entirely around classes. When you see documentation for FilteredElementCollector or Transaction, those are classes. Understanding that a class is a template and an instance is a specific thing built from that template clears up a lot of confusion.

Namespace

A way of organizing classes into groups so their names don't collide. Think of it like a folder structure for code.

Example: The Revit API organizes its classes into namespaces such as Autodesk.Revit.DB (for model elements like walls and floors) and Autodesk.Revit.UI (for interface things like buttons and dialogs). Both could have a class called Selection, but the namespace tells you which one you mean.

Why it matters: Those using statements at the top of every C# file are importing namespaces. When Claude generates a Revit script and writes Autodesk.Revit.DB; at the top, it tells the compiler, "I'm going to use classes from this namespace, so don't make me type the full path every time."

Comment

Text in code that exists for human readers only. The computer ignores it completely. In C#, single-line comments start with //.

Example: // Get all walls on Level 1 sitting above a block of code tells you what the next few lines do. You'll also see comments that explain why something was done a certain way, which is often more useful than explaining what it does.

Why it matters: When AI generates code, it usually adds comments. Read them. They're often the fastest way to understand what each section is doing. And if you modify the code later, updating the comments is how you leave a trail for your future self.

Data Types

The classification that tells the computer what kind of value a variable holds. The three you'll see most often: string (text), int (whole numbers), and bool (true or false).

Example: string projectName = "Library Renovation"; stores text. int floorCount = 3; stores a whole number. bool isExterior = true; stores a yes/no value. Try to put text into an int variable, and the compiler will stop you.

Why it matters: Type mismatches are a common source of errors when you start modifying AI-generated code. If a method expects an int and you hand it a string, the code won't compile. Knowing the basic types helps you read error messages that say things like "cannot convert string to int."

The Development Environment

These are the tools you work in and the things that happen when you press the green button. While the previous section was about reading code, this one is about the place where code gets written, tested, and turned into something that actually runs.

IDE (Integrated Development Environment)

The application where you write, edit, test, and debug code. It combines a text editor with tools for running code, catching errors, and managing files.

Example: Visual Studio (VS) is the IDE most Revit add-in developers use. It provides syntax highlighting (color-coded text so you can tell variables from methods from keywords), auto-complete suggestions, error detection, and a built-in debugger. You could technically write C# in Notepad, but that's like drafting in MS Paint.

Why it matters: If you're building Revit add-ins, Visual Studio is where you'll spend your time. Getting comfortable with the basics of the IDE, how to open a project, where errors show up, how to run your code, is step one.

Solution / Project

In Visual Studio, a project is a single unit of code files that compile into a single output (e.g., a DLL). A solution is a container that holds one or more related projects.

Example: Your Revit add-in might be a single project within a solution. If you later add a shared utilities library, that's a second project in the same solution. The solution file (.sln) is what you double-click to open everything in Visual Studio.

Why it matters: When someone says "open the solution," they mean the .sln file, not a specific code file. When you download a sample Revit add-in from GitHub, look for the .sln file first.

Compile / Build

The process of turning your human-readable code into a file that the computer can actually execute. In C#, that means converting your .cs files into a DLL.

Example: You write a Revit add-in in C#. You press Build in Visual Studio. If there are no errors, it produces a .dll file that Revit can load. If there are errors, it tells you exactly what's wrong and which line it's on.

Why it matters: Build errors are the kindest errors you'll encounter. They happen before your code ever runs, and Visual Studio points you right to the problem. These are the red squiggles and error messages in the Error List window.

DLL (Dynamic Link Library)

A compiled file that contains code which other programs can load and use. This is the actual output of building a Revit add-in.

Example: When you build your Revit add-in project, Visual Studio produces a .dll file. You point Revit at that DLL through a .addin manifest file, and Revit loads your code when it starts up. The .dll is your add-in.

Why it matters: You'll hear people say "drop the DLL in your add-ins folder." Now you know what they mean. The DLL is the compiled, ready-to-run version of your code.

Runtime

The period when your code is actually executing, as opposed to when you're writing it or compiling it. Also refers to the environment in which your code runs.

Example: Your Revit add-in compiles without errors. You start Revit, click your button, and the code runs. That's runtime. A compile-time error is caught while building. A runtime error occurs while the code is actually running in Revit.

Why it matters: The distinction between compile-time and runtime comes up constantly. "It compiles fine but crashes when I run it" is a sentence you'll say more than once. The next section is entirely about what happens when things go wrong at runtime.

Debug / Breakpoint

Debugging is the process of finding and fixing problems in code. A breakpoint is a marker you set on a specific line that tells the program to pause there so you can inspect what's happening.

Example: Your add-in crashes when processing a specific wall. You set a breakpoint on the line that reads the wall's parameters, run the add-in in debug mode, and when it pauses, you can hover over variables to see their values. You discover one wall has a null parameter that your code didn't account for.

Why it matters: Debugging is the single most valuable skill you can develop as a new coder. It turns "I have no idea why this broke" into "I can see exactly what happened on line 147." Learning to use breakpoints in Visual Studio will save you more time than any other technique.

When Things Break

Your code compiled. Visual Studio didn't complain. You pressed the button, and something still went wrong. This section covers the three terms you'll encounter in that moment, in the order you'll encounter them.

Runtime Error

An error that occurs while the program is running, after it has already compiled successfully.

Example: Your script iterates through every room in the model to read its area. It works fine until it hits a room that was never properly bounded. The area value doesn't exist, and your code didn't anticipate that. The script crashes mid-execution.

Why it matters: Compile-time errors are the ones Visual Studio catches with red squiggles before you run anything. Runtime errors are sneakier. The code looks fine, builds fine, and then blows up when it encounters an unexpected situation. Understanding this distinction is the first step toward writing more resilient code.

Exception

The specific mechanism C# uses to signal a runtime error. When something goes wrong, the system "throws" an exception, which is an object containing details about what happened.

Example: NullReferenceException is the one you'll see first and most often. It means your code tried to use something that doesn't exist, like reading a parameter from a Revit element that was deleted, or accessing a variable that was never assigned a value. Other common ones include InvalidOperationException (you tried to do something that isn't allowed in the current state) and ArgumentException (you passed a bad value to a method).

Why it matters: The exception name is your first clue when something breaks. Instead of a generic "error," C# tells you the category of the problem. Learning to read exception names is like learning to read error codes on mechanical equipment. You don't need to memorize them all, but the common ones become second nature fast.

Stack Trace

The trail of method calls that led to an exception. When an error occurs, the stack trace shows you the exact sequence of methods that were running, from the most recent call back to the starting point.

Example: Your add-in crashes, and the stack trace shows: RenameSheets() → ProcessSheet() → GetSheetNumber() → NullReferenceException at line 34. You now know the crash happened inside GetSheetNumber, which was called by ProcessSheet, which was called by RenameSheets. Line 34 is where you look first.

Why it matters: Stack traces look intimidating, but they're a roadmap. Read from the top. The first line that references your code (not the Revit API or system libraries) is where the problem lives. Paste the stack trace into Claude, and it can usually tell you exactly what went wrong.

Managing and Sharing Code

The moment you have more than one version of your code, or more than one person working on it, you need a system. These terms cover how code gets saved, tracked, and shared.

Git / Version Control

A system that tracks every change to your code over time, letting you see what changed, when, and by whom. Git is the most widely used version control tool. GitHub is a cloud platform for hosting Git repositories. Git is the tool. GitHub is where people put their code so others can access it.

Example: You make a change to your Revit add-in that breaks something. With Git, you can see exactly what you changed, compare it to the previous version, and roll back to the working state. Without Git, you're renaming folders "MyAddin_v2_final_FINAL."

Why it matters: Even if you're working alone, Git saves you from yourself. It's an unlimited undo history for your entire project. Once you start using it, you'll wonder how you ever coded without it.

Repository (Repo)

The folder where Git tracks all the files and their complete change history. A repo can live on your computer (local) or on a hosting service like GitHub (remote).

Example: The ArchSmarter Revit MCP Server is available in a public GitHub repository. Anyone can view the code, download it, or suggest changes. Your own Revit add-in project would typically be in a private repo.

Why it matters: When someone says "check the repo" or "it's on GitHub," they're pointing you to a repository. It's the single source of truth for a codebase.

Commit

A snapshot of your code at a specific point in time, saved with a short description of what changed. A commit is Git's unit of saved work.

Example: You fix a bug in your sheet renaming tool and commit with the message "Fix crash when sheet number is empty." Tomorrow, you add a new feature and commit again. Each commit is a checkpoint you can return to.

Why it matters: Commits are how you build a history of your project. Good commit messages ("Fix null check on room area") make the history useful. Bad ones ("updated stuff") make it useless. Write messages that explain what changed and why.

Branch

A parallel version of your code where you can make changes without affecting the main codebase. When the changes are ready, you merge the branch back into the main branch.

Example: Your Revit add-in works fine. You want to add a new feature for batch exporting sheets without risking breaking what already works. You create a branch called feature_batch_export, build the feature there, test it, and merge it back into the main branch when it's solid.

Why it matters: Branches let you experiment without consequences. Even as a solo developer, creating a branch before making big changes gives you a safety net. If the experiment goes sideways, your main code is untouched.

Pull Request

A proposal to merge changes from one branch into another. It's a review step where you (or someone else) can look at all the changes before they're accepted.

Example: You finish your batch export feature on its branch. You open a pull request on GitHub that shows every line you added or changed. A colleague reviews it, spots a missing error check, you fix it, and then the pull request gets merged.

Why it matters: Even if you're working solo, pull requests are useful as a self-review checkpoint. They force you to look at all your changes in one place before merging. And if you ever contribute to an open-source project, pull requests are how you submit your work.

Clone

Copying a remote repository to your local machine so you can work with the code.

Example: You find a useful Revit add-in on GitHub. You clone the repo, which downloads the entire project and its history to your computer. Now you can open the solution in Visual Studio, build it, run it, and modify it.

Why it matters: "Clone the repo" is the first instruction in almost every open-source project's README. It's how you get the code onto your machine so you can start working with it.

Open Source

Software whose source code is publicly available for anyone to view, use, modify, and distribute, usually under a specific license that defines the rules.

Example: The Revit MCP Server I published on GitHub is open source. Anyone can download it, learn from it, modify it for their own use, or contribute improvements back to the project.

Why it matters: Open source is how most of the development world shares knowledge. NuGet packages, GitHub examples, and community Revit tools are often open source. Knowing this means you have access to a massive library of working code you can learn from and build on.

Packages and Dependencies

Nobody writes everything from scratch. These terms cover how you use other people's code and what happens when your project relies on it.

Package / Library

A bundle of pre-written code that you can add to your project to get functionality without building it yourself. A library is the code itself. A package is how it gets distributed and installed.

Example: Instead of writing your own CSV parser from scratch, you install the CsvHelper package. It handles all the messy details of reading and writing CSV files, and you use it with a few lines of code.

Why it matters: Packages are how developers avoid reinventing the wheel. When AI generates code that includes an Install-Package instruction, it's telling you to pull in a library that provides functionality your code needs.

NuGet

The package manager for .NET development. It's the system that lets you search for, install, and update packages in Visual Studio.

Example: You need to read Excel files in your Revit add-in. You open the NuGet Package Manager in Visual Studio, search for "EPPlus," click Install, and the library is added to your project along with everything it depends on.

Why it matters: If you're building Revit add-ins in C#, NuGet is how you'll install almost every third-party library. The NuGet tab in Visual Studio is a tool you'll use regularly.

Dependency

A package or library that your code requires in order to work. If your project uses CsvHelper, then CsvHelper is a dependency.

Example: Your Revit add-in depends on the Revit API libraries (obviously), plus maybe a JSON library and a logging library. Each of those is a dependency. Dependencies can also have their own dependencies, which is where things get interesting.

Why it matters: "Dependency hell" is what happens when packages need different versions of the same thing. NuGet manages this for you most of the time, but when builds fail with cryptic version conflict errors, dependencies are usually the culprit.

SDK (Software Development Kit)

A collection of tools, libraries, documentation, and examples that lets you build software for a specific platform.

Example: The Revit SDK is a package from Autodesk that includes sample code, API documentation, and everything you need to start building add-ins. The .NET SDK is what lets you compile C# code at all.

Why it matters: When a setup guide says "install the SDK," it's asking you to install the full development toolkit for a platform. For Revit development, that means both the .NET and Revit SDKs.

Writing Better Code

These terms separate "it works" from "it works, and I can still understand it next month." None of these are things you need on day one, but they're concepts that improve every piece of code you write once you start applying them.

Refactoring

Restructuring existing code to make it cleaner, more readable, or more maintainable without changing what it does.

Example: Your Revit script has a 200-line method that collects walls, filters them, reads parameters, and writes results. It works, but it's a nightmare to modify. You break it into four smaller methods: CollectWalls(), FilterByLevel(), ReadParameters(), and WriteResults(). Same behavior, much easier to understand and change.

Why it matters: Code written by AI or in a rush tends to work but can be hard to modify later. Refactoring improves your code, making it easier to maintain in the future. This is a skill worth developing, even if you're primarily a vibe coder.

Technical Debt

The accumulated cost of shortcuts, quick fixes, and "I'll clean this up later" decisions in a codebase.

Example: You hard-code a file path, skip error handling, and copy-paste the same block of code in three places because it's faster right now. Each shortcut is a small debt. Six months later, the file path changes, an unhandled error crashes the add-in, and you have to fix the same bug in three places. That's the interest on the debt.

Why it matters: Every coder accumulates technical debt. The key is being aware of it. When you skip something because "it works for now," make a note. Vibe coding generates technical debt quickly because the AI optimizes for getting something working, not for long-term maintainability.

DRY (Don't Repeat Yourself)

A principle that says every piece of knowledge in your code should exist in exactly one place. If you find yourself copying and pasting the same logic, extract it into a method or variable.

Example: You have the same five lines for starting and committing a Revit transaction in twelve different places. If the transaction logic needs to change, you have to find and update all twelve. DRY says: put those five lines in a single RunInTransaction() method and call it from all twelve places.

Why it matters: DRY is the first code quality principle most people learn, and for good reason. It reduces bugs (fix it once, fixed everywhere), makes code shorter, and makes changes less risky. When reviewing AI-generated code, the first thing to look for are repeated blocks of code.

CRUD (Create, Read, Update, Delete)

The four basic operations you can perform on data. Almost every software interaction maps to one of these four actions.

Example: In a Revit add-in: Create a new wall, Read a room's area parameter, Update a sheet's title block, Delete an unused view. When someone says "it's a CRUD app," they mean the software is primarily about creating, viewing, editing, and removing records.

Why it matters: CRUD is a mental framework that helps you categorize what any piece of code is actually doing. When you're staring at an unfamiliar script, asking "is this creating, reading, updating, or deleting something?" usually clarifies the purpose quickly.

Patterns

Proven, reusable solutions to common problems in software design. They're not code you copy and paste. They're structural approaches with names that developers use as shorthand.

Example: The MVVM pattern (Model-View-ViewModel) is what you'll use when building WPF dialog boxes for Revit add-ins. It separates your data (Model), your interface (View), and the logic connecting them (ViewModel). Another common one is the Observer pattern, which the Revit API uses for events: "notify me when the user selects something." Singleton is another common pattern.

Why it matters: You don't need to memorize a catalog of patterns. But when someone says "use MVVM for that dialog" or Claude generates code that follows a pattern, knowing that patterns are named solutions to known problems helps you understand why the code is structured the way it is, not just what it does.

A Final Note

This vocabulary isn't something you study and then graduate from. You pick it up by doing. The first time you see a NullReferenceException, you'll look it up. The tenth time, you'll fix it without thinking. The twentieth time, you'll write code that prevents it from happening.

The terms that matter most are the ones connected to whatever you're building right now. If you're writing your first Revit add-in, focus on Section 1 and Section 3. If you're downloading projects from GitHub, Section 4 is your starting point. Nobody needs all 31 of these on day one.

If you want to go from vocabulary to working code, the Revit Add-in Academy is where that happens. We start with the fundamentals and build real tools that automate real workflows in Revit. Everything in this article becomes second nature along the way.