Przez długi czas nie byłem nawet pewien, czy ta strona w ogóle potrzebuje bloga.
Większość czasu pracy i tak spędzam na rozwiązywaniu problemów. Część to zwykłe zadania frontendowe albo backendowe. Inne stają się bardzo wąskie: kodowanie obrazów, zachowanie przeglądarek, eksperymenty SEO, awarie infrastruktury, development wspomagany przez AI, przetwarzanie mediów albo dziwny problem produkcyjny, który zaczyna się od prostego pytania i zmienia w kilka dni analizy.
Po wszystkim napisanie jeszcze kilku tysięcy słów może wydawać się zbędne.
Kto to przeczyta?
Co ja z tego mam?
Dlaczego po prostu nie rozwiązać problemu i iść dalej?
W końcu znalazłem odpowiedź, która mi wystarcza: część tej pracy jest zbyt kosztowna, żeby ją po prostu wyrzucić.
Trudny problem może zawierać cały artykuł, zanim jeszcze to zauważę
Moje artykuły zazwyczaj nie zaczynają się od myśli: „W tym tygodniu muszę napisać post na bloga”.
Zaczynają się od problemu.
Czasem pochodzi z mojej pracy, czasem z któregoś własnego projektu. Czasem po prostu zainteresuje mnie coś, czego nie rozumiem, i drążę temat tak długo, aż rozumiem go dużo lepiej.
Przetwarzanie obrazów wielokrotnie prowadziło mnie w takie królicze nory.
Na początku zadanie może brzmieć niemal absurdalnie prosto:
Weź te obrazy i zmniejsz ich rozmiar.
Można poprosić model AI o skrypt i dostać go niemal natychmiast.
To nie znaczy, że mamy dobry pipeline do przetwarzania obrazów.
Pierwsza wersja może ignorować różnice między JPEG, PNG, WebP i treściami animowanymi. Może używać jednej wartości quality do wszystkiego, niepotrzebnie powiększać obrazy, źle obsługiwać przezroczystość, zachowywać metadata, które miały zostać usunięte, albo niszczyć te, które powinny pozostać. Może optymalizować tylko rozmiar pliku bez mierzenia pogorszenia obrazu. Na dziesięciu plikach testowych może działać idealnie, a przy znacznie większej skali stać się bardzo drogim błędem.
Skrypt, który kończy się sukcesem, nie jest tym samym co system, któremu ufam.
Wiele moich artykułów bierze się właśnie z tej różnicy.
Mój workflow z AI jest dużo wolniejszy niż „zapytaj ChatGPT o odpowiedź”
Przy takich problemach intensywnie korzystam z płatnego konta ChatGPT.
Jedna rozmowa może trwać dni albo tygodnie. Zadaję pytania, testuję propozycje, odsyłam wyniki, kwestionuję założenia, analizuję kod, znajduję kolejny edge case, zmieniam implementację, uruchamiam ponownie, porównuję wynik i powtarzam cały proces.
Przy szczególnie głębokich analizach zdarzało mi się zgromadzić ponad 100 godzin pracy wokół tego samego większego problemu.
Nie oznacza to, że przez 100 godzin czekam, aż model AI magicznie odkryje odpowiedź.
Proces jest iteracyjny.
Zwykle wygląda bardziej tak:
- Opisuję problem.
- Model proponuje pierwsze rozwiązanie.
- Uruchamiam je na prawdziwych danych.
- Coś okazuje się słabe, nieefektywne albo po prostu błędne.
- Wracam z dowodami.
- Zmieniamy podejście.
- Testuję ponownie.
- Pojawia się kolejny edge case.
- Powtarzamy.
Taki cykl może wystąpić wiele razy.
Przydatnym wynikiem często nie jest pierwszy skrypt, lecz cały zbiór porażek, pomiarów, poprawek i decyzji, które powstały wokół niego.
AI obniżyło koszt wygenerowania punktu startowego. Nie obniżyło kosztu weryfikacji
To jeden z powodów, dla których typowa dyskusja o treściach technicznych pisanych przez AI wydaje mi się zbyt uproszczona.
Tak, model AI może bardzo szybko stworzyć wiarygodnie wyglądający tutorial.
Może też stworzyć kod, który wygląda całkowicie rozsądnie, a jest błędny dokładnie w sytuacjach, które mają znaczenie.
Przy wąskich problemach technicznych rzadko interesuje mnie pierwsza wiarygodna odpowiedź. Chcę zobaczyć, co się stanie, gdy naprawdę ją uruchomię.
Jeżeli buduję pipeline obrazów, chcę sprawdzić rozmiary wyjściowe i jakość wizualną. Chcę wiedzieć, co dzieje się z różnymi formatami źródłowymi. Chcę testować nietypowe wymiary, alpha, animacje i uszkodzone dane wejściowe. Chcę też rozumieć, jakie założenia przyjmuje implementacja.
Jeżeli skrypt ma później dotknąć ogromnej kolekcji, to wszystko staje się jeszcze ważniejsze.
Dziesięć milionów obrazów to celowo ekstremalny przykład, a nie twierdzenie o rozmiarze konkretnego mojego datasetu. Dobrze jednak pokazuje problem: mały systematyczny błąd pomnożony dziesięć milionów razy przestaje być mały.
Koszt generowania kodu gwałtownie spadł.
Koszt określenia, czy ten kod powinien działać na dużą skalę — nie.
Czat to materiał badawczy, a nie gotowy artykuł
Po długiej analizie historia rozmowy może zawierać absurdalnie dużo informacji.
Mogą to być:
- podejścia, które zawiodły;
- kod później zastąpiony innym;
- przydatne wyniki benchmarków;
- logi;
- nieporozumienia;
- poprawki;
- wyjaśnienia niejasnego zachowania;
- porównania alternatyw;
- edge case'y, o których na początku nie pomyślałem;
- oraz końcowe reguły, którym zacząłem ufać.
Zostawienie tego wszystkiego w jednej prywatnej rozmowie wydaje mi się marnotrawstwem.
Dlatego wyciągam przydatne fragmenty i zamieniam je w artykuł.
Artykuł nie jest transkrypcją rozmowy. Większa część rozmowy nigdy nie powinna zostać artykułem.
Przydatny tekst techniczny wymaga jeszcze jednej rundy pracy: trzeba usunąć ślepe uliczki, które niczego nie uczą, zachować te, które wyjaśniają coś ważnego, zweryfikować twierdzenia, odtworzyć chronologię, oddzielić obserwację od wyjaśnienia i zamienić końcowy wynik w coś, czego inny developer rzeczywiście może użyć.
Ten etap redakcyjny ma znaczenie.
AI może w nim uczestniczyć, ale dowody nadal pochodzą z rzeczywistej pracy.
Przetwarzanie obrazów pokazało mi, jak głęboki może stać się „prosty” problem
Optymalizacja obrazów jest chyba najbardziej czytelnym przykładem z mojej pracy.
Poświęciłem jej tyle czasu, że coś, co początkowo wyglądało jak zbiór ustawień enkodera, stopniowo zamieniło się w znacznie większy problem systemowy.
Pytania szybko się mnożą.
Z jakim formatem źródłowym pracuję?
Czy jest animowany?
Czy wymiary powinny się zmienić?
Jak wybrać quality?
Jaka metryka powinna decydować, czy utrata jakości jest akceptowalna?
Czy jeden quality threshold działa dla całkowicie różnych obrazów?
Jak uniknąć upscalingu?
Które metadata powinny pozostać?
Co dzieje się z przezroczystością?
Jak walidować wynik?
Czy mniejszy plik naprawdę uzasadnia dodatkowy koszt kodowania?
Co się stanie, gdy zmieni się populacja danych wejściowych?
Dlatego sceptycznie patrzę na pięcioliniowe skrypty do „ostatecznej optymalizacji obrazów”.
Oczywiście potrafią przetworzyć obraz.
To jednak coś innego niż zbudowanie pipeline'u, którego kompromisy rozumiemy.
W moich obecnych workloadach z dużą ilością obrazów AVIF jest zazwyczaj pierwszym formatem, który biorę pod uwagę. To reguła wynikająca z rodzaju projektów, nad którymi pracuję, a nie twierdzenie, że każda strona internetowa na świecie powinna jutro usunąć wszystkie starsze formaty. Wymagania zgodności, materiał źródłowy, latency, koszt enkodera i architektura delivery mogą zmienić odpowiedź.
Ciekawe nie jest ogłaszanie jednego formatu zwycięzcą.
Ciekawe jest zrozumienie workloadu na tyle dobrze, by podjąć świadomą decyzję.
Chcę równie głęboko wejść w przetwarzanie wideo. Jeszcze tam nie jestem. To również sprawia, że te tematy są interesujące: za każdym razem, gdy wydaje mi się, że dotarłem do dna problemu, pojawia się kolejna warstwa.
Potem japońska strona znalazła blog
Nie oczekiwałem żadnej konkretnej korzyści z publikowania tych artykułów.
Ten blog nie daje mi znaczącego zwrotu finansowego. Robię to, bo lubię sam proces i wolę zachować przydatną pracę, niż pozwolić jej zniknąć w starych czatach i historii terminala.
Potem wydarzyło się coś, czego naprawdę się nie spodziewałem.
17 września 2026 roku japoński serwis Levtech Freelance opublikował zestawienie o tytule, który można w przybliżeniu przetłumaczyć jako „Polecane blogi dla inżynierów chcących rozwijać swoje umiejętności”.
Artykuł Levtech Freelance wymieniał JSVar obok kilku innych blogów inżynierskich.
Levtech jest częścią dużego japońskiego ekosystemu kariery IT, a Levtech Freelance skupia się na wspieraniu i dopasowywaniu freelancerów IT do projektów. Dla mnie ciekawe nie było samo zdobycie backlinku. Ciekawsze było zobaczyć, które fragmenty mojej pracy zewnętrzny zespół redakcyjny uznał za warte opisania.
W sekcji o JSVar szczególnie wyróżnili trzy artykuły.
Jeden dotyczył tego, dlaczego Codex i TypeScript dobrze sprawdzają się razem w moim developmentcie produkcyjnym, szczególnie dlatego, że typy TypeScript i feedback kompilatora mogą wcześniej ujawniać problemy w wygenerowanym kodzie.
Drugi opisywał tłumaczenie bloga na 20 języków przy pomocy ChatGPT i obserwację, że użytkownicy z wyszukiwarek z różnych krajów trafiali bezpośrednio na zlokalizowane strony.
Trzeci dotyczył mojego eksperymentu z publikacją 10 000 stron SEO generowanych przez AI, który ostatecznie stał się historią o porażce, a nie łatwym wzroście.
Ten wybór trochę mnie rozbawił, bo to trzy zupełnie różne artykuły, które mają jednak wspólny wzorzec.
Każdy opiera się na czymś, co naprawdę zrobiłem.
Nie wiem dokładnie, jak Levtech mnie znalazł
Łatwo tu zbudować kuszącą historię.
Nie mówię po japońsku.
Moja strona ma japońską wersję.
Japońska publikacja inżynierska znalazła stronę.
A więc tłumaczenie bloga na japoński spowodowało, że Levtech go odkrył.
Nie potrafię tego udowodnić.
Być może japońskie strony pomogły.
Być może wyszukiwarka doprowadziła ich do angielskiego artykułu.
Być może ktoś udostępnił link.
A być może znaleźli stronę zupełnie inną drogą.
Nie mam takich danych atrybucyjnych, więc nie zamierzam tworzyć z tego czystego SEO case study, którego dane nie potwierdzają.
To, co mogę potwierdzić, jest dużo prostsze: opublikowałem blog w wielu językach, a później japońska publikacja uznała go za na tyle interesujący, by uwzględnić go w redakcyjnym zestawieniu.
To już jest dobry rezultat.
Jest tym przyjemniejszy, że lokalizacja także była eksperymentem, który początkowo wyglądał na dużo pracy przy niepewnym zwrocie.
Ta wzmianka była ważna, bo stanowiła niezależną walidację
Mówiąc „walidacja”, nie mam na myśli tego, że Levtech udowodnił poprawność wszystkiego, co piszę.
Nie audytowali mojego codebase'u ani nie odtwarzali każdego eksperymentu.
Liczyło się coś skromniejszego.
Ktoś po drugiej stronie świata, piszący dla odbiorców, do których sam nie potrafię przemówić w ich języku, dostrzegł w mojej pracy wystarczająco dużo wartości, by ją dla nich streścić.
Nie proponowałem im współpracy.
Nie pisałem oryginalnych artykułów z myślą o Levtech.
Nie spodziewałem się obecności w japońskim zestawieniu.
Dlatego wynik ma dla mnie znaczenie.
Sugeruje, że bardzo niszowy artykuł techniczny nie musi mieć ogromnej publiczności, by warto było go publikować.
Musi być użyteczny dla właściwego czytelnika.
Czy developer powinien zacząć blogować w 2026 roku?
Dla mnie odpowiedź brzmi: tak — pod jednym ważnym warunkiem.
Naprawdę trzeba chcieć coś zapisać.
Nie polecałbym zakładania bloga technicznego tylko dlatego, że ktoś powiedział, że każdy developer potrzebuje „personal brand”.
Nie zaczynałbym go też z oczekiwaniem pasywnego dochodu.
Nie tworzyłbym go również po to, by wypełniać go ogólnymi wyjaśnieniami technologii, które mają już lepszą dokumentację.
Jeśli jednak twoja praca regularnie produkuje rzeczy, które sam chciałbyś znaleźć, gdy zaczynałeś, sytuacja jest inna.
Zapisuj je.
Napisz o dziwnej awarii produkcyjnej.
Napisz o optymalizacji, która zajęła trzy dni dłużej, niż oczekiwałeś.
Napisz o benchmarku, który obalił twoje założenie.
Napisz o eleganckim podejściu, które zawiodło.
Napisz o końcowej implementacji, ale wyjaśnij też, dlaczego oczywista wersja nie wystarczała.
To są elementy trudne do sztucznego odtworzenia z ogólnej wiedzy.
AI daje mi więcej materiału do pisania, nie mniej
AI nie sprawiło, że uznałem blogi techniczne za przestarzałe.
U mnie stało się niemal odwrotnie.
Mogę badać więcej pomysłów, ponieważ uzyskanie początkowej implementacji lub wyjaśnienia jest szybsze niż kiedyś.
Szybsza iteracja produkuje jednak więcej dowodów: więcej wariantów, logów, benchmarków, nieudanych prób i więcej rzeczy do sprawdzenia.
Ten surowy materiał zyskuje wartość dopiero wtedy, gdy ktoś wykona pracę potrzebną do określenia, co jest prawdą i co naprawdę ma znaczenie.
Rozmowa z AI zawierająca 500 wiadomości nie staje się automatycznie wiedzą.
Skrypt, który ostatecznie przechodzi prawdziwe testy, wraz z wyjaśnieniem 20 wersji, które ich nie przeszły, może nią być.
Tę różnicę chcę uchwycić na blogu.
Publikowanie to mój sposób na to, by użyteczna praca nie znikała
Większość pracy technicznej jest zaskakująco tymczasowa.
Trudny bug zostaje naprawiony.
Terminal się zamyka.
Deployment kończy się sukcesem.
Rozmowa spada w historii czatu.
Sześć miesięcy później nawet ja mogę nie pamiętać, dlaczego końcowa implementacja wygląda dokładnie tak.
Pisanie to zmienia.
Zmusza mnie do odtworzenia rozumowania, dopóki dowody nadal istnieją.
Tworzy coś, co da się wyszukać.
Daje mi punkt odniesienia do własnej przyszłej pracy.
A czasem, jak się okazuje, dociera do kogoś, kogo zupełnie się nie spodziewałem — nawet do publikacji inżynierskiej w języku, którego nie znam.
Nadal nie mam szczególnie skomplikowanego powodu, by prowadzić ten blog.
Lubię się uczyć.
Lubię budować rzeczy.
Lubię schodzić zdecydowanie za głęboko w problemy, które początkowo wyglądały na proste.
A po spędzeniu dziesiątek, czasem ponad stu godzin, żeby dojść do użytecznej odpowiedzi, nie chcę już, żeby ta odpowiedź umierała w oknie czatu.
Dla mnie to wystarczający powód, by ją opublikować.
Jeśli twoja praca również tworzy taki rodzaj ciężko zdobytej wiedzy, myślę, że dla ciebie może to być wystarczający powód.