Is Archicad at a disadvantage for AI-assisted scripting compared to Revit and Rhino?

[Steffen]

I’m wondering whether Archicad is at a disadvantage for AI-assisted scripting compared to Revit. My impression is that the Revit API (and Dynamo) has far more public documentation and examples, which makes AI coding assistants much more reliable there. GDL is also a fairly niche language, and the Archicad Python API seems to cover fewer element types and operations so far. Is this something others have run into, or is the Archicad Python API maturing quickly enough that this gap is closing? And are there any workflows people use to get AI tools working well with GDL or the Python API?

Operating system used: Windows

[Mathias Jonathan]

For the python API, you can look into the Opensource TAPIR addon that will give you a lot of access to archicad command, and you can ask (on Github or discord) new commands.

Archicad objects are coded in GDL, and AI can easily code with it, I would say on the contrary that archicad has a big advantage on that side.

[Patrick M]

I think it depends on the bot used, and the level applied. I've had great results getting amazing parametric gdl and even parameter lists and values out of claude, even at a low level. Gemini and ChatGPT both suck, and i've wasted way too much time trying to get them to work.

[vlahtinen]

I would say yes, there’s a disadvantage.

I don’t think it’s only about the lack of documentation and examples. It’s also because the Archicad C++ API is much harder to understand, even for humans, than Revit’s object-oriented C# API.

GDL has also fallen behind as a scripting language. Without real functions, local scope or more advanced data structures, the language itself works against both the human and the AI.

There’s just so much technical debt that I worry Archicad will struggle to keep up with the industry.

[Mathias Jonathan]

Did you try to use Claude code with Archicad? Everybody can create custom addon easily (without any code knowledge), and if you have a little curiosity , you can also create complex objects in gdl, with an interface easily used by human. Coupled with a little knowledge of Archicad, linked to custom model view options, there is no limits at the moment... What kind of limitations do you see in Archicad objects ? What kind of object do you need that are not possible because of GDL? 

[Steffen]

I am not at all advanced in coding. It was just an impression that the "architecture" of Archicad"  had some disadvatages compared to Revit. 
For example Chatgtp. seem to be able to transform an 2D plan into BIM in no time. Havent seen any youtube examples of the same workflow with Archicad. 
Maybe I am wrong--- ? 

[Mathias Jonathan]

I can’t speak for ChatGPT, but with an AI coding tool like Claude Code you can already do a lot with Archicad. There are limitations, yes, but they have nothing to do with a 2D-to-BIM workflow specifically.

The key point is that the “translation” part (reading a 2D plan and understanding where the walls, doors, windows, etc. are) isn’t done by Revit. It’s done by the AI. Revit only receives the result and creates the elements. Revit simply has a much larger ecosystem of consultants, trainers and family creators, so naturally there’s more content and more examples online. We have some, but you'll find those on linkedin or on Tapir discord.

On the Archicad side, the modelling part is accessible through the JSON/Python API, and with Tapir (an open-source add-on that extends this API) most of what’s missing is either already available or can be added quickly. So the same workflow is possible: the AI interprets the plan, then sends commands to Archicad to create the model.

You’re right that there are fewer YouTube examples for Archicad, but that reflects the size of the ecosystem around Revit, not a limitation of Archicad’s architecture.

NB: A lot of people using Claude Code don’t know how to code, and that’s not a problem (though knowing how to code does help for GDL scripting).

---

[vlahtinen]

I didn’t mean that it couldn’t be done. I meant how reliably, verifiably and maintainably it can be done, and there’s a clear disadvantage.

Of course AI can bridge some of the gaps in the APIs, but it’s still like building a house on a shaky foundation. The C++ API is cumbersome to use: modifying an element requires setting masks for the changed fields, part of its data lives in separate memo structures, memory is managed manually through handles, and it uses Graphisoft’s own data types instead of the standard library. A lot of steps where things can go wrong.

For me the biggest limitation with GDL objects is that GDL parameters and Archicad properties don’t talk to each other. There are two separate places to enter data on an object, and there’s no proper link between them. That’s a good example of what I mean by technical debt: the property system was added on top of the old GDL object parameters without really integrating the two.

[Mathias Jonathan]

Fair point, I understand better what you mean now.

On paper, I agree the C++ API isn’t the most pleasant to work with. In practice though, my experience has been quite different. Without any C++ knowledge, I was able to create a lot of new commands for Tapir with Claude. The Claude bot connected to the Tapir GitHub/Discord can also create new commands in minutes from a plain-text description, which makes things much easier from the user’s side.

Of course there can be bugs, tests and retries along the way, but with BIM software where so many elements are interconnected, that seems fairly normal to me. If you haven’t tried creating commands yet, it might be worth a go. You may be surprised by how far you can get. It also helps that Tapir is maintained by a former Graphisoft developer, who set up the Claude integration on GitHub, so the code is reviewed by someone who knows the API well.

You’re right that the property system was added on top of GDL parameters rather than fully integrated with them. That said, I suspect keeping them separate is partly a performance choice, because linking them is technically feasible. This add-on, for example, already does it: https://github.com/kuvbur/AddOn_SomeStuff

That limitation isn’t really tied to GDL or its age, though, but to the software as a whole: permanent synchronization is expensive in terms of resources. If I’m not mistaken, from the feedback I’ve regularly read, Revit files tend to slow down much earlier than Archicad files and need to be split up quite quickly. Seen that way, Graphisoft’s choices seem fairly consistent to me.

More generally, there’s plenty to criticize about Archicad given how disappointing its development has been in recent years. But with the arrival of AI, I don’t think the criticisms about GDL and the C++ API are really relevant anymore. That said, if we were to lose access to AI, I agree those criticisms would become valid again.

[vlahtinen]

I probably see the role of AI a bit differently. AI is a tool that speeds things up, but someone still has to understand and verify what it produces, at least for now. In this case, AI is hiding the shaky foundation rather than removing it.

On properties, the performance cost would only exist because there are two systems that need to be kept in sync. Merging them into a single data model would be a big task now, and probably was even when properties were introduced. But GDL could at least have been given proper access to them. That way an object could read and write its own properties directly without any add-on. Leaving that gap open for years has allowed technical debt to build up in the form of workarounds ever since properties were introduced.