LiveOS - mój pierwszy duży projekt vibe coding z AI - case study

LiveOS - mój pierwszy naprawdę duży projekt zbudowany metodą vibe coding

LiveOS jest trochę innym projektem w moim portfolio. Nie dlatego, że zastosowałem w nim jakiś genialny proces UX. I zdecydowanie nie dlatego, że zaprojektowałem jego interfejs.

Bo nie zaprojektowałem.

LiveOS powstawał metodą vibe coding i zarówno kod, jak i duża część decyzji dotyczących wyglądu interfejsu były generowane przy pomocy AI. Dzisiaj pewne rzeczy zrobiłbym w nim zupełnie inaczej. I właśnie dlatego chcę go tutaj pokazać.

To był jeden z pierwszych projektów, przy których przestałem używać AI wyłącznie do wygenerowania kawałka kodu, a zacząłem traktować je jak narzędzie pozwalające mi budować większą aplikację. Szybko okazało się, że „napisz aplikację” oraz „zbuduj działający produkt” to dwie kompletnie różne rzeczy.

Problem zaczął się podczas transmisji LIVE

Prowadząc transmisję na żywo, mam jeden zasadniczy problem: dużo rzeczy dzieje się jednocześnie. Jest transmisja, OBS, sceny, interakcje z widzami, czat, elementy sterowane podczas programu i dodatkowe narzędzia działające gdzieś obok. A czat? Czat potrafi lecieć jak wodospad.

Standardowy sposób jego wyświetlania niekoniecznie jest wygodny, kiedy jednocześnie prowadzisz program, patrzysz w kamerę, reagujesz na widzów i sterujesz resztą transmisji. Do tego dochodził drugi problem, który interesował mnie jeszcze bardziej: brak pamięci o widzu.

Jeżeli ktoś regularnie pojawia się na transmisjach, aplikacja nie buduje z prowadzącym żadnego kontekstu. Każda kolejna wiadomość jest po prostu kolejnym wpisem na czacie. A ja chciałem, żeby moje narzędzie wiedziało trochę więcej. Chociażby to, jak dana osoba ma na imię.

Nie chodziło więc wyłącznie o stworzenie kolejnego okna z czatem. Chciałem zbudować własne środowisko do obsługi LIVE, które z czasem można rozwijać dokładnie pod sposób, w jaki prowadzę transmisje.

I tak zaczął powstawać LiveOS.

Nazwa trochę zdradza ambicję

„OS” nie znalazło się w nazwie przypadkiem. Od początku myślałem o aplikacji nie jak o jednym małym narzędziu, tylko jak o centrum sterowania transmisją. Miejscu, które może komunikować się z innymi elementami mojego setupu i stopniowo przejmować zadania rozsiane wcześniej pomiędzy różnymi aplikacjami.

Jednym z ważnych elementów tego eksperymentu było połączenie LiveOS z moim środowiskiem transmisyjnym.

Aplikacja działała lokalnie i posiadała własne API sterujące. Dzięki temu mogłem komunikować ją między innymi ze Stream Deckiem i elementami wykorzystywanymi podczas pracy z OBS-em. I tu zaczęła się moja właściwa edukacja z vibe codingu.

„AI napisało kod” brzmi łatwo. Do pierwszego błędu.

Przy małym eksperymencie vibe coding potrafi wyglądać magicznie: piszesz, czego potrzebujesz, AI generuje kod. uruchamiasz i działa.

Człowiek przez chwilę zaczyna podejrzewać, że programiści przez ostatnie kilkadziesiąt lat po prostu niepotrzebnie komplikowali sprawę.

A potem projekt rośnie. I nagle coś przestaje działać.

W LiveOS miałem chociażby sytuację, w której aplikacja teoretycznie działała poprawnie, ale przyciski ze Stream Decka przestały się z nią komunikować. Powód? LiveOS uruchomił swoje Control API na lokalnym porcie 17892, podczas gdy część konfiguracji i wywołań nadal próbowała dostać się pod 17891.

Efekt był prosty: aplikacja działała, API działało, Stream Deck działał - tylko razem nie działało nic. I właśnie takie momenty były dla mnie w tym projekcie najcenniejsze.

Vibe coding bardzo szybko przestał oznaczać: „powiedz AI, żeby coś zrobiło”. Zaczął oznaczać: „zrozum, co właściwie zostało zbudowane, sprawdź, gdzie przepływ się rozjechał, znajdź problem i dopiero wtedy wykorzystaj AI do jego rozwiązania”.

To ogromna różnica.

LiveOS nie był projektem UI/UX

To chcę zaznaczyć szczególnie mocno.

Nie projektowałem interfejsu LiveOS.

Nie powstał wcześniej kompletny projekt w Figmie. Nie projektowałem każdego komponentu, nie budowałem własnego design systemu ani nie traktowałem tej aplikacji jako prezentacji swoich kompetencji UI.

Interfejs w dużej mierze powstawał bezpośrednio podczas pracy z AI.

Ja definiowałem problemy, funkcjonalności i to, co aplikacja powinna robić. AI proponowało i generowało rozwiązania - również wizualne - a później całość była iterowana. To rozróżnienie jest dla mnie ważne.

Pokazywanie LiveOS jako „mojego projektu UI” byłoby zwyczajnie nieuczciwe. Mogę natomiast pokazać go jako projekt produktowy i eksperyment z AI, bo właśnie tutaj wykonałem ogromną pracę: nie przy dobieraniu promienia zaokrąglenia przycisku, a przy wymyślaniu, testowaniu i łączeniu całego mechanizmu.

I właśnie dzięki temu zobaczyłem, gdzie AI projektuje źle

Pozostawienie dużej części UI sztucznej inteligencji było jednocześnie ciekawym eksperymentem. Aplikacja może być technicznie poprawna i nadal być niewygodna, a najlepszym przykładem był sam czat.

Jedną z podstawowych potrzeb, od których zaczynał się LiveOS, było przecież ułatwienie mi pracy z szybko zmieniającą się rozmową podczas transmisji. Tymczasem wraz z rozwojem projektu pojawiał się klasyczny problem narzędzi budowanych funkcja po funkcji: informacji zaczyna być za dużo.

• AI jest całkiem dobre w zaprojektowaniu pojedynczego panelu.

• Dodaj kartę.

• Dodaj przycisk.

• Dodaj kolejną informację.

• Dodaj status.

• Dodaj sekcję.

• Każda pojedyncza decyzja może wydawać się logiczna.

Po kilkudziesięciu takich decyzjach człowiek patrzy na całość i orientuje się, że właśnie stworzył kokpit Boeinga do czytania komentarza „XD”. To była jedna z ważniejszych lekcji z LiveOS. Funkcjonalność nie jest tym samym co użyteczność.

Vibe coding nie sprawił, że zostałem programistą

I nie taki był cel. Nie będę udawał, że po zbudowaniu LiveOS potrafię usiąść przed pustym edytorem i napisać od zera całą aplikację bez pomocy AI.

Ale zacząłem znacznie lepiej rozumieć, jak rozmawiać z AI o produkcie i kodzie, jak dzielić duży problem na mniejsze, jak testować efekt zamiast zakładać, że skoro AI napisało „fixed”, to faktycznie cokolwiek naprawiło, jak opisywać błąd, jak szukać zależności, jak nie pozwolić kolejnym promptom bez końca doklejać nowych warstw do rozwiązania, które należałoby już uporządkować.

Najważniejszą rzeczą, którą zbudowałem w LiveOS, nie był LiveOS

Był nią mój własny sposób pracy z AI. To właśnie na takich projektach zacząłem zauważać, że vibe coding nie musi oznaczać produkowania małych jednorazowych aplikacji.

Może być sposobem tworzenia bardzo konkretnych narzędzi pod własne potrzeby - nawet jeśli osoba, która je tworzy, nie jest klasycznym programistą. Trzeba tylko zaakceptować jedną rzecz: im większa aplikacja, tym mniej wystarcza samo „vibe”.

Potrzebne zaczynają być wymagania, architektura, testowanie, kontrola zmian i coraz bardziej świadome podejmowanie decyzji. LiveOS był moim pierwszym dużym zderzeniem z tą rzeczywistością, dalekim od idealnego.

Od projektu, w którym głównie sprawdzałem: „ciekawe, czy AI da radę to zrobić?”, zacząłem przechodzić do pytania: „jak mam poprowadzić AI, żeby zbudowało dokładnie taki produkt, jakiego potrzebuję?”

I to już jest zupełnie inny poziom zabawy.

Bezpłatna konsultacja