To mój pierwszy artykuł po kilku latach i od razu niesie za sobą sporą, wizualną zmianę całego mojego serwisu. Sprzyja to okazji, by opowiedzieć o kulisach: jak spontaniczna decyzja zaprowadziła mnie, w jeden weekend, do reaktywacji bloga, w zupełnie nowej odsłonie. I do poszukiwania odpowiedzi na kluczowe pytanie: czy korzystanie z AI do pisania kodu degraduje programistę?
Strona od lat
Opowieść zacznę od krótkiej historii. W tym roku, jak policzyłem, minie dokładnie 20 lat, kiedy to wypuściłem w świat swoją pierwszą stronę internetową. Najpierw stworzyłem ją w Wordzie (sic!), później we FrontPage-u. WYSIWYG – What You See Is What You Get – tym mianem określano z grubsza wszystkie graficzne edytory, które służyły do tworzenia prostych stron internetowych. Było ich naprawdę sporo, obiecywały ogromne uproszczenia, lecz nawet z ich pomocą tworzenie stron nie było całkiem trywialne. Z ciekawym, z dzisiejszego punktu widzenia, wyjątkiem: zapewnienia kompatybilności pod Internet Explorer (taki ówczesny monopolista jak Chrome, ale nierespektujący nawet własnych standardów pisania stron internetowych).
W międzyczasie moją ciekawość przykuły systemy zarządzania treścią (CMS), w tym chyba jeden z popularniejszych w tamtym czasie, PHP-Fusion. Cóż to był za cud techniki, choć przez poważne ograniczenia darmowego hostingu, brak było możliwości dokonywania zmian w kodzie. To właśnie wtedy, może trochę w złości na te ograniczenia, zainteresowałem się programowaniem na poważnie. Chciałem stworzyć swoją stronę, dynamicznie zarządzaną, jako zupełnie autorski projekt.
Wyposażony w książeczkę o programowaniu w PHP z Komputer Świata, w październiku 2008, powstał mój nowy serwis. Przez kolejne miesiące i lata był on wielokrotnie modyfikowany, co skrupulatnie za każdym razem opisywałem w kolejnych miniartykułach. Chęć dodania nowej funkcjonalności była motorem do dalszej nauki, a jej rezultat po prostu mnie cieszył.
Przez ostatnie blisko 18 lat, strona działała w dużej mierze na rdzeniu napisanym u początków. Po drodze implementowałem konta użytkowników, system komentarzy, ankiet, integracje z mediami społecznościowymi czy statystykami odwiedzin, a nawet specjalny panel administracyjny. Ostatnia duża zmiana, w 2015, oprócz solidnego redesignu, dodała wsparcie dla smartfonów.
Analiza status quo
Od 2018 roku nie uzupełniłem strony o żaden nowy artykuł. Dlaczego? Z wielu powodów wspomnę o tych najbardziej technicznych:
- panel administracyjny, choć ułatwiał dodawanie nowych artykułów, nie był idealny, brakowało w nim nieco bardziej rozbudowanego zarządzania obrazkami, ich edycji i przesyłania na serwer;
- zbyt sztywnie nadane typy kategorii artykułów, mocno zakotwiczone w strukturze strony, niebędące łatwymi do zmiany;
- mocno portalowy, a nie osobisty charakter strony głównej;
- brak prostej możliwości umiędzynarodowienia bloga.
“AdminPanel” przez lata służył mi do szybkiego zarządzania treściami na stronie
Rozważając zyski i koszty kontynuowania 18-letniego kodu legacy, zacząłem od wgłębienia się raz jeszcze w to, co w nim było. Cóż, zęby mnie bolały, jak to czytałem, ale to z reguły jest dobry symptom, znany każdemu (nie tylko programistom, choć w tym środowisku chyba szczególnie), który po latach na chłodno i bez emocji podchodzi do swojego dzieła.
Rezultat okazał się dość oczywisty: jedyną faktyczną wartością była historyczna baza artykułów, choć bardzo rozproszona w wielu plikach i strukturach. Decyzja: to zachowujmy, całą resztę zmieniamy.
Nowe wymagania
Wiedząc, że potrzebny będzie zupełnie nowy system wyświetlania treści, przystąpiłem do research-u, rozeznania się, co w ogóle już istnieje na rynku, o jakie sprawdzone i istniejące rozwiązanie można się oprzeć. Do takich podstawowych zadań okołotechnicznych korzystam ze zwykłego czatu AI. Precyzując: z co najmniej dwóch czatów. Pierwszy wybór zazwyczaj pada na Claude, drugi na Gemini. Tak dla podstawowej pewności i weryfikowania udzielanych odpowiedzi.
Prompt sprecyzowałem dość konkretnie, zaczynając do oczekiwań, by całość była przede wszystkim łatwa w utrzymaniu, a skończywszy na ograniczeniach technicznych, a więc w jakim środowisku całość będzie uruchamiana. Korzystam z rozwiązań hostingu współdzielonego, bo jest ono jednym z tańszych, istnieje na rynku spora konkurencja, a prawdę mówiąc, do prostej wizytówki więcej nie potrzeba. Odrzucam paradygmat, który stawia wyrafinowaność rozwiązania ponad jego użyteczność. Prompty piszę mieszanym polskim i angielskim; tego drugiego używam częściej do opisywania stricte technikaliów.
Wstępne rozeznanie wykluczyło potrzebę użycia PHP, a w zamian dało do wyboru frameworki: Hugo i Eleventy. Obydwa dość dobrze wspierane przez społeczność, proste w użyciu, łatwe w modyfikacji i co najważniejsze: trzymające treści w Markdownie (co jest super!).
Warto przez chwilę zastanowić się nad samą kwestią porzucenia PHP. Skąd w ogóle wzięło się to, że strony pisałem w tej technologii? Z pewnością dużą rolę odgrywało ówczesne momentum. Rozwiązania konkurencyjne były na dość niskim poziomie rozwoju bądź nie było ich wcale, natomiast wsparcie społeczności PHP było naprawdę spore, a możliwość łatwego przeplatania kodu HTML z PHP dawało mi dokładnie to, czego potrzebowałem: dynamicznie generowanych treści, reużywania stałych fragmentów strony (include()) i zapewnienia pewnej interakcji z użytkownikami.
Te wymagania przestały mieć teraz dla mnie kluczowe znaczenie. Chciałem przede wszystkim prostej wizytówki z blogiem. Strona miała być dużo mniej rozbudowana i pozbawiona elementów społecznościowych, chociażby takich jak komentarze, lecz z pozostawieniem sobie potencjalnej furtki na przyszłość.
Eleventy wybrałem z racji prostoty szablonów i oparcia generowania całej strony o JavaScript. Hugo z kolei korzysta z silnika opartego o język Go. Nie widziałem realnej przewagi tego drugiego, zwłaszcza że migracja pomiędzy nimi w przyszłości również nie wygląda, przy obecnym stopniu złożoności, na karkołomną. A wybór technologii, by tylko dobrze “brzmiała”, to gorzej niż zły wybór.
Setup i test deploymentu
Wybór frameworka to zazwyczaj jedna strona medalu. Drugą jest to, jak finalnie całość ma działać, budować się i deployować na serwer. Chcę to widzieć (choćby oczami wyobraźni), zanim cokolwiek zostanie realnie zaimplementowane. Dziś dysponujemy narzędziami devopsowymi, których te kilkanaście lat temu było brak lub jeśli istniały, to ich koszt był zbyt wysoki do codzienego użytku.
Hostowanie kodu źródłowego strony – GitHub. Budowanie plików strony – GitHub Actions, który w wersji darmowej daje wystarczająco dużo zasobów jak na indywiduane potrzeby. Wrzucenie plików strony na zdalny serwer FTP – również GitHub Actions. Ten fundament daje nam stabilność, a jednocześnie niezależność. W razie jakiejkolwiek zmiany po stronie GitHuba (kosztów lub oferowanej usługi), serwis można jednym poleceniem zbudować lokalnie. Uzależnienie od GitHuba jest zatem w stopniu akceptowalnym.
Podstawowa funkcjonalność
Kolejny krok to przejście do implementacji nowego serwisu. Stworzyłem kilku agentów w Claude Code, takich jak:
- UX/UI Designer,
- HTML/JavaScript/CSS developer,
- Reviewer.
Ten komplet od początku wydawał się być wystarczający i faktycznie taki był.
Kluczem do sukcesu jest umiejętność klarownego i jednoznacznego wyrażania myśli.
Im prompt jest bardziej precyzyjny, a specyfikacja obejmuje, oprócz przypadku głównego, również te poboczne, tym szybciej rezultaty są takie, jakich faktycznie oczekujemy. Ja w swoich promptach skupiałem się najpierw na rozwiązaniu problemu architektury i struktury, a dopiero w dalszej kolejności na całej reszcie, czyli warstwie wizualnej.
Moje wymagania były dość niestandardowe. Stronę główną chciałem mieć w jednym języku (angielskim), ale sam blog uczynić dwujęzycznym. I to ze wsparciem wstecznym, a więc nie każdy artykuł, oryginalnie napisany po polsku, musi mieć swoje angielskie tłumaczenie. Z prostej przyczyny: nie zamierzam automatyzować tłumaczenia swoich artykułów, gdyż chcę mieć nad tym pełną kontrolę.
To doprowadziło mnie do prostej struktury artykułów, po stronie Eleventy. Każdy artykuł to osobny katalog w folderze blog. Jego nazwa jest kluczowa, gdyż będzie on stanowił polski slug. Dla porządku uznałem, że warto zaczynać nazwę folderu od datownika (brak godziny jest intencjonalny – nie potrzebuję publikować więcej niż jednego artykułu dziennie). W ramach folderu jeden plik jest obowiązkowy: index.md, z treścią artykułu po polsku, oraz opcjonalnie index_en.md z artykułem po angielsku. W folderze mogą znaleźć się dodatkowe pliki, chociażby obrazki, które mogą (ale nie muszą) być wspólne dla dwóch wersji językowych.
Każdy plik Markdown ma swoją “metryczkę”, zgodnie z wymaganiami szablonu. I tu również, istotna jest dbałość o prostotę i brak redundancji. Czy potrzebujemy tu raz jeszcze definiować polski slug, czy wystarczy tylko w angielskiej wersji? Czy wartości w bazowym (polskim) artykule, mogą być brane jako domyślne? Te i inne pytania warto sobie zadać, by utrzymać maksymalną prostotę rozwiązania.
Nie chciałem, aby do URL-a był dołączany interfix, z wybranym językiem (taki jak /pl/ albo /en/), gdyż… gryzło mi się to wizualnie z moją domeną .pl. Drobnostka, ale kluczowa w definiowaniu wymagań.
Moim zdaniem to właśnie w tym wyraża się vibe engineering – w kluczowym podejmowaniu decyzji i perspektywicznym myśleniu, przy wykonywaniu danego zadania, a nie podążaniu za pierwszym lepszym rozwiązaniem, na podstawie zbyt lakonicznego prompta. Wtedy możemy mówić o vibe codingu, który, choć w krótkiej perspektywie zdaje się dawać dobre rezultaty, to w dłuższej, bez inżynieryjnych ram, doprowadzi do technicznej katastrofy.
Późniejsze wyprostowanie katastrofalnej architektury, będzie zdecydowanie zadaniem karkołomnym i nietanim, biorąc pod uwagę czas i pieniądze.
UI/UX Design
Kiedy warstwa techniczna była już gotowa, przyszedł czas na skupienie się na warstwie wizualnej. Tu również miałem swoją wizję, jak moja nowa strona może wyglądać. Przede wszystkim dark mode, jako domyślny styl, ale z możliwością przełączenia na jasny. Druga kwestia – odświeżone logo i dobór konkretnej palety kolorów.
Tu kolejny agent, UI/UX Designer, wypracował świetne ramy początkowe, dzięki precyzyjnym wymaganiom. I w takiej kwestii, wyobraźnia techniczna jest potrzebna. Efekt, jaki można obecnie zobaczyć na stronie, w znakomitej większości jest wynikiem początkowych iteracji. Każda kolejna to jedynie poprawienie detali.
Warto wspomnieć, że przy projektowaniu tak małej strony, zazwyczaj nie jest konieczne posiłkowanie się aplikacjami do prototypowania designów takich, jak chociażby Figma. Myślę, że dużo więcej czasu zajęłoby mi samo prototypowanie, a nie przelewanie myśli w dokładny prompt.
Review zmian
Jak już wspomniałem, zdefiniowałem sobie również agenta do przeglądania kolejnych zmian (reviewer), zarówno w kodzie, jak i w designie. Myślę, że dobrą praktyką, jaką sobie wypracowałem, było regularne sprawdzanie poprawności projektowanego serwisu, właśnie z jego użyciem. Tu dochodzi kolejna rola, jaką jest utrzymywanie czystości kodu i niepozostawiania jakichkolwiek nieużywanych resztek kodu, które mogą pojawić się w czasie kolejnych iteracji.
Migracja starych artykułów
Ostatnim krokiem było przeniesienie starej bazy artykułów, wraz ze wszystkimi mediami, w nowe miejsce. Jak wspomniałem na początku, baza danych pierwotnie była źle zaprojektowana, z danymi ulokowanymi w różnych miejscach. Co więcej – treści były w formacie HTML, który z kolei bywał dawniej nadmiernie determinowany ówczesnymi stylami. Obłęd, ale do ogarnięcia.
Kluczem było stworzenie, a raczej zaplanowanie, skryptu, który wykona swoje zadanie, scalając dane i porządkując w nowej strukturze plików. Dla uproszczenia zadania, wszystkie potrzebne pliki oczyściłem i na cele skryptu stworzyłem nową, nieco uproszczoną tymczasową strukturę. Wydaje mi się to dość istotne w przygotowaniu skryptu.
Nie chciałem, aby wszystkie artykuły przechodziły przez LLM, tylko po to, aby mógł być napisany poprawny skrypt. Wybrałem kilka, również z edge case-ami, i to je właśnie wskazałem za przykład, dołączając opis struktury źródłowej oraz docelowej, włącznie z konwersją tekstów HTML na Markdown. Skrypt wykonał swoją pracę, a na koniec – najważniejsze, czyli weryfikacja procesu. Uznałem, że zwykłe logowanie przeprowadzonych zmian, a więc wylistowanie wszystkich plików źródłowych wraz z ich docelowymi ścieżkami, będzie wystarczające, by wyłapać “sieroty” lub inne brakujące pliki.
A więc, czy vibe engineering faktycznie nie jest żadną ujmą dla programisty?
Wszystko to, co napisałem powyżej, było absolutnie realne do wykonania w przeciągu jednego weekendu, po kilka godzin pracy dziennie. Od spontanicznego pomysłu, do wykonania i pełnej migracji.
To zasadnicza zmiana mojego podejścia do pisania oprogramowania. Powtarzalne czynności stają się szybsze, ich wykonanie mniej żmudne, ale nie zmienia się jedno – aby to wszystko miało realną wartość, a nie było zaledwie wydmuszką oprogramowania, potrzebny jest nadzór i pomysł, co i w jaki sposób chce się osiągnąć.
Zmiany, które zachodzą w obszarze sztucznej inteligencji, zachodzą coraz szybciej, choć nadal, rozpowszechnienie tej technologii i jej codzienne użycie jest zaskakująco niskie.
Rozkład użycia AI na świecie w lutym 2026 (źródło: X/@damianplayer)
Zaskakująco niskie jak dla kogoś, kto obraca się w tej dziedzinie praktycznie każdego dnia.
Aby więc ten artykuł nie zestarzał się brzydko, warto na koniec wspomnieć, że oparłem go na swoich doświadczeniach, na początku 2026 roku.
Czy zatem vibe engineering, podążając za tytułowym pytaniem, jest jakąś ujmą, dla takich ludzi jak ja? Uważam, że nie. Z prostego powodu: ta technika, jak wiele innych, pomaga lepiej osiągać konkretne cele, nawet tak banalne, jak przepisanie i redesign mojej strony internetowej. Kluczowe jest jednak to, że nadal wymagane jest inżynieryjne podejście do problemu, wyspecyfikowanie wymagań i jeszcze dokładniejsze walidowanie rezultatów.