Wewnętrzny hackathon AI w zespole BIM: czego nauczyło nas podłączenie Claude'a do Revita i Blendera

Od sierpnia nasz zespół produkcji BIM prowadzi co tydzień wewnętrzny hackathon AI. Sześćdziesiąt do dziewięćdziesięciu minut, jeden realny problem z żywego projektu, jedna osoba przy klawiaturze, reszta zadaje niewygodne pytania. Przerobiliśmy Speckle, bilans mas ziemnych w Revicie, czytelny BEP, Dynamo do pracy na danych i narzędzie pyRevit rysujące wykresy. Sesja, na której opiera się ten artykuł, była pierwszą, gdzie cała agenda dotyczyła sztucznej inteligencji: podłączenie Claude Code do Revita przez serwer Model Context Protocol, ta sama próba w Blenderze oraz ustalenie, jakich pluginów, skilli i uprawnień potrzebuje zespół, zanim agent AI dotknie modelu.

Piszemy dla BIM managerów i liderów cyfryzacji, od których wymaga się, żeby „zrobili coś z AI”, a którzy woleliby najpierw zobaczyć, co się psuje, zanim wdrożą AI na żywym projekcie. Adopcja AI w budownictwie idzie wolniej, niż sugerują nagłówki, i ten artykuł traktuje te powody poważnie. Opisujemy format, konfigurację, co agentowi wyszło, gdzie zawiódł i jakie zasady stosujemy od tamtej pory.

Większość firm robi hackathon raz, z pizzą i jury, i nic się potem nie zmienia. Cotygodniowy hackathon dla zespołów inżynierskich to w mniejszym stopniu konkurs programistyczny, a w większym szybki program odkrywania wartości biznesowej. Tematem jest zawsze aktualny problem z żywego projektu, więc prototyp albo trafia do użycia w kolejnym tygodniu, albo wypada. Prezentuje ta osoba, która miała problem, niezależnie od stanowiska, więc wiedza zostaje w zespole, a nie u konsultanta.

Cztery zasady utrzymują to w ryzach:

• Jeden realny problem, jeden właściciel. Modeler przynosi żmudny proces, który kosztował go popołudnie, a grupa próbuje rozwiązać go na żywo. Efekt ponad perfekcję.
• Dostępny stack. Claude Desktop i plugin, a nie środowisko deweloperskie. Próg wejścia decyduje o tym, kto dołączy, a mieszanka ma znaczenie: biorą udział modelerzy, information manager i osoba, która pisze nasz marketing. Stąd biorą się pomysły międzydziałowe i mocniejsza sieć wewnątrz firmy.
• Każda sesja zostawia ślad. Krótka notatka, skrypt w repozytorium albo taki artykuł jak ten. Praktyczne doświadczenie, którego nikt nie spisał, znika po miesiącu. Starszy kolega zostaje w tygodniu „na telefonie” dla każdego, kto chce dokończyć to, co zaczęła sesja.
• Mierzymy to, co trafia na produkcję. Liczymy prototypy, które weszły na żywy projekt, nie dema. Bez takiego lejka pomysły zostają niewykorzystane.

Ten format okazał się właściwym narzędziem do podnoszenia kompetencji AI: ludzie uczą się technologii, kiedy rozwiązuje ich problem, a nie kiedy slajd ze szkolenia mówi im, że przyszłość jest agentowa. Pokazuje też, kto w firmie jest naturalnym liderem AI, a ponieważ wiedza krąży w formie notatek i skryptów, z automatyzacji korzysta więcej osób w zespole zamiast jednego programisty, który ją trzyma.

Duże modele językowe wiedzą bardzo dużo o Revit API z danych treningowych i nic o modelu otwartym na Twoim ekranie. Tradycyjne modele AI odpowiadały z tego, na czym je wytrenowano. Do niedawna jedynym mostem do Twoich unikalnych danych było kopiuj-wklej: poproś asystenta AI o skrypt, wklej go do pyRevit albo Dynamo, przeczytaj błąd, powtórz. Większość zastosowań AI w budownictwie to nadal to okno czatu.

Model Context Protocol (MCP) to otwarty standard opublikowany przez Anthropic, który zastępuje tę pętlę. Klient MCP, taki jak Claude Desktop, Claude Code czy Cursor, łączy się z jednym lub wieloma serwerami MCP. Każdy serwer opisuje swoje narzędzia jako obiekty JSON: wylistuj zaznaczone elementy, utwórz poziom, odczytaj parametr, odpytaj bazę danych. Model decyduje, które narzędzie wywołać i w jakiej kolejności, serwer wykonuje je w systemie zewnętrznym, a wynik wraca jako kontekst do kolejnego kroku. To właśnie zamienia chatbota w agenta AI: dostęp do Twoich danych w czasie rzeczywistym i zdolność wykonywania na nich wieloetapowych zadań.

MCP nie zastępuje Revit API; siedzi nad nim, tak samo jak nad bazami danych, przechowywaniem plików i innymi zewnętrznymi narzędziami i usługami, dzięki czemu jedna integracja obsługuje każdego zgodnego klienta, a te same rozwiązania przenoszą się z narzędzia na narzędzie.

Serwery MCP dla Revita i Blendera

Serwer open source, którego użyliśmy, ma trzy części: serwer MCP w TypeScript rozmawiający z klientem AI, dodatek C# wewnątrz Revita oraz zestaw komend wykonujących wywołania Revit API przez lokalny WebSocket. Udostępnia około 25 narzędzi: tworzenie siatek, poziomów, pomieszczeń, wymiarów i belek konstrukcyjnych; kolorowanie, zaznaczanie, ukrywanie i tagowanie elementów; eksport danych pomieszczeń, zestawień materiałów i statystyk projektu; wysyłanie kodu C# bezpośrednio do Revita. Obsługuje Revit 2020–2026 na licencji MIT. Komercyjne platformy konektorów reklamują kilkaset narzędzi Revit API za jednym połączeniem z Claude Desktop, działających lokalnie na komputerze użytkownika.

Blender MCP to odpowiednik społecznościowy, a nie produkt Blender Foundation. Otwiera serwer socketowy wewnątrz Blendera i pozwala modelowi tworzyć i modyfikować obiekty, przypisywać materiały, pobierać darmowe zasoby z Poly Haven, eksportować GLB lub FBX i wykonywać dowolny kod Pythona. Jego README ostrzega, że dowolny Python może być niebezpieczny, i każe najpierw zapisać pracę. To samo dotyczy Revita, gdzie analogiczne narzędzie wysyła C# do żywej sesji.

Uczciwa relacja z naszej pierwszej sesji w całości o AI jest taka, że instalacja zjadła jej połowę: Node.js, dodatek, zgoda na jego uruchomienie przy starcie Revita, włączenie właściwych komend w ustawieniach pluginu i przeniesienie całego zespołu na jeden plan Claude Team, żeby ustawienia organizacji i uprawnienia były takie same dla wszystkich. Zaplanuj pierwszą sesję na konfigurację i potraktuj to jako lekcję.

Potem test. Brief dla agenta, zwykłym językiem: pusty projekt z siatkami i poziomami; zamodeluj prostą ramę żelbetową, słupy i belki, z parametrami, których używamy do koordynacji; najpierw zaplanuj i nie pytaj na każdym kroku, czy kontynuować. Dziesięć minut później przejrzeliśmy wynik.

Co zadziałało: agent przygotował plan, zanim dotknął modelu, poprawnie utworzył poziomy i siatki, rozmieścił belki i słupy oraz raportował na bieżąco każde wywołanie narzędzia, więc mogliśmy śledzić, co zrobił. Ta przejrzystość znaczyła więcej niż szybkość. Co nie zadziałało: wszędzie tam, gdzie brief zostawiał lukę, model zgadywał. Typy rodzin, nazewnictwo, który parametr niesie oznaczenie, jak skoordynować wymiary z modelem architektonicznym. Nawet najbardziej zaawansowane modele AI wypełniają te luki z pełnym przekonaniem, a „pewnie i źle” to w projekcie BIM najdroższy rodzaj błędu. Werdykt sali: szybki junior, który potrzebuje kompletnego briefu i recenzenta, czyli dokładnie to, jak traktujemy nowego modelera.

Blender był szybszy i bardziej wyrozumiały, bo siatka mesh nie ma parametrów, które można pomylić. I właśnie dlatego ma dla nas mniejsze znaczenie: informacja, za którą nam płacą, mieszka w Revicie.

Pluginy, skille i pamięć asystenta AI

Claude Code pakuje instrukcje i skrypty w pluginy i skille, które organizacja publikuje i udostępnia do instalacji całemu zespołowi. Opublikowaliśmy wewnętrzny zestaw skilli: naszą konwencję nazewnictwa, parametry, które musi mieć każdy element konstrukcyjny, checklistę przeglądu. To mała baza wiedzy o naszych standardach, którą asystent AI czyta, zanim zacznie działać, i z nią agent zgadywał rzadziej. Pamięć agenta, która przenosi konwencje projektowe między sesjami, pomogła tak samo i postawiła pierwsze pytanie o governance: kto decyduje, co agent zapamiętuje o projekcie klienta i gdzie ta pamięć leży.

Układy wieloagentowe, w których jeden model planuje, a kilka wykonuje, już istnieją w społeczności Blendera. Zostaliśmy przy jednym agencie na zadanie: orkiestracja dodaje możliwości AI i o połowę zmniejsza odpowiedzialność, bo kiedy dwa modele się nie zgadzają, nikt nie powie, dlaczego belka jest w złym miejscu.

Wcześniejsza sesja ujawniła dwie obawy, które ukształtowały wszystko później. Agent kodujący z szerokimi uprawnieniami może źle odczytać prompt i wysłać dane klienta do niewłaściwego odbiorcy. Z podłączonym odpowiednim narzędziem może też skasować bazę danych albo nadpisać model, bo wziął „posprzątaj to” dosłownie. Żadne z tych ryzyk nie jest hipotetyczne w zespole, który podłącza narzędzia AI do Google Drive, bazy projektowej i Revita na tej samej maszynie. Etyka i governance należą do pierwszej sesji, a nie do czasu po pierwszym incydencie.

Bezpieczeństwo danych przy agentach AI w zespole BIM sprowadza się do zasad, które teraz egzekwujemy:

• Żaden serwer MCP z prawem zapisu do żywego modelu klienta. Agenci pracują na odłączonej kopii. Najpierw tam udowodnij, że działa. Publikacja z powrotem to krok człowieka.
• Uprawnienia ustawione na pytanie przed każdym zapisem lub uruchomieniem skryptu. „Nie pytaj” jest dla piaskownicy, nie dla folderu projektu.
• Tylko odpowiednio licencjonowane narzędzia. Open source na MIT jest w porządku; licencja edukacyjna nie, na pracy komercyjnej; darmowy komercyjny konektor i tak wymaga przeczytania regulaminu, dokąd idą dane.
• Kopie zapasowe, monitoring i log. Zapisz przed każdą sesją. Trzymaj log działań agenta razem z modelem, tak jak transmittal zapisuje, kto co i kiedy wysłał.
• Imienny recenzent podpisuje. Odpowiedzialność nie przechodzi na oprogramowanie.

Governance AI w prostych słowach to właśnie ta lista: ramy określające, kto może używać których systemów AI, na jakich danych, z jakimi uprawnieniami i kto sprawdza. Ochrona zdrowia i finanse traktują tak dane pacjentów i rachunków domyślnie. Budownictwo trzyma dane o bezpieczeństwie konstrukcji, a częściej, niż się przyznaje, dane osobowe w parametrach współdzielonych i logach uwag. RODO dotyczy modelu Revit tak samo jak CRM-u. Nic z tego nie blokuje innowacji; to właśnie pozwala firmom wdrażać agentów na realnych projektach zamiast trzymać ich w demach.

Pytanie, do którego nasz zespół wciąż wraca, brzmi: czy Dynamo umiera. Nasza odpowiedź po ośmiu tygodniach: nie, zmienia pracę. Graf Dynamo albo skrypt pyRevit nic nie kosztuje przy pięćdziesiątym uruchomieniu i za każdym razem robi to samo, a tego właśnie potrzebuje automatyzacja BIM w powtarzalnych procesach produkcyjnych. Jego cena to utrzymanie: Revit API zmienia się co roku, stare pakiety przestają się ładować, a ktoś musi utrzymywać skrypty na bieżąco.

Agent AI to przeciwieństwo. Jest świetny w jednorazowych, złożonych zadaniach z kompletnym briefem oraz w pisaniu i aktualizowaniu samych skryptów. Podłączony przez MCP do dokumentacji Revita popełnia mniej błędów API niż model pracujący z pamięci, bo może sprawdzić aktualną metodę zamiast zgadywać. Jest drogi w wielokrotnym uruchamianiu i niedeterministyczny. Podział pracy jest więc prosty: AI tworzy i utrzymuje automatyzację; automatyzacja obsługuje produkcję. Korzyść: deficytowe zasoby, czyli seniorzy i programiści, skupiają się na konkretnych potrzebach projektu, a nie na kodzie-wypełniaczu.

Wybieraj zdefiniowane problemy z mierzalnym wynikiem, te, które już kosztują Cię czas:

1. Kontrola jakości modelu przez serwer MCP. Poproś agenta o listę wszystkich elementów bez wymaganego parametru i raport, zanim cokolwiek naprawi.
2. Narzędzie pyRevit napisane z Claude Code. Coś małego: eksport zestawienia, kontrola nazw widoków.
3. Tłumaczenie parametrów rodzin. Dobry test tego, gdzie ogólne modele AI wykładają się na słownictwie branżowym.
4. Bilans mas ziemnych albo przedmiar w Revicie, z agentem objaśniającym wywołania API po drodze.
5. Czytelny BEP. Przebuduj 60-stronicowy dokument tak, żeby modelerzy czytali tylko rozdziały, które ich dotyczą.
6. Dane do Excela i z powrotem w Dynamo, potem to samo zadanie z agentem, i porównanie kosztu oraz powtarzalności.

Każdy przez dziewięćdziesiąt minut, spisz, co się stało, i w kolejnym tygodniu zdecyduj, czy idzie na produkcję. Wyzwaniem nie jest znalezienie pomysłów, tylko dokończenie notatki.

FAQ