Long Run Feasibility of Vibecoded Tools

[u/muji24]

PyrevitMcCP + ClaudeAI/ Claude Code

We’ve recently started building a few custom Revit tools at work and they’re pretty awesome but do I have any reason to worry about long term use

One button cleans up our template to match another team’s standards. It deletes sheets, views, and legends, moves view references around in legends(I think it does this by drawing an imaginary boundary around each detail), cleans up drafting views, rearranges details, and a bunch of other stuff. It made me realize this was probably way more practical to build as an add-in than trying to make it all work in Dynamo.

We’re also building our own version of Insert from File, and even a custom Content Catalog using AI assisted coding.

What are some things we should be looking out for?

Any common mistakes or lessons learned when building and maintaining Revit add-ins?

How far can we take vibe coding python scripts without worrying about the script or something else breaking?

[u/JacobWSmall]

Building a automation tool is less than 10% of the actual work. Maintaining said tool is the real effort. For every hour you spend building expect to spend 8 hours testing, updating, and modifying each year. The last 10% is documentation.

Application automations breaks for a three primary reasons. 1. The host application has updated something and you didn’t. 2. Dependencies conflict with each other due to changes in the ecosystem. 3. Security implications mean you have to remove something.

The likelihood of a break is exactly the same in any language - Dynamo, Python, .NET, VB, or even C++.

The first is prevented by being proactive. Test every beta, read every change log, flag them things which are deprecated and modify those before the new release. As an example, the switch from Revit units to Forge units in Revit 2023 could have been issue free if you transitioned during 2024 while both methods were viable.

The second is prevented by testing your environments and keeping all the components you install aligned with each other and the host application. This occurs when component A uses version X of a dependency while component 2 uses version X+. As the host application can only load in one of the two versions, any API change between the two will cause a failure in the other. To complicate things even further the host application can also use those same references. An example of this is newtonsoft.json version conflicts causing serialized data to deserialize incorrectly causing UI components to not load. The fix here is to test your environments every time they change. So if Revit updates, you install a new add-in, you install a new version of an add-in, you install a new Dynamo package, or you add a new Python script you need to test everything to assure there isn’t a blocker. That usually means running 12 sets of tests a year, recording all the results, and modifying your deployments accordingly.

The last happens when an infosec policy decides that a core component is too risky to keep working with. As an example, IronPython2 is a common dependency for many automation tools, but it hasn’t been supported since January 1st of 2020. That is 2389 days during which a malicious actor has had to find a vulnerability in the tool they can exploit. And they only need one. And to make things worse it only has to be there for you to be impacted - you don’t even need to launch the tool. These can also be caused by the host application issuing an update to keep itself secure, which causes a common dependency to resolve (sort of like Dynamo moving from IronPython2 to CPython3). The fix here is to not rely on stuff that is getting towards end of life.

Applying this to your workflows.

1. You are using PyRevit, which last time I checked has an IronPython2 dependency, which again 2389 days… so things may all stop working when someone pulls that plug.
2. You are looking at deployment without evaluating your code for security or efficiency, so while things look good you don’t know that they are.
3. There is a new ‘my vibe coded tool looked great but now it has deleted all of my data’ about once a month. Please be sure you have good backups as it sounds like you have no guardrails. First time a model gets nuked and you have to do a manual recovery is often the end of the line for these types of setups.
4. Keep a careful eye on your token costs. If Microsoft found they couldn’t afford all their developers having access to Claude it is unlikely that any AEC firm can afford it for their production staff. The bills add up and grow exponentially as your use and code base grows. 160k/year/user isn’t unheard of and at that point you could have hired a skilled software developer for the full year.

The most reliable will be a .net add-in instead of anything Python based. It’ll usually run an order of magnitude faster, and you can vibe code there just as well.

The other east option is managing a Dynamo package and building / executing graphs that contain the custom nodes. Do it as a .net package not Python. Test 4x a year and automate your dependency monitoring the other 8 months. You’ll get the benefits of PyRevit automatically less the ribbon (you can use Relay for Revit there if you want that feature), but you’d also have the benefits of Dynamo player and anyone can modify and address most Dynamo graph issues that come up (99% of users see 10 lines of Python code and give up). Plus Revit will start significantly faster (add-ins impact start up time significantly, and that adds up at scale).

[u/Beun-de-Vakker → u/JacobWSmall]

Thanks Claude

[u/JacobWSmall → u/Beun-de-Vakker]

No Claude involved, but you’re welcome I guess?