Kategoria: Automatyzacja i autonomia
Zdanie, które najczęściej kończy pokaz prototypu, brzmi: „to już prawie gotowe”.
Nie pada ze złej woli. Pada, bo prototyp zbudowany z pomocą modelu językowego naprawdę tak wygląda, i to jest najpoważniejsza zmiana w mojej pracy z ostatnich lat. Opisuję tu własny proces, nie rekomendację dla nikogo. Liczby w tym tekście to wyłącznie liczebniki: ile kroków, ile pytań. Nie ma tu pomiaru przyspieszenia ani oszczędzonego czasu, bo takiego pomiaru dla żadnego z tych prototypów nie mam.
Od czego zaczynam dzisiaj
Zrzut ekranu zamiast opisu
Jeszcze w 2023 roku droga od pomysłu do działającego prototypu prowadziła przez jedną z trzech rzeczy: naukę programowania, wynajęcie programisty albo tygodnie w narzędziach projektowych, w których kolorowe prostokąty udawały produkt. Dziś opisuję funkcję, dołączam zrzut ekranu i mam klikalną, podłączoną do danych aplikację tego samego dnia.
Dlatego nie zaczynam już od pomysłu w formie zdania. Zaczynam od czegoś konkretnego: zrzutu ekranu produktu, który chcę rozszerzyć, szkicu na papierze albo wskazania narzędzia wewnętrznego, które ma działać inaczej. Model pracuje zupełnie inaczej, kiedy może zobaczyć, co mam na myśli, niż kiedy tylko czyta, co napisałem. U mnie sam opis tekstowy daje najbardziej rozstrzelone wyniki: ta sama instrukcja, za każdym razem inna interpretacja. Dołączony obrazek usuwa większość tej niejednoznaczności i to on, nie długość promptu, decyduje o pierwszej wersji.
Plan przed kodem
Pierwszy prompt nigdy nie brzmi „zbuduj to”
Pierwsze polecenie w każdej sesji brzmi odwrotnie, niż podpowiada pokusa: opisz plan i nie pisz kodu. W praktyce proszę o role użytkowników i ich przepływy, o listę ekranów wraz z odpowiedzialnością każdego z nich, o komponenty i ich stany oraz o propozycję etapów wdrożenia. Dopiero na końcu dopisuję, że w tej turze nie ma powstać ani jedna linia kodu.
To, co z tego wychodzi, jest lekkim dokumentem wymagań i pełni dalej trzy funkcje. Jest punktem odniesienia między sesjami, kiedy kontekst rozmowy już się nie mieści. Jest listą kontrolną zakresu, do której wracam, gdy pojawia się pomysł na coś poza planem. I jest miejscem, w którym widać, że model zaczął przyjmować założenia, na które nie dostał zgody. Dla kogoś, kto przez lata pisał analizy i specyfikacje, to nie jest nowy gatunek dokumentu, ponieważ nowe jest tylko tempo, w jakim powstaje.
Małe kawałki i klikanie po każdym
Cztery kroki zamiast jednego zlecenia
Zamiast jednego polecenia w rodzaju „zbuduj cały moduł rezerwacji, płatności i analityki” rozbijam pracę na kawałki, które da się przejrzeć. W jednym z moich prototypów wyglądało to tak:
- lista pozycji do rezerwacji i prosta strona edycji,
- konfiguracja pozycji: parametry, czas trwania, ustawienia,
- podgląd rezerwacji dla odbiorcy końcowego,
- podstawowy przepływ potwierdzenia płatności.
Po każdym kroku przechodzę przez przepływ ręcznie, wyłapuję to, co widać od razu, i poprawiam plan, zanim zlecę kolejny kawałek. Do tego doszedł nawyk, który oszczędza mi najwięcej zawracania: kiedy nie wiem, jak model zabierze się do danej funkcji, każę mu najpierw opisać swoje podejście, bez pisania kodu. Decyzja architektoniczna wychodzi wtedy na wierzch, kiedy jest jeszcze tania.
Statyczne makiety i „X, ale lepszy”
Przestałem budować statyczne makiety, które ktoś potem przez miesiące przekłada na kod. Przestałem też rysować prostokąty na tablicy i nazywać to projektem interfejsu. Skoro w tym samym czasie powstaje rzecz klikalna, makieta nie ma już czego dowodzić.
Druga rzecz, z którą skończyłem, to zaczynanie od „X, ale lepszy”. Cmentarz takich produktów był pełny, zanim modele językowe cokolwiek przyspieszyły; one tylko ułatwiły kopanie. Zamiast tego szukam procesów niewidocznych i bolesnych: przepływów, które nadal stoją na arkuszach i łańcuchach maili, bo nikt nie miał czasu ich uporządkować, oraz styków dwóch branż, które nigdy ze sobą nie rozmawiały. Przed pierwszym promptem zadaję trzy pytania:
- Czy jest konkretny ból, który odczuwam regularnie i którego żadne narzędzie nie rozwiązuje? Nie chodzi o „rozwiązuje niedoskonale”, ale o „nie rozwiązuje wcale”.
- Czy w mojej branży jest proces, który w 2026 roku nadal stoi na arkuszu i mailu?
- Czy jest zestaw możliwości, który AI otwiera dziś, a dwa lata temu był niedostępny?
Moją przewagą w tej pracy nie jest to, że „też potrafię promptować”. Jest nią to, że po latach w RPA, hiperautomatyzacji i integracjach wiem, jak wyglądają procesy, tryby awarii i przypadki brzegowe oraz co psuje się dopiero na produkcji. Model przyspiesza ten sąd w dowolnym kierunku, w który go skieruję, i właśnie dlatego kierunek waży dziś więcej niż samo tempo.
Gdzie AI pogarsza prototyp
Wygląd wyprzedza architekturę
Prototyp wygląda profesjonalnie od pierwszej wersji, bo model widział miliony istniejących interfejsów. Z bliska widać inne rzeczy: słabą hierarchię, niekonsekwentne odstępy, nadmiar kolorów, które ze sobą walczą, i wzorce przeniesione z zupełnie innego kontekstu. Poproszony o „stronę profilu” bez dodatkowych warunków, model oddaje profil społecznościowy w stylu LinkedIna wtedy, gdy potrzebny był zadaniowy panel monitorowania procesu. Takie ekrany są dobre z daleka i daleko od dobrych. Ryzyko nie polega na tym, że wyglądają źle, lecz na tym, że wyglądają wystarczająco dobrze, by ktoś zatwierdził na ich podstawie kierunek.
Drugi sposób, w jaki model pogarsza prototyp, to tempo narastania funkcji. Kiedy kolejna funkcja kosztuje godzinę, najtrudniejszą umiejętnością przestaje być budowanie, a zaczyna odmawianie. Tryb awarii jest zawsze ten sam: prototyp rośnie szybciej, niż da się go wytłumaczyć, i po kilku tygodniach nikt, włącznie z autorem, nie umie wymienić wszystkich jego funkcji ani powiedzieć, które z nich jeszcze działają.
Trzeci jest najcichszy. Model wypełnia luki w instrukcji najczęstszym wzorcem ze swoich danych treningowych. Za każdym razem, kiedy zatwierdzam coś, bo „wygląda w porządku”, nie rozumiejąc założenia, które za tym stoi, to założenie osadza się głębiej.
Moment, w którym prototyp trzeba przepisać
Koszt nie leży w kodzie
Kiedy w końcu widzę, że model źle odczytał kontekst, przepisanie kodu nie jest problemem, ponieważ model potrafi napisać go od nowa niemal natychmiast. Koszt leży w tym, co wyrosło na złym fundamencie: w decyzjach, w drobnych przepływach między ekranami i w obrazie, jaki wszyscy zaangażowani zdążyli sobie zbudować na temat tego, jak ta rzecz ma działać.
Dlatego momentem przepisania nie jest dla mnie „kod zrobił się brzydki”. Jest nim chwila, w której okazuje się, że błędne jest założenie z fundamentu, a na tym założeniu już coś stoi. Po tej granicy łatanie wychodzi drożej niż start od nowa, a start od nowa jest tani dokładnie o tyle, o ile wcześniej powstał plan z drugiego kroku.
Ponieważ te prototypy wyglądają i zachowują się jak produkty, pozwalają całemu zespołowi ominąć testy z użytkownikami, analizę przypadków brzegowych, przegląd bezpieczeństwa i pytania eksploatacyjne. Dlatego mówię to za każdym razem wprost: to jest prototyp, który sprawdza pomysł, i zmienimy go albo wyrzucimy w zależności od tego, czego się z niego dowiemy. Kiedy prototyp dotyczy modelu językowego, dochodzi jeszcze pytanie, gdzie ten model ma działać; mam na nie własną odpowiedź i opisałem ją osobno w tekstach jak uruchamiam lokalny model na llama.cpp i LiteLLM oraz jaki model wybrać na mini PC.
Prototyp nie jest dowodem, że to wytrzyma produkcję
Nie daje systemu produkcyjnego. Obsługa wyjątków, logowanie, monitoring i bezpieczeństwo są w prototypie ledwo dotknięte, a to one decydują, czy rzecz przetrwa pierwszy tydzień u prawdziwych użytkowników. Demo powstaje dziś znacznie szybciej niż kiedyś; produkcja nie powstaje szybciej wcale.
Nie daje sądu o produkcie. Im mniej precyzyjnie kieruję modelem, tym pewniej dostaję średnią z internetu: rozwiązanie statystycznie najczęstsze, a nie właściwe dla tego procesu. Nie daje też wytrwałości, ponieważ technologia obsługuje budowanie, nie obsługuje zostawania przy temacie, kiedy przez kilka tygodni nic z tego nie wynika.
I nie daje liczby. Nie mam zmierzonego przyspieszenia ani oszczędzonego czasu dla żadnego z tych prototypów, więc żadnej takiej liczby tu nie podaję. Granice samego narzędzia, na którym część tej pracy stoi, policzyłem natomiast osobno: czego lokalne AI nie zrobi.
