Dziś zaserwuję Państwu krótki, aczkolwiek poruszający bardzo trendujący temat artykuł o Vibe coding. Spróbujmy razem zastanowić się, czy pisanie oprogramowania zostało poddane pełnej demokratyzacji? Czy każdy bez większych kosztów może wyprodukować kawałek oprogramowania, sprzedać je, ułatwić sobie życie, a może zwolnić pracowników i robić wszystko sam jako founder? Zaobserwujemy ciekawe trendy i spróbujemy w luźniej formie ocenić wpływ zjawiska vibe-codingu na rynek oraz na nas jako programistów.

Dobrym tłem dla tego wpisu będzie mój poprzedni artykuł dotyczący ogólnego wpływu AI na rynek IT. VIbe Coding to pewien wycinek, dosyć znacząco wpływający. Ostrzegam, że artykuł [../../pl/wplyw-ai-na-rynek-it-w-2026/index.html] jest dość długi, bo i problem nie jest prosty i łatwy do omówienia.

Definicja pojęcia Vibe Coding

Pojęcie zostało wprowadzone około rok temu, gdy ludzie przestali kodować pisząc kod własnoręcznie. Jego pomysłodawcą zdaje się być Andrej Karpathy [https://karpathy.ai/], specjalista od sieci neuronowych i właściciel firm związanych z zagadnieniem sieci oraz content creator. Był między innymi Dyrektorem of AI w Tesli. Jest to na pewno autorytet w branży.

Znaczenie tego pojęcia skupia się tak naprawdę na 4 aspektach:

• Natural-Language-Driven Development - zamiast pisania ręcznie kodu, osoba kodująca daje tylko polecenia narzędziom takim jak Claude Code czy Cursor.ai
• Zmiana charakterystyki pracy - od teraz vibe-coder nie jest już koderem a bardziej menadżerem projektu
• Szybkie iteracje - podczas jednej sesji jesteśmy w stanie zamknąć wiele zadań i szybko sprawdzać jak efekty naszej (oraz agenta) pracy na produkcji
• Duża złożoność poza zasięgiem naszego wzroku - nie musimy już rozumieć każdej klasy czy metody, skupiamy się na widoku ogólnym, nie musimy znać detali implementacyjnych danego komponentu czy nawet całego serwisu

Główne wyzwania stojąca za kodowaniem w ten sposób to problemy z debugowaniem, ryzyko produkcyjne, ryzyka związane z bezpieczeństwem oraz zarządzanie kontekstem i umiejętnościami agentów.

Poziomy (środowiska) do Vibe Codingu

Na rynku widzimy kilka sektorów/poziomów tworzenia oprogramowania w opisywany sposób. Pierwszy, najbardziej popularny wśród osób nietechnicznych to używanie aplikacji do tworzenia oprogramowania językiem naturalnym takich jak: Lovable [https://lovable.dev], Replit[https://replit.com/], Base44 [https://base44.com/] czy Bolt [https://bolt.new]. Wszystkie te narzędzia są używane raczej przez osoby bez umiejętności kodowania. Reklamują się jako narzędzie dla "każdego". Są między nimi jakieś różnice ale w przybliżeniu robią to samo: tworzą aplikacje, deployują, debugują na postawie zadanych promptów.

Kolejny typ narzędzi to IDE lub narzędzia konsolowe, które pozwalają nam zobaczyć i dotknąć kodu w edytorze na swoim komputerze. Narzędzia te poprzez API komunikują się z dostawcami LLM (OpenAI, Anthropic, Google itd.) w celu wymiany informacji i otrzymania odpowiedzi na polecenia wpisywane w oknie czatu. W tych narzędziach mamy nieco większą kontrolę nad kodem, możliwość organizacji pracy agentów, specyfikacje techniczne itd, jest aktualnie używany przez programistów. Zgodnie z wynikami ankiety na githubie z 2025 roku tylko 1/4 programistów używa AI do vibe-codingu [https://survey.stackoverflow.co/2025/ai#developer-tools-ai-explain]. Przykładami takich narzędzi są Cursor.ai, Kiro, Windsurf, Kiro, Antigravity od Google czy nieco inny, bardziej techniczny Claude Code oparty o konsolę komend interface.

Dzisiaj skupimy się głównie na pierwszym z wymienionych typów vibe-codingu, bo to on głównie rozszerza grupę programistów o dotychczasowych nie-programistów. To tam tworzone są codziennie setki tysięcy aplikacji, tak nie pomyliłem się - setki tysięcy użytkowników tworzy tam i realizuje swoje pomysły na oprogramowanie. Wycenia się, że Lovable osiągnęło wartość $6,6 mld (Series B). $200 mln ARR myślę, że wyczerpuje temat ilości płacących użytkowników biorąc pod uwagę Przypomnę, że szwecka firma została założona nieco ponad dwa lata temu.

Trendy

Zobaczmy na trendy w wyszukiwaniu w Google:

Widzimy kosmiczne wzrosty wyszukiwań w narzędziach do kodowania lokalnie oraz regularny stopniowy wzrost zainteresowania narzędziami do czystego vibe-codingu. To pokazuje, że obecnie społeczeństwo stopniowo z niedzielnych programistów bez pisania kodu, powoli chcą przejmować kontrolę nad swoim kodem i stawać się programistami z krwi i kości. W moim odczuciu (nie da się tego zbadać) to mogą być inne grupy docelowe. Vibe coding bardziej dla founderów, manadżerów i prywatnych osób z ambicjami publikacji swojego pomysłu, IDE AI i Claude Code dla osób bliżej technologii niż produktu docelowego - oprogramowania które działa.

Zobaczmy teraz na ilość opublikowanych (analezione na X.com) oraz co najważniejsze pobranych aplikacji mobilnych w ostatnim roku na bazie świetnej strony internetowej ittransition.com[https://www.itransition.com/services/application/development/mobile/statistics]:

Ograniczamy się tutaj tylko do US ale widać wyraźną korelację pomiędzy boomem na aplikacje kodujące w ogólnym rozumieniu (początek 2025 roku) oraz ilością publikowanych aplikacji. Sprawdźmy sobie teraz ilość pobrań aplikacji w tym samym czasie:

Zwróćmy uwagę na Stany Zjednoczone w tabeli powyżej. Mamy 12.6 miliardów pobrań w 2025 roku. Spadek o 2.3% względem 2024. Weźmy pod uwagę, że w Stanach żyje około 350 milionów ludzi, odrzucając 10-15% osób nie korzystających z aplikacji mobilnych w ogóle, w negatywnym scenariuszu 15% - pozostaje około 300 milionów aktywnych użytkowników. To daje około 30-35 pobrań aplikacji przypadających na jednego usera. Weźmy pod wagę to, że:

• ludzie mają nowy telefon często co roku
• niektórzy mają 2 lub więcej urządzeń do zastosowań w pracy/życiu prywatnym

To daje w mojej ocenie pomiędzy 20 a 30 aplikacji przypadających na jedno urządzenie pobranych z marketplaców. Sam mam na telefonie około 50 aplikacji, większości nie używam, są zainstalowane w razie potrzeby do celów, które nie występują często jak rezerwacja wizyty u fryzjera, czy wysyłka paczki.

To stawia jedno pytanie: skoro mam 30 aplikacji na telefonie: po co miałbym pobierać kolejną? Myślę, że to pytanie zadają sobie również klienci dzisiejszych vibe-coderów. Widać wyraźnie rozjazd w liczbie publikowanych aplikacji versus ilość pobrań aplikacji.

Zauważmy, że do telefonu przenieśliśmy już prawie wszystkie czynności jakie wykonujemy na codzień: od budzików, płatności, komunikację, przez opiekę nad dziećmi, gotowanie/katering aż po aplikacje do monitorowania czy polepszania jakści snu. Budzimy się i zasypiamy z telefonem przy głowie lub w ręku. To zadaję pytanie: co jeszcze można tam wpakować?

Wynika z tego, że większość pieniędzy przepalanych na tworzenie apliakcji (tokeny nie są darmowe) idzie na produkcje flopu, który nie wnosi wartości dla użytkownika końcowego. Aplikacje mobilne stały się teraz bardzo łątwe do publikacji, sama publikacja też nie jest darmowa, subskrypcja dla dewelopera też kosztuje. Wynika z tego, że prawie cały kapitał "zainwestowany" w vibe-coding idzie do prowiderów modeli, część pieniędzy zostaje w rękach aplikacji typu Lovable (zakładając marżę 40-60%), część kapitału płynie do korporacji (Google i Apple na opłaty wniesione przez dewelopera - vibe codera), a później dalej od prowiderów modeli do:

• producentów krzemu i kart graficznych
• właścicieli serwerowni
• producentów energii

Przepływ kapitałowy zakłądając, że aplikacje desktopowe oraz gry wideo, czy też aplikacje webowe powielają ten trend ze świata mobile jest skierowany do firm z nasdaqa - firm technologicznych oraz producentów energii. Zobaczmy jak to wygląda jeśli chodzi o wyceny i sentymenty rynkowe:

Widzimy dywergencję na poziomie -40% pomiędzy SaaS index, a top 100 firm notowanych na Nasdaq. To zadziwiające jak bardzo zwycięskie są w tej rzeczywistości giganci tacy jak Alphabet, NVIDIA, Apple czy Microsoft (no tutaj może mniej po ostatnich spadkach), a co za tym idzie do ich inwestorów. Kto by się tego spodziewał? :D Widocznie SaaSy są w mocnej defensywie, lub po prostu rynek inwestorski marnie ocenia ich szansę względem produkcji AI przez dotychczasowych klientów SaaSów.

Techniczne możliwośći Vibe Codingu

No dobrze, omówiliśmy definicję, trendy, ale co z realnymi możliwościami tych narzędzi. Potestowałem je trochę i moje osobiste odczucie jest takie, że jako programista napisał bym to lepiej lokalnie z narzędziami z drugiej grupy. Natomiast nie można odmówić im tego, że potrafią stworzyć całkiem sprawną aplikację jeśli chodzi o funkcjonalności. Kwestię designu pozostawiam waszej ocenie, jedno jest pewne, łatwo można zauważyć poniekąd standardowy UX i kolorystykę danego narzędzia który jest dość powtarzalny. To jednak pewnie kwestia dodatkowych promptów stylujących.

Skalowanie

Co ze skalowaniem aplikacji w chmurze? To też jest możliwe, większość aplikacji oferuje nie tylko kodowanie ale również testing, deployment, raportowanie, monitoring itd. Jest to można powiedzieć mini software house, który napisze i dostarczy oprogramowanie pod danym adresem www. Za skalowanie oczywiście trzeba dopłacić, i tutaj znów operatorzy Claudów zyskują dwukrotnie: na etapie wytwarzania kodu oraz na etapie publikacji danego oprogramowanie czy też aplikacji. Rynek jednoznacznie kieruje pieniądze w stronę dużych graczy.

Bezpieczeństwo

Jako, że cybersecurity nie jest moja specjalizacja, będę posiłkował się opinią innych ludzi. Zachęcam do obejrzenia filmu poniżej lub podobnych:

Autor zaznacza typowe problemy związane z bezpieczeństwem podczas Vibe Codowania. Warto zwrócić na to uwagę. To co chciałem zaznaczyć to fakt, że zagrożenia istnieją i wielu Vobe COderów może zrobić sobie krzywdę publikując na oślep. Pomimo tego, że w materiale autor pokazuje kodowanie w IDE, trzeba pamiętać, że pod spodem leżą te same modele, jakich używają typowe on-line owe narzędzia wymienione wcześniej.

Jakość kodu

Zauważmy, że jakość umieściłem jako ostatni aspekt techniczny, bo z punktu widzenia Vibe COdera nietechnicznego, ma to dość marginalne znaczenie. Liczy się to, że produkt jest gotowy do publikacji i sprzedaży.

Koszty wytworzenia aplikacji

Można by zapytać, a ile kosztuje Panie kierowniku? Dość trudno odpowiedzieć na to pytanie. Pricing narzędzi do Vibe Codingu jest wszędzie podobny, ograniczona ilość tokenów za cenę 20/30/100 dolarów miesięcznie. Po osiągnieciu limitu musimy odczekać lub dopłacić za over-use.

That's just a simple estimation on the cost of software development. Powinniśmy dodać do tego koszt utrzymania. Zaliczamy w to hosting, skalowanie, monitoring, poprawa błędów (zawsze się pojawią), domena, komunikacja z API zewnętrznymi (na przykład LLMami). To jednak nieznacznie będzie się różnić od tradycyjnego sposobu wytwarzania oprogramowania. Opracowałem tabelkę na podstawie zarówno swoich doświadczeń, pomocy LLM-a, różnych źródeł. Można powiedzieć, że jest to przybliżony koszt w każdym z przypadków mocno zależnym od domeny, specyfikacji, dokładności wymagań itd.

Widzimy wyraźnie, że VIbe Coding nie dość, że daje dużo frajdy twórcom, to jeszcze jest tańszy i mniej czasochłonny - co jest bardzo ważne niż tradycyjne zlecanie programowania firmom czy freelancerom. Pomijamy w tym procesie człowieka, który musiał spędzać czas nad koncepcją, projektowaniem, implementacją, testowaniem itd. Czy to dobrze? Nie wiem, choć się domyślam, że dla founderów to bardzo dobra wiadomość. I tak płynnie przejdziemy do kolejnego aspektu, aspektu psychologicznego.

Aspekt psychologiczny

Pamiętajmy, że przez ostatnie 50 lat proces wytwarzania był podobny:

• zatrudniamy zespół lub delegujemy firmie zewnętrznej
• dostajemy wycenę
• negocjacje/akceptacja
• następnie czekamy aż ludzie z piwnicy wyprodukują kod
• testujemy
• rozliczamy
• publikujemy i sprzedajemy

Wcześniej takie proces protrafił trwać nawet kilka lat! Dziś mamy pozornie to samo w czasie 1 czy dwóch tygodni lub nawet jednego dnia!

To sprawia iluzję szybkiego, taniego, z pominięciem problemów ludzkich (lenistwo,przeciąganie, choroby, komunikacja) i wszystko to robię sam, no właśnie.

Iteracyjność w marketingu, szybkie strzały dopaminy w głowie

Nie jestem neurobiologiem, opisuję to tylko z perspektywy programisty z 10 letnim stażem. W programowaniu ewidentnie dużą rolę na wytwarzanie mają zastrzyki dopaminy. Kojarzysz to uczucie kiedy coś zaczyna działać po godzinach spędzonych nad problemem. Albo kiedy kończy się sprint i realisujecie spory kawałek kodu? Wielu (w tym mnie) takie strzały motywują i nakręcają. Stawrzają, że nawet pomimo zmęczenia chcemy dokończyć dany etap prac. Mózg lubi to uczucie: Wow! W końcu działa. Mogę śmiało powiedzieć, że jest to uzależniające podobnie jak social media czy gry wideo. Uzależnienia od substancji też opierają się na podobnych mechanizmach, jednakże, to co opiusuję zaliczyłbym do innej kategorii. Źródła, do których dotarłem są one nazywane uzależnieniami behawioralnymi (źrodło: https://vitalibera.pl/uzaleznienia-behawioralne/).

Mam wrażenie, że szybkość działania narzędzi tylko to nakręca. Można bardzo daleko popłynąć. Będąc na jednym spotkaniu dla Vibe Coderów niedawno, zauważyłem, że prelegencji zachowywali się troche jakby w transie, ekscytacji w stylu: "o patrzcie, jak szybko mi to zaczęło działać, jakie to fajne". Zabawnie to wyglądało z perspektywy osoby, która rozumie jak ten mechanizm działa u programistów.

To zdecydowanie nakęca hype wokół Vibe Codingu. W podsumowaniu jeszcze to poruszę. Teraz natomiast chciałbym też poruszyć kwestię wilczego pędu i nakręcania na szkolenia, webinary, kursy itd przez Vibe Coderskich guru. Każdy oczywiście ma prawo sprzedawania czego sobie zechce. Nie da się jednak pominąć tego w kontekście FOMO, agresywnej reklamy i ich wpływu na naszą psychikę.

Każda osoba nietechniczna, tkóra to widzi może mieć wrażenie, że jakiś pociąg im odjeżdzą. Jeśli nie spróbuje i nie nauczą się kodować, mogże ich ominąć ogromana szansa na wzbogacenie się czy wypuszczenie danego produktu. To ogromna pokusa, którą jako zwierzęta stadne nie potrafimy łątwo ominąć i zamknąć się na wszelkie komunikaty.

Bioroąc pod wagę powyższe, jestem w stanie śmiało przewidzieć dalsze wzrosty użycia, więcej adopcji na rynku i zwiększający się rynek no-code lub low-code w wydaniu Vibe Codingu. Można zadać pytanie: "czy wszyscy jesteśmy dziś programistycznymi ćpunami?" ad voce pytania tytułowego. Ja jednak na ten moment jestem daleki od takiego stwierdzenia. To nadal nisza ale warto ten kontekst obserwować.

Podsumowanie i wnioski

Czy wszyscy jesteśmy dziś programistami?

Technicznie - być może tak.
Praktycznie - jeszcze nie.
Biznesowo - zdecydowanie nie.

Vibe Coding to realna zmiana. Nie jest to chwilowa moda jak kolejne frameworki JS, które przychodzą i odchodzą. To zmiana sposobu wytwarzania oprogramowania. Kod przestaje być celem, staje się efektem ubocznym rozmowy z maszyną. To ogromna różnica.

Z jednej strony mamy pełną demokratyzację. Osoba bez wykształcenia technicznego może dziś stworzyć działającą aplikację, opublikować ją i przetestować rynek w tydzień. To wcześniej było niemal niemożliwe bez kapitału lub zespołu. To ogromna szansa.

Z drugiej strony – rynek aplikacji jest nasycony. Telefon nie jest z gumy. Użytkownik nie ma nieskończonej uwagi. Większość nowych produktów nie rozwiązuje realnego problemu, tylko replikuje istniejące rozwiązania. Produkcja rośnie szybciej niż popyt.

Kapitał również przepływa w bardzo konkretnym kierunku.
Tokeny → modele → chmura → krzem → energia.
Zwycięzcami są dostawcy infrastruktury. Nie każdy vibe-coder.

Technicznie?
Da się zbudować dużo. Czasem zaskakująco dużo.Ale debugowanie, bezpieczeństwo, skalowanie i utrzymanie nadal wymagają zrozumienia systemu. I tutaj doświadczenie programisty wciąż ma ogromną wartość.

Psychologicznie?
To najbardziej fascynujący aspekt. Vibe Coding daje szybkie strzały dopaminy. Tworzysz. Działa. Publikujesz. Iterujesz. To uzależnia. Hype nakręca hype. A FOMO sprzedaje kursy. Czy to źle? Nie. Czy to trzeba rozumieć? Zdecydowanie tak.

Moim zdaniem przyszłość nie należy ani do „czystych” vibe-coderów, ani do programistów ignorujących AI. Wygrywać będą ci, którzy:

• rozumieją fundamenty inżynierii,
• potrafią myśleć systemowo,
• używają AI jako wzmacniacza, nie jako protezy,
• rozumieją biznes, nie tylko kod.

Programowanie nie znika. Zmienia się jego warstwa operacyjna. Coraz mniej pisania klas, coraz więcej podejmowania decyzji. Może więc pytanie nie brzmi: „Czy wszyscy jesteśmy dziś programistami?” Tylko raczej: „Czy wszyscy jesteśmy dziś product builderami?” Bo kod stał się tańszy. Uwaga użytkownika - nie. I to ona, jak zawsze, będzie walutą ostateczną.

Dodatkowo potrzbujemy pewnej strategii, dziś nie jest problemem ile apliakcji wytworzymy ale czy warto pochylać się nad danycm problemm i z długiej listy pomysłów wybrać te, które rzeczywiście rozwiązują problemy rynkowe. Tworzenie dla tworzenia raczej nie da nam świetlnej przyszłości.

Czekam na wasze wnioski! Dzięki

Słucham sobie opinii różnych aktorów na rynku IT: dużych firm, molochów technologicznych, małych przedsiębiorców zatrudniających 1-5 osób, rekruterów, pracowników, podwykonawców, freelancerów, influencerów w AI, szkoleniowców dotyczących AI i jego wpływie na rynek pracy. Każdy z nich moim zdaniem trochę podciąga rzeczywistość pod swój interes.

Dane wejściowe

Moja opinia na ten temat jest niestety okrutna dla części rynku, żeby zgłębić temat potrzebujemy kilku perspektyw i danych wejściowych. Na podstawie poniższych składników postaramy się realnie ocenić stan otoczenia rynkowego, w którym się znaleźliśmy.

1. Perspektywa pracownika (freelancerzy, specjaliści, początkujący)

2. Perspektywa pracodawcy (właściciele, akcjonariusze, menadżerowie)

3. Perspektywa dostawców oprogramowania

4. Badania dotyczące zatrudnienia

5. Moja perspektywa

Przejdźmy przez poszczególne punkty, na końcu zrobimy podsumowanie, które będzie jednocześnie zawierało moją osobistą opinię o rynku.

Perspektywa pracownika

W 2025 roku portal StackOverflow przeprowadził ankietę. Wzięło w niej udział około 20-60 tysięcy specjalistów IT. Liczby różnią się w zależności od pytania. Najbardziej interesująca w kontekście naszego rozważania jest strona: https://survey.stackoverflow.co/2025/ai/. Narzędzia AI w procesie dewelopmentu są używane na codzień przez 47%. Zaledwie 16% w segmencie wszystkich programistów deklaruje, że nie planuje używać AI do tworzenia oprogramowania.

Narzędzia w procesie rozwoju

To bardzo ciekawe ale daje nam jasny obraz, około 84% ankietowanych jest pozytywnie nastawiona do narzędzi AI. Narzędzia jednak są bardzo ogólnym pojęciem i wpada w to: czatowanie, vibe-coding, podpowiadanie składni, generowanie treści itd. Nie jest to aktywność ściśle związana z oprogramowaniem, a raczej codzienne użycie do różnych celów.

Sentyment

Kolejny interesujący trend stanowi sentyment, który spadł z 70% i powyżej w latach 2023 oraz 2024 do około 60% dziś (końcówka 2025 roku). Szczegóły możesz podejrzeć poniżej[https://survey.stackoverflow.co/2025/ai#sentiment-and-usage-ai-sent].

Dzięki temu, że używamy narzędzi wiecej niż w poprzednich latach, część z nas zauważa niedoskonałości czy też brak zaspokojenia naszych potrzeb przez te narzędzia. Hype wszechobecny w mediach, w szczególności na LinkedIn buduje wysokie poziomy oczekiwań względem tych narzędzi. W praktyce, jeśli nie potrafimy "rozmawiać" z AI, nie będziemy w stanie rozwiązać wielu problemów.

Przeznaczenie użycia

Kolejne ciekawe odpowiedzi widzimy w pytaniu: "Which parts of your development workflow are you currently integrating into AI or using AI tools to accomplish or plan to use AI to accomplish over the next 3 - 5 years? Please select one for each scenario."

Zdecydowanie pisanie kodu nie jest dominującym powodem do wykorzystywania AI. W większości używamy modeli do generowania treści, researchu oraz edukacji. Osobiście bardzo wiele pytań zadaję chatowi GPT, jestem w stanei punktowo nauczyć się pewnych zagadnień w krótkim odstępie czasu. Nie potrzebujesz już przeczytać całej książki, czy przejścia 50 godzinnego kursu aby informacje zdobyć. To kwestia zadawania odpowiednich pytań i kierowania rozmowy do celu jakim jest zdobycie i zwizualizowanie poszukiwanej informacji.

Dokładność

Przejdziemy sobie do kolejnej sekcji ankiety, czyli DOKŁADNOŚĆ LLM-ów. Poniższy wykres pokazuje, że zaufanie do dokładności efektów pracy AI pozostawiają wiele do życzenia. Ludzie są raczej sceptyczni jeśli chodzi o ten benchmark.

Co więcej, prawie połowa ankietowanych wyraża brak zaufania. Szczerze powiedziawszy, nie spodziewałem się aż tak negatywnych odpowiedzi. Sam zauważam przekłamania i halucynacje, ale nie powiedziałbym z wysokim stopniem pewności, że nie ufam odpowiedziom, jakie modele generują. Jak to mówią: ufaj ale sprawdzaj!

Frustrations

Idąc tym negatywnym trendem omówionym w rozdziale "Dokładność" zerknijmy sobie, gdzie AI przyprawia użytkowników o frustrację:

The biggest sources of frustration are:
- "AI solutions that are almost right, but not quite"
- "Debugging AI-generated code is more time-consuming"

Oba powody są bardzo zrozumiałe, chcemy przecież aby nasza produktywnośc rosła, to dlatego sięgamy po różnego typu narzędzia. Jeśli musimy się nauczyć korzystać z agentów, chatów czy generatorów to liczymy na zwrot z tej inwestycji w postaci czasu zaoszczędzonego później na wykonywaniu naszych zadań. Jak widzimy, osoby niezadowolone z pracy z AI nie widzą realnego wpływu na ROI. Na poziomie osobowym skutkuje to większą frustracją natomiast dla firm będzie to realny wpływ na finanse i efektywność biznesu.

Vibe coding

Zacznijmy od wyjaśnienia czym właściwie jest vibe-coding. W 2025 roku pewna znana persona nazwała ten sposób współpracy z agentami kodującymi. Praktyka ta polega na wytwarzaniu oprogramowania bez właściwie pisania kodu własnoręcznie a jedynie komunikowania się z agentem opartym o różne modele LLM. Z ankiety wynika, że tylko 25% ankietowanych spożród ponad 20 tysięcy używa agentów właśnie w ten sposób.

To również jest zaskakujące. Wynika z tego, że trend vibe-codingu jeszcze nie rozwinął się na tyle aby zdominować metodologię pracy programistów.

AI Agents Usage

Kolejne pytanie dotyczy celu, w jakim używamy agentów AI. Zdecydowana większość (83.5%) używa ich do Software Engineeringu. To pytanie może być nieco tendencyjne, biorąc pod uwagę charakterystykę ankietowanych. Większość z nich bowiem pracuje właśnie w tym obszarze. Niemniej jednak widzimy sporą korelację wytwarzania oprogramowania oraz użycia agentów AI.

LLM-y bardzo dobrze radzą sobie z kodowaniem. To dlatego, że w ogóle nauka języka, semantyki, składni jest można powiedzieć wąską specjalizacją modeli językowych - jak sama nazwa wskazuje.

Postrzeganie inteligencji modeli

Często mylimy postrzeganie rozmówcy i jego poziomu inteligencji właśnie z umiejętnością władania językiem. W programowaniu pisanie kodu samego w sobie zdaje się problemem rozwiązanym przez LLM-y. Nie oznacza to jednak, że praca programisty przestaje mieć sens. Wręcz przeciwnie, teraz możemy się skupić na rzeczach, w których LLMy nie są najlepsze t.j. projektowanie, modelowanie, architektura, UX itd. Samo pisanie kodu, czyli ostatnią fazę wytwarzania kodu możemy spokojnie delegować agentom po pewnym rygorem i ograniczeniami.

Z drugiej strony widzimy frustrację i niezadowolenie z efektu pracy AI w innych obszarach. Tam gdzie potrzebujemy wysokiej precyzji, braku halucynacji, dokładnego planowania, AI nadal zawodzi i wyraża to spora grupa respondentów.

Moja perspektywa podwykonawcy

Sam z perspektywy podwykonawcy tudzież pracownika zauważam negatywne strony użycia AI. Jednocześnie uważam, że w najbliższych latach wytworzymy kilka frameworków pracy z agentami (Claude Code już to robi, konkurencji również). Celem będzie zminimalizowanie halucynacji i poniekąd zmuszenie agentów to replikowania naszej pracy lub nawet wytwarzania kodu w lepszej jakości.

Sam również staram się swoją metodologię wytworzyć i opisuję ją w swoich repo na przykład tutaj[https://github.com/dwisniewski1804/saas-spine/blob/main/clap/clap_manifest.md]. Nie wiem czy pomysł będę rozwijał intensywnie, natomiast kilka takich metodologii czy frameworków już powstało i jest to moim zdaniem coś czego nie unikniemy.

Nie da się kierować LLM-ami bez konkretnej metodologi i dokumentacji. Wrzucając ad-hockowe prompty narażamy się na duże trudności w zrozumieniu kodu, debugowaniu, rozwijaniu go oraz wykonywaniu code-review. Rynek już to zauważa, dlatego ostatnio głośno jest o SDD - Spec Driven Development [https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html], gdzie podajemy stosowne artefakty zanim zlecamy pisanie kodu. To bardzo zbliżone to mojej metodologii: CLAP - ja swoją rozwijam tak, aby walidacja i bootstrapowanie pomysłów nie były kosztowne i sprowadzały się do kilku sesji z agentami. To jednak temat na osobny post. Postaram się to opisać w najbliższej przyszłości.

Kluczowa sprawa: realny wpływ na efektywność

Ostatnie pytanie z ankiety będzie dotyczyło użycia agentów do pracy i wpływ na efektywność. Nie trudno zauważyć, że jedynie w obszarach komunikacji/kolaboracji z zespołem użycie agentów AI ma neutralno-negatywny wpływ z perspektywy programisty.

Najważniejszy wykres: "AI agents have increased my productivity" potwierdza iż ponad 65% ankietowanych potwierdza iż jego produktywność wzrosła. Pomimo pomyłek, halucynacji, sam proces pisania kodu (stukania w klawiaturę) zabiera jednak wiele czasu i LLM-y są w tym świetne.

Wcześniej korzystaliśmy z narzędzi typu InteliSense IDE, później z modeli językowych do podpowiadania składni, dokończenia linii kodu, czy autocomplete całego pliku. Dziś wiemy, że LLM (szczególnie wytrenowany pod kodowanie) jest w stanie napisać przyzwoity kod szybciej niż my - specjaliści wykształceni w tym celu - do wytwarzania kodu. Samo jednak pisanie jest tylko ułamkiem całego procesu, musimy o tym pamiętać. Dobry koder != dobry inżynier oprogramowania.

OpenAI i podobne firmy - rzeczywiście pojawiają się wypowiedzi (np. od Dario Amodei z Anthropic, Sama Altmana z OpenAI) sugerujące, że AI będzie pisać coraz więcej kodu, a rola programistów się zmieni. Ale to bardziej prognoza niż deklaracja "my już nie kodujemy". Wewnętrznie te firmy zatrudniają tysiące inżynierów, którzy intensywnie piszą kod - tyle że coraz częściej z pomocą AI.

Perspektywa pracodawcy

Ten rozdział opiszę krótko. Trzeba pamiętać, że zatrudnianie programistów w ostatnich 20 latach wiązało się z wysokimi kosztami. To czyste prawo popytu i podaży. Infrastruktura zbudowania podczas bańki dot-commowej w latach 2000 sprawiła, że możemy zdigitalizować tak naprawdę większość naszego życia. Od spraw związanych ze zdrowiem, przez zarządzanie finansami, aż po opiekę nad naszymi dziećmi. Przez to rosnący popyt na ludzi, którzy "potrafią rozmawiać z maszyną" stale rósł, a populacja nie nadążała z produkcją siły roboczej. Temat ten poruszałem w kontekście rynku polskiego tutaj [../../pl/dlaczego-janek-nie-programuje-cz-1-2022/index.html].

Trudność programowania polega przede wszystkim na abstrakcyjnym myśleniu i zauważaniu wzorców, które należy zastosować. Archetypy oprogramowania, wzorce projektowe, metodologie, abstrakcja. Dochodzi do tego trudność ze środowiskiem lokalnym do dewelopmentu. Wszystkie te problemy rozwiązuje teraz AI, ponieważ jest w stanie zrozumień kod na poziomie podobnym do człowieka. Ale do rzeczy, jaki to ma wpływ na pracodawców?

Trzeba zdać sobie sprawę i zrozumieć, że dla większości przedsiębiorstw programiści to duży koszt. W firmach, gdzie oprogramowanie jest znaczącą częścią procesów na deweloperów wydaje się najwięcej. Zatem każda oszczędność bez spadku jakości wydaje się być łakomym kąskiem. Przytoczę teraz dane z największych firm technologicznych:
Zwolnienia w Google [https://businessinsider.com.pl/gospodarka/setki-inzynierow-google-stracily-prace-przez-sztuczna-inteligencje/j7jf6g0] czy plany zwolnień w innych spółkach technologicznych [https://intellizence.com/insights/layoff-downsizing/major-companies-that-announced-mass-layoffs/] określa trend: redukcja zatrudnienia w działał oprogramowania. Nie jesteśmy jednak w stanei określić jednoznacznie, że to AI na to wpłynęła. Być może firmy przeinwestowały w AI i rozwój LLM-ów a do ich tworzenia również potrzebujesz inżynierów. Być może to AI ułatwia redukcję ze względu na wzrost produktywności. Na konkretne dane musimy trochę poczekać.

Pracodawcy jednak często chwalą się, że zredukowali zatrudnienie z powodu automatyzacji i AI. Nie następuje to jednak w działach inżynieryjnych. To najczęściej obsługa klienta, czy działy gdzie wykonuje się bardziej powtarzalna pracę zostają redukowane jak pierwsze. Patrzmy na przykład na: Salesforce czy Klarna. W przypadku Klarny ten ruch okazał się błędem. Widzimy, że zastąpienie przez LLM-y pracownika nie jest wcale taką łatwą sprawą.

Artykuł z 22 grudnia 2025 (całkiem świeży) pokazuje wpływ AI na rynek pracy w USA. https://itreseller.pl/zbadano-wplyw-ai-na-rynek-pracy-z-usa-wyniki-nie-zaskakuja-ale-przecza-popularnej-narracji/. Tam również pokazywane są zwolnienia przede wszystkim w Microsofcie, gdzie spora część pracowników to programiści. Nie wynika to jednak z samego faktu automatyzacji procesu wytwarzania oprogramowania a zmiany profilu wykonywanej działalności z fabryki oprogramowania do tworzenia narzędzi opartych o AI (Machine Learning, Data Scientists, Mathematicians).

Nigdzie nie widziałem case-study zastąpienia pracowników od oprogramowania czysto przez AI czy bardziej szczegółowo mówiąc: agentów kodujących. LLM-y nadal pozostają tylko narzędziem w rękach pracownika, nie pracownikiem samodzielnym.

Podsumowanie

Z perspektywy pracodawców najlepiej byłoby zwolnić wszystkich pracowników, płacić tylko za prąd i tokeny. Nikt jednak do tej pory nie zdołał udowodnić, że taka inwestycja (tak, to zarządzanie zmianą na ogromną skalę, które kosztuje i jest ryzykowne - dlatego nazwałem to inwestycją) jest w stanie się zwrócić w sensownym czasie. Zwolnienie pracowników to również utrata know-how i SOPs, które nie zawsze są udokumentowane. Ba! W większości firm nie dikumentuje się tego a wiedza jest rozproszona pomiędzy pracowników. Do tego dochodzi polityka międzyludzka w korporacjach, gdzie bardziej niż co umiesz liczy się kogo znasz. To wszystko znacznie utrudnia sparametryzowanie pracy, jej ustrukturyzowanie i co za tym idzie zastąpienie kloclów (ludzi) innymi klockami, które są tańsze.

No właśnie, nie wiadomo, czy te nowe klocki są tańsze i po drugie czy w ogóle spełniają wymagania jakie teraz są stawiane pracownikom. Boleśnie przekonała się o tym Klarna, zwalniając, a później zatrudniając ludzi spowrotem. Nie jest to takie proste jakby się mogło wydawać. Pomimo tego, że pracodawcy trochę grają w oszusta i podburzają tym samym pozycję negocjacyjną programistów (zmniejszający się rynek jest jednak faktem - ale o tym zaraz) podczas rozmów o pracę.

Popyt na pewno się zmieni, ale nie powiedziałbym, że to już nastąpiło. Jesteśmy też zasypani nadmierną ilością sygnałów i bardzo ciężko jest określić czy firma rzeczywiście zredukowała, bo ma AI czy dlatego, że nie ma pieniędzy i musi akcjonariuszom pokazać, że utrzyma rentowność. To bardzo trudne zagadnienie. Dodatkowo rynek pracy nie jest jednorodny. Inaczej wyglada charakterystyka pracy w startupach, małych organizacjach, gdzie testowanie AI jako pracownika ma większy impact na wyniki finansowe, oraz jest też łatwiejsza to wprowadzenia. Inaczej jest znowu w korporacjach, gdzie zwolnienie i zastąpienie pracowników to może być proces, który nie jest wart tej gry. Na rynku widzę nadal wiele niepewności i niejasności. Trzeba będzie jeszcze z rok, dwa odczekać zanim woda (bańka) odpłynie i zobaczymy co tak naprawdę AI jest w stanie zaoferować i czy nadaje się do wdrożenia w miejsce programistów. Podobnie rzecz się ma w innych zawodach. Tylko czas pokaże, czy to mrzonki, czy realny substytut ludzi.

Perspektywa dostawców oprogramowania

Tutaj temat jest bardzo szeroki, zacznę od pokazania sentymentu na rynku SaaS. Spójrzmy jaki wygląda dziś giełda i akcje spółek oferujących oprogramowanie. Polecam przeczytać artykuł [https://dnarynkow.pl/czy-ai-zabije-saas-salesforce-pokazuje-ze-to-bardziej-skomplikowane/] omawiający kwestię producentów oprogramowania (w szczególności SaaS) pod kątem inwestora patrzącego na spółki jak na potencjalne źródło zysku.

Wydźwięk jest raczej negatywny ale nie jednoznaczny. To bardzo ciekawa analiza. Zerknijmy na wykresy:

Powyższe ETF-y skupiają spółki technologiczne z sektora softwarowego. Większość z nich to dostawcy oprogramowania w modelu SaaS lub innym. Wyraźny spadek i powrót do poziomów sprzed lata 2025 pokazuje zdecydowanie negatywny sentyment inwestorów. Zdanie inwestorów jest istotne, bo decyduje o tym gdzie popłyną pieniądze. Zarówno inwestorzy indywidualni jak i instytucjonalni stawiają i liczą na zysk. Zdaje się, że dziś mówią sprawdzam, i oczekują udowodnienia , że SaaSy nadal mają prawo bytu na rynki. Nie oznacza to jednak, że ich obawy są uzasadnione. Bowiem to producent oprogramowania ma pełny wachlarz możliwości aby udowodnić wyższość swoich rozwiązań ponad chałupnicze, ad-hokowe aplikacje vibe-codowane przez zespoły in-house.

Być może scenariusz z SaaSami pójdzie w negatywną dla nich stronę. Ciężko jest to określić. Jedno jest pewne, AI będzie miało wpływ zarówno na same firmy jak i ich pracowników. Jeśli okaże się, że SaaSy nie są już potrzebne, wielu programistów i specjalizacji dookoła wytwarzania oprogramowania po prostu straci pracę. Pieniądze popłyną do vibe-coderskich narzędzi i providerów modeli.

Ja osobiście nie przywiązuję dużej wagi do tego co dzieje się z akcjami pojedynczych spółek. Staram się patrzyć na trendy rynkowe. Tutaj wyraźnie widzimy, że jest tendencja spadkowa lub korekta. Jeszcze nie wiadomo. Widać natomiast jak narracja wokół wytwarzania oprogramowania wpływa na inwestorów. To wcale nie musi oznaczać rychłego upadku firm, czy masowych zwolnień. Jest jednak indykatorem mocno na to wpływającym. Inwestorzy głosują portfelem, sprzedają akcje spółek, z których przychód będzie uciekał - a przynajmniej, o których się tak mówi. A w tym przypadku będzie on uciekał do dostawców energii, kart graficznych, serwerowni oraz w mniejszym stopniu do firm typu OpenAI, Anthropic czy ElevenLabs.

Poruszę też temat rentowności powyżej wymienionych firm. OpenAI w 2026 roku przewiduje $14 miliardów straty w swoim własnym forecaście. [https://finance.yahoo.com/news/openais-own-forecast-predicts-14-150445813.html?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAHSDtEMpQwDcAcxU9CnIDiYDFYTqXulgMszR4CO0WQm7AZh8rvRvb6FGhn7twDzLVeqE-0DfXFbhDrrL3j2CutoLV6McZOo9mxuTSEcA-8ipzgnn52_ST4NNquR3b058TNUcLoNWyshSX1-yUZHR4ew74CWxl2ajjWT6FzsAY3-X]

Anthropic nadal nie jest rentowny i nie będzie przynajmniej do 2028 roku. Artykuł [https://pl.investing.com/news/stock-market-news/anthropic-podnosi-prognoze-przychodow-na-2026-r-opoznia-cel-rentownosci-1254392] nie podaje konkretnych liczb, widać jednak, że do uzyskania zysku jest jeszcze kawałek drogi.

W nieco lepszej sytuacji zdaje się być spółka z polskimi korzeniami (Polacy jako założyciele) ElevenLabs. Materiały prasowe nie publikują wyników rentowności ale artykuł [https://www.bankier.pl/wiadomosc/ElevenLabs-warta-11-mld-dolarow-Spolka-potroila-wycene-i-celuje-w-gielde-9079325.html] wyraźnie wskazuje na $11 miliardów wyceny w kolejnej rundzie finansowania. Spodziewam się jednak, że po IPO dowiemy się, że spośród tych 3 graczy to oni radzą sobie najlepiej.

To są jednak providerzy modeli i usług związanych z nimi bezpośrednio. Są właścicielami IP, mają ludzi, mają pod kontrolą infrastrukturę, mają pieniądze inwestorów. Na tym poziomie jednak, ceny jakie oferują Ci dostawcy mogą być zbyt niskie aby bez zewnętrznego finansowania dalej rozwijać produkty.

Andrew Ng powiedział ostatnio, że problemy jakie rozwiązują LLM-y są od kilku lat rozwiązywane tylko dzięki skalowaniu. Od momentu publikacji [https://arxiv.org/abs/1706.03762] bazujemy na tej samej rodzinie rozwiązań (architekturze). Sama technologia nie zalicza skoków, to tylko efekt coraz to większej ilości sprzętu i węzłów przetwarzających ogromne ilości danych. Dzięki architekturze transformerów potrafimy skalować i zwiększać dokładność modeli w tempie przypominającym funkcje logarytmiczną, bez wyraźnej asymptoty (wyglądają jak łuk rosnący) ale też bez większych skoków.

BTW polecam jego wykłady, są świetne jeśli chcemy wprowadzić się w świat ML.

Wracając do tematu, w pewnym momencie jeśli model biznesowy się nie zmieni, najwięksi dostawcy będą musieli podnieść ceny, a co za tym idzie ich rozwiązania nadal będą tańsze od człowieka ale nie będzie aż tak dużej różnicy (x20, x30 itd). Wtedy firmie może nie opłacać się pisać oprogramowania in-house.

Ryzyko poniesione podczas programowania rozwiązań na własną rękę może przygnieść dotychczasowych klientów SaaSów. Dodatkowo jeśli firma jest zwinna, będzie potrzebowała dużej ilości zmian. Jeśli nie znajdzie metodyki, która rzeczywiście pozwala rozwijać oprogramowanie bez firm zewnętrznych, będzie skazana na używanie SaaSów. Trzeba też wziąć pod uwagę różnorodność tych firm. Małe SaaSy do prostych kalkulacji, analizy itd mogą być zastępowalne. natomiast duże ERP, SAP-y, generalnie oprogramowanie enterprise - z tym klienci SaaSów mogą sobie nie poradzić.

Złotym środkiem wydaje się zatrudnić one-man army, którzy z szeroką wiedzą i agentami AI mogą zdziałać cuda. Niestety nie jest to wiadomość zbyt dobra dla ludzi o wąskiej specjalizacji. Coraz więcej małych organizacji mówi o poszukiwaniu tzw. generalistów lub AI-driven deweloperów. To na razie tylko pogłoski rynkowe. Oferty dla klasycznych deweloperów nadal wiszą na portalach z ogłoszeniami. Procesy nadal trwają. Sam w ostatnim czasie brałem w nich udział. Zdaje się, że coś wisi w powietrzu ale na razie rynek działa tak jak działał.

Muszę tutaj poruszyć kwestię social mediów. Youtube, LinkedIn, Instagram, Facebook. Wszystkie portale są zawalone postami o AI i o automatyzacji. Jescze więcej jest szkoleń z programowania z AI, automatyzacji, użycia LLM-ów w wielu celach zarówno życiowych jak i zawodowych. Zastanawiam się teraz: jak można szkolić z czegoś, co dopiero dwa lata temu w ogóle powstało, a niektóre narzędzia zmieniają się z dnia na dzień? Jaką wartość takie szkolenie wnosi? Kto te szkolenia kupuje? Zauważyłem trend, że osoby z rozpoznawalnością wykorzystują swoje 5 minut podpinając się pod słowo kluczowe: AI. Coś na zasadzie: wszyscy o tym gadają, więc zróbmy o tym szkolenie. Tutaj się zatrzymam, bo nie chcę aby ten post był jeszcze dłuższy.

Badania dotyczące zatrudnienia

Badania wskazują, że AI wpływa na rynek pracy w USA, Europie i UK poprzez automatyzację rutynowych zadań, jednocześnie tworząc nowe możliwości w sektorach technologicznych. W USA obserwuje się spadek ofert pracy biurowych o ok. 17-27% w branżach nietechnologicznych, ale wzrost w AI o 68%. W Europie i UK pracownicy wykazują mieszane nastroje – ok. 34% widzi poprawę warunków pracy dzięki AI, choć wielu obawia się utraty stanowisk juniorskich. Rozbiję to teraz na 3 regiony, gdyż różnią się one zarówno prawem pracy jak i sytuacją rynkową.

USA

Wydajność pracowników wzrosła o 7,2% od debiutu ChatGPT w 2022 r., napędzana AI, co potwierdza raport z lutego 2026 r. Badania z Davos 2026 podkreślają brak masowego bezrobocia, mimo prognoz likwidacji połowy stanowisk juniorskich. MIT szacuje potencjalne oszczędności 1,2 bln USD, z ekspozycją 11,7-27% siły roboczej wg źródeł [https://businessinsider.com.pl/technologie/nowe-technologie/mit-ostrzega-sztuczna-inteligencja-juz-zmienia-amerykanski-rynek-pracy/vzb2n0f].

Europa i UK

Trendy podobne do USA: wzrost ofert pracy z "agentami AI" o 1587% wg Randstad[https://itwiz.pl/ai-zmienia-rynek-pracy-pokolenie-z-najbardziej-zaniepokojone/] (styczeń 2026), z pokoleniem Z najbardziej zaniepokojonym. W Polsce i Europie AI transformuje role umysłowe, z obawami o 20% pracowników biurowych; potrzebne będą przekwalifikowania. UK, jako część danych, notuje wzrost w tech i finansach, ale redukcję rutynowych etatów.

Dla porównania zróbmy tabelkę, którą przygotował mi Perplexity [https://www.perplexity.ai]:

Jak widzimy, wzrost produktywności jest faktem. Faktem jest również minimalizacja roli juniorskich i powtarzalnych prac biurowych tzw "przerzucanie papierów". Widać ogromy hype na agentowe systemy w Europie. Jeśli chodzi o generalny rynek pracy, widoczne są fluktuacje, ale na razie nie widać tego w stopach bezrobocia.

W USA są lekkie wzrosty ale nie wiązałbym tego tylko z zastosowaniem AI. Na wykresie [https://pl.tradingeconomics.com/united-states/unemployment-rate] widzimy normalne stopniowe wzrosty rzędu 1 pkt procentowego. To nie się jeszcze nie dzieje. Bardziej chodzi o psychologię i sentyment niżeli realne obcinanie etatów. W europie z kolei widzimy od lat sukcesywny spadek stopy bezrobocia do poziomów około 10% do około 6% w grudniu 2025

To dane globalne, my skupimy się jednak na rynku IT. Zerknijmy najpierw na listę zwolnień w spółkach związanych z IT. Na łamach Reutersa pojawił sie ostatnio bardzo treściwy materiał [https://www.reuters.com/business/world-at-work/corporate-america-continues-job-cuts-2026-efficiency-push-2026-02-06/#:~:text=Table_title:%20Corporate%20America%20continues%20job%20cuts%20in,%7C%20January%20%7C%20Up%20to%20%E2%80%8B30%2C000%20%7C]. Opisuje on ilość zlikwidowanych miejsc pracy. Najbardziej niepokojące jest zwolnienie 16 tysięcy [https://www.reuters.com/legal/litigation/amazon-cuts-16000-jobs-globally-broader-restructuring-2026-01-28/] ludzi na całym świecie.

Zaledwie dwie firmy jasno zadeklarowały, że zwolnienia są spowodowane w jakimś stopniu użyciem AI:

Jeśli chodzi o oferty w IT, doskonała strona do monitorowania rynku IT (szczególnie w Polsce) jest strona: https://czyjesteldorado.pl/raport-rynku-pracy-it, gdzie znajdziemy raport z 9 lutego 2026.

Widzimy stałe wzrosty od początku 2025 roku. Nieustanny wzrost trwa, stawki utrzymują się na tym samym poziomie. Wydaje się, że nie ma powodów do zmartwień.

Jeśli chodzi o USA, sytuacja ofert pracy widocznie przesuwa środek ciężkości w kierunku ML/AI. Źródło [https://www.techtarget.com/whatis/feature/Tech-job-market-statistics-and-outlook] jasno wskazuje, że rynek pracy w IT nie jest już „automatycznie gorący” jak kiedyś, ale nadal oferuje solidny wzrost i duże możliwości dla osób z odpowiednimi umiejętnościami specjalistycznymi, szczególnie w zakresie AI, danych i cyberbezpieczeństwa. Kluczem jest ciągłe zdobywanie nowych kompetencji, bo firmy mają trudności z znalezieniem wykwalifikowanych pracowników. Liczba ofert pracy zdecydowanie spadła (około -36%) względem poprzednich lat.

Podobnie jak na rynku Polskim (5% ofert dla juniorów) początkujący mają problemy z dostaniem się do pracy po lub w trakcie graduacji w szkołach wyższych czy kursach prywatnych. Z drugiej strony 2025 rok pełen był masowych zwolnień, które lekko spowolniły rynek ogłoszeniowy.

Gdy porównamy sobie dane, to w USA rynek tech nadal szuka talentów, ale techniczne umiejętności są kluczem przejścia przez okres spowolnienia. Natomiast w Polsce rynek jest aktywny i stabilny, z dużą liczbą ofert i dobrymi widełkami płacowymi, lecz tempo wzrostu płac i boom rekrutacji już nie przypomina „eldorado” sprzed lat.

Czy jest to jednak rezultat rewolucji AI? Wszystko wskazuje na to, że popyt na poszczególne specjalizacje fluktuuje między nimi, natomiast rynek zarówno lokalnie jak i globalnie wcale nie jest niedostępny dla dobrego specjalisty. Gorzej mają osoby początkujące, tutaj AI może mieć jakieś znaczenie.

Podsumowanie

Z racji tego, że wpis okazał się dużo dłuższy niż się spodziewałem postaram się podsumować sprawnie i wysnuć właściwe wnioski.

AI realnie zmienia sposób wytwarzania oprogramowania, ale nie zabiła rynku IT. Przynajmniej nie w 2026 roku. Zamiast rewolucji „tu i teraz” mamy powolną, nierówną transformację, w której wygrani i przegrani są wyraźnie rozróżnieni.

Poniżej 8 najważniejszych wniosków z powyższych rozważań i danych.

Produktywność rośnie, ale nie liniowo

• Ponad 60–65% programistów deklaruje wzrost produktywności dzięki AI.
• Zysk dotyczy głównie pisania kodu, researchu i nauki – nie całości procesu inżynierskiego.
• Projektowanie, architektura, modelowanie domeny i decyzje biznesowe nadal wymagają człowieka.

AI jest narzędziem, nie pracownikiem

• Nie istnieją wiarygodne case studies masowego zastąpienia zespołów inżynierskich przez AI.
• Najczęściej redukowane są role powtarzalne i pomocnicze (support, back-office), nie core engineering.
• Firmy, które próbowały „pójść na skróty” (np. Klarna), boleśnie się na tym przejechały.

Największym problemem AI nie jest brak mocy, tylko brak metodologii

• Halucynacje, „prawie dobre” rozwiązania i trudne debugowanie to główne źródła frustracji.
• Ad-hoc promptowanie nie skaluje się w realnych projektach.
• Rynek naturalnie skręca w stronę Spec / Structure / Methodology Driven Development

Vibe-coding to nisza, nie standard

• Tylko ok. 25% badanych korzysta z agentów w pełni „bez pisania kodu”.
• Dominują hybrydowe modele pracy: człowiek + AI, a nie AI zamiast człowieka.

Najbardziej zagrożeni są juniorzy i wąskie specjalizacje

• Wejście do branży jest dziś trudniejsze niż 5–10 lat temu.
• AI podnosi „minimalny próg kompetencji”.
• Rośnie popyt na generalistów, inżynierów systemowych i osoby łączące technologię z kontekstem biznesowym.

Rynek pracy IT nie załamał się – zmienił się jego kształt

• W Polsce: stabilna liczba ofert, sensowne widełki, brak paniki.
• W USA: przesunięcie ciężaru w stronę AI/ML/Data, mniej „klasycznego CRUD-owego” devu.
• Spadki ofert ≠ masowe bezrobocie – to raczej korekta po latach przegrzania.

SaaSy nie umierają, ale muszą się bronić

• Inwestorzy są sceptyczni, sentyment jest słaby.
• Małe, proste SaaSy są potencjalnie zastępowalne przez in-house + AI.
• Duże systemy (ERP, enterprise, compliance, mission-critical) nadal mają ogromną przewagę.

Narracja w social mediach jest znacznie bardziej radykalna niż rzeczywistość

• AI-hype służy sprzedaży kursów, szkoleń i zasięgów.
• Rynek realny porusza się wolniej, ostrożniej i dużo bardziej pragmatycznie.

Mój punkt widzenia

Mam nadzieję, że powyższe podsumowanie dostatecznie streszcze treść arykułu. Chcę jednak dorzucić kilka swoich przemyśleń. Gra jest wielowymiarowa - jej obraz nie jest ani dwu-, ani nawet pięciowymiarowy. Na rynku działa wielu graczy: różne segmenty firm, odmienne cele aktorów rynku, inwestorzy oraz bańka spekulacyjna. Jednocześnie dzieje się bardzo dużo i trudno wyciągać proste, jednoznaczne wnioski.

Z mojej perspektywy - osoby aktywnie uczestniczącej w rynku, która w ostatnim czasie intensywnie szukała nowych wyzwań i brała udział w wielu procesach rekrutacyjnych równolegle - najbardziej rzuciły mi się w oczy dwie rzeczy.

Po pierwsze: bardzo twardo stawiane wymagania techniczne podczas rozmów technicznych. Rynek nie premiuje już wąskich kompetencji ani „bezpiecznego średniaka”. Oczekuje się realnej samodzielności, rozumienia systemów jako całości oraz odpowiedzialności za decyzje techniczne.

Po drugie: duża niepewność w podejściu do AI.
Część firm z dumą mówi o aktywnym wykorzystaniu narzędzi takich jak Claude Code czy agentów kodujących. Inne natomiast ograniczają się do stwierdzeń w stylu: „używamy AI, ale nie mamy jeszcze jasnych granic ani metodologii”. To wyraźny sygnał, że rynek jest w fazie przejściowej – adopcja narzędzi wyprzedziła dojrzałość procesów.

Coraz wyraźniej widać, że rynek staje się trudniejszy i wymaga wszechstronności. Moim zdaniem będzie to prowadzić do modelu, w którym firmy wolą zatrudniać kilka bardzo silnych, wielofunkcyjnych jednostek, zamiast utrzymywać rozbudowane zespoły, które z trudem koordynują własną pracę.

Tak właśnie widzę rynek pracy za kilka lat:

• silny nacisk na AI/ML,
• naturalne połączenie tego z obszarami Big Data i Cloud,
• wysoka wartość osób łączących kilka specjalizacji jednocześnie.

W mojej wizji firmy będą stopniowo ograniczać korzystanie z usług zewnętrznych w zakresie wytwarzania oprogramowania. Zamiast tego będą skupować z rynku najwyższe talenty - ludzi zdolnych samodzielnie projektować, implementować i rozwijać systemy, często działających jak „menadżerowie dla samych siebie”, współpracujący bezpośrednio z product Managerem lub Ownerem.

Nie jest to dobra wiadomość dla wszystkich. Jest to natomiast bardzo dobra wiadomość dla tych, którzy potrafią łączyć technologię, kontekst biznesowy i świadome wykorzystanie AI jako narzędzia, a nie protezy.

Wszystkim czytelnikom życzę dużo zapału do nauki, bo na pewno się przyda, a jedyna recepta na powodzenie w karierze to: tworzenie własnych produktów lub szybka adaptacja do otaczającego nas rynku zatrudnienia w IT. Chętnie poczytam wasze przemyślenia i opinie na powyższy temat.

Dzięki i do następnego

W strategicznym Domain-Driven Design (DDD) wyróżniamy kilka kluczowych elementów. Jednym z nich jest Context Mapping. Bounded Contexty mogą, a nawet muszą się ze sobą komunikować. To integralna część projektowania systemów. Dziś przyjrzymy się rodzajom mapowań i opiszemy je na przykładach z prawdziwego świata.

Miejsce w DDD

DDD dzielimy na dwie części. Strategiczne DDD zajmuje się decyzjami wysokiego poziomu: definiowaniem kontekstów, wszechobecnym językiem (ubiquitous language) i komunikacją między komponentami (bounded contextami). Taktyczne DDD rozkłada z kolei na części elementy znajdujące się wewnątrz bounded contextów. To spore uproszczenie, ale na potrzeby tego wpisu możemy przyjąć, że to wystarczająca wiedza, by zrozumieć, gdzie w tej całości mieści się Context Mapping.

Źródła

Pomocna w tym temacie literatura to przede wszystkim tzw. „niebieska książka” Erica Evansa oraz „DDD Distilled” Vaughna Vernona. Jako uzupełnienie możemy wykorzystać repozytorium DDD Crew.

Mógłbym zakończyć artykuł, po prostu podlinkowując te źródła. Chcę jednak rozwinąć definicje o przykłady z prawdziwego biznesu. To właśnie najtrudniejsza część uczenia siebie i innych DDD. Niewiele firm dzieli się swoimi praktykami, a my opieramy się głównie na teoretycznych przykładach proponowanych przez edukatorów. Dziś spróbujemy przełamać ten schemat i omówić Context Mapping w bardziej praktyczny sposób.

Open / Host Service

W tej sytuacji jeden Bounded Context otwiera swoje API i pozwala zależnym serwisom/modułom korzystać z niego na podstawie (zwykle) dokumentacji API, wystawiając na zewnątrz język swojego kontekstu, ale nie reagując na specyficzne wymagania swoich klientów. To najczęstszy model, zwłaszcza w aplikacjach mikroserwisowych, w których Bounded Contexty komunikują się ze sobą przez REST API.

Przykładem z życia może być Spotify albo inna platforma streamingowa. Załóżmy, że jednym Bounded Contextem jest Katalog, a drugim Odtwarzacz. W tej sytuacji Katalog wystawia swoje API lub fasadę (jeśli to monolit). To typowy scenariusz, w którym Odtwarzacz może po swojej stronie dowolnie wykorzystywać dane dostarczane przez Katalog, ale wyłącznie przez publiczny kontrakt API. Jest to szczególnie przydatne, gdy chcemy, by część naszego systemu była publicznie dostępna.

Conformist

W tym typie mapowania mamy do czynienia z relacją upstream → downstream. Ściśle wiąże ona konformistyczną część systemu (BC) z upstreamem. Można powiedzieć, że decyzje podejmowane przez upstream mogą zepsuć wszystko w downstreamowym BC, co opiera się na kontrakcie z upstreamem. Downstream nie ma w tym obszarze własnego modelu domenowego i bezpośrednio przejmuje model upstreamu, akceptując ryzyko jego zmian.

Przykładem z życia może być dowolna aplikacja korzystająca z API Amazona. Amazon zmienia swoje API? Łamie wsteczną kompatybilność? Musisz się dostosować. W takim przypadku jasne i przewidywalne zachowanie dostawcy API jest kluczowe, by nadążać za zmianami w systemie upstream.

To jednak dotyczy komunikacji z zewnętrznym modułem. Żeby lepiej to zilustrować na przykładzie dostawcy wewnątrz naszej organizacji, weźmy dowolną firmę produktową. Niech upstreamem będzie BC User Management, którego właścicielem jest centralny zespół platformowy. Model powinien zawierać podstawowe encje: User, Role, Permission oraz Value Object Status. Załóżmy też, że zespół odpowiedzialny za ten BC ma silną pozycję w firmie albo jego Tech Lead blisko współpracuje z zarządem.

Jako serwis downstream weźmy w tym przykładzie Bounded Context o nazwie Billing. Billing jako klient potrzebuje informacji o użytkownikach; nie jest właścicielem tożsamości użytkownika i nie ma budżetu ani mandatu, by stworzyć własny model (np. z powodu braków kadrowych).

W praktyce oznacza to, że moduł Billing zaimportuje DTO z User Management i będzie ich używał bezpośrednio. Pola takie jak user_id, role czy status (i wiele innych) będą przechowywane w dokładnie tej samej postaci. Nie ma tu żadnego mapowania ani tłumaczenia.

Jeśli pewnego dnia BC User Management zmieni nazwy statusów, semantykę ról albo usunie pole z modelu, model Billingu – mówiąc potocznie – „się wysypie”. Co ważne, w tym typie mapowania jest to akceptowalne. Zwykle dlatego, że koszt izolacji byłby większy niż koszt dostosowania. Świadczy to też o tym, że zespół Billingu ma mniejszy wpływ na ogólną strategię firmy.

ACL (Anti-Corruption Layer)

ACL (warstwa antykorupcyjna) działa jako warstwa pośrednia między dwoma Bounded Contextami. Jej celem jest ochrona modelu downstream przed „zanieczyszczeniem” językiem używanym w kontekście upstream oraz zapewnienie odporności na zmiany – choć ta odporność wciąż jest ograniczona.

W porównaniu z opisanym wyżej modelem Conformist główne różnice, poza większą inwestycją przy implementacji downstreamowego BC, to:

• Downstream nie przyjmuje modelu upstreamu.
• Downstream ma własny język domenowy.
• Integracja odbywa się przez tłumaczenie, a nie bezpośrednie użycie modeli.

Przykładem z życia jest system obsługujący rozliczenia subskrypcji, korzystający z bramki płatniczej lub systemów płatności takich jak Stripe. Typowa struktura danych w takich systemach to: Customer, Invoice, PaymentIntent i Subscription. API zmienia się stosunkowo często, a terminologia również podlega istotnym zmianom.

Nasz Bounded Context, nazwijmy go Billing, może używać zupełnie innej terminologii, np.: Payer, Charge, BillingPeriod, Settlement. W tym przypadku zespół Billingu nie chce, by semantyka i konwencje nazewnicze przeciekały do jego modelu (bo jeśli zmienimy dostawcę płatności, możemy mieć problem, a zmiana przecieknie do naszego modelu).

Tworzymy wtedy ACL, czyli warstwę mapującą dane z systemu płatności. Klasa korzystająca z API mogłaby się nazywać np. BillingPaymentAdapter, a do niej dodajemy PaymentMapper, który pełni rolę naszego ACL. Dla jasności zamieszczam diagram:

Jak widać powyżej, nasz model downstream jest całkowicie niezależny od Stripe'a czy innego dostawcy. Oto dobra wskazówka implementacyjna: ACL (Anti-Corruption Layer) powinien znajdować się w warstwie infrastruktury, jeśli używamy architektury heksagonalnej lub jej odpowiednika w innych podejściach. Zgodnie z dobrymi praktykami (zasady SOLID) zależności powinny płynąć tylko w jednym kierunku (domena nie powinna wiedzieć, że ACL tłumaczy dane z zewnętrznego systemu). Niedopuszczalne jest na przykład tworzenie zależności domena → infrastruktura albo domena → Stripe SDK. Domena w naszym kodzie powinna znać jedynie interfejs klasy ACL (np. PaymentProviderPort).

Shared Kernel

W niektórych sytuacjach chcemy, by wspólne części Bounded Contextów i ich modelu były świadomie wydzielone, ograniczone i współdzielone przez oba moduły. Kluczowe cechy to: kod we wspólnym jądrze (shared kernel) powinien być ograniczony do minimum, a jego utrzymanie wymaga koordynacji po obu stronach relacji (nie ma tu relacji upstream–downstream, raczej bardziej zrównoważona).

To mapowanie ma sens, gdy oba Bounded Contexty naprawdę dzielą to samo pojęcie i definicje, koszt duplikacji i synchronizacji jest wyższy niż koszt współdzielenia, a zespoły po obu stronach wiedzą, że zmiany trzeba koordynować wspólnie.

Jako przykład weźmy aplikację biznesową z modułami: Identity i Audit. Moduł Identity odpowiada za użytkowników, role, uprawnienia i polityki dostępu – typową funkcjonalność wielu platform B2B. Moduł Audit prowadzi dziennik zdarzeń, rejestrując, kto i kiedy wykonał daną akcję, a także spełnia wymagania prawne, takie jak ISO czy SOC2.

W obu kontekstach UserId i TenantId będą wspólnymi pojęciami. Oznacza to, że reguły walidacji, semantyka i Value Objecty będą współdzielone – na przykład Value Object o nazwie Permission. W shared-kernelu (jeśli to modularny monolit) możemy umieścić następujące klasy:

shared-kernel/
    identity/
        TenantId
        UserId
    security/
        Permission
    time/
        Clock 

W powyższym kodzie widzimy, że wspólne części obu modeli będą kontrolowane przez oba zespoły. Każda zmiana w TenantId musi przejść review z obu stron, a żeby zapewnić kompatybilność po obu stronach relacji, trzeba napisać testy kontraktowe.

Shared Kernel jest zalecany tam, gdzie organizacja ma wysoki poziom dojrzałości, w tym wspólne code review, wspólne testy i jasny podział odpowiedzialności. Co więcej, zespoły muszą ściśle współpracować, mieć wspólne cele biznesowe i umieć uzgadniać zmiany w Shared Kernelu. Wyobraź sobie klasę Money. Jeśli zostanie zmieniona, zmiany najpewniej globalnie dotkną całej organizacji, więc wrażliwość na zmiany rozkłada się równo na wszystkie zespoły.

Trzeba jednak uważać, by nie przeładować Shared Kernela zbyt wieloma rzeczami. Powinien mieć ograniczoną odpowiedzialność, zredukowaną do minimum, a sprawy, które obejmuje, powinny być marginalne dla korzystających z niego Bounded Contextów. Idealnie Shared Kernel powinien być mały, wolno się zmieniać i zawierać Value Objecty, a nie złożone procesy czy encje. Dobrze też, jeśli nie ma zależności od infrastruktury – to znacząco upraszcza projektowanie i kodowanie. Gdy rozbieżność definicji jest groźniejsza niż sprzężenie, używamy Shared Kernela. W pozostałych przypadkach warto rozważyć inne rodzaje mapowań.

Published Language

Trzeba przyznać, że ta forma mapowania ma czasem wiele wspólnego z Open/Host Service. Mam na myśli przede wszystkim formę współpracy między zespołami. Jeden zespół udostępnia przestrzeń z dokumentacją, z której inne Bounded Contexty czerpią informacje o konwencjach nazewniczych, dokumentację interakcji i szczegóły procesów udostępnianych przez API. Spójrzmy na świetny przykład pokazujący różnicę.

OHS bez PL: Bank udostępnia API do przelewów. Endpoint /transfers przyjmuje JSON z polami sender_account_id, recipient_account_id, amount_in_cents i currency_code. To OHS – API jest otwarte i udokumentowane. Ale jeśli za 6 miesięcy bank zmieni amount_in_cents na amount_minor_units, wszyscy klienci będą musieli się dostosować. Każdy system downstream tłumaczy te dane na własny język domenowy.

OHS + PL: Ten sam bank, ale wdraża standard ISO 20022 dla płatności. Używa precyzyjnie zdefiniowanych typów, takich jak CreditorAccount, InstructedAmount i PaymentIdentification, ze schematu XML/JSON określonego przez międzynarodowy komitet. Teraz semantyka jest wspólna i stabilna. Gdy Visa, Mastercard i SWIFT używają tego samego ISO 20022, wszyscy mówią tym samym językiem. Zmiana wymagałaby ratyfikacji nowej wersji standardu przez komitet.

Podsumowując różnice:
Open Host Service działa na poziomie architektury integracji (JAK wystawiamy usługi: REST, gRPC, polityka dostępu), a Published Language na poziomie semantyki domeny (CO oznaczają dane: standaryzacja słownictwa, zarządzanie kontraktem). To nie są „wzorce stosowane razem”, tylko ortogonalne wymiary – możesz mieć otwarte API z własnym dialektem (OHS bez PL) albo zamknięty standard ISO 20022 tylko dla partnerów (PL bez OHS).

Spójrzmy na wizualizację:

Koncepcja jest więc bardzo prosta. Weźmy na przykład aplikacje używające OAuth2 do uwierzytelniania/autoryzacji użytkowników. Gdy logujesz się do aplikacji kontem Google, działa Published Language OAuth:

• access_token – token dostępu
• refresh_token – token odświeżania
• scope – zakres uprawnień

Ten język jest opublikowany jako standard i każdy rozumie go tak samo – czy to Facebook, Google, czy GitHub. Dzięki temu przy otwartym API możemy łączyć się bezpośrednio z wymienionymi usługami właśnie za sprawą tego języka, opublikowanego jako powszechnie znany standard.

Separate Ways

Ten format mapowania zakłada, że integracja między komponentami (BC) nie jest potrzebna, a w niektórych przypadkach wręcz niemożliwa. W takim scenariuszu na potrzeby danego kontekstu możemy swobodnie duplikować wszechobecny język, pisać własne rozwiązania, procesy i algorytmy, bo inny zespół nie ma wglądu w zmiany i założenia realizowane przez nasz projekt ani nie jest nimi zainteresowany.

Czasem łatwiej napisać własny pakiet/moduł, niż integrować się z wewnętrznym lub zewnętrznym komponentem biznesowym. Przykładem może być system ERP dla firmy produkcyjnej.

Kontekst 1: Planowanie produkcji

• Zarządza harmonogramem produkcji.
• Przydziela maszyny i operatorów.
• Śledzi postęp zleceń produkcyjnych.
• Ma własną definicję „Zlecenia” = zlecenie produkcyjne z datami i maszynami.

Kontekst 2: Kontrola jakości

• Ma własną definicję „Zlecenia” = partia produktów do kontroli.
• Przeprowadza kontrole produktów.
• Rejestruje wady i niezgodności.
• Generuje raporty jakości.

W tym przypadku zlecenie to coś zupełnie innego, a planowanie produkcji nie jest ściśle powiązane z kontrolą jakości. Powody takiego rozdzielenia mogą być różne: na przykład obecne rozwiązanie „działa, więc go nie ruszamy”, różne zespoły, różne systemy legacy (planowanie produkcji korzysta ze starego modułu SAP z 2005 roku, a kontrola jakości ma własny system kupiony od innego dostawcy w 2018 roku), różne modele danych albo różne rytmy pracy Bounded Contextów.

Załóżmy, że koszt napisania integracji to 200 000 zł. Powiedzmy, że to 7 miesięcy pracy jednego programisty na kontrakcie B2B – na podstawie średnich zarobków seniorów; zachęcam do lektury mojego poprzedniego artykułu o sytuacji na polskim rynku IT.

Pytanie, które warto zadać przy tego typu problemach, brzmi: czy warto integrować dwa serwisy, jeśli jedyną korzyścią będą na koniec ładne diagramy od architektów? Oczywiście to uproszczenie, ale w tym konkretnym przypadku nie ma sensu integrować czegoś, co w biznesie naturalnie działa zupełnie niezależnie. Mam nadzieję, że to w pewnym stopniu ilustruje przypadki użycia.

Big Ball of Mud (raczej antywzorzec)

Och, mógłbym o tym pisać godzinami. W mojej 10-letniej karierze to właśnie z tym typem mapowania spotykałem się najczęściej. Efekty modelowania Bounded Contextów w ten sposób są zwykle przeciętne, jeśli nie wprost fatalne. Prowadzi to do pomieszanych agregatów, nadmiernego sprzężenia, dużej ilości wiedzy ukrytej w głowach programistów i trudności z uzyskaniem testowalnego kodu.

To właściwie tylko uproszczony przegląd. Trzeba pamiętać, że większość aplikacji biznesowych czy B2B będzie miała podsystemy zbudowane w ten sposób. Bardzo często kod w tych podsystemach będzie kluczowy dla działania aplikacji. Aby rozwiązać problem związany z tym mapowaniem, trzeba w miarę możliwości rozbić dużą „kulę błota” na mniejsze, bardziej zrozumiałe Bounded Contexty. Czasem jedyną drogą jest tworzenie nowych Bounded Contextów dla nowych funkcjonalności i oddzielanie ich od „Big Ball of Mud” za pomocą omówionego wyżej ACL (Anti-Corruption Layer).

Myślę, że temat „Big Ball of Mud” omówię w osobnym artykule poświęconym systemom legacy i sposobom ich modernizacji. Zapraszam więc do śledzenia bloga – może się tu pojawić wiele ciekawych historii opartych na prawdziwych przykładach (oczywiście zanonimizowanych) z moich wcześniejszych projektów.

Nie wszystkie tematy zostały omówione

W źródłach wymienionych we wstępie można zauważyć pewną niejednoznaczność wokół Bounded Contextów i lekkie mieszanie tego pojęcia z typami relacji między zespołami. Żeby wprowadzić więcej struktury, stworzyłem własny diagram, który oddziela zależności Bounded Contextów od relacji między zespołami. Te pojęcia są ze sobą bardzo blisko związane, ale mam wrażenie, że w książkach i materiałach, które czytałem, to rozróżnienie nie zostało jasno przeprowadzone. To po prostu moja interpretacja dostępnej literatury. Spójrzmy na poniższy obraz:

Jak widać, w tym wpisie nie omówiłem dwóch wariantów:

• Customer-Supplier
• Partnership

Zrobiłem to celowo. W moim rozumieniu Context Mappingu relacje Customer-Supplier i Partnership dotyczą bardziej komunikacji między zespołami niż technicznych warunków, na jakich zespoły się łączą. Uważam, że ich nazwy mówią same za siebie i nie ma potrzeby wchodzić w szczegóły. Komunikacją między zespołami zajmę się w osobnym artykule, w którym uwzględnię powyższe punkty i dokładniej omówię czerwone bloki z diagramu.

Kolejnym elementem legendy jest strzałka opisująca narzut komunikacyjny między zespołami. Dość dokładnie oddaje ona, jak bardzo musisz koordynować działania z zespołem utrzymującym sąsiedni komponent biznesowy i ile spotkań/wiadomości będziesz musiał z nim wymienić. W niektórych przypadkach będzie to istotne kryterium, na przykład tam, gdzie komunikacja nie jest dobrze rozwinięta.

Gdy spojrzymy na moją wizualizację, widzimy, że zielony obszar jest zagnieżdżony w czerwonym. Opisuje to też pewną hierarchię w podziale zadań. Najpierw z wyższego poziomu patrzymy na komunikację między zespołami (albo – jeśli jeden zespół odpowiada za wiele zdolności biznesowych – na komunikację wewnątrz tego zespołu), a dopiero potem schodzimy na poziom mapowań. Tak to widzę i tak to sobie układam w głowie.

Podsumowanie

Mam nadzieję, że opisałem temat Context Mappingu w miarę przejrzyście. Z perspektywy strategicznego DDD to bardzo ważny element projektowania na poziomie systemu. Wiele źródeł, prezentacji i książek opisuje mapowanie kontekstów bardzo ogólnie. Próbowałem się od tego oderwać i pokazać przykłady aplikacji i systemów, z którymi stykamy się w codziennej pracy czy w życiu.

Trzeba jednak pamiętać, że na poziomie enterprise Context Mapping to nie tylko ćwiczenie techniczne, ale przede wszystkim potężne narzędzie polityczne. Każda linia na mapie – czy to Customer-Supplier, czy Conformist – odsłania faktyczny układ sił w organizacji i przepływ decyzji. Jako architekci musimy mieć świadomość, że wybór wzorca często wynika nie z elegancji kodu, lecz z hierarchii budżetowej albo gotowości zespołów do współpracy. Mapowanie kontekstów pozwala jawnie nazwać te napięcia, zamieniając architekturę z teoretycznego diagramu w realną strategię poruszania się po strukturze władzy w firmie.

Jeśli nie zgadzasz się z moimi argumentami, zauważysz niedoskonałości albo chcesz dalej podyskutować o temacie, śmiało komentuj. Najwięcej uczymy się przez wymianę myśli. Nic nie jest wyryte w kamieniu. Metodyki i koncepcje mogą się zmieniać – ważne, by nadążać za zmianami na rynku i dostosowywać definicje do otaczającego nas świata, nigdy odwrotnie!

Do następnego razu!

To trzecia i ostatnia część serii „Dlaczego Janek nie programuje?”. Po czterech latach wracamy do tematu, sprawdzamy, co zmieniło się z czasem, i przyglądamy się obecnej sytuacji tytułowego Janka. Spróbujemy przedstawić położenie osób na poziomie wejściowym i znaleźć dla nich dobre rady i wskazówki. Zapraszam do podsumowania serii i podzielenia się swoimi przemyśleniami.

Szybkie przypomnienie dwóch poprzednich części

W pierwszej części podeszliśmy do tematu tak:

Artykuł z 2022 r. analizuje, dlaczego w Polsce jest tak mało programistów (zaledwie 0,66% populacji, wobec 1,73% w Szwecji i 1,21% w USA), mimo że rynek szukał wtedy około 100 000 specjalistów rocznie i kusił świetnymi zarobkami. Obalam w nim mit, że programowanie wymaga szczególnego talentu – powołując się na badania pokazujące, że około 44% osób potrafi stworzyć model mentalny prostych instrukcji programistycznych nawet bez wcześniejszego doświadczenia.

Problem leży gdzie indziej: przede wszystkim w strachu przed nieznanym i przekonaniu, że programowanie jest niesamowicie trudne, co blokuje ludzi jeszcze przed pierwszą próbą nauki. Do tego dochodzi paradoks rynku pracy – 80–90% ofert jest dla specjalistów, a tylko 10% dla juniorów, więc nawet jeśli ktoś się uczy, trudno mu wejść do branży. Zapowiedziałem, że to dopiero początek analizy i że temat będzie kontynuowany.

W drugiej części biorę na celownik polskie uczelnie i pokazuję absurdy systemu: co roku na informatykę idzie 35 000 studentów, a kończy ją tylko 13 000, czyli 60% odpada. Ale uwaga – nie dlatego, że programowanie jest trudne, tylko dlatego, że studenci toną w algebrze, fizyce i innych przedmiotach ścisłych, których jest mnóstwo, a samo programowanie to tylko 20–30% czasu studiów. Z 25 przedmiotów na pierwszych dwóch latach tylko 5–6 to faktyczne programowanie.

Skrytykowałem to, że wykładowcy to w większości teoretycy bez doświadczenia komercyjnego, uczący na przestarzałym sprzęcie i oprogramowaniu sprzed 2010 roku. Dlatego bootcampy miażdżą uczelnie – choć są krótsze, ich programy rzeczywiście odpowiadają na potrzeby rynku. Jedyną zaletą studiów są praktyki, które faktycznie pomagają wejść na rynek. Doszedłem do wniosku, że system edukacji zupełnie rozmija się z IT, nie przygotowuje ludzi do prawdziwej pracy i marnuje potencjalnych programistów na niepotrzebnych przedmiotach.

Co się zmieniło?

Przede wszystkim sytuacja juniorów się pogorszyła. W moim artykule sprzed tygodnia, w którym analizuję obecną sytuację, wyraźnie widać trend spadkowy (tylko 5% ofert jest skierowanych do juniorów), czyli ofert dla juniorów jest dwa razy mniej – chore!

Szkoły programowania w dużej mierze podupadły. Obietnica wejścia do IT jest tak odległa, że nawet naganiacze i marketingowa magia nie przekonają magazyniera, że w trzy miesiące zostanie programistą. Pojawił się nowy trend: zamiast obietnic zostania programistą mamy obietnice zostania AI DEV-em, co mocno działa na wyobraźnię potencjalnych klientów. Mimo to kurczenie się rynku szkoleń dodatkowo pogłębiła AI. Podlinkowuję artykuł opisujący to zjawisko.

Rynek pracy jest teraz rynkiem pracodawcy, więc przede wszystkim:

• Junior ma niewiele do powiedzenia przy negocjacjach wynagrodzenia (jakby to miało znaczenie, skoro nawet samo zaproszenie na rozmowę graniczy z cudem).
• Pracodawca nie musi się już martwić, że mid ucieknie, bo konkurencja da mu +20% do pensji – nie ma presji na podwyżki, co widać też we wspomnianym artykule.

Nietrudno zgadnąć, że te zmiany są raczej negatywne dla osób, które chcą być w IT.

Co się nie zmieniło?

Sposób działania uczelni niewiele się zmienił. Sylabusy zostały lekko dostosowane pod AI i ML, ale ogólnie rzecz biorąc szkolnictwo wyższe w Polsce, szczególnie publiczne, nie jest skore do szybkich zwrotów i zmiany kierunku. Problem leży w kadrze, która zatrzymała się 10 lat temu. A świat nieubłaganie pędzi do przodu. Nawet mnie – osobie, która śledzi trendy i codziennie obserwuje rynek – trudno poznawczo ogarnąć niektóre aspekty. Nic dziwnego więc, że osoby nieznające rynku nie nadążają.

Uczelnie prywatne wychodzą naprzeciw tym oczekiwaniom, oferując programy bardziej dopasowane do potrzeb rynku. Ogólna sytuacja na polskim rynku pracy (wysoka płaca minimalna, spadek liczby gospodarstw z dwiema pracującymi osobami, rosnące koszty życia w ośrodkach, gdzie jest praca) jest pewną przeszkodą dla edukacji prywatnej. Niewielu weźmie kredyt na iluzję przyszłej pracy w Eldorado, jakim z perspektywy kuriera czy sprzedawcy jest IT. Osobiście uważam, że IT to jeden z najlepszych rynków do rozwoju finansowego. Bariera wejścia jest jednak tak wysoka, że osiągnięcie sukcesu wymaga trudnych decyzji i ogromnej determinacji.

Narzędzia AI a sytuacja juniorów

Bardzo gorący temat, czyli AI w IT, trzeba rozpatrywać z dwóch stron:

1. poddziedzina AI/ML na rynku pracy,
2. wsparcie AI w codziennej pracy (jak to nazywam: klienci AI).

AI/ML

Jeśli chodzi o AI/ML, wiele firm migruje swoje rozwiązania programistyczne na takie, które opierają się na modelach językowych, ogólnie na uczeniu maszynowym i przetwarzaniu danych. To wspiera naturalną ewolucję firm w kierunku organizacji napędzanych przez AI. Tak było też w mojej obecnej firmie. Cały zespół software'owy został zwolniony, a garstka ludzi miała odtworzyć pewne funkcjonalności z użyciem platformy danych i AI/ML. Ja osobiście zostałem w firmie, co opisałem w artykule.

Niestety dla juniorów nie ma tu dobrych wieści. Ich zestaw umiejętności i brak doświadczenia uniemożliwiają start w AI/ML czy nawet w branży danych. Tam wymagane jest solidne doświadczenie i umiejętność myślenia projektowego i systemowego, a nie tylko rozwiązywania pojedynczych drobnych problemów. Dlatego moim zdaniem programiście łatwiej jest zmienić kierunek rozwoju niż komuś, kogo na rynku nie ma i kto nie ma doświadczenia.

Klienci AI

Tu wieści są pokrzepiające. Nie trzeba już wszystkiego wiedzieć, żeby dobrze kodować. Asystenci programowania, tacy jak Codex, Claude Code, Antigravity i wreszcie Cursor (prawdopodobnie najbardziej przystępny zarówno cenowo, jak i w użyciu), znacząco ułatwiają:

• robienie zadań domowych w rekrutacji,
• naukę zagadnień punkt po punkcie,
• budowanie portfolio na GitHubie lub w innych miejscach,
• tworzenie działających aplikacji, które pozwalają na mikrobiznes,
• z perspektywy pracodawcy: Junior + AI == Mid za znacznie niższą stawkę (średnio -50% wynagrodzenia).

AI wzmocni mądrych, a osłabi głupich (sorry :()

Mam teorię, że AI ogłupia głupich i pomaga mądrym. Teraz możesz zrobić 100% różnicy, inwestując mniej niż 100% więcej. Z AI możesz przyspieszyć naukę, skrócić krzywą uczenia się i dostarczać biznesowi wartość za znacznie niższą stawkę. Z nietechnicznej perspektywy nie ma znaczenia, czy to junior, czy mid – liczy się wynik. Inteligentni i sprytni ludzie potrafią to wykorzystać na swoją korzyść.

Reszta jednak (nie chcę tu nikogo wskazywać; nie jestem tu, by oceniać innych; sam byłem młody i wiem, że sposób myślenia zmienia się z czasem – taka natura młodości) ma duży problem. Jeśli nie używasz AI, by zwiększyć swoje szanse na rynku, popełniasz ogromny błąd. Dziś nie da się dogonić konkurencji bez AI, bo zrobi to każdy, kto ma lepiej poukładane w głowie. Dotyczy to także osób, które chcą zmienić branżę.

Odpowiedź na tytułowe pytanie w 2026 roku

Sprawdźmy oficjalne dane i porównajmy liczbę programistów z 2022 rokiem. Najnowsze raporty pokazują wyraźny wzrost z 250 000 do (liczby się różnią) około 300 000–350 000 zawodowych programistów. Oznacza to wzrost o mniej więcej 30%. Dane te są nieprecyzyjne, bo IT to szerokie pojęcie, a programiści stanowią zwykle około 70% stanowisk – to bardzo zgrubne szacunki. Większość danych dotyczy szeroko rozumianego rynku IT, a nie konkretnie programistów.
Dane zebrałem z kilku źródeł:

https://forsal.pl/praca/wynagrodzenia/artykuly/9527794,mamy-juz-w-polsce-ponad-400-tys-specjalistow-it-ale-prostsze-zadania.html
https://stormit.pl/raport-o-programistach-2025/
https://www.otoprzetargi.pl/news/w-polsce-brakuje-ok-50-tys-specjalistow-it-a-w-ue-ponad-270-tys

Średnio odsetek programujących Polaków wzrósł, również dlatego, że przechodzimy kryzys demograficzny, a liczba obywateli z roku na rok spada. To podnosi odsetek. Mamy więc około 0,8–0,9% całej populacji. Wygląda na to, że postęp cyfryzacji i wymiana pokoleniowa na rynku pracy przybliżają nas do bardziej rozwiniętych gospodarek, takich jak Niemcy i Szwecja.

Janek jednak programuje! Ale ma problem z pracą

Skoro nasze podstawowe wskaźniki poprawiły się w porównaniu z 2022 rokiem, musimy odrzucić tezę, że Polacy nie programują zawodowo. To się zmieniło – rynek coraz bardziej się nasyca, a to powoduje problemy na poziomie wejściowym. Nie przezwyciężymy tego bez zmiany sposobu myślenia pracodawców.

Moim zdaniem powinniśmy doceniać jednostki i przyglądać się im uważniej, zamiast odsiewać je dlatego, że mają mniej niż X lat praktycznego doświadczenia. To bardzo trudna kwestia, bo ocena człowieka wymaga znajomości ludzi i pewnej wrażliwości – nosa do wykrywania potencjału. Firmy są gotowe płacić spore pieniądze firmom rekrutacyjnym za ściąganie specjalistów o wysokim potencjale. Ale jeśli chodzi o juniorów, rynek nie dojrzał jeszcze do zatrudniania ich na dużą skalę.

No tak, może to pomysł na biznes: stworzyć farmę juniorów, dać im wszystkie dostępne narzędzia AI i pomóc im aplikować na stanowiska od juniora do mida? Muszę to przemyśleć. W każdym razie.

Chcę tu przekazać, że moim zdaniem procesy rekrutacyjne nie powinny opierać się wyłącznie na doświadczeniu, ale też na indywidualnych predyspozycjach do adaptacji w danej branży. Rynek nie jest na to jeszcze gotowy, ale wierzę, że postęp technologiczny i pogarszające się warunki makroekonomiczne w Polsce zmuszą pracodawców do szukania rozwiązań. I tu wchodzą juniorzy, cali na biało, którzy za niskie stawki (także dzięki zerowemu PIT dla osób poniżej 26. roku życia i zapowiedziom rządu dotyczącym likwidacji swobodnych kontraktów B2B – preferencji podatkowych) mogą osiągnąć 90% wyników kogoś, kto zarabia o 50% więcej. Tak to widzę; nie wiem, czy ktoś się zgodzi. Ostatecznie każdy ma prawo do własnej perspektywy.

Ciekawi mnie, jak oceniasz sytuację na polskim rynku IT i jakie masz rozwiązania problemów, przed którymi stoją zarówno pracownicy, jak i pracodawcy. Moją perspektywę już znasz. Dzięki, że dotarłeś aż tutaj!

Ten artykuł był wcześniej opublikowany po polsku, ale postanowiłem wrzucić go ponownie, żeby dać ci potrzebne tło cztery lata później. Zapraszam też do lektury artykułu z 2026 roku, który wkrótce się ukaże.
W pierwszej części poznaliśmy liczby opisujące niedobór programistów na polskim rynku pracy IT. Dowiedzieliśmy się też, ilu aktywnych programistów pracuje obecnie w branży i jak wygląda sytuacja w innych krajach. Dziś rozwiniemy temat uczelni wyższych i ich wpływu na obecną sytuację.

To druga część serii – zapraszam do śledzenia jej w całości.

Jeśli czytasz część 2, a nie udało ci się przeczytać części 1, koniecznie zajrzyj tutaj: link do pierwszej części serii.

Szkolnictwo wyższe w liczbach

Według oficjalnych danych Głównego Urzędu Statystycznego (GUS) polskie uczelnie co roku kształcą około 13 000 absolwentów informatyki. Nie wszyscy z nich to przyszli programiści, ale można bezpiecznie założyć, że co najmniej połowa pójdzie w tym kierunku. Po ukończeniu kursów z programowania i baz danych oraz odbyciu praktyk (jeśli uczelnia je oferuje) absolwenci informatyki mogą szukać pierwszej pracy.

Wielu studentów potrafi programować już przed rozpoczęciem studiów. Musimy jednak odróżnić umiejętność pracy przy projektach komercyjnych od umiejętności programowania, które same w sobie nie gwarantują pracy ani założenia firmy i realizacji zleceń. Co więcej, w niektórych przypadkach firmy zatrudniające Junior Developerów wymagają dyplomu z informatyki.

Co jednak zaskakujące, co roku mamy co najmniej 35 000 kandydatów na kierunki informatyczne (źródło), (źródło 2), którzy wybierają ścieżkę akademicką. Co dzieje się z 60% studentów, którzy nie kończą studiów? Odpowiedź jest prosta: trafiają bezpośrednio na rynek pracy (niekoniecznie w IT) albo na inne kierunki i kontynuują naukę. Innej opcji nie ma, jeśli weźmiemy pod uwagę, że bezrobocie w Polsce wynosi zaledwie 5–6% (GUS).

Czy programowanie jest zbyt trudne?

Teza z pierwszej części zdaje się potwierdzać: programowanie, czy ogólnie informatyka, wydaje się zbyt trudne lub nieciekawe dla kandydatów do IT. Po pierwszym roku nauki większość z nich odchodzi z uczelni.

Nic bardziej mylnego – i właśnie tu leży problem. Gdy przejrzymy tzw. sylabusy uczelni, odkryjemy, że wśród około 25 przedmiotów na pierwszych dwóch latach studiów tylko 5–6 jest ściśle związanych z programowaniem.

Przytłoczeni algebrą czy fizyką studenci rezygnują lub zostają skreśleni z listy, nawet jeśli ich predyspozycje do nauki programowania są wystarczające. Potencjalnie obiecujący programiści nie są profilowani pod programowanie – zamiast tego zdobywają rozległą wiedzę z nauk ścisłych.

Z drugiej strony można powiedzieć, że sprawdza to zdolność studenta do nauki. Jeśli nauczy się różniczkowania, z pewnością będzie w stanie ogarnąć abstrakcję, która nieustannie pojawia się w programowaniu.

Ten kontrargument zostawiam do dyskusji. Czy naprawdę potrzebujemy aż tyle czasu poświęconego matematyce i fizyce? Osobiście uważam, że podstawy matematyki i fizyki byłyby w zupełności wystarczające. Tymczasem na pierwszych czterech semestrach miałem pięć przedmiotów z samej matematyki: dwa semestry analizy matematycznej, algebrę, statystykę i matematykę dyskretną. Czy pomogło mi to w nauce programowania? Nie jestem przekonany.

Szkoły programowania miażdżą publiczne uczelnie

Właśnie dlatego szkoły programowania rozwijają się tak dynamicznie. W nauczaniu programowania nie mają sobie równych w sektorze publicznym. Deklarują, że osiągają lepsze wyniki w krótszym czasie niż ich edukacyjna konkurencja. Rzeczywistą skuteczność bootcampów zostawiam do dyskusji – to temat na osobny artykuł. Skupiam się wyłącznie na ich założeniach. Szkolnictwo wyższe w Polsce nie jest przygotowane na ogromną potrzebę „produkcji” programistów.

Nie znalazłem w Polsce uczelni, która skupiałaby się bezpośrednio na programowaniu. Zazwyczaj programy mają charakter ogólny, z możliwością specjalizacji na ostatnich semestrach i napisania pracy inżynierskiej związanej z programowaniem.

Gdyby studia informatyczne obejmowały to, co dziś obejmują dobrze ułożone programy bootcampów, z pewnością znacznie więcej osób chciałoby je ukończyć.

Pofantazjujmy!

Wyobraź sobie kurs programowania wydłużony pięciokrotnie. I do tego darmowy. Ile projektów do portfolio moglibyśmy stworzyć w trakcie takiego kursu? Jak szeroko moglibyśmy omówić algorytmy i struktury danych? Ile narzędzi, takich jak Scrum, systemy kontroli wersji czy zagadnienia inżynierii oprogramowania, moglibyśmy poznać na tyle dogłębnie, by wejść z tym na rynek pracy?

Szkoły programowania też nie są idealne – obiecują klientom za dużo. Ich programy są jednak znacznie lepiej dopasowane do wymagań rynku IT. Mamy więc z jednej strony bootcampy i kursy zbyt krótkie, by odpowiednio zgłębić pewne tematy, a z drugiej programy przeładowane niepotrzebnymi zagadnieniami.

Osobiście, gdybym miał wybierać teraz, nadal poszedłbym na studia dzienne (albo zaoczne, gdyby było mnie na nie stać), ale programowania uczyłbym się sam i po czterech–pięciu semestrach szukałbym pracy. W efekcie pewnie musiałbym przejść na studia zaoczne. Taką radę daję maturzystom, którzy chcą zostać programistami.

Przestarzałe technologie tylko pogarszają sytuację

Szkolnictwo wyższe nie nadąża za wymaganiami technicznymi stawianymi kandydatom na rynku pracy. Nauka programowania na uczelniach często sprowadza się do poznania jednego języka niskopoziomowego i kilku języków obiektowych. W ciągu czterech lat około 20–30% przedmiotów dotyczy stricte programowania. To za mało. Co więcej, wersje oprogramowania używane w laboratoriach pochodzą sprzed 2010 roku.

Kadra akademicka to często teoretycy, którzy nie pracowali komercyjnie. W moim przypadku zajęcia z programowania prowadzili bardzo uprzejmi wykładowcy, ale niestety większość z nich skończyła studia kilkanaście lat wcześniej. Nie byli na bieżąco.

Gdyby uczelnie szukały trenerów programowania działających komercyjnie, studenci zdobywaliby wiedzę prosto z miejsca, do którego ostatecznie trafią. Same programy studiów lepiej reagowałyby też na rynek, który – jak wiemy – szybko się zmienia.

Jedyną zaletą, i to dużą, są praktyki, które większość uczelni oferuje studentom. W moim przypadku, jak u wielu innych kandydatów, praktyki okazały się kamieniem milowym, który wprowadził mnie na rynek pracy. Po zdobyciu pierwszej pracy z każdym rokiem coraz łatwiej było negocjować warunki i szukać nowych projektów i pracodawców.

Podsumowanie

W artykule bez ogródek krytykuję szkolnictwo wyższe. Nasza edukacja nie przygotowuje odpowiednio studentów do programowania i potrzeb rynku. Wielu studentów rezygnuje też ze studiów informatycznych z powodu trudności z przedmiotami ścisłymi. Problem pogłębia brak odpowiedniej kadry. Mimo to praktyki są niewątpliwie plusem, dla którego warto iść na studia techniczne. To jednak za mało.

Na szczęście programowanie od pewnego czasu jest ważnym filarem zajęć pozalekcyjnych w szkołach podstawowych. Miejmy nadzieję, że szkoły średnie o profilu programistycznym, które również powoli powstają, nadadzą tempo także uczelniom. W najbliższych latach zobaczymy popularyzację programowania, co powinno pozytywnie wpłynąć na rynek IT w Polsce.

Ten artykuł był wcześniej opublikowany po polsku, ale postanowiłem wrzucić go ponownie, żeby dać ci potrzebne tło cztery lata później. Zapraszam też do lektury artykułu z 2026 roku, który wkrótce się ukaże.

Programowanie uchodzi za szczególnie trudne. Ogłoszenia o pracę pokazują, jak wysoko rynek ceni umiejętności programistów. W porównaniu z innymi branżami, takimi jak handel, produkcja czy nawet marketing, programista może zarabiać znacznie więcej dzięki swojej wiedzy, umiejętnościom i doświadczeniu. Dlaczego więc tak niewielu ludziom udaje się zostać programistami? Dlaczego mimo wysokiego popytu tak mały odsetek naszego społeczeństwa decyduje się rozpocząć przygodę z programowaniem, a potem szukać pierwszej pracy w IT?

Dane podstawą analizy

Aby przeanalizować problem, najpierw przyjrzymy się prawdziwym liczbom. Na podstawie artykułu Karola Bednarza „Ilu jest programistów na świecie, a ilu w Europie?” [2022], opublikowanego pół roku temu (stosunkowo świeże dane), sprawdzimy, ilu programistów jest w poszczególnych krajach Europy.

Polska:

Liczba programistów: 250 000 
Liczba mieszkańców Polski (źródło: GUS): ok. 37,767 mln
Udział programistów w naszym społeczeństwie to zaledwie: 0,66%

Porównanie z innymi krajami Europy:
Niemcy: 901 000 programistów, kraj liczy 83,2 mln mieszkańców – 1,08%
Szwecja: 180 000 programistów, kraj liczy 10,42 mln mieszkańców – 1,73%
Ukraina: 212 500 programistów, kraj liczy 43,79 mln mieszkańców – 0,49%
Wielka Brytania: 408 000 programistów, kraj liczy 67,33 mln mieszkańców – 0,61%

Oraz USA:
4 000 000 programistów (4,3 mln w całej Ameryce Północnej) (https://www.bairesdev.com/blog/how-many-software-developers-in-the-world/), kraj liczy 331,9 mln mieszkańców – 1,21%

*dane dotyczące liczby mieszkańców pochodzą z Google.com według stanu na 13 lutego 2023 r.

Powyższe dane należy teraz zestawić z popytem na rynku pracy IT w Polsce:

Liczba poszukiwanych pracowników w pierwszym kwartale 2022 r. wyniosła: 26 121.

Artykuł na Prawo.pl świetnie opisuje te liczby z pierwszego kwartału 2022 r.

To tylko jeden kwartał. Jeśli pomnożymy to przez cztery, okaże się, że w 2022 r. rynek szukał rocznie około 100 000 programistów. Gdyby cały popyt został zaspokojony (a już wiemy, że nie został), mielibyśmy w Polsce około 350 000 programistów, co przybliża nas do pożądanego 1% populacji.

Aby potwierdzić tę liczbę, możemy zajrzeć też do Raportu Płacowego IT 2022 opublikowanego przez justjoin.it. Raport pokazuje, że liczba ofert pracy dla programistów przekroczyła 100 000. Źródło: https://raport.justjoin.it

W porównaniu z krajami rozwiniętymi (poza Wielką Brytanią) zostajemy w tyle pod względem odsetka programistów w całym społeczeństwie. Nie wynika to z małej liczby firm szukających programistów.

Problem leży głównie po stronie Kowalskiego, który nie zaczyna nauki programowania albo nie osiąga poziomu, który pozwoliłby mu z powodzeniem wejść na rynek IT.

Dodatkowo struktura zatrudnienia w IT charakteryzuje się tym, że 80–90% ofert pracy jest skierowanych do specjalistów, a nie do początkujących. Według danych, które co roku alarmują o niedoborze kadr w IT, firmy będą musiały zmienić taktykę rekrutacyjną i szkolić pracowników na poziomie wejściowym, a mówiąc dokładniej – zacząć zatrudniać więcej juniorów.

Dlaczego więc w tym kontekście nie jesteśmy w stanie dogonić innych krajów? Spróbujemy odpowiedzieć na to pytanie w dalszej części artykułu.

Programowanie od dawna uchodzi za trudne

Tekst Dana Bricklina z 2002 r. opisuje, jak programista konstruuje instrukcje dla komputera, jak potrafi poprawnie przewidzieć wyniki i jak może to wpływać na akceptację systemu.

Ten artykuł zainspirował mnie do napisania niniejszego, a jego przesłanie można streścić tak: niektórzy ludzie potrafią nauczyć się programowania szybciej. Są też tacy, dla których składnia języków jest zbyt trudna. Fragment artykułu:

„Języki programowania takie jak Assembler, FORTRAN, C i Java są najmniej powszechnie akceptowane. Ich składnia jest bardzo bezlitosna.”

Po kilku latach doświadczenia w branży jako programista twierdzę, że programowanie nie jest trudne. To rzemiosło, którego praktycznie każdy przy odpowiedniej motywacji może się nauczyć. Do bycia programistą przybliża nas też nie składnia, lecz sposób, w jaki myślimy i analizujemy konkretne problemy. Wnioski z powyższego artykułu są bezpodstawne.

Nie sądzę też, żeby problemem była tu motywacja. Wysokie zarobki, praca zdalna, liczne benefity, imprezy integracyjne, nowoczesny sprzęt i biura. Kto nie chciałby pracować w takich warunkach?

Czy niektórzy rodzą się, by programować?

Aby odpowiedzieć na to pytanie, posłużę się kolejną publikacją z 2006 r. autorstwa Jeffa Atwooda, współzałożyciela Stack Overflow: „Separating Programming Sheep from Non-Programming Goats”.

Ten artykuł odwołuje się do badania (link do badania), które w gruncie rzeczy miało odpowiedzieć na pytanie: czym różnią się ludzie, którzy programują, od tych, którzy tego nie robią? W dosłownym tłumaczeniu:

„sposób na oddzielenie programujących owiec od nieprogramujących kóz na zajęciach z informatyki”

Wyniki badania są bardzo ciekawe. Na podstawie podstawowych instrukcji programistycznych, takich jak przypisanie, iteracja, rekurencja i instrukcja warunkowa, zebrano odpowiedzi od osób, które nigdy wcześniej nie miały styczności z programowaniem. Byli to studenci informatyki – niewielka grupa w populacji, w dużej mierze skupiona na programowaniu.

Test użyty w badaniu można pobrać tutaj.

W zakresie podstawowych instrukcji, z którymi zetkniemy się podczas nauki, wyniki pokazały, że:

1. 44% studentów stworzyło spójny model mentalny działania zadania (nawet jeśli był błędny!).
2. 39% studentów nigdy nie stworzyło spójnego modelu mentalnego działania zadania.
3. 8% studentów zignorowało zadanie i zostawiło puste odpowiedzi.

Wniosek przedstawiony w badaniu:

„Aby napisać program komputerowy, trzeba się z tym pogodzić, zaakceptować, że cokolwiek chcesz, by program zrobił, maszyna ślepo będzie podążać za własnymi bezsensownymi regułami i dojdzie do jakiegoś bezsensownego wniosku”

Badanie pokazało też, że mniej więcej połowa uczestniczących w nim studentów nie zdałaby testu wstępnego skonstruowanego według powyższych zasad. Czy ten wysoki próg wejścia jest odpowiedzią na tytułowe pytanie?

Postawię kolejną tezę: nauka programowania wydaje się obca i trudna przeciętnej osobie, która nie miała wcześniej styczności z kodowaniem. To główny powód, dla którego nie podejmuje się nawet najmniejszej próby. Jak to jednak możliwe, że nawet studenci z mniejszymi „predyspozycjami” kończą studia informatyczne i stają się specjalistami, którzy łatwo znajdują pracę i rozwijają karierę? Wszystko zależy od:

• ilości pracy, jaką trzeba włożyć w naukę programowania,
• braku obaw przed wysokim progiem wejścia – ten argument mógł być zasadny 50 lat temu, gdy programowało się na kartach perforowanych i dyskietkach. Dziś każdy, kto umie obsługiwać komputer, może w mniejszym lub większym stopniu nauczyć się programowania,
• innych czynników, które omówimy w kolejnych artykułach z serii „Dlaczego Janek nie programuje?”.

Jeden artykuł to za mało na pełne wnioski

W tym artykule poznaliśmy wyzwania, przed którymi stają początkujący programiści, oraz zastanowiliśmy się, czy do szybkiej nauki programowania – albo nauki w ogóle – potrzebne są szczególne zdolności. W dużej mierze wynika to z lęku przed nieznaną naturą programowania, który jest wspólny dla zdecydowanej większości społeczeństwa (ponad 95%).

Rynek IT powinien skupić się na szkoleniu i zatrudnianiu juniorów, wbrew obecnemu trendowi, w którym oferty dla juniorów stanowią zaledwie 10% (!!!) wszystkich ofert.

Problem jest bardzo szeroki, a jego analiza fascynująca. Jeden artykuł zdecydowanie nie wystarczy, by zgłębić temat, dlatego zapraszam do lektury kolejnej części serii, która ukaże się na it-leaders.pl w najbliższych tygodniach.

Żeby niczego nie przegapić, polecam zapisać się do newslettera – dostaniesz powiadomienie e-mailem o nowych publikacjach, które mogą cię zainteresować.

W dzisiejszym świecie wiele firm zmaga się z problemem analizy danych. To dane są kluczowym elementem podczas podesjmowaina biznesowych decyzji (a przynajmniej powinny). Aby efektywnie te dane przedstawić, musimy je najpierw odpowiednio zamodelować. W dzisiejszym poście spróbujemy "zareklamować" rozwiązanie które w moim zespole ułatwia nam codzienną prace z danymi. Zapraszam do przeglądu artykułu i dzieleniu się wnioskami w komentarzach.

Pozyskiwanie danych

Na potrzeby dzisiejszego wpisu, założymy, że dane mogą spływać do s3 (magazyn danych od AWS) z wielu różnych źródeł w wielu różnych formatach. Spójrzmy na grafikę poniżej aby mniej więcej zrozumieć jak to działa od strony pozyskania danych.

Komunikacja S3 -> Snowflake

To jest dość ważna część całego ekosystemu. To ten element automatyzuje i zdejmuje z ciebie odpowiedzialność za płynny przepływ danych z S3 do Snowflake. Wejdźmy trochę głębiej w ten element i najlepszy sposób konfiguracji. Z racji tego, że Snowflake leży na infrastrukturze AWS, konfiguracja i komunikacja pomiędzy serwisami jest ułatwiona. Snowflake wspiera to w bardzo sprytny sposób. Poniżej pokażę diagram przepływu który fajnie to prezentuje. To wyjaśni wam całą magię stojącą za tym setupem, który osobiście bardzo lubię i stosuję w projektach domowych jak i komercyjnych.

Krótki komentarz do powyższego diagramu. Zaczynamy od momentu kiedy plik ląduje fizycznie w naszym systemie plików. W s3 mamy opcję wysyłania do kolejki SQS wiadomości kiedy wystąpi dany event: plik dodany, plik usunięty, plik zmodyfikowany etc. To pozwala nam stworzyć podstawy systemu reaktywnego.

Kolejny krok to transpozycja wiadomości w kolejce SQS na notyfikację w SNS. Amazon SNS (Simple Notification Service) to usługa chmurowa AWS, która umożliwia wysyłanie powiadomień z aplikacji do wielu odbiorców jednocześnie. Działa na zasadzie publikowania wiadomości do "tematów" (topics), a następnie dostarczania ich do wielu subskrybentów. SNS może wysyłać powiadomienia przez różne kanały, takie jak: funkcje Lambda, SMS-y, E-maile, Powiadomienia push do aplikacji mobilnych, Zapytania HTTP/HTTPS, Kolejki SQS.

Snowpipe jako złote rozwiązanie

Dzięki istnieniu Snowpipes możemy zdefiniować sobie czego nasłuchujemy i co robimy z tą informacją. Nie lubię mówić bez przykładu więc zerknijmy na kod od razu:

CREATE OR REPLACE PIPE pipe_data_source_data_provider_domain_table
AUTO_INGEST = TRUE
AWS_SNS_TOPIC = 'arn:aws:sns:us-east-1:2472837483:name_of_the_sns_service'
AS
COPY INTO data_source_data_provider_domain_table (
data,
filename,
file_row_number,
file_last_modified
)
FROM (
SELECT
$1,
METADATA$FILENAME,
METADATA$FILE_ROW_NUMBER,
METADATA$FILE_LAST_MODIFIED
FROM @your_bucket/provider/prod/
)
FILE_FORMAT = (type = 'PARQUET')
PATTERN = '*_domain_.*/.*table/.*';

Kod jest dosyć prosty. To definicja PIPE, która ma kilka kluczowych elementów.

• Name - nazwa Snowpipe, która powinna definiować poprzez konwencję skąd bierzemy dane i dokąd one zmierzaja.
• SNS Topic - adres topica, który nasłuchujemy - ważne: musimy mieć uprawnienia nadane na jednostkę Snowflake - robimy to w konfiguracji roli w SNS. Nie będę tego pokazywał w tym wpisie gdyż jest to rzecz standardowa i można znaleźć wiele przykładów w internecie, dokumentacja Snowflake również dobrze to opisuje.
• COPY statement - część definicji, która mówi co kopiujemy, w jakiej postaci i skąd, to tez ma swoje subelementy:
  • INTO - do której tabeli lądują dane
  • FROM - jaki path mamy nasłuchiwać (filtrowanie wiadomości SNS) - staraj się zawężać FROM jak najbardziej możesz, zaoszczędzisz na skanowaniu s3 przez Snowpipe
  • FILE FORMAT - jakiego rodzaju plików poszukujemy podczas nasłuchu
  • PATTERN - pattern ścieżki pliku jakiego oczekujemy

Wszystkie te elementy tworzą żyjący byt, którego istnienie możemy sprawdzić i sprawdzić również historię za pomocą kwerend:

DESCRIBE PIPE XXX 

oraz

SELECT * FROM TABLE(INFORMATION_SCHEMA.PIPE_USAGE_HISTORY( PIPE_NAME => 'MY_PIPE' ));

Jest wiele sposobów aby monitorować działanie i status Snowpipes, natomiast na to poświęcimy osobny wpis. Zamysł myślę, że jest jasny i możemy przechodzić dalej.

Wiersz w tabeli

Efektem powyższych działań jest powstanie wierszy w tabeli docelowej, którą nazywamy RAW.name_of_the_table. To będzie najniższa warstwa w naszej instancji Snowflake. Będzie podstawą, z której będą czytać nasze tabele na poziomie DBT (lub innego narzędzia do analizy danych).

W momencie insercji wiersza do tabeli RAW możemy zgodnie z harmonogramem lub przez trigger uruchamiać Github Actions, które w naszym procesie ELT wykonuje krok transformacji. To, w jaki sposób zamodelować dane wysokopoziomo opisuje poniższy schemat:

Szybkie wyjaśnienie. Nie musimy wcale używać metodologii jaką podałem: stg->int->mart. To kwestia konwencji i jest wiele rozwiązań typu medialion czy bronze->silver->gold. Można w nich przebierać. Tak nisko dziś nie będziemy schodzić ale pokazaliśmy prosty przykład w jaki sposób można te dane zamodelować.

Dane są zamodelowane

Kiedy już dane są zdatne do odczytu, możemy swobodnie przejśc do ich odczytu na wyższym poziomie. W naszym rozwiązaniu używamy PowerBi, jednakże do raportowania możesz użyć innych narzędzi takich jak: Tableau, Looker, Qlik Sense, Metabase, Apache Superset, Sisense, Domo. Na rynku jest obecnie mnóstwo narzędzi tego typu. Kwestia potrzeb twojej organizacji i jej możliwości.

Dla lepszego bezpieczeństwa dostęp powinien być tunelowany, najlepiej jest skonfigurować to w taki sposób aby pomiędzy instancja PowerBI a Snowflake było coś pośredniczącego, co kontroluje ruch danych pomiędzy platformami. To ważne i można to rozwiązać na wiele sposobów. Aby zastosować IP whitelisting na przykład, można skonfigurować API Gateway, który będzie naszym strażnikiem.

I oczywiście lekko utrudnia to pracę przy tworzeniu raportów, bo zespół musi być na to przygotowany i ich lokalne komputery muszą być ustawione w taki sposób aby łączyć się poprzez VPN oraz trzeba pilnować dostępu poprzez login/password (wygaszane) lub SSO. To sprawia zawsze problemy w utrzymaniu ale w nagrodę mamy bardzo bezpieczny i hermetyczny system. Więcej detali opiszę w innym artykule. Dziś podejmujemy temat z bardzo wysokiego poziomu i nie chcę napisać tutaj księgi z zakresu security. To zresztą nie jest do końca moja specjalizacja więc muszę się doedukować.

Wreszcie raporty

Na końcu tej ścieżki mamy zawsze warstwę, która prezentuje dane. To najprzyjemniejsza część dla biznesu, ponieważ z ich perspektywy nasz system to PowerBI. Nie muszą I NIE POWINNI być uświadamiani o detalach technicznych. To nasz problem i odpowiedzialność jako zespół techniczny aby te szczegóły implementacyjne przed nimi ukrywać.

Dla biznesu możemy stworzyć system raportów, analiz, aplikacji, która pomogą im w robieniu codziennych działań operacyjnych i podejmowaniu decyzji. To jest naszym celem, nie stworzyć technicznego potworka ale dawać wartośc biznesowi. Jeśli stakeholderzy korzystają z naszych rozwiązań powinniśmy być zadowoleni. Jeśli nie to czeka nasz długa droga rozwiązania tego problemu. O tym też się kiedyś rozpiszę bo to jest temat rzeka.

Podsumowanie

Jeśli dobrnąłeś do końca to świetnie. Na dziś to wszystko. Mam nadzieję, że powyższy schemat trochę rozjaśnił Ci cel i środki jakie chcemy podjąć. Jakie problemy konkretnie rozwiązujemy i dlaczego jest to rozwiązanie bardzo atrakcyjne i nie wymagające dużych nakładów. W obecnym projekcie stworzyliśmy w 3 osoby platformę danych złożoną z ponad 600 tabel i prawie 100 raportów. To zdumiewające, że potrzbowaliśmy do tego zaledwie kilka miesięcy. Pracy było co nie miara ale satysfakcja z wykonanej roboty była ogromna. Polecam Ci zapoznanie się z detalami i oczekujcie kolejnych artykułów powiązanych z poszczególnymi elementami powyższego rozwiązania. Ten artykuł to tylko wstęp. Zapraszam do kolejnych!

Koniec roku to często czas podsumowań i wniosków. Ponieważ różne firmy publikują teraz raporty o sytuacji na rynku IT w 2025 roku, postanowiłem przyjrzeć się jednemu z nich. Jako że sam szukam obecnie nowych wyzwań i próbuję znaleźć swoje miejsce na rynku, uznałem to za wartościową treść – zarówno do publikacji, jak i do własnej lektury. Zapraszam do czytania.

Źródło danych

Jako źródło wykorzystamy raport największego polskiego portalu z ogłoszeniami o pracę w IT.

Justjoin.it publikuje obecnie 15 110 ofert pracy (14 stycznia 2026 r.). To czyni go liderem nie tylko w Polsce, ale i w Europie pod względem liczby ogłoszeń. Na tej podstawie zakładam, że wyniki publikowanego przez nich raportu opierają się na wystarczająco dużej próbie i przedstawiają wiarygodny, uśredniony obraz rynku pracy na dziś.

Raport znajdziesz na ich stronie pod adresem:
https://justjoin.it/salary-report/

Raport podzielony jest na kilka sekcji: statystyki ofert pracy, wynagrodzenia według kategorii, warunki pracy w branży technologicznej oraz statystyki wynagrodzeń. Przejrzałem kolejno każdą z nich i podzielę się z tobą swoimi przemyśleniami.

Statystyki ofert pracy

Liczba ogłoszeń w podziale na miesiące jest dość wymowna. Widać wyraźne różnice między miesiącami i pewną sezonowość.

Znalezienie pracy jest zdecydowanie najtrudniejsze w okresie letnim i wakacyjnym. Po pierwsze dlatego, że ofert jest mniej, a po drugie dlatego, że rekruterzy i zespoły są ogólnie mniej aktywni.

Jeśli chodzi o technologie, wyraźnymi liderami są: Data, JS i Java.

Wcale mnie to nie dziwi. Te technologie i kategorie od lat są najbardziej poszukiwane. Dane pokazują wyraźny trend wzrostowy. W dużej mierze wynika to z rozwoju LLM-ów (dużych modeli językowych). Firmy muszą przetwarzać czyste, ustrukturyzowane dane i chcą analizować je z pomocą AI. Dlatego liczba ofert dla Data Engineerów i Data Analystów wciąż rośnie.

Wciąż trochę zaskakuje mnie duża liczba ofert dla JavaScriptu. LLM-y całkiem sprawnie kodują warstwę frontendową, być może dzięki Node.js, którego ekosystem ostatnio mocno się rozwinął. Z mojej perspektywy Claude Code czy Cursor potrafią pisać kod JavaScript na znacznie lepszym poziomie niż ja, rodowity backendowiec, korzystający z przykładów z internetu i dokumentacji. Trzeba by zapytać frontendowców, jak udaje im się unikać zwolnień i jak pokazują swoją wartość dla firmy. Może są tu aspekty, które dałoby się przenieść na inne obszary wytwarzania oprogramowania!

Nikt nie potrzebuje juniorów

To smutne i trudne dla ludzi, którzy wiążą z pracą w IT nadzieję na lepsze życie. Pisałem kiedyś artykuł o wejściu na rynek i o tym, że próg wejścia do IT jest coraz wyższy. Widzę, że nic się nie zmieniło – liczba ofert dla początkujących (juniorów) wciąż oscyluje wokół 5%.

Moje zdanie w tej kwestii jest dość kontrowersyjne. Z punktu widzenia pracodawcy myślę, że dziś zatrudniałbym więcej juniorów. Dzięki AI proces nauki jest teraz znacznie szybszy. Jeśli chcemy inwestować w zasoby ludzkie, zatrudnienie kilku juniorów (np. 3) i jednego seniora jest w dłuższej perspektywie bardziej opłacalne niż zatrudnienie dwóch seniorów. Choć koszt finansowy może być podobny, senior może wkrótce odejść, a juniora mamy większą szansę zatrzymać na dłużej. Zwłaszcza że rynek powoli staje się rynkiem pracodawcy, ryzyko szybkiego odejścia juniora jest mniejsze. Zastanawiam się tylko, kiedy pracodawcy to zrozumieją. Rynek szuka natychmiastowego zwrotu, który daje zatrudnianie midów i seniorów – nie trzeba ich szkolić. Moim zdaniem to jednak błąd.

Praca zdalna

Wiele firm oferuje teraz pracę hybrydową zamiast w pełni zdalnej, z możliwością lub obowiązkiem spotykania się z zespołem twarzą w twarz co najmniej raz w tygodniu. Jako entuzjasta pracy zdalnej i trochę domator zdecydowanie nie lubię tej zmiany! A tak na poważnie – praca hybrydowa to moim zdaniem złoty środek. Zwłaszcza gdy spotkania w biurze planujemy na konkretny dzień. Wiele problemów da się lepiej rozwiązać w konkretnym otoczeniu. Moim zdaniem ten trend utrzyma się w najbliższych latach.

Wykres pokazujący stosunek pracy zdalnej, hybrydowej i stacjonarnej. Czy widać już powrót do biur?

Rodzaje umów

Rynek kontraktów B2B jest dość znaczący. Wynika to z dużych ulg podatkowych dla jednoosobowych działalności gospodarczych w Polsce. Efektywne obciążenie spada z około 60% dla pracowników na standardowej umowie o pracę (najwyższy próg podatkowy dotyczy już zarabiających na poziomie mida) do około 25% dla samozatrudnionych. To spora ulga dla domowych budżetów.

Firmy z kolei korzystają na tym, bo łatwiej im zarządzać zasobami ludzkimi i nie są tak obciążone przepisami wynikającymi z prawa pracy, praw pracowniczych, układów zbiorowych itp.

Wynagrodzenia

Pełny zakres technologii i specjalizacji znajdziesz tutaj: https://justjoin.it/salary-report/category-statistics. Przedstawię tylko najciekawsze aspekty i swoją opinię.

BOTTOM 3 – PRZEGRANI (spadek lub najmniejszy wzrost):

1. Support – -4,93% (UoP)
   • Największy spadek w branży.
   • Średnio: 11 250 zł (umowa o pracę), wcześniej 11 833 zł
   • Najniższe wynagrodzenia w IT
2. Net (.NET) – -1,61% (B2B)
   • Spadek na kontraktach B2B
   • Średnio: 17 140 zł (B2B), wcześniej 17 420 zł
3. C – -1,91% (B2B)
   • Niewielki spadek
   • Średnio: 17 530 zł (B2B), wcześniej 17 871 zł

TOP 3 – ZWYCIĘZCY (największy wzrost):

1. Scala – +58,83% (umowa o pracę)
   • Największy wzrost w całej branży IT.
   • Średnio: 22 025 zł (umowa o pracę), wcześniej 13 867 zł
2. Go (Golang) – +35,67% (umowa o pracę)
   • Drugi największy wzrost
   • Średnio: 22 250 zł (umowa o pracę), wcześniej 16 400 zł
   • Najwyższe średnie wynagrodzenie w branży!
3. ERP – +14,88% (B2B)
   • Największy wzrost na kontraktach B2B.
   • Średnio: 20 927 zł (B2B), wcześniej 18 217 zł

Przegrani

Jak widać powyżej, zdecydowanie najmniej zadowoleni są programiści .NET pracujący na B2B. Osoby na tradycyjnych umowach o pracę dostały niewielki wzrost o 3,13%, co też nie napawa optymizmem. Czy sektor .NET ma już w pełni nasycony rynek? Sektor Support odnotował takie same, a nawet gorsze wyniki, co czyni go najsłabiej opłacanym sektorem w IT. Dodatkowo z powodu automatyzacji i wdrażania AI w wielu procesach firmowych widzimy zarówno spadek liczby ofert, jak i niższe wynagrodzenia (ze względu na niski próg wejścia do IT Support w porównaniu z innymi sektorami). Mimo to zarobki są tam wciąż całkiem przyzwoite.

Udział Supportu w ogłoszeniach spadł z 3,1% do około 2,4%. Widać tu silną korelację.

Zwycięzcy

Wśród języków, które notują wzrost, wyróżniają się Scala i Go, a w mniejszym stopniu ERP. Wzrost wynagrodzeń dla tych „nowszych” i przypuszczalnie mniej dojrzałych języków programowania jest zdumiewający. Rynek nie zdążył jeszcze właściwie wycenić umiejętności tych programistów, a może popyt jest tak wysoki, że zaburza i mocno wpływa na wycenę usług (pilność, potrzeba szybkiego wdrożenia).

Trzeba dodać, że Scala to zaledwie 0,4% wszystkich ogłoszeń, więc wolumen może też nieco wpływać na dynamikę wzrostu płac.

Gdzie można zarobić najwięcej?

Jeśli chodzi o najwyższe wynagrodzenia odnotowane na justjoin.it, szczególnie ciekawy jest przypadek co najmniej jednej oferty: 99 490 zł – WOW, 100 tys. miesięcznie – to by było coś! Chyba nie muszę wspominać, że zapotrzebowanie na specjalistów od modeli sieci neuronowych i AI stale rośnie, a tak niewiarygodnie wysokie stawki są tego moim zdaniem najlepszym dowodem.

Ogólnie najlepsze średnie wynagrodzenia mamy w następujących obszarach:

TOP 3 – najwyższe średnie zarobki (na kontraktach B2B):

Security – 20 465 zł

Scala – 21 487 zł

ERP – 20 927 zł

Widzimy, że 2 z 3 najlepiej płatnych kategorii to te same, które pokazują trend wzrostowy rok do roku. Trochę dziwi mnie brak specjalizacji związanych z AI/ML w tym rankingu. Być może jest jeszcze za wcześnie. Bardzo jestem ciekaw, jak zmienią się średnie wynagrodzenia w sektorze AI w moim zdaniem kluczowym roku 2026.

Podsumowanie

Rok 2026 z pewnością będzie rokiem zmian. Rewolucja AI powoli daje o sobie znać na rynku pracy. Narzędzia do kodowania stają się dojrzalsze i bardziej niezawodne. Z mojej perspektywy (bańka PHP) rynek się profesjonalizuje; rozmowy rekrutacyjne wymagają więcej niż kiedyś, a na każde stanowisko jest znacznie więcej chętnych. Jakość tych kandydatów to osobna kwestia, ale niestety nie mam na nią wpływu, bo sam nikogo nie zatrudniam (i nie zamierzam w najbliższym czasie).

Poza moim najbliższym otoczeniem trudno jednoznacznie ocenić sytuację. Rynek z pewnością się stabilizuje, a dynamika i wzrosty nie są już tak silne jak w latach 2015–2022. Patrząc na twarde dane, rynek powoli stabilizuje się od trzech lat. Po więcej informacji zachęcam do lektury pełnego raportu. Ponownie podaję link: https://justjoin.it/salary-report/.

Ciekawi mnie też twoja opinia o tym raporcie: czy odzwierciedla to, co widzisz w swoim otoczeniu? A odpowiadając na tytułowe pytanie: nie, Eldorado jeszcze się nie skończyło, ale mam przeczucie, że zmiany technologiczne mogą nadać mu nowego rozpędu. Wtedy naprawdę może pójść w dwóch kierunkach: albo rynek będzie potrzebował więcej rąk do pracy, by zaspokoić popyt na oprogramowanie, albo część rynku zostanie wchłonięta przez narzędzia AI. Wszystko jest w rękach właścicieli technologii związanych z LLM-ami i właścicieli kapitału – to w końcu oni każdego dnia decydują, czy Damian z Gdańska albo Janek z Gliwic będą mieli co robić.

Mam nadzieję, że nowe możliwości technologiczne pozwolą nam tworzyć szybciej i lepiej. Możliwe jednak, że klienci (konsumenci indywidualni) będą w stanie rozwiązać wiele problemów bez potrzeby angażowania programisty. W takim przypadku najlepiej mieć plan B. A czy ja mam plan B? Oczywiście, że tak. Swoje szanse widzę w obszarach danych i architektury. Pewnie tam przeniesie się marża znikająca z rynku programowania, jeśli takie zjawisko wystąpi.

Z drugiej strony polecam każdemu poznawać narzędzia AI i starać się nadążać za rynkiem. Umiejętność uczenia się i otwarty umysł zawsze dadzą nam przewagę na rynku. Jeśli w dżungli przetrwają tylko najsilniejsi, to tą siłą w najbliższych latach z pewnością będzie umiejętność pracy z pomocą AI.

Życzę wszystkim czytelnikom powodzenia na tej drodze i zawodowego spełnienia, niezależnie od technologii czy sektora. W końcu to tylko praca – ważne, by przede wszystkim dało się z niej utrzymać, a po drugie, by choć trochę cieszyło nas to, co robimy. Jedyną pewną rzeczą jest zmiana – i z tą myślą chciałbym cię zostawić.

Dzięki!

Dziś poruszymy temat, który od jakiegoś czasu wisiał na mojej liście. Ostatnio obejrzałem sporo materiałów o modelowaniu domeny w DDD. Niestety wiele z nich omawia trywialne albo dobrze znane zagadnienia. Poniżej opiszę problem, z którym na pewno się wcześniej nie spotkałeś (ja też nie). Spróbujemy go rozłożyć na części – najpierw na wysokim poziomie, a potem budując głęboki model domenowy. Dołącz do mnie!

Opis problemu (w skrócie)

• System rozlicza wspólne wydatki ponoszone w ramach jednej lokalizacji (mieszkania, biura, nieruchomości).
• Rozliczenia są wyliczane w zdefiniowanych okresach rozliczeniowych, zwykle miesięcznych.
• Każdy okres może mieć zmienną liczbę uczestników.
• Uczestnik może dołączyć lub odejść w trakcie okresu rozliczeniowego.
• Odpowiedzialność za koszty zależy od faktycznego czasu uczestnictwa, chyba że dany koszt definiuje inną regułę.
• Każdy koszt ma kwotę pieniężną, datę, kategorię i powiązaną regułę podziału.
• Koszty mogą być cykliczne, zależne od zużycia albo jednorazowe.
• Koszt może dotyczyć:
  • wszystkich uczestników,
  • wybranej podgrupy,
  • uczestników z jawnymi wyłączeniami lub limitami.
• System obsługuje wiele reguł podziału kosztów, m.in.:
  • podział równy,
  • podział proporcjonalny według zdefiniowanych wag,
  • podział czasowy (proporcjonalny do okresu),
  • podział według zużycia,
  • kombinacje wielu reguł.
• Reguły podziału mogą zmieniać się w czasie.
• Podział kosztów może generować różnice z zaokrągleń, które trzeba obsłużyć zgodnie z określoną polityką.
• Koszty mogą być dodawane po zakończeniu okresu rozliczeniowego.
• Korekty kosztów wpływają na przyszłe rozliczenia zgodnie z ustalonymi regułami korekt.
• Okres rozliczeniowy może zostać zamknięty – wtedy wyniki uznaje się za ostateczne.
• Dla każdego uczestnika system wylicza:
  • kwotę do zapłaty albo
  • nadpłatę.
• Wyniki rozliczenia muszą być przejrzyste i możliwe do prześledzenia – kwotę każdego uczestnika trzeba umieć wyjaśnić aż do pojedynczych pozycji kosztowych.

Definiowanie elementów modelu

Żeby zacząć projektować model, narysujmy jego elementy. Model będzie składał się przede wszystkim z rozliczeń (Settlements). W naszym systemie to synonim słowa „zobowiązania”. Mamy też użytkowników zasobu – w naszym języku kontekstowym będzie to „uczestnik” (participant).

To podstawowe rozpoznanie elementów. Zauważ, że nie ma tu jeszcze relacji ani pól, bo to nie jest ERD (diagram związków encji). Zwizualizujmy problem. Pokażmy go z innej perspektywy – czasowej:

Ten wykres lepiej pokazuje przebieg w czasie. Nasz przedział czasu to „Okres X”. W tym okresie uczestnicy (A, B, C) ponoszą koszty. Możemy roboczo założyć, że to osoby wynajmujące miejsca w przestrzeni open space. Myślę, że to całkiem dobry przypadek użycia, który pomoże nam zwizualizować problem.

Nasze oprogramowanie ma więc zarządzać najmem danego zasobu między uczestnikami (najemcami). Jak widać, początek i koniec zobowiązania każdego uczestnika są ustalane indywidualnie (są okresy, w których ktoś nie ponosi kosztów, ale są też okresy ciągłego najmu). Wyobraźmy sobie, że jedna osoba przychodzi do biura 20 dni na 20 dni roboczych, inna z przerwami itd.

Event storming – jedna z technik poznawania problemu

Spróbujmy rozłożyć to na karteczki. Alberto Brandolini, twórca ES, wymyślił sposób na eksplorowanie problemów podczas projektowania oprogramowania. Więcej szczegółów znajdziesz tutaj. Nie jestem ekspertem od tej techniki, ale znam podstawowe pojęcia i spróbuję przygotować tablicę ES na poziomie eksploracji problemu (Big Picture).

Tak wyglądałaby lista zdarzeń domenowych. Możemy:

• otworzyć okres,
• dodać koszt,
• uczestnik może dołączyć,
• uczestnik może odejść,
• okres może się zakończyć,
• okres może zostać rozliczony (zamknięty),
• zobowiązania mogą zostać przeliczone,
• do uczestników może zostać wysłana faktura.

Rodzaje podziału kosztów

Oś czasu zdarzeń pomaga nam zidentyfikować najważniejsze zdarzenia w okresie rozliczeniowym. Daje to ogólny obraz tego, co dzieje się w trakcie okresu. Spójrzmy teraz, jak rozwiązać reguły podziału – jeden z kluczowych elementów rozliczeń:

• podział równy – koszty dzielone są po równo między uczestników,
• podział proporcjonalny według zdefiniowanych wag – każdy uczestnik ma przypisaną własną wagę dla danego typu kosztu,
• podział czasowy (proporcjonalny) – podział między uczestników w zależności od czasu, przez jaki każdy z nich korzystał z danego zasobu,
• podział według zużycia – podział na podstawie proporcjonalnego zużycia zasobu przez uczestników (niezależnie od czasu korzystania),
• kombinacje wielu reguł – najtrudniejsze, choć z wysokiego poziomu nie ma to aż takiego znaczenia.

Przy implementacji modelu będziemy musieli zaimplementować odpowiednie rozwiązanie tego problemu, ale nie zajmiemy się tym w tym artykule – implementacji poświęcę osobny wpis. Na razie odłóżmy to na bok.

Struktura kosztu

Koszt powinien składać się z kilku elementów:

• Kwota pieniężna – wartość zapisana jako liczba + waluta,
• Data – data naliczenia kosztu,
• Kategoria – kategoria wydatku (rachunek za prąd, korzystanie z biurka, korzystanie z mikrofalówki itp.),
• Reguła podziału – znana z powyższej listy, określa sposób podziału kosztu między uczestników.

Myślę, że w ten sposób stworzyliśmy pierwszą encję domenową. Następną będzie na pewno Uczestnik. Uczestnik będzie prostą encją złożoną z imienia, adresu e-mail i identyfikatora. Na potrzeby tego modułu nic więcej nie potrzebujemy. Każdy uczestnik będzie miał też własne konto, na którym zapisywana będzie historia jego rozliczeń. Nazwijmy je Kontem Uczestnika.

Kolejną encją będzie prawdopodobnie Okres Rozliczeniowy. Będzie reprezentował przedział czasu (konkretnie miesiące rozliczeniowe). Jego właściwości to początek i koniec okresu oraz status (otwarty/zamknięty).

Po tym podstawowym rozpoznaniu możemy swobodnie narysować przypuszczalny kształt encji.

Encję Faktura celowo oznaczyłem innym kolorem. Nie ma jej w wymaganiach, ale jest naturalną konsekwencją działania aplikacji. Spróbujmy teraz dokładniej opisać elementy encji i relacje między nimi. Ten szkic ma jedynie zarysować i uporządkować kolejne klocki. Już na tym etapie widać, że encja Faktura zdecydowanie nie pasuje do reszty, ponieważ:

1. Dotyczy zdarzeń po zamknięciu okresu rozliczeniowego.
2. Może być wystawiona niezależnie od innych zdarzeń – jest konsekwencją, ale nie częścią procesu.

Nie odrzucajmy jednak Faktury, dopóki nie będziemy pewni, że to inny Bounded Context.

Pseudo-ERD

Poniżej znajdziesz kolejny etap projektowania: projektowanie encji i relacji między nimi, które roboczo możemy nazwać „pseudo-ERD”. Diagram związków encji (ERD) to pojęcie kojarzone z bazami danych, ale zauważ, że do tej pory nie wspomnieliśmy o warstwie persystencji. Nie wspomniałem o żadnym silniku bazy danych, frameworku ani ORM-ie, bo to nie one wyznaczają kierunek modelowania. Decyzje techniczne przyjdą później. Spójrzmy więc na ERD:

Tu widzimy bardziej szczegółowy obraz. Widzimy też, że wszystkie encje w pewnym stopniu zależą od Okresu Rozliczeniowego. Przyjrzyjmy się teraz centralnej encji, czyli Wspólnemu Wydatkowi (Shared Expense). To centralne miejsce schematu, ponieważ zawiera:

• typy kosztów,
• typy podziału kosztów między uczestników,
• kwotę do podziału (SharedAmount),
• SettlementPeriodId – referencję do naszego Aggregate Roota.

Klocki z DDD

Zaczynam używać pojęć ściśle związanych z DDD, więc warto krótko opisać podstawowe klocki taktycznego DDD (tak, jesteśmy już na pograniczu taktyki – jedyna strategiczna decyzja, jaka nam została, to czy włączyć Fakturę do naszego kontekstu, czy Fakturowanie będzie osobnym kontekstem).

Encja (Entity)

Obiekt z tożsamością, która jest ważniejsza niż jego bieżący stan. Może z czasem zmieniać atrybuty, ale pozostaje „tą samą” encją.

Przykłady: zamówienie, użytkownik, subskrypcja.

Obiekt wartości (Value Object)

Obiekt bez tożsamości, definiowany wyłącznie przez swoje wartości. Jest niemutowalny i porównywany przez równość wartości.

Przykłady: kwota pieniędzy, zakres dat, adres e-mail.

Agregat (Aggregate)

Spójna granica transakcyjna grupująca encje i obiekty wartości. Chroni niezmienniki biznesowe.

Korzeń agregatu (Aggregate Root)

Jedyne wejście do wnętrza agregatu. Tylko przez niego można modyfikować stan agregatu.

Z zewnątrz nigdy nie operujesz bezpośrednio na wewnętrznych encjach.

Repozytorium (Repository)

Abstrakcja dostępu do agregatów.

Naśladuje kolekcję w pamięci – to nie DAO ani Active Record.

Pobiera i zapisuje Aggregate Rooty, a nie dowolne encje.

Serwis domenowy (Domain Service)

Logika domenowa, która:

• nie pasuje naturalnie do jednej encji,
• operuje na wielu agregatach,
• nie przechowuje stanu.

To wciąż domena, a nie infrastruktura.

Zdarzenie domenowe (Domain Event)

Zdarzenie opisujące coś, co już wydarzyło się w domenie. Służy do komunikacji i reagowania na zmiany stanu.

To nie jest polecenie ani żądanie.

Fabryka (Factory)

Odpowiada za tworzenie złożonych agregatów. Ukrywa skomplikowaną logikę inicjalizacji i pilnuje niezmienników od samego początku.

Specyfikacja/Polityka (Specification/Policy)

Enkapsuluje regułę lub warunek biznesowy. Może służyć do walidacji, filtrowania i podejmowania decyzji.

Czytelny sposób zapisu złożonej logiki warunkowej.

Moduł (pakiet)

Logiczne grupowanie elementów domeny.
Pomaga utrzymać spójność i czytelność modelu.

Nie mylić z bounded contextem – to poziom niżej.

Model jest niekompletny

Mam wrażenie, że bezpośrednią relację między SettlementPeriod, SharedExpense i Participant można by zamknąć w mini-agregacie o nazwie ParticipantExpense, który działałby jako most między pojedynczym uczestnikiem kosztu a całym okresem rozliczeniowym. Co więcej, skoro nie mamy żadnej referencji do wspólnego zasobu, warto zgrupować to w ParticipantExpense. Kolejna iteracja naszego modelu wyglądałaby tak:

Sporo się zmieniło. Po pierwsze pojawiło się oznaczenie (C), czyli kolekcje obiektów. Z perspektywy relacyjnej jedna encja zawiera kolekcję innych encji. Dodałem też (VO) – Value Object. To jeden z opisanych wyżej klocków DDD.

Idąc dalej, zaznaczyłem też zakres naszego agregatu: jednostkę spójności, która agreguje wiele encji i zapewnia spójność podczas operacji biznesowych. Zaznaczyłem również Aggregate Root, którym w naszym przypadku jest SettlementPeriod. Do agregatu można się dostać z zewnątrz wyłącznie przez Aggregate Root. To bardzo przydatne, by logika się nie rozlewała, i pomaga zapewnić enkapsulację. Coś o tym było kiedyś na studiach, prawda? :) Usunąłem też z agregatu Participant i Facility.

Nasz model powinien zawierać jedynie referencje do nich, ale nie operuje bezpośrednio na uczestnikach ani na obiekcie (Facility). Zarządzaniu użytkownikami będzie prawdopodobnie poświęcony inny BC, a nawet inny moduł, i z pewnością osobny agregat zadba o jego spójność. To samo dotyczy Facility – w naszym agregacie chcemy tylko niezbędnych elementów; wystarczy referencja do FacilityID; nie powinno nas obchodzić, gdzie obiekt się znajduje ani jak się nazywa. Z perspektywy naszego modelu nie jest to istotne.

Poszedłem krok dalej i dodałem też ramę Bounded Contextu, który nazwałem Settlements. Postanowiłem nie włączać do niego Faktury – po analizie i krótkiej sesji modelowania już wiem, że będzie to osobny BC. Może nawet osobny moduł. Kto wie?

Wszystko pięknie, ale jak to teraz zakodować?

Jak zauważyłem, nasz model jest teraz kompletny, a przynajmniej tak się wydaje. W tym artykule nie pokażę implementacji. Poświęcę jej całą drugą część, ale tytułem wstępu przedstawię diagram klas UML. Do tej pory skupialiśmy się na rzeczownikach – encjach. Teraz, żeby było bardziej funkcjonalnie, dodamy do UML-a czasowniki, czyli procesy i akcje – zachowania klas.

Zauważ też, że brakuje nam tzw. stanu wejściowego. Za jego sformułowanie będzie odpowiadał inny BC: Facility Management, w którym można dodawać zasoby do obiektów i uczestników do obiektów. Będzie to pewnie standardowy CRUD z dodawaniem, edycją i usuwaniem. Możemy go sobie wyobrazić jako panel administracyjny dla zarządców, w którym wprowadzają wszystkie te dane. Nasz moduł będzie jedynie reagował na zdarzenia domenowe takie jak:

• SharedExpenseCorrected
• ParticipantJoined
• ParticipantLeft
• SettlementPeriodStarted
• SettlementPeriodClosed

W naszym kontekście zakładamy, że takie powiązanie już istnieje i jedynie je odczytujemy (Read Model), by zbudować nasz agregat i zarządzać jego zachowaniem i spójnością.

Powyższy diagram to tylko szkic; gdy zacznę kodować, sporo się pewnie zmieni. Drugiej części tego wpisu spodziewaj się wkrótce. Tymczasem zostawiam cię z tymi wnioskami i zachęcam do podzielenia się przemyśleniami w komentarzach.

Problem początkowo wydawał się dość trywialny, ale im głębiej wchodzimy, tym bardziej się komplikuje. W rzeczywistości wciąż daleko nam do pisania kodu. Mamy koncepcję, mamy diagramy, ale kod musi działać. Może stworzenie aplikacji rozwiązującej ten problem byłoby dobrym pomysłem. Nie wiem, zobaczę, jak to się rozwinie w najbliższych dniach. Na razie myślę, że całkiem dobrze rozpracowaliśmy sam model. Ale jak to często bywa w programowaniu, diabeł tkwi w szczegółach.

Dziś porozmawiamy o metrykach w procesie wytwarzania oprogramowania. Pokażę na wstepie fajną grafikę którą znalazłem na kanale: LeaderShip Failed Successfully - podcast liderski. To grafika będzie podstawą do omówienia każdej metryki oraz oceny dla kogo i po co te metryki są potrzebne.

Zacznę od filmu, który skłonił mnie do omówienia tematu:

Szczególnie zainteresował mnie raport, który chłopaki pokazali w filmie:

Grupy metryk

Widzimy 4 grupy najpopularniejszych metryk. Sam zanim nie zagłebiłem się w temat dużo słyszałem o DORA. Zostałem też o to zapytany na ostatniej rozmowie kwalifikacyjnej. Może zacznijmy od DORA właśnie:

DORA - DevOps Research and Assessment

Składa się z 4 metryk (wg autorów filmu 5. metryka została dodana - sprawdziłem to i uwzględnie to w poniższym opisie). Metryki mają na celu badać szybkość dostarczania oraz bezpieczeństwo zmiany.

Deployment Frequency (DF)
Jak często zespół wdraża zmiany na produkcję
→ mierzy zdolność do szybkiego dostarczania wartości

Lead Time for Changes - Cycle Time (LT)
Czas od commit/merge do uruchomienia zmiany na produkcji
→ mierzy sprawność procesu delivery

Change Failure Rate (CFR)
Procent wdrożeń powodujących incydenty, rollbacki lub hotfixy
→ mierzy jakość i stabilność zmian

Mean Time to Recovery (MTTR)
Średni czas przywrócenia systemu po awarii
→ mierzy odporność systemu i zespołu

Reliability
mierzy, na ile system faktycznie spełnia oczekiwania użytkowników pod względem:

• dotrzymywania SLO / SLA.
• dostępności,
• stabilności,
• poprawności działania,

Jeśli zerkniemy na grafikę, zauważymy że najlepsze zespoły (elite) są w stanie deployować kod średnio codziennie. Oznacza to, że codziennie na produkcję wskakuje przynajmniej jedna wersja kodu (nowy feature, funkcjonalność). To samo dotyczy Lead Time For Changes (Cycle Time). Od momentu zacommitowania zmiany, nie powinien minąć więcej niż jeden dzień w przybliżeniu aby zmiana ta została uruchomiona na produkcji.

Change Failure Rate - to bardzo ważna metryka i wg raportu ilość problematycznych wdrożeń powinna być niższa niż 1% - co więcej są zespoły, które takie wyniki dowożą.

Kolejną metryką z raportu jest MTTR - czyli zdolność do reagowania na bugi/incydenty na produkcji. Czas na regenerację jest bardzo ważny - nie chcemy przecież żeby nasi klienci/użytkownicy korzystali z zepsutej aplikacji. Najlepsze zespoły potrafią te problem rozwiązać w mniej niż 6 godzin.

Dora - dobra na start ale zbyt ogólna dla programistów

Mój wniosek o zagłębeniu się w temat jest prosty - DORA pomaga całemu zespołowi ale w szczególności zespołowi DevOps utrzymać płynnośc i stabilność systemu na dobrym poziomie.

Z pomocą przychodzi kolejna grupa metryk czyli DevEx:

Mamy tutaj kilka elementów:

• Coding Time (hours) - Coding time is what we like best - top teams need on average less than an hour to code a solution.
• Pickup Time (hours/minutes) - Pickup time - The time it takes a programmer to start a task and change its status to in-progress. The best teams need less than 75 minutes to do this.
• Approve Time (hours) - the amount of time needed to receive approval for deployment to production; <10 hours is already an excellent result according to the table above.
• Merge Time (hours) - the number of hours between completing a CR and merging changes to the main branch. Elite teams can do this in 2 hours (on average).
• Review Time (hours) - how long a code review takes. The best teams can do it in less than 3 hours.
• Deploy Time (hours) - how many hours it takes to deploy after merging to the main branch. Elite teams can do it in less than 6 hours. This reflects Lead Time for Changes from DORA.
• Merge Frequency (per dev/week) - czyli ile PR na jednego programistę jest mergowane tygodniowo - najlepsi są w stanie utrzymać tą metrykę na poziomie > 2.25 PR tygodniowo
• PR Maturity - bardzo ważna metryka mówiąca o tym jaki odsetek PRs jest do razu przydatna do wdrożenia bez sesji poprawek po code review. Najlepsze zespoły utrzymują to na poziomie >91%

Other metrics. Do we need them?

I will answer this question briefly: NO. In my opinion, DORA + DevEX is more than enough to observe and draw conclusions. However, if you're interested in learning about Predictability and PM Hygiene, I encourage you to watch the video or at least take a look at the graphic I've shared above.

Summary

In conclusion, I'd like to remind you that metrics aren't meant to put pressure on us as developers or DevOps teams, but rather to help us continuously improve our performance and identify bottlenecks in the software development process. If you want to implement metrics gradually, I suggest starting with DORA, then adding (perhaps not even all) the DevEx elements. This should be enough to test the metrics in your environment and select the ones you can influence.

I hope this article has been encouraging. After all, it's all about becoming better professionals. And what if you want to be better at something you don't measure? Metrics are just measurable tools for continuous process improvement, and I'd like to leave you with that thought today. I'd appreciate any comments and sharing experiences. Thanks!

Zastanawiałeś się kiedyś, jak firmy zamieniają ogromne oceany surowych danych w wnioski, na podstawie których można działać? Inżynieria danych to ukryty silnik napędzający tę transformację. Od analityki w czasie rzeczywistym po przełomowe modele uczenia maszynowego – inżynieria danych kształtuje cyfrowy krajobraz.

Ta dziedzina sprawia, że firmy mogą polegać na czystych, dostępnych i bezpiecznych danych, by rozwijać się w dzisiejszym konkurencyjnym świecie. Zobaczmy, jak ta fascynująca dziedzina stanowi kręgosłup nowoczesnej technologii.

Czym jest inżynieria danych?

• Zarządzanie dużymi zbiorami danych: umożliwia szybkie i wydajne przetwarzanie ogromnych ilości informacji.
• Integracja danych: łączy dane z różnych źródeł, takich jak bazy danych, API czy pliki.
• Przygotowanie danych do analizy: czyści i przekształca dane do formatu odpowiedniego dla procesów analitycznych.
• Automatyzacja procesów: tworzy pipeline'y – zautomatyzowane przepływy przetwarzania danych, które ograniczają błędy ludzkie i przyspieszają przetwarzanie.
• Zapewnienie bezpieczeństwa danych: chroni dane przed utratą i nieuprawnionym dostępem, zgodnie z przepisami prawa.

Rola inżyniera danych w zespole IT

Inżynier danych to kluczowy członek zespołów zarządzających informacją. Współpracuje z różnymi działami, m.in. z data scientistami, analitykami biznesowymi i programistami. Do jego głównych obowiązków należą:

• Projektowanie i budowa infrastruktury danych: tworzenie hurtowni danych, baz danych i systemów przetwarzania.
• Implementacja pipeline'ów danych: budowa procesów ETL (Extract, Transform, Load) lub ELT do wydajnego przetwarzania danych.
• Monitorowanie jakości danych: wdrażanie narzędzi do walidacji i czyszczenia danych.
• Zapewnienie skalowalności: dostosowywanie systemów do rosnącej ilości danych.
• Wspieranie zespołów analitycznych: dostarczanie spójnych i gotowych do użycia danych w czasie rzeczywistym.

Umiejętności wymagane od inżyniera danych

Praca Data Engineera wymaga szerokiego wachlarza umiejętności, m.in.:

• Znajomość baz danych: zarówno relacyjnych (SQL), jak i nierelacyjnych (NoSQL, np. MongoDB).
• Umiejętności programistyczne: biegłość w językach takich jak Python, Scala, Java czy R.
• Narzędzia do przetwarzania danych: znajomość Hadoop, Apache Spark, Kafka.
• Zdolności analityczne: rozumienie modelowania danych i statystyki.
• Znajomość chmury: doświadczenie z AWS, Google Cloud lub Azure w kontekście przetwarzania danych.

Dlaczego inżynieria danych jest dziś tak ważna?

Współczesne firmy podejmują decyzje na podstawie analizy danych. Bez inżynierii danych byłoby to niemożliwe – dane pozostawałyby rozproszone, niespójne lub niedostępne. Dzięki pracy inżynierów danych organizacje mogą:

• Podejmować decyzje oparte na faktach zamiast na intuicji.
• Optymalizować procesy biznesowe.
• Rozwijać zaawansowane modele predykcyjne.
• Zapewniać zgodność z przepisami o ochronie danych.

Inżynieria danych leży w samym sercu nowoczesnych systemów informacyjnych i jest kluczem do sukcesu w cyfrowej gospodarce.

Dlaczego przeszedłem do inżynierii danych?

Tak naprawdę przeszedłem z czystego Software Engineeringu do Data Engineeringu połączonego z SE. Opowiem więcej o tym, dlaczego zdecydowałem się na to 2 lata temu.

Po 7 latach pracy jako Junior, potem Mid, a w końcu Senior Software Engineer nagle znalazłem się na rozdrożu. Cały mój zespół został rozwiązany – budowaliśmy narzędzie logistyczne dla e-commerce – i musiałem wybrać jedną z dwóch opcji:

a) Odejść z firmy zaledwie kilka miesięcy po dołączeniu (tuż po tym, jak w końcu się wdrożyłem) i zacząć szukać pracy na podobnym stanowisku.

b) Zostać i pomóc zbudować zupełnie nowy zespół, którego celem było stworzenie platformy danych dla większości działów w firmie – platformy wspierającej ich codzienne podejmowanie decyzji.

Ponieważ pracuję z technologią od dawna, wiedziałem jedno: narzędzia takie jak Databricks, Snowflake, DBT czy PySpark to tylko narzędzia. Nauka ich to dla kogoś z moim doświadczeniem właściwie zwykły dzień w biurze. Nie wiedziałem natomiast, czy praca z danymi będzie rzeczywiście ciekawa.

Trochę niepewnie wybrałem opcję b. Uznałem, że dam sobie szansę na poznanie nowych technologii – może pomoże mi to się rozwinąć. Choć wcześniej tylko słyszałem o tych narzędziach albo ledwo ich dotykałem, postanowiłem nauczyć się ich w trakcie pracy. Żadnych kursów, żadnych szkoleń – zostałem rzucony na głęboką wodę i szczerze mówiąc, pokochałem to. Lubię pracę pod presją – wtedy czuję się najbardziej produktywny.

Po około trzech miesiącach wiedziałem, że chcę iść dalej w tym kierunku. Na mojej drodze pojawiały się kolejne narzędzia – PowerBI, MCP (Model Context Protocol) i inne. Praca z danymi okazała się dla mnie idealna. Uwielbiam wykresy, korelacje, tabele, prognozowanie, analizy i opowiadanie historii za pomocą danych. Moja rola rozszerzyła się z Data Engineeringu na całe spektrum – od Software Engineeringu po specjalistę BI.

Zbudowałem dziesiątki dashboardów, które do dziś są używane w firmie i przynoszą realną wartość. Umiejętności prezentacji mogłyby być lepsze – wiem, że to coś, nad czym muszę popracować. W świecie technologii można budować niesamowite rzeczy, ale jeśli nie potrafisz ich dobrze zaprezentować, twoja praca może nigdy nie dostać uwagi, na jaką zasługuje.

Przydało się też moje doświadczenie programistyczne. Dane często trzeba było skądś zebrać, a szybkie integracje z zewnętrznymi API pozwalały nam w imponującym tempie rozszerzać źródła danych.

Tak w skrócie wygląda moja historia. Nie chcę zanudzać wszystkimi szczegółami, ale chcę przekazać jedną myśl: zmiany ścieżki kariery – szczególnie w IT – będą teraz zdarzać się bez przerwy. Technologia ogromnie przyspieszyła. Samo programowanie nie jest już unikalną umiejętnością. Szczerze mówiąc, nawet wujek z rodzinnej imprezy mógłby dziś pewnie zbudować aplikację mobilną z pomocą LLM-ów (dobra, może trochę przesadzam).

Programiści, którzy nigdy nie zrobili kroku w stronę architektury rozwiązań czy oprogramowania, mają teraz trudne czasy. Patrząc wstecz, uważam, że moja decyzja o zmianie kierunku była ryzykowna, ale absolutnie warta tego. Dwa lata temu nie wiedzieliśmy, jak bardzo LLM-y zmienią rynek pracy. Dziś już wiemy – i samo programowanie to za mało. Inżynieria danych natomiast pozwala część tego ryzyka ograniczyć.

W przyszłości planuję dalej rozwijać się w zarządzaniu projektami (mam już pewne doświadczenie) oraz w architekturze rozwiązań. Moim celem jest stać się jednoosobową armią – kimś, kto potrafi poprowadzić projekt z kilkoma agentami AI lub juniorami. Wierzę, że taki profil będzie najbardziej wartościowy w nadchodzącej dekadzie. W skrócie:

• Programowanie
• Testowanie
• Inżynieria i analiza danych
• Zarządzanie projektami IT
• Architektura rozwiązań i oprogramowania (głównie chmurowa)

Jeśli spojrzysz na moje CV, zmierza ono dokładnie w tym kierunku. I choć znowu jestem na rynku pracy, nie martwię się. Wiem, dokąd zmierzam, i wiem, skąd przyszedłem. A dotarłem tu wyłącznie dzięki ciężkiej pracy i wytrwałości.

Wpis robi się trochę zbyt osobisty, więc na tym zakończę.

Moje przesłanie dla świata? Nie bój się ryzyka. Czasem trzeba zrobić krok w tył, żeby pójść do przodu – i ten krok może być dokładnie tym, czego potrzebowałeś.

Powodzenia!

Liczba programistów na świecie wciąż rośnie, niestety tych oferujących wysoką jakość jest niewielu. Co sprawia, że deweloper nie jest w stanie dostarczyć usług dobrej jakości? Zazwyczaj wiążę się to z błędami. Poniżej znajdziesz skondensowaną listę dotyczącą tego problemu.

1. Myślenie, że jesteś niezastąpiony

Wielu przeciętnym programistom wydaje się, że są niesamowitymi programistami. Miałem to samo. Po kilku latach zdałem sobie sprawę, że jest mnóstwo ludzi, którzy są naprawdę niesamowici, lepsi ode mnie, a ja byłem po prostu zbyt pewny siebie.

W momencie, gdy powiedziałem sobie, że mam wiele braków do poprawy i nie jestem tak niesamowity, jak zakładałem, zmienił się mój pogląd na sprawy. Zacząłem uczyć się nowych rzeczy i poprawiam się z dnia na dzień. Chęć uczenia się i przekonanie, że wciąż masz wiele do poprawy, zabierze Cię daleko. Dotyczy to nie tylko programowania, ale także każdej innej umiejętności życiowej.

2. Praca bez szacowania i rekompensowanie nadgodzinami

Wielu programistów pisze kod, nie zważając na czas wykonania prac. Wylewa się poza godziny pracy, zabiera rodzinie czas w weekendy, ogranicza sen, zachodząc do późnych godzin nocnych i tak dalej. Dzieje się tak, ponieważ nie ustalasz terminu zakończenia zadania.

Na przykład, jeśli budujesz moduł, musisz zdecydować „Skończę to w 3 godziny, z 1 godziną dodatkowego bufora”. Jeśli nie skończysz w ciągu 4 godzin, przechodzisz do czegoś innego. Kiedy nie dotrzymujesz terminu, ciągniesz go w nieskończoność. Ponieważ wiesz, że zatuszujesz to pracując w ramach nadgodzin, nie będziesz próbował poprawiać swoich umiejętności szacowania zadań (tzw. estymacji).

Ustaw konkretną godzinę, o której zamkniesz laptopa i włączysz go dopiero następnego dnia. Zaufaj mi, zmusi cię to do ustalania priorytetów i doskonalenia, dzięki czemu staniesz się lepszym programistą.

3. Wahania przed udziałem w heckatonach i zadaniach dla programistów

Programiści często boją się spróbować swoich sił w wyzwaniu związanym z kodowaniem na stronach internetowych takich jak TopCoder, Coderbyte. Przyczyną zazwyczaj jest obawa się, że uczestnicząc w nich, poczują się źle z powodu obnażenia swoich braków.

Nie bądź tchórzem! Poprawisz swoje umiejętności tylko wtedy, gdy będziesz chciał wiedzieć, na czym stoisz, wielokrotnie zawodzić i ponosić porażki. Nic nie tracisz i nikt nie dowie się, jeśli poniesiesz porażkę. Podczas gdy ty rezygnujesz z takiego zadania, inni programiści udoskonalają się, tym samym zostawiając cię w tyle.

Jednocześnie uważaj na niektóre wyzwania programistyczne. Niektóre wyzwania związane z kodowaniem mają śmiesznie krótkie ograniczenia czasowe, co może prowadzić do złych nawyków związanych z kodowaniem. Mogą też mieć do rozwiązania dziwny problem, który nie pomaga w doskonaleniu umiejętności. Nie krytykuj siebie, jeśli nie poradzisz sobie z tymi wyzwaniami. Z biegiem czasu będziesz w stanie odróżnić dobre wyzwanie związane z kodowaniem od złego.

4.Niekorzystanie z optymalnego środowiska, narzędzi i urządzeń

Wielu programistów uważa, że ​​mogą kodować, leżąc na łóżku z laptopem na piersi. Jasne, że możesz, ale twoje umiejętności będą tak dobre, jak twoje lenistwo.

Poza tym, ktokolwiek powiedział Ci, że praca na touchpadzie/klawiaturach w laptopie jest równie szybka jak praca na myszce/klawiatury, nie pracowała z myszką/klawiaturą wystarczająco. Kombinacja myszy i klawiatury jest szybsza, kropka.

Pracując na różnych laptopach, konfiguracjach komputerów stacjonarnych i wszelkiego rodzaju urządzeniach peryferyjnych, mogę zagwarantować, że pisanie kodu siedząc na stole, używając większego ekranu z kombinacją myszy i klawiatury, przyspiesza programowanie, i to znacznie.

5. Brak próby szybszego kodowania

Programowanie to także szybkość. Chociaż ludzie mówią ci, że pisanie dobrego kodu jest ważne, nie ignoruj ​​​​szybkości. W obecnym świecie czas to pieniądz. Musisz rzucić sobie wyzwanie, aby szybciej kodować, pisać szybciej i używać skrótów swojego edytora. Musisz włożyć świadomy wysiłek, aby zwiększyć szybkość.

Uwaga: nie chcę powiedzieć, że musisz zwiększyć szybkość kosztem jakości kodu. Pisanie dobrego i wydajnego kodu jest ważniejsze niż szybsze kodowanie. Twoim pierwszym celem powinno być pisanie kodu, który generuje wyniki we właściwy sposób. Ale w trakcie szukaj okazji do szybszego załatwiania spraw. W większości przypadków masz możliwość zwiększenia szybkości bez utraty jakości. Ale nigdy nie będziesz w stanie osiągnąć maksymalnej prędkości z najlepszym punktem jakości bez rzucenia sobie wyzwania. Zwiększenie prędkości nie oznacza tylko szybszego pisania. Możesz zwiększyć szybkość programowania, rzucając sobie wyzwanie rozwiązania zadania programistycznego szybciej niż zwykle.

6. Kopiowanie kodu na ślepo

Bez wątpienia wszyscy używamy kodu z Internetu, ze stron takich jak StackOverflow czy z ostatnio popularnego ChatGPT. W rzeczywistości nieużywanie kodu w ogóle nie jest najmądrzejszym pomysłem. Ale czy za każdym razem, gdy używasz jakiegoś kodu, wklejasz go na ślepo i sprawdzasz, czy zadziałał? Cóż, jeśli tak, tracisz okazję do nauki. To za mało, aby tak naprawdę zrozumieć, czy kod, który wkleiłeś można napisać lepiej niż zasugerowano w odpowiedzi.

Powodem, dla którego szukałeś kodu, jest to, że albo nie wiedziałeś, jak to zrobić, albo chciałeś zaoszczędzić czas. Spróbuj zrozumieć kod, którego użyłeś przynajmniej na wysokim poziomie. Nie musisz rozumieć kodu wiersz po wierszu, ale przynajmniej rozumieć zastosowane podejście.

7. Robienie rzeczy w ten sam sposób bez doskonalenia umiejętności

Jeśli zacząłeś od PHP, nadal możesz zbudować dowolną funkcjonalność, korzystając z tego, czego nauczyłeś się w pierwszym roku. Jeśli napiszesz tylko kod, który już znasz lub napisałeś wcześniej, popadniesz w stagnację.

Poruszaj się z nowymi technologiami i stawiaj sobie wyzwania. Wypróbuj inny język programowania, wypróbuj nowe frameworki, poznaj nowe algorytmy, wypróbuj najlepsze praktyki. Stale się ulepszaj.

Spójrz na to tak, 10 lat później, jeśli robisz to samo, dlaczego ktoś miałby ci płacić więcej niż programista z 1-2 letnim doświadczeniem?

Podsumowanie

Powyższy artykuł powstał na bazie moich doświadczeń oraz doświadczeń ludzi o podobnym do mnie nastawieniu. Będę bardzo wdzięczny jeśli rozszerzysz tą listę o swoje propozycje w komentarzach.

Jeśli chociaż jeden punkt uda ci się wyeliminować, to już osiągnąłeś/aś sukces. Życzę powodzenia w kreowaniu lepszego świata IT, bo o to tak naprawdę chodzi.

Programowanie to umiejętność tworzenia oprogramowania komputerowego za pomocą specjalnych języków i narzędzi. Może być używane do tworzenia gier, aplikacji, stron internetowych, systemów operacyjnych i wielu innych rzeczy. Programowanie jest bardzo ciekawe i przydatne, ponieważ pozwala rozwiązywać problemy, wyrażać kreatywność i tworzyć wartościowe produkty. Jeśli chcesz zostać programistą, możesz się zastanawiać, od czego zacząć programowanie. W tym artykule przedstawię Ci kilka kroków i wskazówek, które pomogą Ci w nauce programowania.

Wybierz język programowania

Pierwszym krokiem w nauce programowania jest wybór języka programowania. Język programowania to zestaw reguł i słów, które służą do komunikacji z komputerem i polecenia mu wykonania określonych zadań. Istnieje wiele różnych języków programowania, które mają różne cechy, zalety i zastosowania.

Wybór języka programowania może być trudny, ponieważ nie ma jednego najlepszego języka dla wszystkich celów. Niektóre języki są lepsze do tworzenia gier, inne do tworzenia aplikacji mobilnych lub stron internetowych. Niektóre języki są łatwiejsze do nauki dla początkujących, inne wymagają więcej doświadczenia i wiedzy.

Jednym ze sposobów na wybór języka programowania jest określenie swojego celu lub zainteresowań. Jeśli chcesz tworzyć gry komputerowe, możesz wybrać język taki jak C++, C# lub Java. Możesz też tworzyć aplikacje mobilne dla systemu Android lub iOS, możesz wybrać Kotlin lub Swift. Jeśli chcesz tworzyć strony internetowe lub aplikacje webowe, możesz wybrać HTML/CSS/JavaScript lub Python/Django/Flask.

Innym sposobem na wybór języka programowania jest sprawdzenie popularności lub popytu na dany język. Możesz poszukać rankingów lub statystyk pokazujących najczęściej używane lub najbardziej poszukiwane języki przez pracodawców lub społeczność programistyczną. Możesz też sprawdzić opinie innych osób uczących się danego języka lub korzystających z niego w swojej pracy.

Niezależnie od tego jakiego języka wybierzesz ważne jest abyś się go dobrze nauczyć i praktykować go regularnie. Nie musisz się ograniczać do jednego języka – możesz też uczyć się kilku równocześnie lub kolejno po sobie – ale nie próbuj uczyć się wszystkiego naraz bo to może być przytłaczające i demotywujące.

Zdobądź solidne podstawy

Drugim krokiem w nauce programowania jest zdobycie solidnych podstaw teoretycznych i praktycznych dotyczących działania komputerów oraz podstawowych pojęć i technik programistycznych.

Podstawy teoretyczne dotyczą takich zagadnień jak:

• Systemy liczbowe (binarny, dziesiętny itp.)
• Architektura komputera (procesor, pamięć RAM itp.)
• System operacyjny (Windows, Linux itp.)
• Algorytmy (sposoby rozwiązywania problemów)
• Struktury danych

Ucz się z różnych źródeł

Trzecim krokiem w nauce programowania jest korzystanie z różnych źródeł wiedzy i materiałów edukacyjnych. Nie ma jednego idealnego sposobu na naukę programowania – każdy ma swoje preferencje i tempo uczenia się. Dlatego warto wykorzystywać różne formy i metody zdobywania wiedzy, takie jak:

• Studia – to najbardziej kompleksowe rozwiązanie, które zapewnia szeroką i głęboką wiedzę teoretyczną i praktyczną z wielu dziedzin informatyki. Studia wymagają jednak dużo czasu, pieniędzy i zaangażowania.
• Bootcampy programistyczne – to intensywne kursy, które uczą konkretnych umiejętności i technologii potrzebnych do pracy jako programista. Bootcampy są skierowane do osób, które chcą szybko zmienić zawód lub zdobyć nowe kwalifikacje.
• Kursy wideo – to nagrania lekcji lub prezentacji na temat różnych aspektów programowania. Kursy wideo są łatwo dostępne, tanie lub darmowe i pozwalają uczyć się we własnym tempie.
• Książki – to tradycyjne źródło wiedzy, które oferuje bogactwo informacji i przykładów kodu. Książki mogą być aktualne lub przestarzałe, więc warto sprawdzać datę wydania i recenzje.
• YouTube – to popularna platforma wideo, na której można znaleźć wiele darmowych materiałów na temat programowania. YouTube może być dobrym uzupełnieniem innych źródeł, ale nie wystarczy samemu do nauki programowania¹.

Korzystając z różnych źródeł wiedzy należy pamiętać o kilku ważnych zasadach:

• Nie ograniczaj się do jednego źródła – porównuj informacje z różnych miejsc i szukaj potwierdzenia lub wyjaśnienia niejasności.
• Nie ufaj ślepo wszystkiemu co czytasz lub słyszysz – sprawdzaj wiarygodność autora lub źródła oraz aktualność informacji.
• Nie bierz wszystkiego dosłownie – interpretuj informacje krytycznie i stosuj je do swojego kontekstu i celu.

Praktykuj regularnie

Czwartym krokiem w nauce programowania jest regularna praktyka kodowania. Teoria jest ważna, ale bez praktyki nie można zostać dobrym programistą.

Praktyka kodowania pozwala utrwalić wiedzę, zrozumieć działanie kodu i rozwiązywać problemy. Praktyka kodowania pomaga również rozwijać kreatywność i umiejętność myślenia logicznego. Aby praktykować kodowanie regularnie, można:

• Wykonywać zadania i projekty związane z kursami lub książkami.
• Rozwiązywać łamigłówki i zadania programistyczne na stronach internetowych takich jak Codewars, HackerRank czy LeetCode.
• Tworzyć własne aplikacje lub strony internetowe na podstawie własnych pomysłów lub inspiracji z internetu.
• Uczestniczyć w konkursach programistycznych lub hackathonach.
• Dołączyć do społeczności programistów i dzielić się swoimi pracami lub pytać o pomoc.

Praktykując kodowanie należy pamiętać o kilku ważnych zasadach:

• Nie poddawaj się przy napotkaniu trudności – szukaj rozwiązań w internecie lub poproś o pomoc innych programistów.
• Nie kopiuj gotowego kodu – staraj się go zrozumieć i zmodyfikować według własnych potrzeb.
• Nie zapominaj o jakości kodu – dbaj o czytelność, komentarze i formatowanie kodu oraz stosuj dobre praktyki programistyczne.

Podsumowanie i zaproszenie na darmową konsultację

W tym artykule dowiedziałeś się o czterech krokach w nauce programowania:

• Wybierz język programowania i technologię odpowiednią do Twojego celu i zainteresowań
• Poznaj podstawy programowania i naucz się logicznego myślenia
• Ucz się z różnych źródeł wiedzy i materiałów edukacyjnych
• Praktykuj regularnie kodowanie i rozwijaj swoje umiejętności

Nauka programowania jest ciekawym i satysfakcjonującym procesem, który może przynieść Ci wiele korzyści osobistych i zawodowych. Nie bój się wyzwań i błędów – one są nieodłączną częścią nauki. Pamiętaj też o ciągłym doskonaleniu swojej wiedzy i umiejętności – technologia nie stoi w miejscu.

A Ty jak uczysz się programować? Jakie masz cele i plany? Podziel się swoimi doświadczeniami w komentarzach poniżej!

Mam nadzieję, że to Ci pomoże. Jeśli masz jeszcze jakieś pytania lub uwagi dotyczące artykułu, chętnie na nie odpowiem. Zapraszam na darmową konsultację, którą umówisz tutaj: DARMOWA KONSULTACJA.

Źródła:

• https://ladytech.pl/hobby/nauka-programowania-od-czego-zaczac/
• https://codecool.com/pl/blog/od-czego-zaczac-nauke-programowania/
• https://www.giganciprogramowania.edu.pl/blog/jak-zaczac-przygode-z-programowaniem-gier
• https://www.komputerswiat.pl/artykuly/redakcyjne/od-czego-rozpoczac-nauke-programowania-najwazniejsze-sa-solidne-podstawy
• https://webporady.pl/od-czego-zaczac-nauke-programowania/
• https://kodilla.com/pl/blog/nauka-programowania-od-zera