Kim jest programista w czasach AI?

Robert C. Martin, czyli Uncle Bob, jeden z najbardziej znanych programistów w historii, autor kultowej książki “Czysty kod”, mówi, że tworzonego przez AI kodu już nawet nie czyta.

David Heinemeier Hansson, znany jako DHH, twórca Ruby on Rails, podczas wrześniowej konferencji Rails World stwierdził, że era ręcznego pisania kodu dobiegła końca.

To wszystko prowadzi nas do kilku bardzo ważnych pytań:

Kim jest programista w erze sztucznej inteligencji?

Jak będzie wyglądała przyszłość programistów i branży IT?

Czego warto się uczyć i na jakie umiejętności stawiać?

Sztuczna inteligencja wywołała w ostatnich tygodniach prawdziwe trzęsienie ziemi.

Twórcy z pomocą AI łączą dziś elementy gier, które na pierwszy rzut oka nie mają ze sobą nic wspólnego. Postacie z Mario trafiają do świata Elden Ringa, a w Modern Warfare można jeździć na deskorolce z gry Skate. Z kolei jeden programista wziął na warsztat aplikacje Adobe: stworzył własne odpowiedniki Lightrooma, Photoshopa i Premiere Pro, a ich kod udostępnił na GitHubie jako open source.

To wszystko było możliwe dzięki procesowi zwanemu reverse engineering - po polsku jest to inżynieria wsteczna - który polega na analizowaniu gotowych aplikacji, aby zrozumieć, jak działają pod spodem i jak zostały zbudowane.

Jednym z kluczowych narzędzi w tym procesie jest dekompilacja.

Krótkie tłumaczenie dla osób nietechnicznych - tworząc aplikację, piszemy kod, którego struktura jest zrozumiała, zarówno dla nas, jak i dla modeli sztucznej inteligencji. Taki kod jest następnie kompilowany do tak zwanego kodu maszynowego, zrozumiałego dla procesora, który uruchamia aplikację.

Dekompilacja to proces odwrotny - ten absolutnie nieczytelny na pierwszy rzut oka kod maszynowy staramy się odszyfrować i zamienić z powrotem na zrozumiałą dla nas formę. Takie rzeczy oczywiście były możliwe wcześniej, ale były bardzo trudne i trwały bardzo długo. Bywało, że reverse engineering pojedynczej gry lub aplikacji trwał latami. Teraz, dzięki AI, można to zrobić praktycznie od ręki.

Jeszcze bardziej szokujące jest to, co wydarzyło się w świecie matematyki.

Najpierw OpenAI opublikował rozwiązanie problemu Naviera-Stokesa, który był jednym z najważniejszych problemów w matematyce i należał do tak zwanych problemów milenijnych. Tysiące agentów OpenAI pracowało nad rozwiązaniem kilkadziesiąt godzin i zakończyło się to sukcesem.

Maszyna dokonała czegoś, czego człowiek nie był w stanie zrobić przez dekady.

Co prawda nie obyło się bez kontrowersji, bo pojawiły się głosy, że OpenAI korzystało z wyników badań innych matematyków, ale nie zmienia to tego, że rozwiązanie problemu stało się faktem.

Prawdziwe trzęsienie miało jednak dopiero nadejść.

Na początku października OpenAI opublikowało rozwiązania ponad siedmiuset problemów, z którymi matematycy bez powodzenia zmagali się od dziesięcioleci.

Szok? Niedowierzanie? Strach? Smutek? Rezygnacja?

Reakcje były różne, ale niekoniecznie pozytywne.

Pojawiły się nawet głosy, że matematyka, w dotychczasowej formie, po prostu przestała istnieć.

Czy tak samo wygląda to w branży IT?

Jednego możemy być pewni - rola programisty się zmieniła.

I z dużym prawdopodobieństwem, choć jeszcze nie ze stuprocentową pewnością, możemy powiedzieć, że skończyła się era ręcznego pisania kodu.

Oczywiście przez jakiś czas będą jeszcze projekty - jak na przykład projekty bankowe - gdzie programiści będą pracować w tradycyjny sposób, ręcznie pisząc kod, ale i to wkrótce się zmieni.

Pytanie brzmi - w jakim miejscu nas to stawia i przede wszystkim, co dalej?

Pisanie kodu jest absolutnie fantastyczną czynnością. Ten akt tworzenia czegoś z niczego, wydawanie komputerowi instrukcji niezrozumiałych dla zwykłego śmiertelnika, ma w sobie coś wręcz magicznego, ale musimy pogodzić się z tym, że będzie tego coraz mniej, a być może ten sposób pracy zniknie całkowicie już wkrótce.

I jasne, to jest coś, co jak najbardziej może wywołać silne emocje: smutek, żal, nostalgię za tym sposobem pracy, który już nie wróci. Ale jednocześnie czeka nas coś zupełnie nowego, kto wie, czy nie równie, a może jeszcze bardziej ekscytującego.

Jesteśmy w szoku, bo jeszcze żadna rewolucja w historii świata nie przebiegała tak szybko jak rewolucja sztucznej inteligencji. Zastanówmy się, co by się działo, gdyby konie zostały zastąpione samochodami na przestrzeni kilku lat. Ludziom też by było żal i mówiliby, że na tych koniach jeździło się tak cudownie, że wiatr rozwiewał nam włosy, a podróżując czuliśmy wolność. Teraz, odpalając tę maszynę, co prawda dużo szybciej przemieszczamy się z punktu A do punktu B, ale nie ma w tym żadnej ekscytacji i żadnej magii.

Ale jakie niesamowite możliwości to otworzyło. Dzięki samochodowi możemy nie tylko szybciej dojechać do Lidla, ale możemy też zjeździć cały świat, przeżywając przygody, które wcześniej były poza zasięgiem człowieka.

Dokładnie tak samo jest i będzie z programowaniem. Pisanie kodu było absolutnie niesamowitą, dającą masę satysfakcji czynnością. Z jednej strony było to trudne, wymagające, czasem frustrujące, ale jednak koniec końców, gdy rozwiązywaliśmy problem, czuliśmy się jak bogowie.

I powiedzmy to sobie jasno - w przypadku budowania produktów z AI wygląda to zupełnie inaczej.

Nie ma tej ekscytacji, gdy po wielu godzinach znajdziemy i naprawimy buga.

Nie ma tych wielu godzin spędzonych na myśleniu jak daną rzecz rozwiązać.

Nie ma takich sytuacji, gdy nagle wpadamy na rozwiązanie i to rozwiązanie okazuje się właściwe.

Pamiętam, jak wiele lat temu, pracowałem nad pewnym problemem, myśląc o nim cały dzień, ale bez sukcesu. Kładąc się spać pomyślałem, “ok wrócę do tego jutro”, a w środku nocy rozwiązanie po prostu mi się przyśniło. Wstałem, podszedłem do biurka, zapisałem kilka zdań na kartce, żeby do rana tego nie zapomnieć i wróciłem do łóżka. Rano spojrzałem na notatki i tak, to było poprawne rozwiązanie.

A więc jak najbardziej można być smutnym, że w dużym stopniu to się skończyło.

Ale w tym momencie warto przypomnieć sobie słowa DHH, który w trakcie konferencji podczas Rails World powiedział bardzo mądre słowa:

We had a wonderful run. And that’s it over.

But on the other side of that is another career, an exciting career.

Czyli:

Przeżyliśmy niesamowitą przygodę. I to się skończyło. Ale po drugiej stronie czeka na nas nowa kariera, ekscytująca kariera.

I tak powinniśmy do tego podchodzić.

Nie ze smutkiem, ale z ciekawością. Z ekscytacją na to, co dopiero się zaczyna.

Bo czy nie to, co dzisiaj jest możliwe, było celem od samego początku?

Jasne, pisanie kodu jest wspaniałym doświadczeniem, ale to tylko środek do osiągnięcia celu, jakim jest budowanie działających rozwiązań. A dzisiaj możemy budować więcej, szybciej. Możemy eksplorować ścieżki, na które wcześniej nie było czasu. Te wszystkie pomysły, które od zawsze mieliśmy w głowie, ale nie było realnej możliwości, żeby je zrealizować, teraz stoją przed nami otworem.

Do tej pory musieliśmy wybierać.

Zastanawiać się, czy warto daną rzecz robić. Czy mamy na to czas, pieniądze, czy nie ma czegoś, co jednak jest ważniejsze. Dzisiaj sporo z tych dylematów przestało istnieć. Możemy bawić się tworzeniem, próbować i eksperymentować na skalę, która wcześniej była poza zasięgiem naszych możliwości.

Ale czy kształtowanie rozwiązania za pomocą rozmowy z AI w języku naturalnym sprawia, że rola programisty się dewaluuje? Czy tworząc w ten sposób jesteśmy jakby mniej programistami? W tym momencie przypomnę moją ulubioną definicję programowania, ukutą przez twórcę Linuxa, Linusa Torvaldsa.

Powiedział on, że programowanie to mówienie komputerowi, co ma robić.

Uwielbiam tę definicję. W przeszłości mówiłem o niej wielokrotnie, twierdząc, że jest to absolutnie najlepsza i najprostsza definicja, jaką możemy stworzyć. Bo tak, dokładnie tym jest programowanie - mówieniem, co komputer ma robić.

I w czasach AI ta definicja wciąż pozostaje aktualna.

Nie ma znaczenia, w jaki sposób mówimy komputerowi, co ma robić. Czy jest to assembler, czy język wysokiego poziomu jak Java czy Python, czy jest to język naturalny - polski, angielski lub jakikolwiek inny.

Dopóki dajemy komputerowi instrukcję, a komputer tę instrukcję wykonuje, to tak, jest to programowanie.

Ale to prowadzi do pytania: skoro piszemy mniej kodu lub w ogóle go nie piszemy, za co faktycznie odpowiada współczesny programista?

Najprostsza odpowiedź brzmi: za stworzenie działającego, spełniającego zdefiniowane wymagania, rozwiązania. I właśnie na to należy położyć dzisiaj największy nacisk: na określanie tego, jaki problem chcemy rozwiązać oraz określanie, jak chcemy to zrobić.

Wbrew pozorom to nie są tak oczywiste kwestie. Osoby, które pracowały w branży IT znają to doskonale, ale osoby bez tego doświadczenia często są zaskoczone, na jak wiele pytań trzeba sobie odpowiedzieć przy tworzeniu nawet prostych aplikacji.

Jakiś czas temu tworzyłem aplikację do tworzenia shortów z dłuższych materiałów wideo. Teoretycznie prosta rzecz: wrzuć film, zrób jego transkrypcję, wyślij tę transkrypcję do modelu AI, poczekaj aż model AI przeanalizuje treść, wybierze najlepsze fragmenty i wróci z odpowiedzią - z proponowanymi fragmentami wraz ze znacznikami czasu, tak aby nasze narzędzie mogło te fragmenty powycinać z oryginalnego filmu.

A oto pytania, które pojawiły się, zanim jeszcze w projekcie powstała pierwsza linia kodu:

Czy short może składać się z kilku fragmentów materiału źródłowego?

Co oznacza lokalna transkrypcja? Jaki model ma za nią odpowiadać?

Jak generujemy shorty? Czy wybieramy zawsze środek kadru czy śledzimy twarz?

Jakie pliki wejściowe obsługujemy?

W jaki sposób generujemy napisy do powstałych shortów?

Czy użytkownik może ręcznie zmieniać granice zaproponowanego shorta?

Czy jeden fragment filmu może być częścią kilku różnych shortów?

Jak ciąć na poziomie pojedynczych słów, tak aby nie urywać głosek?

Czy usuwać momenty ciszy i dźwięki takie jak yyy, eee, itd,?

A to tylko kilka pytań z długiej rozmowy na temat tego, jak aplikacja ma działać.

Rozmowy, którą nota bene prowadziłem ze sztuczną inteligencją.

I to jest technika, którą bardzo mocno polecam. Odwrócenie ról, czyli scenariusz, w którym to AI pyta Ciebie, pozwala nie tylko na doprecyzowanie założeń, ale także na odkrycie i przemyślenie zagadnień, które w ogóle nie przyszły nam do głowy. Podczas pracy nad projektem jest to szczególnie istotne i jest to krok, którego nie możemy pomijać, zarówno na etapie projektowania całego systemu, jak i implementowania poszczególnych funkcjonalności.

Jeśli chcesz przejść przez taki proces tworząc własną aplikację - od doprecyzowania pomysłu, przez planowanie, aż po budowanie z AI - zrobisz to z moim kursem „Aplikacja z AI w jeden weekend”:

→ Zobacz szczegóły kursu ←

Od niepamiętnych czasów w programistycznym świecie krąży humorystyczna grafika przedstawiająca to, co klient opisał, to co lider projektu zrozumiał, to co analityk zaprojektował, to co programista stworzył i to, czego klient faktycznie potrzebował. Oczywiście każdy obrazek na grafice przedstawia coś zupełnie innego.

I wydaje się, że na obecną chwilę w tym właśnie tkwi największa siła człowieka, który w tym aspekcie wciąż jeszcze przewyższa maszynę. Człowiek ma doświadczenie, człowiek ma świadomość konsekwencji podejmowanych decyzji i człowiek potrafi też operować w warunkach braku informacji.

W przeciwieństwie do dużych modeli językowych, które w stu procentach opierają się o matematykę i jeżeli matematycznie dana odpowiedź jest najbardziej prawdopodobna, model niekoniecznie musi rozważać alternatywy i zadawać sobie dodatkowe pytania, dotyczące konsekwencji podejmowanych działań. Dlatego cały czas zdarzają się wpadki, polegające na tym, że na przykład agent AI skasował wszystkie pliki z dysku. A zrobił to, bo matematycznie wyszło mu, że to najlepsze możliwe rozwiązanie.

Człowiek jednak, nawet bez doświadczenia i bez wiedzy technicznej, w takiej sytuacji zadałby sobie pytanie: czy ja faktycznie chcę wszystko usunąć? Czy to nie jest coś podejrzanego i potencjalnie niebezpiecznego?

Ale oczywiście narzędzia AI projektowane są w taki sposób, żeby takie pytania również sobie zadawały i tych wpadek jest coraz mniej. Jeżeli coś jest niejasne, to dzisiaj model zdecydowanie częściej o to dopyta i doprecyzuje, zanim podejmie działanie.

Dlatego też przewagę człowieka w aspekcie definiowania wymagań i odgadywania potrzeb klienta ograniczam do chwili obecnej. Być może za jakiś czas i to będziemy mogli oddać w stu procentach maszynie. Potrafię sobie wyobrazić coraz bardziej złożone, wieloagentowe systemy, które zbierają wymagania, doprecyzowują je, projektują architekturę, implementują, testują, zbierają feedback, wprowadzają poprawki i robią to tak długo, aż projekt spełni wszystkie oczekiwania.

Zwłaszcza że już dzisiaj w dużym stopniu możemy tak pracować.

To prowadzi nas do kolejnych bardzo ważnych pytań.

Czy to oznacza, że programista przestaje być potrzebny czy tylko zmienia się jego rola?

Jeżeli zmienia się jego rola, to jak ta rola będzie wyglądać w przyszłości?

I absolutnie kluczowe: czego się uczyć, w co inwestować swój czas oraz na jakich zagadnieniach i umiejętnościach się skupiać, tak aby mieć pewność, że za kilka lat to wszystko będzie dalej aktualne?

Teraz powiem coś, co może być dla wielu osób szokujące i stresujące:

Nie możemy mieć żadnej pewności.

Świat zmienia się w takim tempie, że nie ma sensu starać się przewidzieć, co będzie za pięć, dziesięć czy piętnaście lat.

Jeżeli czegoś możemy być pewni, to tylko tego, że czeka nas bardzo dużo nauki, a nasza rola będzie się nieustannie zmieniać.

Dlatego zamiast myśleć zbyt dużo o przyszłości, o tym, jak będzie wyglądać rynek za kilka lat i czy będzie na nim praca dla programistów, analityków, testerów i wszystkich innych z branży IT i jakichkolwiek innych branż, lepiej jest się skupić na tym, co tu i teraz. Bo jeżeli dzisiaj nauczysz się rozwiązywać problemy z wykorzystaniem dzisiejszych narzędzi, to gwarantuję Ci, że za pięć lat, gdy pojawią się zupełnie inne narzędzia, będzie Ci się ich dużo łatwiej nauczyć niż osobie, która zacznie dopiero wtedy.

Nawet jeżeli narzędzia, z których korzystamy odchodzą do lamusa, to doświadczenie, które w ten sposób zdobywamy, nie traci na znaczeniu. Chcę, żeby to bardzo mocno wybrzmiało, bo wiem, że dzisiaj sporo osób ma wątpliwości i czuje swego rodzaju rozgoryczenie - uczyłem się programowania tyle lat, poznawałem przez lata dziesiątki technologii, a dzisiaj taki sam projekt może stworzyć osoba bez żadnego doświadczenia, która odpali Claude’a lub ChatGPT.

Czy w takim razie to wszystko, co przez te lata zrobiłem, nie ma finalnie żadnego znaczenia?

Ale to nieprawda, bo to doświadczenie ma ogromne znaczenie. To, czego przez ten czas się nauczyłeś, możesz przenieść na zupełnie inne obszary i pracować z AI jeszcze wydajniej, ucząc się i odkrywając nowe dla Ciebie rzeczy. I będziesz to robić szybciej i sprawniej niż osoba, która przygodę z technologią zaczyna dopiero dzisiaj.

A jeżeli to Ty jesteś osobą, która właśnie teraz zaczyna swoją przygodę z technologią i tworzeniem projektów z AI, na czym się skupić?

Czego się uczyć i w co inwestować najwięcej czasu?

Wiele zależy od tego, jaki jest Twój cel.

Jeżeli chcesz budować aplikacje dla siebie, na własny użytek albo do usprawnienia działania Twojej firmy, jest duża szansa, że nie będziesz musiał uczyć się programowania. Sztuczna inteligencja powinna zbudować działające rozwiązanie zgodnie z Twoimi instrukcjami, a tam gdzie będzie potrzeba podjęcia decyzji zahaczających o technologię, wystarczy, że poprosisz AI o wytłumaczenie nowych zagadnień w prostych słowach.

W takiej sytuacji kurs "Aplikacja z AI w jeden weekend" to idealny wybór na start: Przechodzę do strony kursu

Jeżeli jednak myślisz o wejściu do branży IT to tutaj tak naprawdę niewiele się zmienia. Budując duży, komercyjny projekt z AI, wciąż warto wiedzieć, co robimy. Tak więc chcąc pracować w IT, te teoretyczne podstawy i doświadczenie w tworzeniu kodu w tradycyjny sposób wciąż są ważne i wciąż będziesz o to pytany podczas rozmów kwalifikacyjnych, nawet jeżeli później w pracy większość kodu lub całość będzie za Ciebie pisać AI.

To trochę jak z umiejętnością liczenia. Mamy przecież kalkulatory, więc teoretycznie nie musielibyśmy uczyć się arytmetyki na kartce. A jednak to robimy, bo to daje nam solidne podstawy, dzięki którym możemy rozwiązywać trudniejsze rzeczy.

Jeżeli chcesz rozpocząć naukę programowania, przygotowałem bezpłatny Starter Programisty. Znajdziesz go na starterprogramisty.pl.

Ale czy tak samo będzie to wyglądać za pięć lat?

Czy za pięć lat znajomość kodu wciąż będzie wymagana i sprawdzana podczas rozmów kwalifikacyjnych czy może będzie tak jak sugeruje Andrej Karpathy - że głównym wymaganiem będzie stworzenie rozbudowanego systemu od A do Z, ale bez konieczności głębokiego rozumienia każdego jego elementu?

Dzisiaj przecież też nikt z nas nie zagłębia się w kod maszynowy czy nawet assembler, bo ufamy, że kompilator wykonuje właściwie swoją pracę. I jasne, kompilatory w odróżnieniu od dużych modeli językowych są deterministyczne, o czym sam wielokrotnie mówiłem, ale czy ten brak determinizmu na poziomie odpowiedzi od AI jest faktycznie istotny?

Gdy mamy zdefiniowane wymagania, wiemy jak dana funkcjonalność ma działać i mamy wszystko dokładnie rozpisane, to liczy się przede wszystkim to, czy dany fragment kodu faktycznie działa zgodnie z oczekiwaniami. A przecież nigdy nie ma jednego właściwego rozwiązania.

Mając zespół programistów i zlecając im to samo zadanie do wykonania, otrzymasz kilka różnych rozwiązań, tak więc tutaj też nie możemy w żaden sposób mówić o determinizmie.

To teraz po prostu zamieńmy zespół programistów na zespół agentów AI.

Czy w takim razie warto się tego kodowania uczyć czy nie? Czy może należy zostawić te wszystkie języki programowania i skupić się tylko na budowaniu z Claude Codem i Codexem?

Ja mówię: rób jedno i drugie.

Przynajmniej na obecną chwilę znajomość wybranego języka programowania jest niezbędna, żeby wejść do IT na stanowisko programisty. A czy będzie niezbędna za pięć lat, to nie ma najmniejszego znaczenia. Zaczniesz teraz od Pythona lub Javy lub jakiegokolwiek innego języka i na bieżąco będziesz się uczyć tego, co potrzebne.

W trakcie Twojej drogi narzędzia będą się zmieniać. Część będzie odchodzić, a na ich miejsce będą pojawiać się nowe. Dlatego nie ma sensu bawić się w hazard i obstawiać, co będzie na topie za pięć lat, bo z dzisiejszego punktu widzenia jest to po prostu nieistotne.

Liczy się to, co jest tu i teraz. Cała reszta przyjdzie w trakcie.

Z jednej strony ucz się wybranego języka programowania, w nim pogłębiaj wiedzę, a z drugiej strony wykorzystuj sztuczną inteligencję do tego, by na własną rękę budować duże projekty, bo to też wiele Cię nauczy. Nawet jeżeli to AI wykona za Ciebie większość pracy i nie staniesz się ekspertem w żadnej z wykorzystanych w projekcie technologii, to i tak wiele się nauczysz i zrozumiesz projekt na zupełnie innym poziomie. Na poziomie architektury, na poziomie powiązań pomiędzy poszczególnymi komponentami całości. I siłą rzeczy, nawet jeżeli nie będziesz się w nie zagłębiać, poznasz zupełnie nowe zagadnienia.

Dlatego wykorzystaj dzisiejsze możliwości i buduj własne rozwiązania, bo to pozwoli Ci być o krok przed innymi.

W tym temacie polecam Ci mój kurs Aplikacja z AI w jeden weekend.

I podtrzymuję to, co powtarzam konsekwentnie od kilku lat: sztuczna inteligencja nie zabierze pracy w IT. Tak, zmieni tę pracę, co już się dzieje, ale jeżeli chodzi o zapotrzebowanie na specjalistów, to będzie ono coraz większe. Tutaj naturalnie pojawia się pytanie: Ale jak to? Skoro dzisiaj programista może pracować pięć razy szybciej, to potrzebnych będzie pięć razy mniej programistów.

Ale spójrzmy, czym już teraz zaowocowało łatwiejsze wytwarzanie kodu. Jak wiele osób tworzy własne aplikacje, jak wiele osób realizuje swoje pomysły, które latami czekały na lepszy moment. To samo dzieje się na poziomie firm. Projekty, które jeszcze niedawno nie miałyby uzasadnienia biznesowego, bo byłyby za długie, zbyt ryzykowne i niekoniecznie potrzebne już tu i teraz, nagle są realizowane jeden po drugim. A to otwiera nowe drogi i nowe możliwości, prowadzące do kolejnych projektów. A kolejne projekty to potrzeba zatrudniania kolejnych osób.

Nie jest to nowe zjawisko w historii świata. To, co obserwujemy, to paradoks Jevonsa, który polega na tym, że jeżeli jakiś zasób tanieje, to zapotrzebowanie na niego rośnie lawinowo. Tak więc programista może pracować pięć razy szybciej, ale to nie oznacza, że pracy będzie pięć razy mniej. Bo pięć razy szybsza praca programisty oznacza dziesięć, piętnaście, dwadzieścia razy więcej projektów, a tym samym zdecydowanie więcej zapotrzebowania na specjalistów, którzy będą te projekty, wraz ze sztuczną inteligencją, rozwijać.

Wróćmy jeszcze na moment do tego porównania z końmi i samochodami.

Gdybyśmy cały czas jeździli konno, mielibyśmy więcej jeźdźców, ale czy w branży transportowej byłoby więcej pracy? Nic z tych rzeczy. Transport mógł się rozwinąć, bo przemieszczanie stało się szybsze i bardziej dostępne.

Dokładnie tak samo powinniśmy myśleć o transformacji, która dokonuje się w branży IT.

Tworzenie kodu stało się szybsze i bardziej dostępne, a to oznacza, że będzie go powstawać coraz więcej.

To z kolei oznacza, że pracy również będzie coraz więcej.

A to co się dzieje teraz, to dopiero początek. Kolejna złota era software engineeringu jest jeszcze przed nami.