Interner KI-Hackathon im BIM-Team: Was wir gelernt haben, als wir Claude mit Revit und Blender verbunden haben

Seit August veranstaltet unser BIM-Produktionsteam jede Woche einen internen KI-Hackathon. Sechzig bis neunzig Minuten, ein echtes Problem aus einem laufenden Projekt, eine Person an der Tastatur, der Rest stellt unbequeme Fragen. Wir haben Speckle, Massenbilanz in Revit, einen lesbaren BEP, Dynamo für Datenarbeit und ein pyRevit-Werkzeug für Diagramme durchgenommen. Die Sitzung, auf der dieser Artikel beruht, war die erste, in der es ausschließlich um künstliche Intelligenz ging: Claude Code über einen Model-Context-Protocol-Server mit Revit verbinden, dasselbe in Blender versuchen und klären, welche Plugins, Skills und Berechtigungen ein Team braucht, bevor ein KI-Agent ein Modell anfasst.

Geschrieben ist er für BIM-Manager und Digitalverantwortliche, die „etwas mit KI machen“ sollen und lieber vorher sehen möchten, was kaputtgeht, bevor sie KI in einem laufenden Projekt einführen. Die KI-Einführung im Bauwesen geht langsamer voran, als die Schlagzeilen vermuten lassen, und dieser Artikel nimmt die Gründe dafür ernst. Wir beschreiben das Format, die Einrichtung, was der Agent gut gemacht hat, wo er gescheitert ist und welche Regeln wir seitdem anwenden.

Die meisten Unternehmen veranstalten einen Hackathon einmal, mit Pizza und Jury, und danach ändert sich nichts. Ein wöchentlicher Hackathon für Ingenieurteams ist weniger ein Programmierwettbewerb als ein schnelles Programm zur Entdeckung von Geschäftsnutzen. Das Thema ist immer ein aktueller Schmerzpunkt aus einem laufenden Projekt, also wird der Prototyp in der Folgewoche genutzt oder verworfen. Es präsentiert, wer das Problem hatte, unabhängig vom Titel, damit das Wissen im Team bleibt und nicht beim Berater.

Vier Regeln halten das Ganze nützlich:

• Ein echtes Problem, ein Verantwortlicher. Ein Modellierer bringt den mühsamen Arbeitsschritt mit, der ihn einen Nachmittag gekostet hat, und die Gruppe versucht, ihn live zu lösen. Wirkung vor Perfektion.
• Der Stack bleibt zugänglich. Claude Desktop und ein Plugin, keine Entwicklungsumgebung. Die Einstiegshürde entscheidet, wer mitmacht, und die Mischung zählt: Modellierer, der Informationsmanager und die Person, die unser Marketing schreibt, sind alle dabei. Daher kommen die bereichsübergreifenden Ideen und das stärkere interne Netzwerk.
• Jede Sitzung hinterlässt eine Spur. Eine kurze Notiz, ein Skript im Repository oder ein Artikel wie dieser. Praxiserfahrung, die niemand aufschreibt, ist nach einem Monat verschwunden. Ein erfahrener Kollege bleibt unter der Woche ansprechbar für alle, die zu Ende bringen wollen, was die Sitzung begonnen hat.
• Gemessen wird, was in die Produktion kommt. Wir zählen Prototypen, die es in ein laufendes Projekt geschafft haben, keine Demos. Ohne diesen Trichter bleiben die Ideen ungenutzt.

Dieses Format ist das richtige Vehikel für KI-Weiterbildung: Menschen lernen eine Technologie, wenn sie ihr Problem löst, nicht wenn eine Schulungsfolie ihnen erzählt, die Zukunft sei agentisch. Es zeigt außerdem, wer Ihre KI-Champions sind, und weil das Wissen in Form von Notizen und Skripten geteilt wird, nutzen mehr Leute im Team die Automatisierung, statt dass ein Entwickler sie für sich behält.

Große Sprachmodelle wissen aus ihren Trainingsdaten sehr viel über die Revit-API und nichts über das Modell, das auf Ihrem Bildschirm geöffnet ist. Traditionelle KI-Modelle antworteten aus dem, worauf sie trainiert wurden. Bis vor Kurzem war die einzige Brücke zu Ihren eigenen Daten Copy-Paste: den KI-Assistenten um ein Skript bitten, es in pyRevit oder Dynamo einfügen, die Fehlermeldung lesen, wiederholen. Die meisten KI-Anwendungen im Bauwesen sind immer noch dieses Chatfenster.

Das Model Context Protocol (MCP) ist ein von Anthropic veröffentlichter offener Standard, der diese Schleife ersetzt. Ein MCP-Client wie Claude Desktop, Claude Code oder Cursor verbindet sich mit einem oder mehreren MCP-Servern. Jeder Server beschreibt seine Werkzeuge als JSON-Objekte: ausgewählte Elemente auflisten, eine Ebene erstellen, einen Parameter lesen, eine Datenbank abfragen. Das Modell entscheidet, welches Werkzeug es in welcher Reihenfolge aufruft, der Server führt es im externen System aus, und das Ergebnis kommt als Kontext für den nächsten Schritt zurück. Genau das macht aus einem Chatbot einen KI-Agenten: Echtzeitzugriff auf Ihre Daten und die Fähigkeit, darauf mehrstufige Aufgaben auszuführen.

MCP ersetzt die Revit-API nicht; es sitzt darauf, so wie es auf Datenbanken, Dateispeichern und anderen externen Werkzeugen und Diensten sitzt. So bedient eine Integration jeden kompatiblen Client, und dieselben Lösungen lassen sich von einem Werkzeug zum nächsten übertragen.

MCP-Server für Revit und Blender

Der Open-Source-Server, den wir verwendet haben, besteht aus drei Teilen: einem TypeScript-MCP-Server, der mit dem KI-Client spricht, einem C#-Add-in in Revit und einem Befehlssatz, der Revit-API-Aufrufe über einen lokalen WebSocket ausführt. Er bietet rund 25 Werkzeuge: Raster, Ebenen, Räume, Bemaßungen und Tragwerksbalken erstellen; Elemente einfärben, auswählen, ausblenden und beschriften; Raumdaten, Materialmengen und Projektstatistiken exportieren; C#-Code direkt an Revit senden. Er unterstützt Revit 2020 bis 2026 unter MIT-Lizenz. Kommerzielle Konnektor-Plattformen werben mit mehreren hundert Revit-API-Werkzeugen hinter einer einzigen Claude-Desktop-Verbindung, lokal auf dem Rechner des Nutzers.

Blender MCP ist das Pendant aus der Community, kein Produkt der Blender Foundation. Es öffnet einen Socket-Server in Blender und lässt das Modell Objekte erstellen und ändern, Materialien zuweisen, kostenlose Assets von Poly Haven laden, GLB oder FBX exportieren und beliebigen Python-Code ausführen. Die README warnt ausdrücklich, dass beliebiger Python-Code gefährlich sein kann, und rät, die Arbeit vorher zu speichern. Dasselbe gilt für Revit, wo das entsprechende Werkzeug C# in eine laufende Sitzung schickt.

Die ehrliche Bilanz unserer ersten reinen KI-Sitzung: Die Installation hat die Hälfte der Zeit gefressen. Node.js, das Add-in, die Freigabe beim Revit-Start, die richtigen Befehle in den Plugin-Einstellungen aktivieren und das ganze Team auf einen Claude-Team-Plan umstellen, damit Organisationseinstellungen und Berechtigungen für alle gleich sind. Planen Sie die erste Sitzung für die Einrichtung ein und nehmen Sie das als Lektion mit.

Dann der Test. Der Auftrag an den Agenten, in normaler Sprache: ein leeres Projekt mit Rastern und Ebenen; modelliere einen einfachen Stahlbetonrahmen, Stützen und Balken, mit den Parametern, die wir für die Koordination nutzen; plane zuerst und frage nicht bei jedem Schritt, ob du weitermachen sollst. Zehn Minuten später haben wir das Ergebnis geprüft.

Was funktioniert hat: Der Agent erstellte einen Plan, bevor er das Modell anfasste, legte Ebenen und Raster korrekt an, platzierte die Tragwerksbalken und meldete jeden Werkzeugaufruf in Echtzeit, sodass wir nachvollziehen konnten, was er getan hatte. Diese Transparenz zählte mehr als die Geschwindigkeit. Was nicht funktioniert hat: Überall, wo der Auftrag eine Lücke ließ, hat das Modell geraten. Familientypen, Benennung, welcher Parameter die Positionsnummer trägt, wie die Maße mit dem Architekturmodell zu koordinieren sind. Selbst die fortschrittlichsten KI-Modelle füllen diese Lücken mit voller Überzeugung, und „überzeugt und falsch“ ist in einem BIM-Projekt die teure Art von falsch. Das Urteil im Raum: ein schneller Junior, der einen vollständigen Auftrag und einen Prüfer braucht, also genau das, was wir auch von einem neuen Modellierer erwarten.

Blender war schneller und nachsichtiger, weil ein Mesh keine Parameter hat, die man falsch setzen kann. Genau deshalb ist es für uns weniger relevant: Die Information, für die wir bezahlt werden, lebt in Revit.

Plugins, Skills und Gedächtnis für den KI-Assistenten

Claude Code verpackt Anweisungen und Skripte als Plugins und Skills, die eine Organisation veröffentlicht und dem ganzen Team zur Installation bereitstellt. Wir haben ein internes Skill-Set veröffentlicht: unsere Benennungskonvention, die Parameter, die jedes Tragwerkselement tragen muss, die Prüfliste. Es ist eine kleine Wissensbasis unserer Standards, die der KI-Assistent liest, bevor er handelt, und damit hat der Agent seltener geraten. Das Gedächtnis des Agenten, das Projektkonventionen zwischen Sitzungen mitnimmt, half auf dieselbe Weise und warf die erste Governance-Frage auf: Wer entscheidet, was sich der Agent über das Projekt eines Kunden merkt, und wo dieses Gedächtnis liegt.

Multi-Agenten-Setups, in denen ein Modell plant und mehrere ausführen, gibt es in der Blender-Community bereits. Wir sind bei einem Agenten pro Aufgabe geblieben: Orchestrierung erweitert die KI-Fähigkeiten und halbiert die Verantwortlichkeit, denn wenn zwei Modelle sich widersprechen, kann niemand sagen, warum der Balken an der falschen Stelle sitzt.

Eine frühere Sitzung brachte zwei Bedenken zutage, die alles Weitere geprägt haben. Ein Coding-Agent mit weitreichenden Berechtigungen kann einen Prompt falsch lesen und Kundendaten an den falschen Empfänger schicken. Mit dem passenden Werkzeug verbunden kann er auch eine Datenbank löschen oder ein Modell überschreiben, weil er „räum das auf“ wörtlich genommen hat. Keines dieser Risiken ist hypothetisch in einem Team, das KI-Werkzeuge mit Google Drive, einer Projektdatenbank und Revit auf derselben Maschine verbindet. Ethik und Governance gehören in die erste Sitzung, nicht in die Zeit nach dem ersten Vorfall.

Datensicherheit bei KI-Agenten in einem BIM-Team läuft auf Regeln hinaus, die wir jetzt durchsetzen:

• Kein MCP-Server mit Schreibzugriff auf ein laufendes Kundenmodell. Agenten arbeiten auf einer abgekoppelten Kopie. Dort erst beweisen, dass es funktioniert. Das Zurückveröffentlichen ist ein menschlicher Schritt.
• Berechtigungen so gesetzt, dass vor jedem Schreibvorgang oder Skriptstart nachgefragt wird. „Nicht nachfragen“ ist für die Sandbox, nicht für den Projektordner.
• Nur ordnungsgemäß lizenzierte Werkzeuge. Open Source unter MIT ist in Ordnung; eine Bildungslizenz ist es bei kommerzieller Arbeit nicht; ein kostenloser kommerzieller Konnektor braucht trotzdem einen Blick in die Bedingungen, wohin die Daten gehen.
• Backups, Monitoring und ein Protokoll. Vor jeder Sitzung speichern. Das Aktionsprotokoll des Agenten beim Modell aufbewahren, so wie ein Transmittal festhält, wer was wann gesendet hat.
• Ein namentlich benannter Prüfer zeichnet ab. Verantwortung geht nicht auf die Software über.

KI-Governance in einfachen Worten ist genau diese Liste: ein Rahmen dafür, wer welche KI-Systeme nutzen darf, mit welchen Daten, mit welchen Berechtigungen und wer kontrolliert. Gesundheitswesen und Finanzbranche behandeln Patienten- und Kontodaten standardmäßig so. Das Bauwesen hält Daten zur Tragwerkssicherheit und, öfter als zugegeben, personenbezogene Daten in gemeinsam genutzten Parametern und Issue-Protokollen. Die DSGVO gilt für ein Revit-Modell genauso wie für ein CRM. Nichts davon bremst Innovation; es ist das, was Unternehmen erlaubt, Agenten in echten Projekten einzusetzen statt nur in Demos.

Die Frage, zu der unser Team immer wieder zurückkehrt: Stirbt Dynamo? Unsere Antwort nach acht Wochen: nein, es wechselt den Job. Ein Dynamo-Graph oder ein pyRevit-Skript kostet beim fünfzigsten Durchlauf nichts und tut jedes Mal dasselbe, und genau das braucht BIM-Automatisierung in repetitiven Produktionsprozessen. Der Preis ist die Wartung: Die Revit-API ändert sich jedes Jahr, alte Pakete laden nicht mehr, und jemand muss die Skripte aktuell halten.

Ein KI-Agent ist das Gegenteil. Er ist hervorragend bei einmaligen, komplexen Aufgaben mit vollständigem Auftrag und beim Schreiben oder Aktualisieren der Skripte selbst. Über MCP mit der Revit-Dokumentation verbunden macht er weniger API-Fehler als ein Modell, das aus dem Gedächtnis arbeitet, weil er die aktuelle Methode nachschlagen kann, statt zu raten. Er ist teuer im wiederholten Betrieb und nicht deterministisch. Die Arbeitsteilung ist also einfach: KI entwickelt und wartet die Automatisierung; die Automatisierung erledigt die Produktion. Der Nutzen: Knappe Ressourcen, erfahrene Modellierer und Entwickler, konzentrieren sich auf die konkreten Anforderungen des Projekts statt auf Routinecode.

Wählen Sie klar definierte Probleme mit messbarem Ergebnis, die Sie heute schon Zeit kosten:

1. Modell-QS über einen MCP-Server. Lassen Sie den Agenten jedes Element ohne Pflichtparameter auflisten und berichten, bevor er irgendetwas korrigiert.
2. Ein pyRevit-Werkzeug, geschrieben mit Claude Code. Etwas Kleines: ein Bauteillisten-Export, eine Prüfung der Ansichtsnamen.
3. Familienparameter übersetzen. Ein guter Test dafür, wo allgemeine KI-Modelle am Fachvokabular scheitern.
4. Massenbilanz oder Mengenermittlung in Revit, wobei der Agent die API-Aufrufe unterwegs erklärt.
5. Ein lesbarer BEP. Ein 60-seitiges Dokument so umstrukturieren, dass Modellierer nur die Kapitel lesen, die sie betreffen.
6. Daten nach Excel und zurück mit Dynamo, dann dieselbe Aufgabe mit einem Agenten, und Kosten sowie Wiederholbarkeit vergleichen.

Jede Idee neunzig Minuten lang, aufschreiben, was passiert ist, und in der Folgewoche entscheiden, ob sie in die Produktion geht. Die Herausforderung ist nicht, Ideen zu finden, sondern die Notiz fertigzuschreiben.

FAQ