5 czerwca 2025 roku byłem na MoscowJS 65 w T Banku w Moskwie. W tamtym momencie pracowałem z JavaScriptem już od sześciu lat, więc nie szedłem na meetup po odpowiedź, jakiego frameworka albo narzędzia powinienem użyć jako następnego. Interesowało mnie coś innego, trudniejszego do uzyskania podczas samotnej pracy: kilka godzin skupienia na konkretnych tematach technicznych wśród ludzi, których interesują te same problemy.
Program był mocno skoncentrowany na AI. Zgodnie z oficjalnym programem MoscowJS 65 cztery wystąpienia dotyczyły asystenta opartego na LLM, działania i ograniczeń współczesnej AI, wykorzystania vision-language models w testach UI oraz ryzyk bezpieczeństwa związanych z AI przy pracy z NPM. Program był krótki, ale ten sam szeroki temat pokazywał z bardzo różnych perspektyw inżynierskich.
Co zostało ze mną po spotkaniu
Prezentacje były technicznie ciekawe, ale atmosfera miała dla mnie równie duże znaczenie. Prelegenci wnosili prawdziwą energię, a wydarzenie było żywe, a nie pasywne. To jeden z powodów, dla których nadal lubię lokalne meetupy dla programistów.
Dokumentację, artykuły i kod źródłowy mogę czytać w dowolnym momencie, podobnie jak oglądać nagrania konferencji. To wszystko jest niezbędne. Meetup tworzy jednak inny rodzaj skupienia: jeden wieczór, ograniczony zestaw tematów i sala ludzi na tyle zainteresowanych, że przyszli porozmawiać o nich na żywo. Przy niszowych zagadnieniach taki kontekst pomaga lepiej zapamiętać idee i bardziej krytycznie je ocenić.
Prezentacja to punkt wyjścia, nie dowód
Jest też ważne ograniczenie. Wystąpienie konferencyjne nie jest dokumentacją, benchmarkiem ani dowodem, że pokazane podejście nadaje się już do mojego własnego kodu produkcyjnego. Dobre demo może być wartościowe, ale nie pokazuje automatycznie, że ta sama idea wytrzyma inne ograniczenia, edge case’y, koszty utrzymania czy założenia dotyczące bezpieczeństwa.
W przypadku AI to rozróżnienie jest szczególnie ważne. Pytanie nie brzmi tylko: „czy demo działa?”. Chcę też wiedzieć, co dokładnie pokazano, jakie założenia pominięto, czy wynik da się odtworzyć, jakie nowe failure modes się pojawiają i czy narzędzie rzeczywiście zmniejsza złożoność, czy tylko przenosi ją w inne miejsce.
To jest już praca inżynierska po meetupie. Wydarzenie może zwrócić moją uwagę na pomysł. Weryfikacja nadal musi odbyć się osobno.
Dlaczego nadal chodzę
JavaScript jest tak szeroki, że łatwo spędzić miesiące wyłącznie w tej jego części, której wymaga jeden projekt. Meetup na chwilę wyrywa z tej rutyny. Na MoscowJS 65 jeden temat połączył developer tooling, zachowanie modeli, testowanie i bezpieczeństwo pakietów. Nie musiałem wdrażać każdego pomysłu, żeby wieczór był wartościowy.
Najprostsze przypomnienie było dla mnie najważniejsze: po sześciu latach z JavaScriptem nadal lubię zagłębiać się w konkretne tematy i rozmawiać o nich z ludźmi o podobnych zainteresowaniach. Ekosystem się zmienia, modne narzędzia się zmieniają, tematy prezentacji się zmieniają. Ta część pozostaje.
Dla mnie to wciąż wystarczający powód, żeby chodzić na lokalne wydarzenia dla programistów.