Resilience w erze AI. Jak zostać developerem, którego nie zastąpi model - notatki prelegenta - CyberShu

To notatki do mojego wystąpienia na Confiturze 2026. Wystąpiłem w piątek, 25 września 2026 r. o godz. 14:30.

Pytanie z tytułu jest prowokacją ;) Nie znam sposobu na zagwarantowanie zatrudnienia na godnych i słusznych warunkach, ale wiem ze można zwiększać liczbę dostępnych opcji i szybciej reagować na zmianę.

Przez resilience rozumiem zdolność do realizowania celów, gdy zmieniają się warunki. W pracy developera oznacza to regularne sprawdzanie, gdzie powstaje wartość i które umiejętności warto rozwijać.

Prezentacja

PDF: prezentacja

Ankieta

Ten formularz obsługuje Tally. Wczytanie połączy Cię z usługą zewnętrzną.

Otwórz bezpośrednio w Tally ↗

Rynek i produktywność z AI

Zmiany na rynku pracy zaczęły się przed upowszechnieniem generatywnego AI. Samo pytanie „czy AI zastąpi developerów?” niewiele pomaga w podjęciu decyzji zawodowej. Ważniejsze jest to, jakie zadania się zmieniają, w jakim środowisku i z jakim kosztem błędu.

Wyniki badań nad produktywnością developerów różnią się, bo dotyczą innych zadań i sposobów pomiaru. Zadanie o jasnych granicach i szybkim teście poprawności nie przypomina utrzymania systemu z długą historią oraz ukrytymi ograniczeniami biznesowymi.

Wartość wykracza poza kod

Model może przyspieszyć implementację, ale nadal trzeba zdefiniować problem, sprawdzić wynik, zintegrować zmianę i odpowiadać za jej działanie. Gdy kodu powstaje więcej, review i weryfikacja mogą stać się nowym wąskim gardłem.

Delegowanie pracy agentowi wymaga określenia granic zadania, przekazania kontekstu oraz ustalenia kryteriów akceptacji. Przydaje się wiedza domenowa: bez zrozumienia problemu trudno ocenić pozornie poprawne rozwiązanie.

Nauka i portfel kompetencji

Rozróżniam dwa tryby pracy z AI. W trybie produkcji liczy się wynik, czas i ryzyko. W trybie nauki potrzebny jest także wysiłek, który buduje własne zrozumienie. AI może wtedy zadawać pytania i pomagać sprawdzić tok rozumowania, zamiast od razu podawać gotową odpowiedź.

Warto przyjrzeć się swoim zadaniom: które AI może przejąć, w których pomaga, a gdzie potrzebne są znajomość domeny, projektowanie granic systemu, weryfikacja i odpowiedzialność za decyzje. Kodowanie pozostaje potrzebne, między innymi po to, żeby umieć sprawdzić rezultat.

Career OODA

Proponuję regularnie wracać do czterech kroków: Observe - zbieranie sygnałów z pracy i rynku; Orient - interpretacja ich znaczenia dla własnych umiejętności i celów; Decide - wybór hipotezy rozwojowej; Act - wykonanie małego eksperymentu i zapisanie wyniku.

Przykład: przez cztery tygodnie przejąć odpowiedzialność za jeden problem, od rozpoznania potrzeby do oceny efektu na produkcji. Działania obejmują doprecyzowanie wymagań, ustalenie kryteriów akceptacji, oddelegowanie części implementacji AI i sprawdzenie rezultatu. Potem pętla wraca do obserwacji.

Do zapisania takiego eksperymentu wystarczy prosty work log: plan na dzień, osiągnięty rezultat, nowa wiedza i napotkane blokady. Po tygodniu warto przejrzeć zapisy. Szerzej opisałem ten sposób pracy we wpisie o work logu.