150 stron z AI. Co działa, a co tylko robi wrażenie?

Chciałem znaleźć pomysły na małe serwisy, które sam miałbym ochotę rozwijać. Coś o konkretnym kawałku świata. O rzece schowanej pod miastem. O torze, który zniknął, ale nadal organizuje krajobraz. O tym, dlaczego jezioro wydaje dźwięki, a latarnia potrafi przekazać wiadomość bez wysyłania powiadomienia.

Tak powstał Atlas małych odkryć: 150 mini-stron przygotowanych z AI. Wszystkie dostały te same wymagania, każda inny temat. Miałem zobaczyć, który z tych małych światów chciałbym rozwijać.

Można było zrobić wielką planszę zrzutów ekranu, napisać „jak można szybko postawić 150 stron” i zakończyć badanie. Planszę zrobiłem. Zakończenie odłożyłem.

Zainteresował mnie AI slop: generowana masowo treść, która wygląda na bardziej wartościową, niż jest. Zwykle rozmawiamy o nim, patrząc na styl obrazów albo czytając przewidywalne teksty. Chciałem zobaczyć, jak rozpoznać go w działającej stronie.

Małe strony o dużej liczbie ciekawych rzeczy

Atlas opowiada o Polsce przez lokalną historię, przyrodę i technikę. Są w nim wydmy Kampinosu i ślady lodowca pod Olsztynem. Młyny nad Radunią i cukrownicze wąskotorówki Kujaw. Miejscowości zatopione przy budowie zbiorników, dawne granice, źródła małych uzdrowisk.

Jedne pomysły mają zachęcić do wycieczki: zobaczenia kwitnących sadów Grójecczyzny, jesiennego lasu czy pozostałości rozebranej kolei. Inne pozwalają pobawić się mechanizmem: sprawdzić pracę turbiny, przepuścić wodę przez stawy albo posłuchać syntetycznego dźwięku pękającego lodu.

Te tematy potrzebują różnych stron. W opowieści o zatopionej wsi ważne jest, skąd pochodzą zdjęcia i co przedstawiają. W kalkulatorze turbiny znaczenie mają liczby. W przewodniku po kwitnieniu trzeba wiedzieć, czy czytamy ogólny opis sezonu, czy aktualną obserwację.

Dlatego samo porównywanie kolorów i krojów pisma szybko przestało mi wystarczać. Przejrzeliśmy kod wszystkich 150 projektów, a wybrane funkcje sprawdziliśmy dokładniej. Szukaliśmy pokrycia dla tego, co strona obiecuje odbiorcy.

Dobry projekt ma związek ze swoim tematem

Przydatna okazała się prosta próba: wyobrazić sobie podmianę tematu. Gdybym zamienił stronę o pompie na opowieść o dawnej wsi, co musiałbym zmienić poza nagłówkiem i zdjęciem?

W modelu pompy liczymy objętość wody. Przy znakach powodziowych trzeba ustalić, względem czego mierzymy wysokość. Plan na deszcz powinien doliczać przejazdy i powrót, bo sam czas spędzony w muzeum nie wyczerpuje dnia.

To jest dla mnie ciekawszy początek rozmowy o designie niż wybór kolejnej palety. Układ strony zaczyna wynikać z tego, co użytkownik ma zrozumieć albo zrobić. Podobny font sam w sobie jeszcze niczego nie dyskwalifikuje.

Suwak suwakowi nierówny

W 47 stronach znalazły się suwaki. Przesuwasz, coś się zmienia, masz poczucie wpływu. Tyle że pod podobnymi kontrolkami kryją się bardzo różne rzeczy.

W „Lodowcu pod miastem” zabudowa staje się przezroczysta i odsłania schemat terenu. To pomoc w patrzeniu, podobna do zdejmowania kalki z rysunku.

W „Jeziorach po martwym lodzie” wybieramy jeden z czterech przygotowanych etapów. Dostajemy ilustrowaną opowieść o powstawaniu jeziora. Strona nie oblicza tempa topnienia i sama to wyjaśnia.

W „Od koła do turbiny nad Bobrem” zmiana przepływu wody uruchamia obliczenie mocy. Można przewidzieć wynik: dwa razy większy przepływ, przy pozostałych ustawieniach bez zmian, daje dwa razy większą moc.

Każde z tych rozwiązań może być dobre. Cztery czytelne sceny bywają bardziej przydatne niż skomplikowana symulacja. Problem zaczyna się wtedy, gdy strona obiecuje więcej, niż robi. Samo zamontowanie suwaka nie zmienia ilustracji w laboratorium.

Można usłyszeć jedno, a zobaczyć co innego

„Głos zamarzającego jeziora” okazał się szczególnie ciekawy. Strona tworzy dźwięk z kilku składowych, dodaje opóźnienia, tłumienie i echo. Zaznacza przy tym, że to dźwięk syntetyczny, a nie nagranie konkretnego jeziora.

Obok jest wykres. Wygląda fachowo, ale sposób jego rysowania gubi szybkie zmiany sygnału. Program zagląda do dźwięku zbyt rzadko. W sprawdzonym przykładzie szybkie drganie daje na takiej siatce dokładnie te same punkty co bardzo wolne. Z punktów można więc narysować przekonującą, lecz mylącą linię.

Odtwarzany dźwięk powstaje osobno, więc ten błąd wykresu nie dowodzi błędu w odsłuchu. Pokazuje za to, dlaczego trzeba sprawdzać części projektu oddzielnie. Rozbudowana synteza dźwięku i źle narysowany wykres mogą spokojnie mieszkać na jednej stronie.

To była jedna z ważniejszych obserwacji. AI potrafi zrobić coś ambitnego, a obok przeoczyć podstawową zależność. Zachwyt nad pierwszym elementem łatwo przenieść na resztę. Przyklejenie całej stronie etykiety „slop” byłoby z kolei równie mało pomocne: jest tu mechanizm, który warto rozwijać.

9000 testów i jedno pominięte pytanie

W projekcie o Stawach Milickich sterujemy dopływem i odpływem wody w trzech umownych zbiornikach. Sprawdziliśmy 9000 kombinacji ustawień dla pojedynczego kroku. Wszystkie przeszły testy.

Testy pilnowały kilku rzeczy: żeby poziomy mieściły się w dozwolonym zakresie, odłączony staw się nie zmieniał, a przyrost zgadzał się z raportem programu. Przydatne kontrole. Tyle że nie sprawdzały, czy przyjęte tempo dopływu jest właściwe.

Zrobiliśmy więc dodatkową próbę. W kopii kodu uruchomionej na potrzeby analizy zmniejszyliśmy o połowę współczynnik dopływu. Program mógł przydzielać mniej wody. Wszystkie 9000 przypadków nadal przeszło.

Wersja bardziej oszczędna w wodę dostała dokładnie tyle samo zielonych znaczków.

Nie ustaliliśmy w ten sposób, która wersja lepiej opisuje prawdziwe stawy. Ustaliliśmy, czego testy nie potrafią rozstrzygnąć. Liczba sprawdzeń brzmi imponująco, ale trzeba jeszcze wiedzieć, jakie pytania zadaliśmy i skąd znamy prawidłową odpowiedź.

Dla kalkulatora turbiny możemy policzyć prosty przykład niezależnie i porównać wynik. Dla prawdziwych stawów potrzebowalibyśmy danych o ich wielkości, przepływach i czasie. Ten projekt używa jednostek umownych i o tym informuje.

Druga AI też nie dostaje ostatniego słowa

Zleciłem dodatkową ocenę w Antigravity. Audyt trafnie zakwestionował traktowanie przechodzących testów jako dowodu poprawnej fizyki. Zarzucił też modelowi, że przy prawie pełnych stawach woda „znika”.

Po sprawdzeniu kodu sprawa okazała się mniej jednoznaczna. Model przyjmuje tylko tyle wody, ile mieści się w zbiornikach. Nie opisuje, co dzieje się z potencjalną nadwyżką. To ważne ograniczenie, które trzeba wyjaśnić. Samo w sobie nie dowodzi jeszcze błędu w bilansie przyjętej wody.

Druga AI pomogła postawić lepsze pytania. Jej pewny ton nie zwalniał nas ze sprawdzania odpowiedzi.

Slop potrafi wyglądać na skończoną pracę

Po tych sprawdzeniach najbardziej interesuje mnie luka między obietnicą a działaniem. Strona wygląda na przemyślaną. Wykres sugeruje pomiar. Suwak sugeruje obliczenie. Zielone testy sugerują, że ktoś już wszystko sprawdził.

AI slop widzę tam, gdzie te oznaki wykonanej pracy zaczynają zastępować samą pracę. Prosta ilustracja może być świetna, jeśli pomaga zrozumieć temat i uczciwie mówi, czym jest. Rozbudowany panel może zawodzić, jeśli jego wiarygodność kończy się na wyglądzie.

W pracy zawodowej dochodzi do tego workslop: materiał wyglądający na gotowy, który przerzuca niedokończoną robotę na odbiorcę. Ktoś musi odtworzyć założenia, sprawdzić liczby i poprawić błędy. Gotowy interfejs przychodzi z ukrytym zleceniem: „teraz sprawdź za mnie resztę”.

Prototyp ma prawo zostawiać otwarte pytania. W Atlasie właśnie po to je budowałem, żeby wybierać i sprawdzać. Gdybym jednak przekazał je komuś jako gotowe przewodniki, oczekiwania byłyby zupełnie inne. Szybkość wygenerowania strony to tylko część pracy potrzebnej do uzyskania użytecznego serwisu.

Co rozwijałbym dalej

W tych 150 projektach widzę sporo punktów startowych. Żeby wyjść poza slop, zacząłbym od jednej konkretnej obietnicy wobec odbiorcy.

Stronę o zatopionej wsi rozwijałbym wokół porównania „wtedy i dziś”, ze źródłami zdjęć i datami. Stronę o latarniach wokół rozpoznawania rytmu światła. Stronę o turbinie wokół zrozumienia, skąd bierze się moc.

Potem sprawdziłbym tę obietnicę. Czy użytkownik odróżnia historyczne zdjęcie od współczesnego widoku? Czy rozpoznaje sygnał latarni? Czy potrafi przewidzieć skutek zwiększenia przepływu wody? To są badania, które chciałbym zrobić. Sama analiza kodu ich nie zastąpi.

Przy wyborze kolejnej strony do rozwijania chcę umieć wskazać jedną rzecz, którą ktoś dzięki niej naprawdę zrozumie albo zrobi. Dopiero wtedy będę się spierał o kolor przycisku.