„Ten kod trzyma się na ślinę”. Ekspert Agenty AI o tym jak mądrze automatyzować polski biznes
Wiktor Cyrny, My Company Polska: Zacznijmy od uporządkowania pojęć. Jaka jest z Twojej perspektywy różnica między zwykłym modelem językowym (LLM) a agentem AI?
Adam G. Dobrakowski: Powiem szczerze, że dla mnie, jako osoby zajmującej się sztuczną inteligencją od blisko dekady, ta granica jest obecnie bardzo płynna. Kiedy firmy pytają nas, czy robimy agenty, najpierw staram się zrozumieć, jak oni w ogóle to pojęcie definiują. W moim rozumieniu agent to system, który w tle wykonuje serię zaplanowanych akcji, by osiągnąć oczekiwany efekt. Jeśli spojrzymy na dzisiejszy ChatGPT, to nie jest to już ten sam prosty bot co w 2022 roku, który generował tylko ścianę tekstu. Dziś, gdy zadasz mu skomplikowane polecenie, pod spodem uruchamia się model planowania: system zastanawia się, czy musi przeszukać internet, agreguje materiał i decyduje, w jakiej formie podać wynik.
Czy w waszym startupie wykorzystujecie potencjał tej płynności o której wspomniałeś, czyli synergii modeli językowych z agentami AI?
Oczywiście. W Cogita AI tworzymy wyspecjalizowane agenty dla klientów enterprise. Przykładem może być agent pełniący rolę analityka danych. Pracownik zadaje w języku naturalnym pytanie o trendy sprzedaży, a agent sam musi je zrozumieć, przekształcić na konkretne zapytanie do bazy zawierającej setki milionów rekordów, wyciągnąć dane i narysować dla użytkownika wykres. Niezależnie jednak od skomplikowania, pod spodem takich systemów i tak zawsze pracują duże modele językowe (LLM) – kluczowe jest po prostu to, w jakie narzędzia i autonomię je wyposażymy.
Skupmy się na bardzo gorącym trendzie, jakim jest "vibe coding". Wiele osób zachłysnęło się wizją, że teraz każdy, nawet pracownik bez wiedzy technicznej, może napisać i wdrożyć własną aplikację, omijając dział IT. Czy to faktyczna rewolucja, czy prosta droga do biznesowej katastrofy?
Trzeba to ostrożnie rozgraniczyć. Czym innym jest celowane, przemyślane użycie agenty AI przez doświadczonego programistę w celu drastycznego przyspieszenia pracy, a czym innym radosny "vibe coding" w wykonaniu laika, który kompletnie nie rozumie, co pod spodem generuje mu maszyna. Jeśli, dajmy na to, prezes małej firmy w ten sposób wygeneruje sobie proste narzędzie do automatyzacji np. pracy na swoim komputerze, ryzyko jest niewielkie. Problemy zaczynają się wtedy, gdy taki amatorski produkt chcemy wypuścić na rynek, do zewnętrznych użytkowników.
W czym zatem tkwi problem i gdzie leży prawda? Znam „ewangelistów” vibecodingu, którzy twierdzą, że ta metoda to rewolucja w cięciu kosztów.
Tworzenie oprogramowania jest jak budowa domu. Dobry architekt działa zgodnie ze sztuką: wie, gdzie zaplanować ściany nośne, a gdzie działowe, i z jakich materiałów skorzystać. Aplikacja po amatorskim "vibe codingu" to dom, w którym jedna ściana jest z cegły, druga z drewna, a trzecia z pustaków. Z zewnątrz, od strony interfejsu (front-endu), może wyglądać profesjonalnie – mieć dziesiątki funkcji i przycisków. Ale wystarczy wejść do środka z zamiarem drobnej przebudowy, by zorientować się, że wszystko trzyma się na przysłowiową „ślinę” i jakakolwiek ingerencja grozi zawaleniem całej konstrukcji.
W branży IT pojawiło się nawet nowe określenie: "Vibe coding cleaner", czyli sprzątacz po AI. Jak wygląda naprawianie takiego "architektonicznego spaghetti" u Waszych klientów? Kto ostatecznie płaci za ten dług technologiczny?
Zdarzają nam się takie zapytania i mieliśmy okazję przeglądać taki kod. Prawda bywa brutalna: oszczędność z faktu samodzielnego użycia AI przez nietechnicznego foundera jest często ujemna. Mieliśmy przypadek mocno "zwaibkodowanej" aplikacji służącej do przewidywania wielkości zakupów. Kiedy nasi inżynierowie się z nią zetknęli, poświęcili około 20 godzin na samą próbę zrozumienia struktury, po czym orzekli, że jest to całkowicie bezwartościowe i musimy napisać system od zera. Te 20 godzin było czasem straconym.
Modele AI, generując duże fragmenty na raz, tworzą przesadnie skomplikowany, nieuporządkowany kod, mieszający równocześnie wiele standardów. To trochę tak, jakby maszyna pisała opowiadanie i na samym początku wprowadziła 100 bohaterów tylko po to, by pojawili się na chwilę dopiero na 50 czy 200 stronie. Dla senior developera jest to koszmar i zamiast modyfikować trzy pliki, musiałby de facto zmienić wszystkie pięćdziesiąt.
Adam G. Dobrakowski, CEO Cogita AI
Skoro agenty AI potrafią sami wygenerować aplikację, to dlaczego nie potrafią jej po sobie posprzątać? Narzędzie powinno potrafić zrefaktoryzować własny kod.
Agenty AI są świetne w wyłapywaniu pojedynczych, wąskich usterek i luk bezpieczeństwa – w tym potrafią być wręcz lepsi od ludzi, bo niczym szachowe komputery analizują naraz o wiele więcej ścieżek z dużym horyzontem. Jednak jak na razie nie radzą sobie z fundamentalnymi przebudowami. Wynika to z natury tych modeli. LLM-y operują na kolejnych tokenach. Posiadają pewne zdolności logicznego rozumowania w wąskich kadrach, ale brakuje im abstrakcyjnej zdolności zbudowania spójnego, głębokiego obrazu zależności w dużym projekcie.
Patrzą na kod fragmentarycznie. Do znalezienia luki to wystarczy, ale do zmiany architektury już nie. Co więcej, jeśli do szukania błędów użyjemy tego samego modelu AI, który kod wygenerował, z dużym prawdopodobieństwem w ogóle ich nie zauważy, ponieważ sam utwierdzi się w swoim błędnym wnioskowaniu.
Często słyszymy takie historie: menedżer zwalidował projekt, aplikacja idealnie działa u niego na laptopie. Otwiera szampana. Ale gdy próbuje wypuścić ją w świat na serwer produkcyjny dla użytkowników, platforma się dusi, a architektura nie wytrzymuje obciążenia. Skąd ta drastyczna przepaść?
Z bardzo prostej przyczyny: wdrożenie to nierzadko drugie tyle czasu i energii co napisanie samej aplikacji. Różnica w skali jest olbrzymia. Aplikacja na laptopie korzysta z zasobów jednego użytkownika. Ale gdy ma z niej korzystać tysiąc osób w jednym momencie, wkraczamy w twarde dylematy infrastrukturalne: dobór chmury, zarządzanie procesami, czas oczekiwania na komunikację między systemami.
Kiedy laik pyta chatbota: "jak wrzucić aplikację na serwer?", model podrzuca mu najprostszą możliwą ścieżkę, kompletnie ignorując specyfikację wydajnościową. U nas, w profesjonalnym software house, zanim programista napisze choć jedną linię kodu, przeprowadzamy kilkugodzinne warsztaty. Zadajemy 20 kluczowych pytań. Mapujemy całą ścieżkę użytkownika, wymagania obciążeniowe, poziomy dostępu (admin, manager, użytkownik) i budujemy specyfikację techniczną. Osoba bez wiedzy technicznej nie poda agentowi AI tych wymagań, a sam agent nie ma w sobie jeszcze umiejętności zatrzymania się na godzinę i wypytania klienta o te detale. Po prostu zmyśla i wybiera drogę na skróty.
W takim razie, w jakich obszarach ta rewolucja faktycznie dowozi największą rynkową wartość?
To nie jest zwykła optymalizacja rzędu kilkunastu procent, my obserwujemy skoki wydajności, które skracają czas procesów nawet dwudziestokrotnie. Największymi beneficjentami są dzisiaj np. founderzy i startupy. Widzimy to po grupie klientów, z którymi współpracujemy.
Kiedyś budowa prototypu MVP, by zderzyć pomysł z rynkiem, kosztowała zespoły programistyczne wiele miesięcy pracy i nierzadko budżety rzędu 200–300 tysięcy złotych. Dziś zespół techniczny z użyciem AI, może stworzyć działającą wersję w kilka dni, redukując ten początkowy próg wejścia powiedzmy do 10 tysięcy złotych, pozyskując błyskawicznie pierwszych płacących użytkowników. To pozwala zwalidować model biznesowy i uzyskać cenny feedback od docelowej grupy odbiorców. Robimy to jednak z wiedzą o architekturze. Trend użycia agentów przez deweloperów jest już nieodwracalny. Dwa lata temu firmy głowiły się nad prawami autorskimi kodu generowanego przez AI, co swoją drogą nadal jest pewnym nierozwiązanym zagadnieniem. Dziś już tego nie kwestionują – jeśli senior developer nie będzie używał AI, to po prostu odpadnie z rynku.
Odchodząc na moment od samego kodu. Jakie szerokodostępne rozwiązania oparte na LLM i agentach poleciłbyś polskim przedsiębiorcom do codziennych, biznesowych zadań?
Prywatnie widzę niesamowity przełom w kilku narzędziach, z których sam intensywnie korzystam. Pierwszym jest tworzenie prezentacji przy użyciu Notebook LM. Po wgraniu odpowiednich promptów i logotypów, jesteśmy w stanie generować spersonalizowane, świetnie wyglądające slajdy pod konkretnego klienta w zasadzie od ręki. Grafikowi takie zadanie zajęłoby wiele dni.
Druga sprawa to wykorzystanie modeli takich jak Claude do generowania skomplikowanych budżetów lub planów kampanii w Excelu. Agent jest w stanie zaprojektować całą ścieżkę wielokanałową, napisać posty na LinkedIn, maile do newslettera i idealnie rozmieścić je w czasie w arkuszu kalkulacyjnym, dając nam doskonały materiał wyjściowy do modyfikacji.
Ostatnia rzecz to obszerne raporty badawcze. Modele te mogą syntetyzować gigantyczne porcje danych i składać z nich kilkudziesięciostronicowe dokumenty. Konieczne jest tu silne ostrzeżenie przed zjawiskiem halucynacji – trzeba bardzo uważnie sprawdzać podane przypisy, bo statystycznie co dziesiąty link wygenerowany w takim raporcie może kierować w próżnię. Z perspektywy czasu oszczędność wypracowana na wstępnym researchu jest warta tego dodatkowego etapu ludzkiej weryfikacji.
