Interfejs bez trwałej warstwy
Jeszcze do niedawna AI w frontendzie oznaczało głównie generowanie kodu komponentów, które potem trafiały do repozytorium i były utrzymywane jak zwykła aplikacja. W przypadku Cuttlekit sugerowany jest inny model, w którym UI staje się odpowiedzią modelu, a nie stałym elementem projektu. Zamiast klasycznego cyklu build–deploy–maintain pojawia się podejście oparte na promptach, danych i generowaniu HTML dokładnie wtedy, gdy jest potrzebny.
Nowy sens pojęcia aplikacji
Z udostępnionych zapowiedzi wynika, że Cuttlekit ma generować pełne, interaktywne UI w czasie odpowiedzi, bez sztywnego frameworka i bez wcześniej przygotowanej warstwy wizualnej. W demie pojawiają się odniesienia do zewnętrznych danych i dynamicznej prezentacji, między innymi na bazie informacji z Linear i Notion oraz materiałów reklamowych tworzonych w różnych stylach. Taki model sugeruje, że interfejs przestaje być produktem samym w sobie, a zaczyna działać jak tymczasowa powierzchnia robocza dla jednego zadania.
Branża zaczyna iść w tym samym kierunku
Pomysł nie pojawia się w próżni, ponieważ w ostatnich dniach kilka dużych firm pokazało podobny zwrot w stronę osadzanych i generowanych interfejsów. Vercel ogłosił pełne wsparcie dla MCP Apps w Next.js, Stack Overflow opisywał MCP Apps jako sposób na przenoszenie bogatszych interakcji niż sam tekst, a społeczność Cursora pokazała interaktywne widoki HTML trafiające bezpośrednio do czatu agenta. To wyraźnie pokazuje, że sam tekst przestaje wystarczać tam, gdzie użytkownik ma pracować na danych, stanach i konfiguracji.
Od produktu do jednorazowego epizodu
Klasyczna aplikacja jest zwykle projektowana z myślą o wielu użytkownikach i wielu przyszłych scenariuszach, dlatego zawiera zestaw stałych ekranów i z góry przewidzianych ścieżek. Generative UI odwraca tę logikę, bo interfejs może być budowany dla jednej osoby, jednego problemu i jednego momentu pracy. SAP opisał ten kierunek jako software w modelu batch size 1, czyli oprogramowanie dopasowywane do pojedynczego przypadku zamiast projektowania wszystkiego z wyprzedzeniem.
Koszt utrzymania staje się głównym celem
Największa obietnica tego podejścia nie dotyczy wyłącznie szybkości tworzenia ekranów, lecz tego, że można ograniczyć długoterminowy koszt utrzymania UI. W tradycyjnym podejściu problemem są zależności, migracje frameworków, rozjazdy design systemu, poprawki responsywności, testy regresji i stale rosnąca liczba edge case’ów. Jeśli interfejs jest generowany od nowa przy wywołaniu, część tych kosztów może zostać przesunięta z utrzymania komponentów na kontrolę danych wejściowych, polityk bezpieczeństwa i sandboxu renderowania.
Tu kończy się efekt demo
Marketingowa atrakcyjność takiego rozwiązania jest oczywista, ale w praktyce wszystko rozbija się o przewidywalność, bezpieczeństwo i wydajność. Sam fakt, że model umie wygenerować estetyczny HTML, nie wystarcza, jeśli nie potrafi robić tego powtarzalnie i bezpiecznie w dłuższych workflowach. Właśnie dlatego tak ważne są dziś narzędzia agentowe, długi kontekst i kontrola użycia tooli, bo bez tej infrastruktury generative UI pozostanie efektowną demonstracją zamiast realnej warstwy pracy.
Luka między rozmową a użytecznością
Wiele współczesnych aplikacji AI ma mocne modele, ale nadal korzysta z interfejsów zaprojektowanych jak klasyczne SaaS-y z poprzedniej dekady. Chat jest wygodny do zadawania pytań, jednak słabo sprawdza się przy porównywaniu danych, konfiguracji procesów czy pracy na wielu stanach jednocześnie. Jeśli model potrafi sam ułożyć właściwy zestaw tabel, kart, przycisków i podglądów, wtedy tarcie między rozumowaniem AI a praktyczną obsługą produktu zaczyna realnie spadać.
Nie każdy frontend nadaje się do zastąpienia
Teza o końcu klasycznego frontendu jest przesadzona, ponieważ w wielu obszarach nadal liczy się deterministyczny, audytowalny i testowalny interfejs. Systemy transakcyjne, aplikacje wymagające zgodności, rozwiązania z wysokimi wymaganiami accessibility oraz procesy o stabilnej logice biznesowej nadal potrzebują stałej warstwy UI. Generative UI może jednak przejąć obszar narzędzi ad hoc, paneli roboczych i agentowych nakładek, gdzie najważniejsza jest szybkość i dopasowanie do kontekstu.
Miejsca, w których to ma sens
Najbardziej naturalne zastosowania dotyczą sytuacji, w których interfejs ma charakter tymczasowy i zadaniowy. Chodzi przede wszystkim o jednorazowe analizy danych, robocze panele agentów, formularze zależne od kontekstu oraz kreatywne narzędzia, w których sama prezentacja jest częścią odpowiedzi modelu. Znacznie słabiej taki model pasuje tam, gdzie wymagany jest stabilny kontrakt UI i wielomiesięczna przewidywalność zachowania, bo wtedy elastyczność zaczyna kolidować z kontrolą.
