Vom Hackathon zum laufenden Projekt: Was uns zehn Tage Claude Skills in Revit beigebracht haben (Teil 2)

In Teil 1 haben wir eine Hackathon-Sitzung beschrieben: Claude Code, über einen MCP-Server (Model Context Protocol) mit Revit verbunden, ein leeres Projekt und ein einfacher Tragwerksrahmen. Das Urteil damals: ein schneller Junior, der einen vollständigen Auftrag und einen Prüfer braucht. Dieser Artikel behandelt die zehn Tage danach, in denen dasselbe Team den Agenten in einem laufenden Rechenzentrumsprojekt eingesetzt hat.

Der Kunde ist ein auf Rechenzentren spezialisiertes Planungsbüro, dessen Standard durch fertige Referenzmodelle gesetzt wird, darunter ein aktuelles, vollständig spezifiziertes Modell eines erstklassigen Ingenieurbüros. Unsere Aufgabe war, diesen Standard in einem neuen Projekt zu erreichen: Wandtypen, Türen, Decken, Bodenbeläge und Räume, so codiert, wie es die Referenzen vormachen. Gearbeitet haben drei von uns: unser Informationsmanager und zwei Modellierer, eine davon noch neu in Revit. Die Werkzeuge waren Claude Code, ein quelloffener Revit-MCP-Server samt Revit-Plugin, Speckle und ein kleines Set eigener Skills.

Der Artikel richtet sich an BIM-Manager, Informationsmanager und Digitalverantwortliche, die entscheiden müssen, ob KI-Agenten in Produktionsabläufe gehören. Das ist wichtig, weil eine Demo einen einzigen Durchlauf zeigt und ein laufendes Modell den zweiten. Im Folgenden: was ein Skill ist, wie wir unsere gebaut und kaputt gemacht haben, vier Episoden, unsere Regeln und die Grenzen des Agenten.

Ein Skill ist eine schriftliche Vorgehensanweisung in natürlicher Sprache, die der Agent liest, bevor er handelt. Er ist kein Skript und kein Chat-Prompt, sondern eine Datei, die für die Organisation veröffentlicht wird und für genau eine Aufgabe festhält, worauf zu achten ist, welche Typen zu verwenden sind, wie sie zu codieren sind und wann der Agent anhalten und nachfragen muss. Unsere Skills decken Wandtypen, Türtypen, Deckentypen, Bodenbeläge und Räume ab, dazu einen allgemeinen Geometrie-Skill für Massenmodelle.

Der Unterschied ist am Bildschirm sichtbar. Mit installierten Skills hat der Agent jeden Schritt kommentiert und weniger geraten; ohne sie lieferte er nur einen Abschlussbericht. Außerdem stellte er bessere Fragen. Bevor er Wandtypen tauschte, wollte er wissen, was jeder Raum ist: Waren die Kerne Stahlbeton, war die Anlieferungszone eine Straße? Ein Modellierer sagte, was wir anderen auch dachten: Es gefiel ihm, dass der Agent nachfragt.

Wie wir sie aus einem Referenzmodell gebaut haben

Keiner der Skills wurde von Grund auf geschrieben: Jeder entstand aus einer Arbeitssitzung. Ein Modellierer öffnete das Referenzmodell neben der Arbeitsdatei, erledigte die Aufgabe mit dem Agenten und bat Claude dann, aus der Sitzung einen Skill zu erstellen und in die Organisation hochzuladen. Aus den ersten Tagen sind zwei Regeln geblieben:

• Den Skill aus der ganzen Unterhaltung bauen, nicht aus dem Abschlussbericht. Der Bericht ist nur das Endergebnis. Die Überlegungen und die Korrekturen stehen im Chat.
• Ein Skill, der Aktionen auslöst, darf zwischen Projekten nicht variieren. Wo die Referenz kein klares Muster zeigt, weist der Skill den Agenten an nachzufragen, damit ein Mensch entscheidet.

Für die Bodenbeläge erstellte der Agent über den MCP-Server eine Farblegende in Revit, nachdem wir ihn daran gehindert hatten, pyRevit-Skripte aus dem Gedächtnis zu schreiben. Als der Wand-Skill überarbeitet wurde, bekam die neue Fassung das Suffix „V2“, damit ihre Beschreibung nicht mit der alten kollidiert. Damit begann die Verwaltungsarbeit.

Die Verwaltungsarbeit, die schiefging

Ein guter Teil der ersten Woche ging für die Versionsverwaltung drauf: sicherzustellen, dass alle denselben Skill nutzen.

• Organisations- gegen persönliche Kopien. Eine Modelliererin bekam weiter die alte Wandlogik, obwohl sie gelöscht worden war, weil eine Kopie in ihre persönlichen Skills gezogen worden war. Wir haben die persönlichen Kopien gelöscht.
• Veraltete Versionen. Zwei Wand-Skills mit ähnlichen „Verwenden, wenn“-Beschreibungen ließen den Agenten den alten wählen. Duplikate verändern, was der Agent tut.
• Neu laden. Eine neue Version wirkt erst, wenn Claude Code geschlossen und die Skills neu geladen wurden. Wer das vergisst, testet die Logik von gestern.
• Administratorrechte. Um einen Organisations-Skill zu ersetzen, braucht man Admin- oder Eigentümerrechte, die die Autoren anfangs nicht hatten.
• Standardmäßig installieren. Wer beim Veröffentlichen das Häkchen setzt, verhindert, dass die eine Person einen Skill sieht und die andere nicht.

Nichts davon ist kompliziert. Alles davon bleibt unsichtbar, bis zwei Personen mit demselben Prompt unterschiedliche Ergebnisse bekommen.

Decken knapp unter dem Geschoss darüber

Die Referenzprojekte färben Räume über Ansichtsfilter ein, die Elemente auswerten und nicht nur Parameter. Deshalb setzt der Decken-Skill überall dort, wo ein Raum eine Decke braucht, eine Referenzdecke etwa 1 cm unter das Geschoss darüber und lässt sie dort weg, wo es die Referenz auch tut, zum Beispiel beim Portal mit seinem Regenrost. Die erste Reaktion unseres Informationsmanagers war, eine Decke zu modellieren, die es nicht gibt, sei kein BIM. Er änderte seine Meinung, als er sah, dass elementgesteuerte Filter die klügere Lösung sind. Bisher ist sie nur für Filter nützlich, sonst für nichts.

Korridordecken lagen unter dem Geschoss und verschwanden, bis wir den Ansichtsbereich nach oben unbegrenzt mit einem Versatz konfiguriert hatten. Treppen- und Aufzugskerne kamen grau statt grün heraus, weil das Geschoss darüber keine Öffnung hatte und der Skill Decken macht, keine Öffnungen. Vorerst bekommen Treppenkerne keine Decke.

Die Modelliererin, die den Skill testete, wählte fast jedes Mal die „empfohlene“ Option; der Autor des Skills sagte, er hätte zu etwa 90 Prozent genauso entschieden. Ihr Kommentar war der nützliche: Sie hatte den Skill nicht geschrieben, also sagten ihr die Typnamen nichts. Ein Skill muss auch für jemanden funktionieren, der die Antwort nicht schon kennt.

Sechzig Wände und ein Typ mit sieben Schichten

Der Prompt war kurz: Auf Grundlage der Räume Wandtypen einführen, sie im Grundriss tauschen und die Filter setzen. Der Agent tauschte 60 Wände automatisch und kam mit Freigabefragen zurück. Außenwände an Kern und Portal: nicht ändern. Kühlkorridor: Typ 105 akzeptieren. Zwölf Fassadenwände, sechs Portalwände und vier Umspannstationswände: keine Änderung. Wände zwischen zwei Nebenräumen: 104 akzeptieren. Einwortantworten genügten.

Dann die Probleme:

• Stützen. Sie wechselten mit den Wänden die Farbe, weil in der Stützenfamilie „Automatically joins“ (automatisches Verbinden) aktiv war. Wir haben rückgängig gemacht, die Familie ohne diese Option neu geladen und neu eingefärbt.
• Lange Wände. Eine Wand änderte den Typ über ihre gesamte Länge, weil der Agent keine Wand teilen kann.
• Handkorrekturen. Zweimal korrigierte ein Modellierer eine Wand von Hand, und der Agent machte es im nächsten Durchlauf rückgängig.
• Schichten. Die neuen Typen hatten die richtigen Namen, Codes und Dicken, aber Schichten und Materialien waren aus den Ausgangstypen kopiert. Der Skill hatte keinen Aufbaukatalog; sein Autor hatte die Schichten in seiner eigenen Sitzung erarbeitet und nie hineingeschrieben.

Version 2 ergänzte sie, und der rote Wandtyp kam mit allen sieben Schichten und dem Indexpräfix des Kunden statt dem der Referenz heraus.

Ein Gebäude aus einem Speckle-Link, gleich zweimal

Der erste Versuch war der ehrgeizige, ein großer Schritt weg vom Spielzeugrahmen. Ein Modellierer gab dem Agenten einen Speckle-Link auf die Konzeptgeometrie, ein Lageplan-PDF und einen Orchestrator-Skill und ließ ihn etwa zwei Stunden unbeaufsichtigt laufen. Er legte das Tragwerk in Systemfamilien an und erkannte dann Generatoren und Racks an ihren Namen. Als er im Hintergrund arbeiten sollte, schrieb er bei geschlossenem Revit eine Revit-Datei in einen Ordner. Der Lauf verbrauchte das gesamte Nutzungsfenster von fünf Stunden, danach folgten zwei Stunden Wartezeit. Das PDF und die Speckle-Geometrie widersprachen sich stellenweise, und wir haben nie geklärt, woran sich der Agent orientiert hat.

Der beaufsichtigte Neuaufbau war langsamer und aufschlussreicher. Speckle übertrug weder die Rhino-Parameter noch sonstige Metadaten, also las der Agent Namen und riet. Manche Elemente waren als Räume benannte Quader, zum Beispiel „Büro“, die er mit Wänden umrandete, mit Lücken und einer doppelten Wand. Er bot an, leicht schiefe Wände geradezurichten, was wirklich nützlich war. Aber nach dem Kampf Wand für Wand kam unser Informationsmanager zu dem Schluss, dass die letzten Wände von Hand schneller gezeichnet wären. Die Quelle war eine Skizze, und eine Skizze hat kein Muster, das sich wiederholen ließe.

Räume: den Agenten nicht raten lassen

An den Räumen zeigte sich das Problem der Wiederholbarkeit am deutlichsten. Bei einem erneuten Durchlauf stellte der Skill Raumfragen, die er beim ersten Mal nicht gestellt hatte. Ein Raum, den er nicht identifizieren konnte, entpuppte sich als Dachraum.

Die Lösung sind Hinweise, nicht Freiheit. Räume übernehmen ihre Namen aus der Speckle-Quelle. Wo es keinen Namen gibt, heißt der Raum „nicht angegeben“, nie eine erfundene Bezeichnung, und Hinweise stehen als Text im Plan, den der Agent lesen kann. Wenn er es trotzdem nicht sagen kann, fragt er nach. Wie ein Modellierer es ausdrückte: Der Agent liest nicht, er rät, es sei denn, man gibt ihm etwas zu lesen.

• Neue Skills in einem sauberen Kontext auf dem Rechner einer anderen Person testen. Das Claude des Autors erinnert sich an die Referenz und besteht daher Tests, an denen ein neuer Nutzer scheitern würde.
• Echte Geometrie einspeisen, keine Screenshots. Ein paar Zahlen kosten weniger Kontext als ein Bild, und ein PDF schlägt einen Browser-Screenshot.
• Ein Referenzprojekt schlägt einen Prompt. Mit der Referenz in derselben Revit-Sitzung fand der Agent neun Türtypen und holte sich seine Regeln aus der Referenz statt aus dem Skill. Das ist uns auf die Füße gefallen: Die Kopie der Referenz war sehr alt, also wählte er die falschen Türen. Referenzen aktuell halten und Familiennamen bei jedem Lauf identisch lassen.
• Beaufsichtigter MCP-Zugriff für Projektänderungen, Hintergrundgenerierung nur für ladbare Familien. Alles, was das Projektmodell verändern würde, geschieht live unter den Augen einer Person.
• Schrittkommentare und Freigaben sind Funktionen. So fällt eine rückgängig gemachte Handkorrektur auf. Lange unbeaufsichtigte Läufe brauchen automatisches Akzeptieren, das wir an einem Projektmodell nicht wollen.
• Wiederholbarkeit ist die Messgröße. Ein Skill, der beim zweiten Durchlauf anders antwortet, ist immer noch eine Demo.
• „Revit-Code ausführen“ mit Vorsicht behandeln. Im Vollzugriffsmodus mit allen aktivierten Funktionen führt der Server beliebigen Code aus und folgt Ihren Befehlen wörtlich, auch dem, was Sie nicht gemeint haben. Der Agent fragt nach und endet mit einer Checkliste, Strg+Z funktioniert, bis jemand speichert und synchronisiert, und der Agent sieht nur die Datei, die auf dem Rechner des Modellierers geöffnet ist. Der Server stammt aus der Community, also sind sein Revit-Plugin und die lokale Bridge auch eine Frage der Datensicherheit, und seine Berechtigungen brauchen sorgfältige Konfiguration; mehr dazu in MCP in Revit. Unser Informationsmanager wäre lieber, der Agent würde pyRevit-Code schreiben, mit jeder Änderung freigegeben innerhalb von Revit.

Das gehört auf eine Seite eines BIM-Abwicklungsplans, wo ein Agent es so leicht befolgen kann wie ein Mensch. Modellnamen in ACC bestehen aus Projektnummer, Kundenkürzel, Gebäudekürzel (DC01), ZZ im Feld für das Geschoss, einem Feld für den Modelltyp, der Disziplin (A für Architektur) und dann einem Suffix für Gelände (ST) oder Kontext (CX). Laufende Arbeit liegt in einem Unterordner „01 WIP“. Feste Benennung und Vorlagen halten Dokumente konsistent und lassen das nächste Projekt die Skills wiederverwenden.

Die Synchronisierung mit Speckle läuft jetzt automatisch: In der ACC-Integration von Speckle verbindet man sich, wählt Team und Projekt, setzt die Häkchen bei den Modellen und legt eine Synchronisierung an, und Speckle holt von da an neue Versionen. Die Speckle-Dashboards des Kunden hängen von den Referenzparametern ab, die unsere Skills schreiben. Das offene Risiko sind Koordinaten: Verknüpfte Kontext- und Masterplanmodelle teilen sie womöglich nicht.

Am Ende der zehn Tage haben wir uns mit dem Gründer des Kunden und einem externen Softwarestudio zusammengesetzt.

Die Vision des Kunden ist keine Entwurfsautomatisierung. Die Masterplanung bleibt menschlich, und Testentwürfe sind nicht das Ziel. Das Ziel sind Produktion und Detaillierung, von der Entwurfs- bis zur Ausführungsplanung, zuerst in der Architektur: Pläne, Wandtypen, Türlisten, damit fünf oder sechs erfahrene Fachleute, die die Verantwortung tragen, schneller vorankommen. Die Erfahrenen unterstützen, nicht ersetzen.

Der Plan hat drei Schritte. Erstens ein Handbuch: Die täglichen Arbeitsabläufe, die wir zwei bis drei Wochen lang als Checklisten und eine Woche lang als Skills geschrieben hatten, werden zu einer schriftlichen Erklärung, die zugleich maschinenlesbar ist. Der Entwickler des Studios schlug vor, einem LLM das ganze Handbuch zu geben und es die Leute Kapitel für Kapitel interviewen zu lassen; der Gründer zweifelte, dass Interviews funktionieren, und wollte lieber Besprechungen aufzeichnen und wiederkehrende Probleme systematisieren. Zweitens KI-Integrationen: Konnektoren zwischen den Werkzeugen. Drittens eine Oberfläche, die die KI-Hürde für Architekten senkt. Das Handbuch soll sich im Lauf der Arbeit selbst umschreiben.

Der Punkt, der für einen BIM-Manager am wichtigsten ist, kam vom Gründer: In zwanzig Jahren sei jedes F&E-Projekt in einem Architekturbüro, das er gesehen habe, gescheitert, und hängen geblieben sei nur, was täglich an einem laufenden Projekt getestet wurde.

Auch die Token-Kosten kamen zur Sprache. Die eingebaute KI-Funktion einer Plattform verkauft den Modellzugang teurer als eine direkte Verbindung über KI-Coding-Werkzeuge wie Claude Code, die es zudem erlauben, das KI-Modell selbst zu wählen. Weil MCP ein offenes Protokoll ist, lässt sich der KI-Anbieter wechseln, ohne die Verbindung zu Revit neu aufzubauen. Wir hatten eine lokale Workstation mit lokalen Modellen und unbegrenzten Tokens erwogen. Gekauft haben wir sie nicht: Sie läuft unter Linux und kann Revit nicht ausführen.

• Eine Wand teilen oder eine Tür setzen. Der Tür-Skill tauscht vorhandene Türen anhand des Raumkontexts; ohne Türen im Modell gab es nichts, woran er anknüpfen konnte. Ein Skill für Türpositionen ist als Nächstes dran, und wir erwarten, dass er 80 bis 90 Prozent richtig macht.
• Einen Aufbau kennen, der ihm nie gegeben wurde. Der Schichtenkatalog musste in den Skill geschrieben werden. Deckenöffnungen werden noch nicht unterstützt.
• Günstig laufen. Ein unbeaufsichtigter Lauf verbrauchte ein ganzes Nutzungsfenster, und wir rechnen damit, dass Tokens teurer werden, ein Grund mehr für feste Standards.

Und die wichtigste Grenze: Wir haben keine gemessene Zeitersparnis. Eine Modelliererin sagte, sie habe zwei Tage mit Claude gesprochen, ohne Revit zu öffnen, und sich gefühlt, als würde sie schummeln. Das ist ein Gefühl, keine Messung.

FAQ