A Small Revit and LLM Experiment

I recently built a small proof of concept that lets a chat assistant talk to Revit through a controlled set of tools. Technically, it works: the assistant can understand a natural language request, choose an approved Revit tool, and return something useful from the live model. But building it left me with a more interesting question than whether it is possible. If we can let AI interact with Revit, when is that actually better than the tools and workflows we already have? That is the part I am still thinking through.

Keeping the Data Local and Secure

Another reason I wanted to build this from scratch was project information confidentiality. In many BIM environments, the model is not just geometry; it contains project names, locations, scopes, asset information, consultant input, and sometimes sensitive client or infrastructure data. Some projects are cautious about cloud-hosted models, let alone sending live model context to a cloud AI provider. For this proof of concept, I wanted the loop to be able to stay local: Revit, the plugin, and the LLM can all run on the same machine or local network. It can still be connected to a cloud AI API if needed, but that should be a deliberate choice rather than the default assumption.

The Boundary Matters

I did not want the assistant to freely “drive” a BIM model, and I did not want to send an entire Revit project into a chat window. The prototype is intentionally bounded. The LLM acts more like an interface than an authority, while the actual model interaction still happens through deterministic plugin code.

The assistant can ask approved tools to read the current context, find and summarise elements, inspect selected items, diagnose common visibility issues, or perform safe UI actions like selecting, zooming, clearing a selection, and opening a view. It does not create, delete, move, rename, or silently change model data.

That boundary matters, but not only because of risk. It also forces a more honest question about usefulness. If every Revit operation is wrapped in chat, the result is not automatically better. In many cases, it may just be slower, less direct, or harder to predict. The tool boundary helps separate where language is genuinely helpful from where a button, schedule, filter, view template, or purpose-built command is still the better interface.

Where I Feel Unsure

The part I am less sure about is the real workflow value. A lot of current AI discussion seems to start from the assumption that if AI can do something, we should make it do that thing. I am not convinced that is the right starting point for BIM or design technology.

Revit already has many precise ways to interact with model data. If someone knows exactly what they want, a direct command is usually better than a conversation. Asking a chat assistant to do something simple can easily become AI for the sake of AI usage, rather than a genuine improvement to the workflow.

Where it starts to feel more useful is when the user has intent, but not the exact path. Questions like “what am I looking at?”, “show me these elements”, “summarise this view”, or “why can’t I see this element?” are small, but they are real moments of friction in day-to-day Revit work.

The visibility example is the one that interests me most. “Why can’t I see this element?” can involve hidden elements, category visibility, view templates, phases, filters, crop regions, view range, links, design options, and more. A chat assistant does not need to replace expertise there, and it does not need to pretend to be intelligent in a broad sense. It may simply help someone walk through the right checks faster.

Still a Proof of Concept

I do not see this as proof that chat should become the main way we work in Revit. I also do not think “AI inside BIM” is automatically useful just because it is possible. This prototype is more of a way to test the boundary between novelty and actual value: what is meaningfully improved by a natural language layer, and what is better left as conventional software?

At the moment, the framing I trust most is: AI explains. Tools operate. Humans decide whether the interaction was worth having. For me, the question is no longer whether Revit can talk to an LLM. It can. The harder and more useful question is where that conversation genuinely helps the person doing the work, rather than simply adding AI to a workflow because we can.

ZCodeBundler + ZDecoder: Why I Built This

I built ZCodeBundler because copying code snippets into an LLM chat is annoying. It is fine when the question is about one isolated function, but real project questions usually need more than that. The useful files are often scattered across folders: a UI file, a code-behind file, a helper class, a project file, a README, or some configuration.

Inside an IDE, that structure is easy to follow because the project tree, file paths, tabs, and references are all there. In an LLM chat, that structure disappears unless I prepare it manually. If I paste too little, the answer becomes generic. If I paste too much, the chat becomes messy. If I upload files one by one, the process becomes tedious. ZCodeBundler came from wanting a cleaner middle ground.

The Gap I Wanted to Solve

Agent-style coding tools are powerful, especially when the job is repo-level: reading files, making edits, running commands, and working through a task from end to end. But not every coding conversation needs that. A lot of the time I just want to ask for an explanation, get a design review, understand a bug, or talk through a refactor before touching the code.

For those cases, a normal chat interface is often easier, more transparent, and more economical. The problem is context. Chat works well when the model can see enough of the project, but manually preparing that context is the painful part. ZCodeBundler is designed for that gap: bringing the relevant part of a project into a chat without needing to hand over the whole repository.

What ZCodeBundler Does

ZCodeBundler lets me select files and folders from a project, review what I am including, and export everything into one readable .zcb.txt file. That bundle keeps the selected files organised with their names, paths, types, and contents preserved, so the LLM sees related project files rather than disconnected snippets.

That small difference matters. When I upload a well-prepared bundle, the conversation feels much more grounded. I can ask for a review, an explanation of how files work together, or a diagnosis of why a design feels messy, and the response is usually more specific because the context is clearer.

Why It Works Well

The useful part is not that the format is clever. It is that it removes a repeated piece of friction. Instead of spending time copying files, adding labels, and explaining where everything came from, I can prepare the context once and start the actual conversation sooner.

It also helps me stay intentional about what I share. I still choose the files because I know what I am asking about, and I can review the selection before creating the bundle. That keeps the context focused rather than dumping an entire project into the chat just because it is possible.

What I Learned

Building ZCodeBundler reminded me that better AI-assisted work is not only about the model. It is also about the shape of the input. A good prompt helps, but a clear set of relevant project files can change the quality of the whole conversation.

For my own workflow, this has become surprisingly useful. It makes chat-based LLM work feel closer to discussing a real part of the project, not just asking questions about pasted fragments. ZCodeBundler does not make the LLM smarter; it simply gives it better context to work with.

And for many coding conversations, that is exactly what was missing.

Current Project

ZCodeBundler is still evolving. The GitHub repository remains the source of truth for the current feature set and project status.

View ZCodeBundler on GitHub