W pierwszej części opisałem, co kryje się za prostą bezpłatną apką. W drugiej, jak wyglądał weekend, w którym ta apka się zepsuła.
W pierwszej części opisałem, co kryje się za prostą bezpłatną apką. W drugiej, jak wyglądał weekend, w którym ta apka się zepsuła. Ta część jest o tym, dlaczego strona www, aplikacja webowa i oprogramowanie w potocznej mowie zlewają się w jedną rzecz, choć niosą zupełnie inną odpowiedzialność i inne ryzyko.
Trzy różne rzeczy, które wyglądają tak samo
Przy stronie www zawsze jest się między użytkownikiem a błędem. Przy aplikacji desktopowej nie. Gdy apka się wywali, wywala się człowiekowi na komputerze. Gdy źle się pilnuje uprawnień, sięga do jego danych. A gdy trzeba ją naprawić, trzeba mieć nadzieję, że pobierze nową wersję.
Czym strona www w ogóle się nie zajmuje
Do różnicy w ryzyku dochodzą rzeczy, z którymi przy stronie nigdy się nie spotkamy: podpisywanie aplikacji, uprawnienia systemu operacyjnego, zachowanie przy usypianiu i wybudzaniu, różne wersje systemu, różne komputery, instalacja, odinstalowanie. Nic z tego AI nie potrafi rozwiązać za Państwa, bo nic z tego nie dotyczy pisania kodu.
Znaki diakrytyczne w nazwie pliku zepsuły podpis aplikacji. Zaostrzony tryb uruchomieniowy macOS po cichu wyłączył dostęp do kalendarza, więc apka udawała, że jest w porządku, a przy tym nie działała. Przeciągnięcie do kosza zostawiło po sobie ustawienia, uruchamianie po zalogowaniu i wpis w systemowym Pęku kluczy. Żadna z tych rzeczy nie dodała użytkownikowi funkcji, a bez żadnej z nich apki nie dałoby się nikomu dać.
Po co to w ogóle pokazujemy
Właściciele firm i osoby decydujące o budżetach zwykle nie mają zaplecza technicznego. To całkowicie w porządku, to nie ich dziedzina. Ma to jednak jeden praktyczny skutek: nie odróżniają strony internetowej, aplikacji webowej i oprogramowania. Wszystko wygląda jak ekran, na którym coś świeci. A gdy te trzy rzeczy zlewają się w jedną, nie da się oszacować, ile pracy za nimi stoi ani kto potrafi ją wykonać.
Ptáček to mała apka. Właśnie dlatego można na niej pokazać, co znaczy mała. Jeden dzień funkcjonalności i dwukrotność czasu na rzeczy, których nie widać.
Gdzie jest granica między Vibe Codingiem a produkcją
Nie mam nic przeciwko Vibe Codingowi, sam go uczę i używam codziennie. Po pięciu tysiącach godzin z AI mam dość jasny obraz, gdzie leży granica.
Gdzie Vibe Coding działa świetnie: narzędzie wewnętrzne dla Państwa i trzech współpracowników, kalkulator na miarę, prototyp, który komuś pokazuje się na ekranie, skrypt, który w piątek oszczędzi dwie godziny. Rzeczy, w których jest się jednocześnie autorem i jedynym użytkownikiem i w których błąd oznacza, że próbuje się jeszcze raz.
Gdzie przestaje wystarczać: gdy dotknie tego ktoś obcy. Klient, współpracownik z innej firmy, odwiedzający stronę, człowiek, który to pobierze. W tym momencie nie chodzi już o to, czy to działa, ale o to, co się stanie, gdy nie działa. A to inna dyscyplina niż pisanie kodu.
Kilka wskazówek do Vibe Codingu
To nie są ogólne rady z internetu. To siedem rzeczy, które wypracowaliśmy na apce Ptáček, część boleśnie, w weekend, gdy się zepsuła.
Przetestować czystą instalację. Usunąć apkę i całe ustawienia i zainstalować ją od nowa, jakby widziało się ją pierwszy raz. U nas od razu ujawniło to trzy rzeczy. Czytając kod, nie znaleźlibyśmy żadnej z nich.
Kazać oponować wynikowi drugiemu modelowi, który o pierwszym nie wie. Nie tym samym modelem po raz drugi, innym, z innym zadaniem. Gdy apka w weekend się zepsuła, puściliśmy dwa niezależne audyty i żaden nie wiedział o drugim. Zgodziły się co do przyczyny, a jeden dodatkowo poprawił drugiego w szczególe.
Pytać, co się stanie, gdy to zawiedzie. Model odpowiada tylko na pytania, które dostaje. Odziedziczonego kanału aktualizacji wskazującego na repozytorium obcego autora AI sama nam nie wspomniała, bo nikt jej o to nie pytał. Potrafi to znaleźć, tylko trzeba wiedzieć, o co pytać.
Trzymać ostatni działający stan i umieć do niego wrócić. W trzy dni poprawek zrobiliśmy trzy powroty o krok wstecz. Bez tego nie byłyby to trzy błędy po drodze, ale jeden nienaprawialny.
Testy pisać przede wszystkim na to, co coś usuwa lub zmienia. W Ptáčku jedyna funkcja, która coś usuwa, to odinstalowanie, i ma własne testy na to, że nie usunie niczego innego. Reszta apki tylko czyta i wyświetla.
Nie dawać modelowi tajemnic. Adres kalendarza jest faktycznie hasłem, kto go zna, widzi, kiedy ma się spotkania. Nie należy do pliku konfiguracyjnego, a tym bardziej do logu.
Odróżniać błąd, który się wywala, od błędu, który milczy. Awarię widać od razu. Pusta odpowiedź, którą apka ocenia jako brak spotkań, podczas gdy w ustawieniach świeci na zielono, że wszystko w porządku, jest gorsza, bo nie wiadomo o niej, dopóki nie ucieknie spotkanie.
Dlatego uczymy tego tak
Na warsztatach Vibe Codingu nie mówimy ludziom, że teraz zbudują produkt. Mówimy im, że zbudują narzędzia dla siebie i dla zespołu, i to jest ogromna wartość.
A jednocześnie pokazujemy im dokładnie tę granicę, o której jest ten artykuł. Żeby wiedzieli, kiedy mogą zbudować apkę sami, a kiedy potrzebny jest ktoś, kto zadaje niewygodne pytania. Bo najdroższy wariant to taki, w którym ktoś wypuszcza w świat aplikację z danymi klientów i dowiaduje się o tym dopiero wtedy, gdy jest za późno.
Sprawdzić, komu się to zleca, można u każdego. Także u nas.
I pytanie do Państwa: gdzie jest u Państwa ta granica? Gdzie Vibe Coding puszczają Państwo sami, a gdzie wzywają już kogoś, kto ma w tym przepracowane lata?
Artykuł pierwotnie ukazał się na LinkedInie. Oryginalny artykuł na LinkedInie
