Podsumowanie 2025

2025

Dominacja tematów związanych z AI w 2025 była niezaprzeczalna, miażdżąca wręcz. MCP niedawno obchodził pierwsze urodziny, a mam wrażenie, że jest przynajmniej dwa razy starszy. Myślę, że wynika to z tego, jak wiele się w tym czasie wydarzyło. Z drugiej jednak strony, wciąż mam poczucie obcowania z niedojrzałą technologią. Nie chodzi mi bynajmniej (tylko) o to, jak często wpadają ficzery do copilot’a. Bardziej mam tu na myśli UX/DX. Dla przykładu choćby to, jak nieuporządkowany jest temat definiowania plików ze wskazówkami i preferencjami dla agentów. Niby istnieją jakieś standardy, ale ciężko się w tym połapać. Przypomina mi to nieco walkę na rynku przeglądarek, która toczyła się początkiem XXI wieku. Z mojej perspektywy w wojnie vendorów, na razie największymi przegranymi są sami użytkownicy. Mnogość możliwości konfiguracji w połączeniu z niedeterministyczną naturą często prowadzi do tego, że efekt jest niezadowalający. Dla przykładu, w swoim pliku agents.md zazwyczaj zaczynam od nakazania wywoływania poleceń w shellu, zaczynając białym znakiem, celem zachowania higieny historii. Niestety instrukcja ta szybko pada ofiarą spuchniętego okna kontekstowego i — jak rozumiem — mnogość konfiguracji tu nie pomaga. Pewnie można by się umówić na jakieś skrótowe, skompresowane formy takich wskazówek. Może AI mogłaby przetwarzać rozwlekły opis człowieka na takie predefiniowane, ustandaryzowane tipy, co oszczędziłoby cenne tokeny w dłuższych zadaniach.

Oczywiście to tylko jeden z wielu przykładów. Przytoczyłem go jednak celem wskazania, w jakiej sytuacji się znajdujemy. Rozumiem znaczenie tego postępu, ale droga jest kręta i wyboista, co sprawia, że doznania są w najlepszym razie ciekawe, a oczekiwałbym komfortowych.

Dla kontrastu rynek technologii, w których się poruszam, zarabiając na swoją miskę ryżu, wydaje się stabilizować z szerszej perspektywy.

Java dogoniła konkurencję — ma większość “nowoczesnych” ficzerów, a jednocześnie nie sprawia wrażenia poligonu doświadczalnego. Czekam wciąż na withery i jeszcze lepszy pattern matching (guard’y itp), ale zasadniczo bardzo mi się podoba to, co już dostaliśmy. Miałem okazję trochę już z tego skorzystać, pomimo że w tym roku działałem głównie przy frontendzie.

Jak to możliwe? Otóż skorzystałem na wzrastającej popularności html-over-the-wire. Miałem bowiem okazję użyć połączenia java + spring + thymeleaf + htmx. Doświadczenie uważam za bardzo ciekawe i satysfakcjonujące, mimo że nie obyło się bez pewnych problemów. Pierwsza sprawa jest taka, że nie polecam tego podejścia do bardzo interaktywnych aplikacji. Popularność nowoczesnych bibliotek i frameworków javascriptowych nie wzięła się znikąd. Wobec braku reaktywności na kliencie, dla co bardziej złożonych scenariuszy logika zachowań niebezpiecznie szybko cieknie do kontrolerów. Jest to jednak kwestia doboru technologii do danego problemu, nie samej technologii czy nawet architektury rozwiązania. Projekt, nad którym pracowałem, był czymś pomiędzy. Z jednej strony nie miałem dużo interaktywności na frontendzie. Z drugiej jednak strony, gdy zrezygnowałem z prostoty pełnego przeładowania pomiędzy podstronami na rzecz uzyskania efektu Single Page Application, kod kontrolerów znacząco przybrał na złożoności.

Pracując nad tym projektem, uzmysłowiłem sobie, że ten stos (a nawet architektura) wymaga zasługuje na ustalenie jakiegoś luźnego zestawu wzorców w rodzaju reduxowego ducks.

Mam tu na myśli sprawy typu granularność endpointów, sposób przekazywania stanu formularza itd. Być może jest to charakterystyczne dla htmx’a, jako najprostszego wariantu html-over-the-wire, a bardziej złożone narzędzia typu HotWire czy Phoenix LiveVue mają to wbudowane — liczę, że sam się o tym przekonam w 2026. 🤓

Wracając jednak do problemów ze stosem, gorzej było z mieszaniem htmx’a z Thymeleaf. Szczęśliwie problemy składniowe częściowo udało się zniwelować dzięki użyciu nieocenionej biblioteki integrującej. Czapki z głów przed autorem, świetna robota.

Jak już wcześniej nadmieniłem, w 2025 rzeźbiłem dużo frontu, a tym samym było sporo Next.js’a. Technologia zaczyna się stabilizować, choć ostatnia sytuacja z react2shell pewnie nadwątliła zaufanie społeczności.

Myślę, że stało się to w bardzo niefortunnym momencie, bo od jakiegoś czasu obserwuję rosnącą falę uciekinierów do tanstack’a. Nie wiem, jak popularne jest całkowite przejście, sam jednak miałem okazję użyć tanstack-form w reactowej wersji właśnie.

Biblioteka wydaje się dobrze przemyślana, szczególnie w obszarze integracji z typescript’em. Mam jednak spore wątpliwości w kwestii obsługi kolekcji. Użycie indeksu jako klucza to dla mnie dość kontrowersyjna decyzja, niewpasowująca się w react’ową architekturę. Domyślam się, że wynika to z generyczności samej biblioteki — react jest jedynie jednym z obsługiwanych wariantów. Rozumiem decyzję twórców, lecz jako użytkownik mam mieszane odczucia. Z tego, co pamiętam, rodziło to zresztą realne problemy z modyfikowaniem kolekcji. Być może zabrakło mi wiedzy (mimo czytania dokumentacji) i popełniałem jakiś błąd. Biorąc pod uwagę jak mocno moda i trendy sterują decyzjami programistów, szanse na zdobycie popularności oceniam nadal na wcale duże.

Mam również pewne obserwacje dotyczące DX.

Po pierwsze, biblioteka dość mocno narzuca sposób pisania — probemtyczne jest oddzielanie kodu komponentów od biblioteki, przy jednoczesnym wydzielaniu dedykowanych komponentów (np. dla warstw, komponentów reużywalnych itd). Innymi słowy wnika w implementację i generuje coupling.

Po drugie, silna integracja z TypeScript’em nie jest za darmo — weźmy przykład. Jednym ze sposobów dobierania się do pól obiektu jest używanie selektorów nazw pól, czyli czegoś w rodzaju

<form.Field name="people" mode="array">

gdzie people to pole obiektu, a jego zgodność z modelem jest sprawdzana na poziomie typów (!). W optymistycznym scenariuszu IDE elegancko podpowiada możliwe selektory pól. Problem pojawia się jednak gdy zaczynamy grzebać przy modelu. Doświadczałem zarówno:

• false-positive na selektorach podkomponentów, gdy miałem błędy w modelu, jak i
• przeciwnie — czasem musiałem restartować IDE i odświeżać cache, gdy coś uparcie było podświetlane jako błędne.

Co więcej, generowało to zauważalny narzut na wydajność. Nie wiem, w jakim stopniu była to kwestia ciągłego mielenia kompilatora tsc, bo drugim hamulcowym był copilot.

Fakt, że macbook na m4’ce ma problemy ze środowiskiem, dał mi do myślenia. Zdaję sobie sprawę, że jest to koniunkcja czynników. Niemniej jednak jest to niejako w kontrze do podążania za prostotą i efektywnością, które wypromował w tym roku DHH w swoim projekcie omarchy. OS i edytor to teoretycznie rozłączne tematy, ale myślę tu w szerszym ujęciu. Poza tym mogą zachodzić pewne synergie między nimi w niektórych przypadkach.

Obecnie zarówno w pracy, jak i prywatnie nadal używam mac’ów, w oparciu o nix’a i home-manager’a, jednak wyżej wymienione doświadczenia skłaniają do zastanowienia nad tym status quo. W kwestii edytora, w prywatnych projektach testuję zed’a z vim mode, co wydaje mi się interesującym kompromisem. Co do OS’a, to miewałem w przeszłości dłuższe okresy używania arch’a i jego forków. Przejście na mac’a było spowodowane zmęczeniem niestabilnością i problematycznym wycofywaniem zabugowanych aktualizacji.

Wtedy jeszcze nie znałem nix’a, a arch’a lubiłem za prostotę. Z zainteresowaniem śledzę rozwój omarchy, jednak do pełni szczęścia brakuje mi tam gwarancji bezpieczeństwa. Wiem, że równocześnie istnieją forki archa oferujące pewną dozę immutable (ze steam OS na czele) oraz że istnieje inicjatywa reprodukowalnych buildów.

Nie widzę jednak dla siebie oczywistego zwycięzcy w tym pojedynku. Hobbystycznie testuję NixOSa na wirtualce. Luźną inspiracją było tu podejście Michtella Hashimoto, a potencjalnym uzupełnieniem może w przyszłości zostać omanix.

Niestety wyżej wymienione aspekty, jak i obiektywne przeszkody odciągnęły mnie od zgłębiania innych, nowych obszarów, a nawet samego blogowania.

2026

Największą zagadką dla wszystkich jest pewnie, co się zmieni w kontekście AI. Sposób pracy ewoluuje niemal stale. Budowa nowych centrów obliczeniowych spowodowała, że w ostatnim kwartale 2025 ceny pamięci wystrzeliły, niczym ceny kart graficznych w czasach największego boomu na koparki.

Z drugiej strony wiele się słyszy, o przegrzaniu całego tematu. Pytanie, czy w tym roku więcej będzie stabilizacji, czy przeciwnie — może ujawni się nowy czarny łabędź AI.

Pisząc to, moją myślą przewodnią na 2026 jest szukać balansu w rozwoju, poprzez eksplorowanie nowych obszarów przeplatane gruntowaniem wiedzy oraz narzędzi pracy. Jak wspomniałem w ostatnim ustępie podsumowania 2025, ruch w obszarze narzędzi (a szczególnie omarchy) zainspirował mnie. Myślę, że DHH (znów) dobrze zdiagnozował problem i zaproponował intrygujący kierunek rozwiązań. Ogromna dynamika zmian w sposobie pracy generuje oczywistą potrzebę porządkowania. Podążanie za nowinkami poszczególnych narzędzi AI grozi utratą z horyzontu celu. Po prawdzie nie jest to całkiem nowe zjawisko w naszej branży, ale sytuacja wydaje się bezprecedensowa. Nowe narzędzia powinny służyć nam, a nie odwrotnie. Aż dziw bierze, jak łatwo jesteśmy skłonni poświęcać tak ważne dla nas aspekty, jak funkcjonalność, prostota, bezpieczeństwo czy wydajność, urzeczeni coraz to nowymi możliwościami agentów.

Na tym tle postawienie programisty na powrót w centrum procesu wytwórczego wydaje mi się zasadną korektą kursu.

Zabawnym efektem ubocznym może tu być niespodziewane ziszczenie się wyszydzanego od lat “roku linuksa” niczym Bilbo opuszczający Shire. Tym optymistycznym akcentem życzę sobie i Wam, by 2026 nas mile zaskoczył.

Bywajcie 🖖