Windsurf w praktyce – pierwsze dni pracy nad aplikacją dla klienta
Zapraszam na kolejny wpis z serii pisanej w duchu #buildinpublic. Dziś opowiem o tym co osiągnąłem ze pomocą Windsurf przez pierwsze kilka dni pracy nad aplikacją, o której pisałem w poprzednim wpisie.
TL;DR;
Piszę dla klienta pełnoprawną aplikację mimo, że nie jestem zawodowym programistą. Wnosi ona realną wartość – obniża koszty, przyspiesza procesy. Jeszcze 3 miesiące temu byłoby to niemożliwe i prawie zrezygnowałem tego projektu (miałem go zlecić na rynek). Na szczęście byłem uparty, pilnie się uczyłem i… pojawił się Windsurf.
Teraz każdy wieczór przynosi mi masę frajdy. Czuję się jak posiadacz zaczarowanego ołówka. Fakt – trzeba umieć trochę rysować, mieć dużo cierpliwości i pustych kartek. Czasem przydaje się też magiczna gumka, czyli Git. Wszystko to jednak nie przeszkadza mi robić postępy dla mnie wcześniej nieosiągalne.

Trudne początki z Claude Dev/Cline, Cursor, Windsurf
W poprzednim wpisie opisałem jak wyglądały pierwsze tygodnie, w których (natchniony nagraniami AiCodeKing’a) próbowałem używać wielu narzędzi AI nie mając zbyt dużego pojęcia o architekturze Laravel i o zaawansowanej składni PHP.
Skończyło się to… głęboką frustracją. Uznałem w pewnym momencie, że AI jest jeszcze za głupie i nie ma szans abym zdołał to napisać!

Na szczęście założyłem wtedy (słusznie!), że to ja jestem za głupi. Zabrałem się za oglądanie kursów na Udemy i Laracasts (są opisane w tej notce). Kilka dni spędziłem w normalnym VS Code (bez wtyczek do AI) i pracowałem nad zdobyciem solidnych podstaw – czyli zrozumieniu jak działa Laravel.
Po tych kursach wiedziałem, że Laravel jest super i potrafię w nim napisać proste rzeczy. Miałem też pewność, że moja aplikacja jest w nim możliwa do napisania. Nadal jednak brakowało mi doświadczenia kogoś, kto napisał kilka(naście) takich systemów. Potrzebowałem pomocy kogoś (czegoś?) znającego kod i potrafiącego w nim napisać to co wymyślę.
Windsurf (i podobne edytory) to turbo dla mojej (i Twojej) wiedzy
Mając te podstawy wróciłem do Windsurf’a. Nagle okazało się, że:
- wcześniej nie potrafiłem w ogóle chodzić i każdy krok (nieważne w jakich butach) kończył się wywrotką,
- po kursach z Laravel poczułem, że nawet bez wsparcia AI mogę powolutku dreptać w kierunku mojego celu,
- po odpaleniu Windsurf poczułem, że moje nieśmiałe kroczki zmieniły się w ogromne susy, które czasem nawet powodują wypadki (nadal nie jestem zawodowcem) ale mój cel zbliża się 10x szybciej niż bez AI.
Czyli – musisz coś wiedzieć, inaczej budowanie zaawansowanych aplikacji może skończyć się frustracją. Jeśli przekroczysz pewien próg wiedzy, pozwalający rozumieć błędy popełniane przez AI oraz wydawać precyzyjne polecenia – twój projekt niesamowicie przyspieszy.
Co to jest Windsurf?
Windsurf to edytor kodu bazujący na Visual Studio Code i będący konkurencją dla Cursora. Jest powiązany z Twoim kontem na Codeium, do którego możesz przypisać darmową lub płatną subskrypcję na zestaw usług wspierających tworzenie kodu. Możesz z nich korzystać albo z poziomu Windsurf albo w Visual Studio Code za pomocą wtyczki do wielu IDE.

Edytor ma wbudowany zaawansowany chat, nazwany tu Cascade, który wspiera Cię w trakcie kodowania. Możesz poprosić w nim o wykonanie poprawek czy nowych funkcji (wzmiankując konkretną linię, plik, czy cały katalog) a on:
- przeanalizuje wskazany przez Ciebie kod,
- znajdzie i przeanalizuje właściwe pliki (np. zawierające definicje klas i metod, modele, kontrolery itd.),
- przygotuje plan działania i w razie potrzeby podzieli go na etapy,
- zacznie edytować kolejne pliki, pokazując wszystkie edycje w przejrzysty sposób,
- w razie potrzeby wykona polecenia w terminalu,
- na koniec podsumuje co zrobił i poprosi o akceptację wprowadzonych zmian, które możesz przejrzeć w postaci diff każdego pliku (a nawet jego fragmentów) a także w całości odrzucić.
Wszystko to jest możliwe z pomocą modeli premium (Claude Sonnet 3.5, GPT 4o), które mają miesięczne limity lub własnego modelu, który dla posiadaczy subskrypcji pro jest darmowy i nielimitowany.

Windsurf ma też „miniczat”, w którym możesz poprosić o wprowadzenie szybkich zmian w danym fragmencie kodu (w trybie inline), bez uruchamiania pełnego Cascade.

W każdej chwili możesz sprawdzić ile edycji na ten miesiąc Ci zostało oraz w razie potrzeby dokupić brakujące tokeny.

Jak to się sprawdza w praktyce?
Jaką aplikację piszę?
O tym będzie jeszcze cała osobna notka. W skrócie – będzie ona wspierała inspektorów budowlanych, którzy mają zadanie przeprowadzić kontrolę techniczną obiektu budowlanego. Jej centralną częścią będą więc Protokoły, które zawierają dziesiątki a nawet setki pól takich jak lista elementów z ich stanem technicznym, wykaz instalacji, fotografie, podstawowe dane o obiekcie, zalecenia pokontrolne i wiele innych.
Czy Windsurf jest nieomylny?

Ło panie… ile ja się napoprawiałem, ile straciłem nerwów, ile razy wgrywałem sejw…to znaczy wracałem o kilka commitów wstecz albo całkiem anulowałem całą gałąź! Mój git log jest naznaczony śladami porażek i potknięć, zarówno moich jako i Claude Sonet (bo głównie z niego korzystam).

Ale wiesz co? Nadal to jest jakieś 20-30% czasu mojej pracy. Reszta edycji albo była od razu poprawna albo wymagała doprecyzowania czy dopieszczenia, ale koniec końców nie powodowała większych usterek. Przy ciągle zwieszającym się poziomie komplikacji aplikacji uznaję to za duży sukces.
To czego należy unikać obecnie to odwoływanie się do zbyt dużych plików i ich zbiorów. Okno kontekstowe modelu jest ograniczone i czasami widać, że pojedyncze fragmenty kodu powyżej 500-600 linii już sprawiają mu problem. Co prawda Cascade dzieli sobie analizę takich plików na kilka etapów (po 200-300 linii) ale i tak zdarza się, że rzuca błędem albo pisze nie do końca działający kod. Warto więc kod dekomponować, dzielić na mniejsze fragmenty, komponenty itd.
Windsurf ma też dość częste aktualizacje i czasami ich instalacja wiąże się usterkami. Przykładowo – siadasz do kodu a Cascade się zacina, nie może uzyskać dostępu do plików, zawodzi jego wyszukiwarka i tak dalej. Są to czasem problemy, które trwają 2-3 dni, do czasu wydania poprawki. Frustrujące, bo pokazuje mi jak słabym koderem jestem. Na szczęście zawsze awaryjnie można odpalić Cursor albo jak zwierzę kopiować kod do ChatGPT czy Claude.
Co udało mi się napisać w pierwsze kilka wieczorów?
Poniżej historia wersji z moimi komentarzami i przykładowe screeny z aplikacji. Czas pracy nad kolejnymi wersjami jest oczywiście przybliżony a opisy nie zawierają setek testów i drobnych poprawek, które przy budowie każdej aplikacji są nieuniknione. Musisz też wziąć pod uwagę, że do edytora kodu siadam ciągle z plakietką „Uczę się”.
Wersja 0.0.1, Czas pracy: 4 godziny, 2.12.2024
Ta wersja powstała pod wpływem impulsu. Byłem po 2 kursach z Udemy i trafiłem na bardzo fajny warsztat Laravel na YT, który w 90 minut pokazał mi jak od zera (czyli instalacji Breeze) dojść do aplikacji mającej podstawowe funkcje – zarządzanie użytkownikami, uprawnieniami, projektami i zadaniami.
Postanowiłem, że zacznę od tego i zobaczę ile uda mi się zbudować na tej podstawie. Na początek dodałem widoki do zarządzania użytkownikami.

Wersja 0.0.2, Czas pracy: 2 godziny, 05.12.2024
Tutaj dodałem właściwie tylko dwie mało widoczne rzeczy, czyli system ról i „miękkie” usuwanie użytkowników (a dzięki temu, że Laravel to ma „w standardzie” całość zamknęła się w 1 linijce kodu dodanej w modelu).
Dodałem też „ochronę” dla trasy user, czyli zarządzania użytkownikami, tak aby do jej wywołania była potrzebna rola admin.
Wersja 0.0.3, Czas pracy: 10 godzin, 7.12.2024
To był pracowity dzień. Dodałem zakładki z listami klientów oraz protokołów. Do protokołów dodałem kilka podstawowych pól, takich jak daty, numer, status. Wykonałem też zapewne masę innych drobnych poprawek.


Wersja 0.0.4, Czas pracy: 2 godziny, 8.12.2024
Zorientowałem się, że warto pomyśleć o wielojęzyczności, albo chociaż o tłumaczeniu na polski język. Na szczęście Laravel ma na to patent i wystarczyło kilka poleceń aby AI utworzyło właściwe zmiany w kodzie i wygenerowało plik z tłumaczeniami pól i etykiet.
Dodałem też pierwszą funkcję, której nie widziałem wcześniej w żadnym kursie – czyli filtry nad tabelą protokołów pozwalające wyszukanie ich po statusie, typie bądź części nazwy klienta.

Wersja 0.0.5, Czas pracy: 6 godzin, 09.12.2024
Udało mi się dodać w protokołach system zakładek, które reprezentują kolejne sekcje protokołu. Było to pierwsze użycie Alpine.js i wygenerowało sporo błędów, których naprawa sprawiła AI pewną trudność, szczególnie że js to dla mnie bardzo mało znany język.

Powstała też jedna z ważniejszych sekcji – Rekomendacje. Pozwala ona dodawać, usuwać i edytować dwa rodzaje zaleceń. Pierwsze to rekomendacja z poprzednich kontroli. Drugie to zalecenia bieżące, czyli całkiem nowe lub wynikające z niezrealizowania poprzednich.
Wyzwaniem było tutaj zbudowanie modelu danych (relacja jeden do wielu) oraz mechanizmu ładowania danych na poszczególne zakładki. Sporo było też pracy z dynamicznym usuwaniem i dodawaniem zaleceń (znowu Alpine) ale ostatecznie udało się. Od ekranu odchodziłem z poczuciem triumfu :).

Wersja 0.0.6, Czas pracy: 8 godzin,13.12.2024
Ta wersja wprowadziła między innymi panel główny, czyli kokpit widoczny po zalogowaniu. Tu po zalogowaniu będą informacje ważne dla poszczególnych ról i użytkowników. Dla inspektorów będą to na przykład protokoły do wykonania w najbliższym czasie.

Rozwinąłem mechanizm atomowych uprawnień, dzięki czemu funkcje w aplikacji mogą być dostępne w zależności od posiadanego uprawnienia a nie bycia w danej roli. Przy okazji wprowadziłem 4 role i zmieniłem ekran logowania do systemu TST, tak aby ułatwić klientowi testowanie i przełączanie między rolami.

Poprawiłem też sekcję rekomendacji dodając mechanizm ich oznaczania jako wykonane lub niewykonane. Udało się też zrobić funkcję przenoszenia zaleceń poprzednich do bieżących.
Co dalej?
W dniu publikacji tego wpisu aplikacja ma numerek 0.0.17, więc jest już znacznie bardziej zaawansowana. Wszystkie wersje obiecuję sukcesywnie opisywać w tej serii. Nie chcesz przegapić kolejnych wpisów? Zapisz się na powiadomienia!
