OD INTENCJI DO DOKUMENTACJI
Napisałem jedno zdanie, a po chwili miałem na ekranie model konstrukcji stalowej – siatkę słupów, profile i fundamenty. Pierwszy odruch był entuzjastyczny. Drugi, typowo konstruktorski: sprawdzić jednostki, podpory i przekroje. Nie chodzi o to, czy AI zbuduje model. Chodzi oto, czy jako inżynier mogęzaufać wynikowi i co mogęz nim zrobić dalej. Opisujękonkretny eksperyment,w którym z tekstowegoopisu powstały: model,jego analiza statycznai gotowa dokumentacja,a także to, co po drodzenie zadziałało.
Od dłuższego czasu w projektowaniu głośno jest o agentach AI i protokole MCP (Model Context Protocol). To otwarty standard ogłoszony pod koniec 2024 r., opisywany jako „USB-C dla sztucznej inteligencji”: jedna wtyczka, wiele aplikacji. Wcześniej każda integracja programu z modelem językowym powstawała osobno, na własną rękę. MCP daje wspólny język, dzięki któremu agent nie tylko rozmawia omodelu, lecz także działa w programie, uruchamia jego funkcje, czytadane, wykonuje polecenia.
Agent wchodzi do programu CAD
Dla konstruktora najważniejsze jest to, że powtarzalne czynności – zestawienia, sprawdzenia, raporty – można opisać zdaniem, zamiast wyklikiwać. Agent dobiera narzędzia i kolejność działań. Przez ostatnie lata inżynierowie uczyli się traktować AI jako pomoc do pisania skryptów, teraz następny krok omija samo kodowanie – agent sięga po funkcje programu bezpośrednio, a użytkownik nie musi znać programowania. Część narzędzi tylko odczytuje model, a część może go zmieniać. Ta druga grupa wymaga znacznie większej ostrożności – i to od niej zaczyna się pytanie, kto odpowiada za wynik. Istnieją też ryzyka mniej widoczne podczas demonstracji: prompt injection, czyli podsunięcie agentowi polecenia ukrytego w danych, oraz pytanie, gdzie trafiają dane projektowe.
Model z jednego zdania
Eksperyment zacząłem od krótkiego tekstowego polecenia: „zbuduj model hali stalowej z siatką słupów, fundamentami i profilami”. Po chwili geometria była na ekranie wraz konkretnymi przekrojami, w tym dwuteownikami. Zaskoczyło mnie nie samo pojawienie się brył, lecz to, że agent nadał im właściwą klasyfikację: w modelu były to „słupy” i „fundamenty”, a nie anonimowe obiekty. To różnica między modelem, na którym można dalej pracować, a ładnym obrazkiem. Agent nie rysuje geometrii „na oko”. Operuje parametrami i regułami, które program zamienia w bryły. Dzięki temu wynik jest powtarzalny i łatwiejszy do skorygowania niż rysowanie od zera.
Pod maską agent korzysta z narzędzi programu oraz ze skryptów wykonywanych w izolowanym środowisku. W tym eksperymencie środowisko wykonawcze nie miało dostępu do dysku ani sieci, agent mógł liczyć i modelować, ale nie zapisywał danych poza modelem. Przed napisaniem kodu agent korzystał z dostępnych sygnatur API i przykładów, co ograniczało liczbę sytuacji, w których musiał zgadywać sposób wywołania funkcji. Nie wszystko poszło gładko. Interaktywne, „klikane” wskazanie punktów wstawienia bryły agent potrafił rozpocząć, lecz nie potrafił dokończyć. W tym przypadku gotowe narzędzie nie wystarczyło i geometrię dokończyłem skryptem. Zdarzały się też klasyczne potknięcia: pomylona jednostka (metry zamiast milimetrów), pominięty warunek brzegowy, odwołanie do funkcji, której nie ma. Te błędy dobrze pokazują, gdzie technologię trzeba prowadzić za rękę i kontrolować każdy krok.
Walidacja w STAAD.Pro
Najciekawsze zaczęło się przy przekazaniu modelu do analizy. Drugi serwer MCP – tym razem dla STAAD.Pro – odebrał geometrię i uruchomił w tym programie obliczenia, a następnie odczytał wyniki: przemieszczenia, reakcje podpór oraz siły i momenty w prętach, z automatycznym uporządkowaniem jednostek. Zaznaczę od razu: STAAD.Pro to produkt mojego pracodawcy, Bentley Systems, ale ten test traktuję jako własny eksperyment inżynierski, a nie materiał promujący gotowe rozwiązanie. To STAAD.Pro wykonał sprawdzenia nośności prętów według Eurokodu 3. Agent odczytał, który pręt jest miarodajny i jaki jest stopień wykorzystania przekroju, a pozostałe elementy opisał jako mające duży zapas. Agent nie poprzestał na liczbach. Próbował też zinterpretować wyniki i wskazał, że przyczyną słabego wytężenia części prętów może być koncentracja obciążenia w kilku węzłach zamiast rozłożenia na całą kratownicę. Traktowałem to jako interpretację do sprawdzenia, a nie jako wynik obliczeń. Podkreślam też: z tego pojedynczego, uproszczonego modelu nie wyciągam żadnych wniosków projektowych.
Wartość jest gdzie indziej – w tym, że powstała pełna pętla: od opisu tekstowego, przez model przestrzenny, po analizę i raport. Zbudowałem ją z dwóch programów, dwóch serwerów MCP i jednego agenta spinającego całość. W tym eksperymencie MCP nie służył tylko do wykonania pojedynczego polecenia – agent korzystał także z kolejnych narzędzi, odczytywał wyniki i na ich podstawie przechodził do następnego kroku. Doceniłem też, że agent zna granice narzędzia: prawidłowo rozpoznał, że część operacji, na przykład aktualizacja danych wymienianych między programami, pozostaje ręczna, poza dostępnym mu API, i nie próbował udawać, że ją wykona. Dla inżyniera to sygnał zaufania. Maszyna, która mówi „tego nie zrobię”, jest bezpieczniejsza od takiej, która zawsze udaje pewność siebie. Agent może też pomóc w interpretacji wyników: wskazać element krytyczny i podpowiedzieć, co sprawdzić w kolejnej iteracji.
Automatyczna dokumentacja
Ostatni etap to dokumentacja. I właśnie tutaj wynik był najbardziej praktyczny. Z gotowego modelu i wyników agent wygenerował zestawienia oraz wielostronicowy raport śledzący stateczność konstrukcji, zgodność z normą i kolejne iteracje optymalizacji masy stali. To najbardziej żmudna, powtarzalna część pracy – raportowanie, tabele, opisy – która zwykle pochłania godziny. Powtórzyłem ten scenariusz na większym obiekcie – przekryciu typu galeria. Przebieg był podobny: od opisu modelu, przez analizę, po zestawienia i rysunki. Nie mierzyłem pełnego czasu procesu projektowego, ale jeśli pierwsza wersja raportu powstaje w kilka minut, zamiast być pisana ręcznie, różnica jest odczuwalna.
Trzeba jednak od razu dopowiedzieć, czego taki dokument nie załatwia. Zapewnienie kompletności, zgodności ze standardem biura i kontrola merytoryczna pozostaje zadaniem człowieka. Agent nie wie, że w danej pracowni tabela ma wyglądać inaczej, a pewien detal wymaga osobnego rysunku. Wygenerowana dokumentacja bywa też nierówna – część arkuszy jest gotowa od ręki, część wymaga uzupełnień i poprawek redakcyjnych. Dokument z AI to dobry punkt startu, który trzeba przejrzeć i poprawić, a nie produkt końcowy do podpisania w ciemno.
Gdzie kończy się agent
Najważniejszy wniosek z tego testu nie dotyczy technologii, lecz odpowiedzialności. Agent potrafi zbudować geometrię, uruchomić analizę i przygotować raport, ale dobór układu konstrukcyjnego, kombinacje obciążeń, wymiarowanie i decyzje projektowe pozostają po stronie inżyniera. Użycie sztucznej inteligencji nie zmienia faktu, że za przyjęte rozwiązanie odpowiada osoba pełniąca odpowiednią funkcję zawodową – odpowiedzialności zawodowej nie da się scedować. Najważniejsza pozostaje umiejętność odróżnienia wyniku użytecznego od tylko pozornie poprawnego, a do tego potrzebne są wiedza inżynierska i sprawdzenie, co agent faktycznie zrobił.
Dla biura rekomendacja jest prosta: zacząć od jednego, nudnego, powtarzalnego zadania na realnym projekcie, a nie od efektownego dema. Wybierz coś, co dziś robisz ręcznie: zestawienie stali, kontrolę nazw warstw, porównanie jednostek – i przeprowadź to z agentem od początku do końca, mierząc czas i jakość. Nie kupuj „funkcji AI” dla samej obecności w ofercie i nie wierz demonstracjom, lecz testuj na własnych danych. Człowiek powinien zatwierdzać działania zmieniające model i kontrolować wyniki kolejnych etapów. Największy problem nie pojawi się bowiem wtedy, gdy agent zrobi coś za nas. Zacznie się wówczas, gdy zrobi to wystarczająco dobrze, byśmy przestali sprawdzać.
Słowniczek
MCP (Model Context Protocol) – otwarty standard łączący agentów AI z aplikacjami i danymi.
Agent AI – model, który nie tylko odpowiada, lecz także wykonuje zadania w programie.
Prompt injection – podsunięcie agentowi polecenia ukrytego w danych wejściowych.
Human-in-the-loop – zasada, że człowiek zatwierdza akcje zmieniające model.
Studium przypadku oparte na eksperymencie autora. Przykłady służą jako ilustracja mechanizmów, nie jako materiał promocyjny.
