Streszczenie: W kolejnym odcinku cyklu „Limity AI” Iwo Zmyślony rozmawia z Tomaszem Ducinem o tym, co dzieje się tam, gdzie hype wokół sztucznej inteligencji zderza się z codzienną pracą inżynierów oprogramowania. Punktem wyjścia jest teza, że technologia niczego nie obiecuje sama z siebie — obietnice składają ludzie, a konsekwencje ponoszą firmy. Stąd najgroźniejszy mit nie dotyczy konkretnej funkcji, lecz postawy: ucieczki od niuansów i delegowania maszynie samego procesu decyzyjnego.
Branża IT uwierzyła w obietnicę autonomii. Tymczasem za każdą decyzją modelu wciąż stoi człowiek — albo jej brak. Tomasz Ducin, software generalist i współautor programu „Developer Jutra”, tłumaczy, dlaczego architektura jest dziś potrzebna bardziej niż kiedykolwiek, gdzie kryją się realne ryzyka biznesowe sztucznej inteligencji i kto przetrwa nadchodzącą rekalibrację rynku pracy.
W cyklu „Limity AI” konsekwentnie oddzielamy fakt od marketingowego szumu. Tym razem rozmawiamy o miejscu, w którym hype zderza się z rzeczywistością najtwardziej — w codziennej pracy inżynierów oprogramowania. Naszym gościem jest Tomasz Ducin: od ponad dwóch dekad praktyk, lider zespołów programistycznych i trener, przez którego ręce przewinęły się tysiące uczestników kursów. Laureat nagrody Microsoft MVP, twórca systemów korporacyjnych i projektów startupowych, a wraz z Maciejem Aniserowiczem współautor programu „Developer Jutra”, który ukończyło już ponad dwa tysiące absolwentów pierwszej edycji.
Iwo Zmyślony: Jakie najbardziej szkodliwe bzdury na temat AI spotykasz najczęściej?
Tomasz Ducin: Najgroźniejsze jest zniechęcanie ludzi do wchodzenia w niuanse. Rzucanie szybkich, łatwostrawnych odpowiedzi. Patrzenie zero-jedynkowe: albo czarne, albo białe. To drastyczne upraszczanie jest fundamentem większości szkodliwych narracji.
Jeśli mam wskazać konkret, to autonomia modeli i agentów. Mówi się o niej tak, jakby AI robiło coś samodzielnie, bez udziału człowieka. To nieprawda. Zawsze — pośrednio albo bezpośrednio — stoi za tym projekt człowieka, system człowieka albo intencja człowieka. Technologicznie pojawia się żądanie, na które dopiero przychodzi odpowiedź. A nawet jeśli żądanie wysyła agent, to gdy odpowiednio podłubiemy, u źródła znajdziemy człowieka.
Z tego mitu wynika konkretna pokusa.
Najgorsza jest delegowanie do agentów decyzji projektowych i architektonicznych. A tym, co boli mnie najbardziej, jest delegowanie samego procesu decyzyjnego — delegowanie myślenia. To źródło problemu, który sprowadzi na Ciebie konsekwencje. I to Ty będziesz za nie odpowiadać, nie model.
Ekonomia, która musi się domknąć
Niedawno „wybuchł” temat pricingu. Dla części rynku to było zaskoczenie.
Dla części — owszem. Dla innych był to fakt znany od dawna. Subsydia szły bardzo szerokim strumieniem. Niewiadomą nie było czy cenniki wzrosną, lecz kiedy i o ile.
Doprecyzujmy stan na kwiecień 2026 roku. Pierwszym dostawcą, który ma planowo wyjść na zero, będzie Anthropic — w perspektywie około dwóch lat. Pod warunkiem, że nie pojawi się żaden „czarny łabędź”: kolejna pandemia, wojna, cokolwiek, czego nie da się przewidzieć. Dziś dostawcy wciąż przepalają budżety swoich inwestorów.
Czyli taniej już było.
Tak to widzę. Choć dla równowagi trzeba dodać drugą siłę. Działa prawo Moore’a — hardware będzie coraz tańszy i coraz wydajniejszy, firmy pokroju Nvidii inwestują w tańszą produkcję. Mamy więc układ dwóch przeciwstawnych sił. Z jednej strony dostawcy będą musieli podnosić cenniki, bo kurczy się finansowanie. Z drugiej — rozwój technologii pcha koszt sprzętu w dół. Której siła przeważy i w którym momencie, tego nie przewidzimy w precyzyjnych liczbach. Dochodzą jeszcze czynniki spoza tej układanki: dostępność surowców czy realna żywotność procesorów, która bywa krótsza od pierwotnych założeń.
Co z tego wynika dla praktyka?
Prosta reguła kciuka: nigdy nie chodziło o to, by zrzucać na agentów jak najwięcej. Im bardziej abstrakcyjne zadanie delegujesz, tym większe zużycie tokenów. A skoro nie wiemy, ile token będzie kosztował i jakiej będzie jakości, celem nie jest maksymalizacja zużycia, lecz szukanie złotego środka — najlepszego przełożenia tokenów na realnie wykonaną robotę. Ten punkt się przesuwa, bo modele się zmieniają. Dopóki tokeny były „tanie jak barszcz”, nic nie zmuszało ludzi do myślenia o ich ekonomii. Teraz to, co dla świadomych było oczywiste, staje się jawne dla wszystkich.
Concorde kontra rower
Mówisz o „gargantuicznych” modelach niemal z niechęcią.
Bo w długiej perspektywie one nie bardzo mają sens. Widzę znacznie bardziej zrównoważoną, sustainable przyszłość w modelach małych, lokalnych i wyspecjalizowanych. Świat nie kończy się na trzech czy czterech wielkich, chmurowych dostawcach. Istnieje cały ekosystem modeli otwartych.
Posłużę się analogią Karen Hao, do której wracamy w tej serii. Dziś mamy przerośnięte konstrukcje — trochę jak Concorde. Projekt efekciarski, technologiczna utopia, która biznesowo nigdy się nie spinała. A przecież czasem nie potrzebujesz odrzutowca. Potrzebujesz roweru, żeby gdzieś dojechać.
Do tego dochodzi koszt środowiskowy: woda, energia, surowce.
To realny składnik rachunku. I jest jeszcze błąd kolejności, który widać na rynku: „wdrożyliśmy AI, a teraz zastanowimy się, jaki będzie biznesowy use case”. Każdy, kto ma głowę na karku, widzi, że kolejność powinna być odwrotna. Najpierw pytanie, jak AI wpisuje się w nasz konkretny przypadek biznesowy.
Ryzyka jednostkowe: kiedy uproszczenie staje się decyzją
Jakie zagrożenia widzisz dziś najwyraźniej?
Dzielę je na jednostkowe i społeczne. Jednostkowe polega na tym, że ktoś — nie rozumiejąc technologii — łyknie uproszczenie i podejmie złą decyzję, której skutki ujawnią się dopiero w czasie. Potem szuka winnych: narracji, autora narracji, świata, przypadkowo spotkanej osoby.
To realny problem. Dezinformacja buduje fałszywe przekonania o możliwościach modeli. Ludzie na tej podstawie wydają pieniądze i podejmują ryzyko biznesowe, a później są sfrustrowani, bo technologia nie dowozi obietnic. Ograniczenia technologii to jedna rzecz. Bajki, które nie wytrzymują zderzenia z rzeczywistością — druga.
Masz przykład takiej „bajki”?
Autonomizowanie wszystkiego. Powstają narzędzia do budowy autonomicznych agentów, które przepalają gigantyczne ilości tokenów, a w 99 procentach przypadków służą do tego, by agent „pogadał” na Slacku czy Discordzie. Fajna zabawka. Tylko jaki problem to rozwiązuje? Jaką wartość biznesową niesie? W szerokim przekazie brakuje właśnie tego pytania o uzasadnienie. Nie jestem przeciwnikiem eksperymentowania — jestem przeciwnikiem ekscytacji bez sensu.
A wyciek samego pomysłu?
To pole ryzyka jest szersze, niż się sądzi. Nie chodzi tylko o relację użytkownik–dostawca, ale też użytkownik–użytkownik. Kiedyś, gdy startup miał dobry pomysł, budował MVP i musiał o nim mówić, żeby zdobyć klientów. Dziś, dysponując narzędziami do kodowania z AI, konkurent jest w stanie odtworzyć rdzeń takiego produktu niemal w weekend. Patrzysz na sam pomysł, robisz reverse engineering tego, co siedzi pod spodem, i odbudowujesz.
Wiele produktów, które do tej pory były płatne w modelu SaaS, można dziś „odklikać” w godzinę czy dwie — wersję uboższą, ale działającą. A że programiści lubią chwalić się dokonaniami, prędzej czy później ktoś wrzuci to na GitHub jako narzędzie open source. Biznes, który dotąd się spinał, może po prostu stracić rację bytu. Część produktów czeka po prostu anihilacja.
Ryzyka społeczne: zawłaszczony łańcuch wartości
Przejdźmy do poziomu społecznego.
Najmocniej przejmuje mnie łamanie praw własności intelektualnej i brak transparentności co do danych treningowych. Anthropic miał już z tego tytułu sprawę sądową. Problem polega na tym, że dostawca zawsze zasłoni się tajemnicą technologiczną — bo dobór danych, ich proporcje i oczekiwane odpowiedzi to faktycznie know-how data science. W efekcie wielkie modele karmią się danymi praktycznie nieweryfikowalnymi.
Pozytywnym kontrapunktem jest otwarta społeczność modeli i danych — tu liderem jest Hugging Face. To firma, która też chce zarabiać, choćby na hostingu, ale dzięki niej widzisz, na czym model był trenowany. To moim zdaniem kierunek zrównoważony. Bez niego dochodzi do swoistej oligarchizacji danych, a złamanie IP ma realne konsekwencje społeczne.
Krytycy — Kate Crawford, Karen Hao, Sylwia Czubkowska — nazywają to wprost strategią kolonialną. Korporacje zawłaszczają dane, które społeczność programistyczna latami tworzyła w duchu dzielenia się.
Spójrzmy na to przez łańcuchy wartości. Stary łańcuch — ten sprzed AI, w którym kod powstawał ręcznie — wciąż istnieje, ale gwałtownie traci na znaczeniu. Nie jest dokładnie tak, że dane zostały zawłaszczone w nim. Powstał nowy łańcuch wartości, i to on jest już zawłaszczony przez twórców modeli. Kod nie został przejęty wprost — został przetworzony w trakcie treningu i zaszyty w zdolności modelu do generowania nowego kodu. To dlatego całość jest tak śliska.
Profesor Dragan odpowiedziałby, że Ty też uczyłeś się, podpatrując cudzy kod i dokumentację.
Lubię patrzeć na rzeczy jak na system: przyczyny, kontekst, konsekwencje. Owszem, miliony programistów takich jak ja czytały cudzy kod. Ale nawet gdybym założył firmę, istniała ogromna przeciwwaga dla mnie i moich pomysłów. Ryzyko, którego wcześniej nie było, pojawia się dziś: trzy firmy — plus na szczęście rosnąca część otwarta — zawładnęły całym łańcuchem dostaw. To nie był monopol na wiedzę o programowaniu. To monopol na zdolność jej egzekwowania.
Widać to namacalnie, gdy model bywa chwilowo niedostępny. Przy awariach trwających godzinami przez branżę przechodzi fala bezradności — ludzie nie wiedzą, czy wracać do „kodowania jak zwierzę”, czy czekać. To pokazuje, jak głęboka stała się ta zależność.
Trucizną jest dawka: podatności w kodzie
Profesor Piotr Górka zwraca uwagę, że w repozytoriach, na których trenowano modele, były nie tylko fragmenty słabej jakości, ale i celowo wstrzykiwane podatności. Czy inżynier dopuszczający kod do produkcji może ich nie zauważyć?
Zacznę od angielskiego powiedzenia, które warto przetłumaczyć precyzyjnie: to nie substancja czyni truciznę, lecz dawka. W odpowiednio małej ilości nawet trucizna nie zabije. W nadmiarze zabójcza staje się nawet woda.
Branża IT jest gigantyczna i rozproszona — miliony specjalistów, brak jednego punktu, w którym dałoby się narzucić reguły kontroli. Czy będą wielcy dostawcy, czy tylko małe modele otwarte, czy w ogóle nie byłoby AI — kwestia hakerów i wstrzykiwanych podatności jest praktycznie nie do wyeliminowania. To impreza, z którą będziemy się borykać tak długo, jak istnieje oprogramowanie. Dostawca powinien kierować się regułą skauta: staraj się nie czynić świata oprogramowania gorszym, niż go zastałeś. Ale przy skali danych treningowych zero podatności jest nieosiągalne.
Czyli ryzyka nie ma?
Ryzyko jest, i to duże. Przestrzegam tylko przed sformułowaniem „zawsze będzie źle” — albo jego odwrotnością. Tu zawsze są niuanse. Realne ryzyko polega na tym, że model wygeneruje ścianę kodu, a człowiek, który nie drąży, poprzestanie na satysfakcji, że „robota jest wykonana”.
Co do „jakości kodu” — to ekstremalnie trudne do zmierzenia. Gdzie dziesięciu programistów, tam jedenaście opinii. Człowiek z trzyletnim doświadczeniem, który stawia pytania, może rozumieć temat głębiej niż ktoś, kto od dwudziestu lat odgrzewa te same kotlety. W otwartych repozytoriach jest mnóstwo kodu, który można nazwać tandetą, ale ocena zawsze jest kontekstowa. MVP zrobione tanio i szybko, które rozwiązuje problem klienta i działa stabilnie, bywa „złe” technologicznie, a jednocześnie w pełni adekwatne biznesowo.
System drugi pod presją
Wraca ryzyko odmóżdżenia. Gdy przyzwyczajasz mózg do tego, że AI przyspiesza Twoje zadania, połączenia neuronalne uruchamiane przy wysiłku przestają być wzmacniane.
Tu zrobiłbym mocne rozgraniczenie. Sam pilnuję się ostro, żeby jak najwięcej myślenia i ważenia argumentów zostawało po mojej stronie — do decyzji projektowych i architektonicznych podchodzę z ogromną pokorą. Ale patrząc na nasz gatunek ewolucyjnie: mózg dąży do chodzenia na skróty, żeby przepalać jak najmniej glukozy. I będzie chodził na skróty, kiedy tylko będzie mógł. Wyłapanie momentu, w którym naprawdę można coś odpuścić, wymaga energii, dyscypliny i doświadczenia.
To jak kopanie szpadlem. Często nie ma znaczenia, pod jakim kątem wbijesz łopatę. Ale są miejsca, gdzie liczy się głębokość albo to, czy nie rozetniesz systemu korzeniowego rośliny. Doświadczenie pozwala odróżnić jedno od drugiego.
Tu kłania się Kahneman.
To idealny punkt odniesienia, a rzadko używam słowa „idealny”. Mózg ewolucyjnie dąży do systemu pierwszego — myślenia szybkiego, automatycznego. A pracując z AI, musimy masowo uruchamiać system drugi: powolny, wysiłkowy, krytyczny. To trudne i wymaga dyscypliny. Da się jednak podejść metodycznie: model wygenerował kod, ja robię krok wstecz i spokojnie ustalam, który element jest krytyczny do zrewidowania, a który mniej priorytetowy.
Jak mitygować zjawisko brain rot, skoro maszyna produkuje strugi kodu szybciej, niż człowiek je weryfikuje?
Skupiłbym się właśnie na tym, jak omijać minusy, a czerpać korzyści. To, że modele są gadatliwe i lizusowskie, wiemy. Ale one nie muszą takie być — są takie, bo tak je wytrenowano. Wpływ na to mają przede wszystkim dostawcy oraz ci, którzy współtworzą łańcuch — dofinetunowują czy trenują modele. Jako zwykli użytkownicy mamy go w ograniczonym zakresie: system prompt pozwala wymusić pewne zachowania, ale tylko częściowo.
Maszyna się nie przyznaje
Język, którym opisujemy modele, sam przesądza, jak je rozumiemy.
Mam świeży przykład. Agent dostał zbyt szeroki token — uprawnienia do pracy nad systemem chmurowym. „Zdecydował”, że usunie nie tylko bazę produkcyjną, ale cały wolumen razem z backupami. Wykasował wszystko. Ewidentny fuck up z wykrzyknikiem.
I tu zaczęła się dyskusja, w której część osób powoływała się na to, że „model przyznał się” do tego, co zrobił. Jeśli rozumiesz językową naturę tej technologii, wiesz, że nie ma tu żadnego przyznania. Przyznanie się zakłada wolę, świadomość, doświadczenie, pamięć, intencję. Po stronie modelu nie ma żadnej z tych rzeczy. Jest czysta statystyka na tekście — w gigantycznej skali.
Da się to pokazać technicznie?
Mogę spreparować rozmowę: user, assistant, user, assistant — w której „model” robi rzeczy absurdalne, na przykład każe zrobić kanapkę z gwoździami. Taką spreparowaną historię przekazuję przez API innemu modelowi do kontynuacji. On nie ma świadomości, że to nie jego tekst — bo znacząca większość modeli nie ma pamięci. Weźmie cudze słowa za swoje, bo tak działa ta architektura. „Przyznanie się” w kontekście LLM-a jest więc absurdem.
To język antropomorfizujący, systematycznie forsowany przez PR big techów.
Ostrzegali przed tym Emily Bender i Timnit Gebru pięć lat temu. Ale już Joseph Weizenbaum, twórca ELIZY z lat 60., pisał o tym wprost w latach 70. To niepokojąca skłonność człowieka — jak dostrzeganie twarzy w plamach na szybie. Nasz układ nerwowy widzi osobę i świadomość wszędzie tam, gdzie rozpoznaje cechy, które ewolucyjnie nauczył się traktować jako symptomy istoty.
Bywa gorzej. Psychologowie potwierdzają, że ludzie chętnie zdejmują z siebie odpowiedzialność. Paradoksalnie spora część programistów kurczowo trzyma się apokaliptycznej wizji „wszyscy stracimy pracę”. Bo jeśli wszystko jest przesądzone, jeśli to fatum, to nie trzeba już brać odpowiedzialności za siebie. Erich Fromm nazwał to ucieczką od wolności — dorosły człowiek chce znów być dzieckiem, które szuka winnych i rezygnuje ze sprawczości.
Architektura wraca do tablicy
Czym właściwie jest LLM?
Technicznie to zbiór gigantycznej liczby parametrów — paczka liczb — plus program, który ją ładuje i pozwala zadawać pytania. W treningu podajemy ogromny zestaw danych i oczekiwanych odpowiedzi, liczymy gradienty, robimy propagację wsteczną. Sednem jest rozpoznawanie wzorców i odpowiadanie zgodnie z nimi. Lubię myśleć, że w pewnym abstrakcyjnym ujęciu każda odpowiedź LLM-a jest halucynacją — większość statystycznie adekwatnych albo marginalnie problematycznych. Modele bywają mega użyteczne, ale miejmy z tyłu głowy ten pierwiastek błędności.
Gary Marcus mówi o kalkulatorze, który prawie nigdy się nie myli — z naciskiem na „prawie”.
Dokładnie. A jeśli się myli, to czasem w sytuacjach bez znaczenia. Punkt ciężkości jest jednak tam, gdzie pomyłka kosztuje.
Halucynacje są nieusuwalne, bo wynikają z architektury Transformer.
Z badania z 2017 roku. Architektura jest jasno opisana, jej ograniczenia zidentyfikowane. Halucynacje to jej nieodłączna cecha — profesor Karbowicz przeprowadził na to dowód matematyczny jeszcze przed publikacjami pracowników OpenAI. Część badaczy słusznie zauważa, że samo słowo „halucynacja” jest antropomorfizujące; trafniejsza bywa „konfabulacja”. By pójść krok dalej, potrzebujemy nowej architektury — i nie wiemy jeszcze, jak będzie wyglądała. Powstanie dopiero. Albo powstaną, bo będzie ich więcej niż jedna.
Tej architektury po prostu nie ma. Być może to ona okaże się słynnym AGI.
François Chollet utożsamił AGI z systemem drugim Kahnemana — ze zdolnością adaptacji w kontekście, uczenia się spoza modelu treningowego. Pisał o tym Gary Marcus już w 2019 roku, długo będąc w tej diagnozie osamotniony i szykanowany. W zeszłym roku dołączył do niej Richard Sutton, a w listopadzie Ilya Sutskever — współtwórca OpenAI — wprost powiedział, że architektura musi „wrócić do tablicy”. To, co powtarzaliśmy od lat, zostało przyklepane.
Wniosek brzmi twardo: na dziś nie ma technologii, która wyręczyłaby człowieka w pracy systemu drugiego. W modelu jest zero informacji o świecie pozajęzykowym — fizycznym i społecznym — a biznes stoi na wiedzy kontekstowej w jakichś 95 procentach.
Prawo Conwaya: czego model nie widzi
Czego LLM nie weźmie pod uwagę?
Nie potupta do project managera, żeby dopytać o priorytety czy specyfikę projektu. Nie ma doświadczenia w wieloletnim utrzymaniu systemów, więc nie myśli konsekwencjami — analizuje tekst i dopasowuje go do wzorców. A jest aspekt, który programistom regularnie umyka: prawo Conwaya, sformułowane przez Melvina Conwaya jeszcze w latach 60.
System informatyczny prędzej czy później odzwierciedli strukturę zespołów i hierarchię ludzi, którzy go tworzą. To siła niemal fizyczna — można z nią walczyć, ale nie da się jej wygrać. Jeśli księgowość i płatności obsługuje jedna „pani Basia” w jednym pokoju, te dwie domeny, choć merytorycznie osobne, w kodzie skleją się ze sobą. Rozwiązanie techniczne idealne dla jednego zespołu może pasować jak pięść do nosa przy pięciu zespołach.
A model ten aspekt ignoruje.
Ignoruje — bo nie ma świadomości ani intencji. Ignoruje też potrzeby klienta, za to uwzględnia specyfikę, która często występowała w danych treningowych. I znów wracamy do braku transparentności tych danych.
Rozróżnijmy przy tym decyzje techniczne i architektoniczne. Techniczna to wybór stylu implementacji. Architektoniczna potrafi unieważnić istnienie dużej części kodu. Jeśli postawisz złe fundamenty, ich późniejsza zmiana w stojącym już budynku jest inwazyjna i kosztowna. Dlatego architekt, który ma kontekst, proaktywnie go weryfikuje i naprowadza model, dostaje wzmacniacz: szybciej eksploruje, generuje i waliduje pomysły. To my musimy być pilotem. Model dostaje łopatę i macha nią na maksa.
Indyki i Święto Dziękczynienia
„Pytać programistów o AI to jak pytać indyki o Święto Dziękczynienia”. Czy AI wycina etaty?
Nie ma obserwowalnych zjawisk wskazujących, że AI wygasza konkretne etaty. Jest za to bardzo wygodną wymówką do redukcji „bo AI” — która przy okazji zmienia strukturę finansową firmy i buduje w inwestorach przekonanie o nowoczesności.
Praca programisty zmienia się jednak gwałtownie. Ktoś, kto utknął mentalnie w roku 2015, będzie się odnajdywał coraz trudniej. Sednem jest pytanie, na które wielu nie potrafi odpowiedzieć: za co właściwie płaci Ci pracodawca? Jaką wartość dostarczasz biznesowi? Programiści bywają kiepscy w myśleniu strategicznym i biznesowym, bo przez długi czas nikt tego od nich nie wymagał.
Bo był boom.
Krytykuję własną branżę, więc ktoś może się obrazić — trudno. Bardzo wiele osób dołączyło do IT, gdy za relatywnie proste rzeczy — przysłowiowe formularze w jakimś frameworku — płacono pięć razy tyle, co wynosiła średnia krajowa. Ssanie na rynku było ogromne jeszcze przed pandemią, a w jej trakcie przybrało rozmiary absurdalne. Problem w tym, że za „obsługę śrubokręta” będzie coraz trudniej kupić przysłowiowy chleb. Te kompetencje są po prostu tańsze, gdy użyjemy modelu. To fakt.
Obietnica Agile i DevOps wraca ze zdwojoną siłą
Wracasz do fundamentów zwinności.
Obietnica Agile’a brzmiała: przybliżmy development do biznesu, by w krótszych iteracjach dostarczać dokładniej i szybciej to, czego klient potrzebuje. Obietnica DevOps szła dalej — programista bierze pełną odpowiedzialność także za utrzymanie produkcji, a więc i za doświadczenie klienta. Obie sprowadzały się do tego samego: zbliżyć development do klienta.
Dziś AI stoi przed dokładnie tym samym wyzwaniem. Generowanie kodu jest tańsze — nawet gdyby dostawcy podnieśli ceny dziesięciokrotnie, wciąż byłoby o dwa, trzy rzędy wielkości tańsze niż człowiek. Ale kod to nie rozwiązanie. Skoro kod tanieje, naszą wartością staje się identyfikowanie okazji biznesowych, przybliżanie klienta do produktu i skracanie pętli feedbacku. Tymczasem nasz ekosystem branżowy jest do tego grubo niedostosowany — wciąż spotykam ludzi z „papierami na Agile”, którzy nie włączają kamerek na spotkaniach z klientem.
Manifest Agile mówił o tym w pierwszym punkcie.
Narzędzia i procesy są ważne. Ale jeśli nie chcesz interakcji i relacji z ludźmi, nie będziesz zwinny. Kropka. Bez tego nie wiesz nawet, czy Twój wysiłek jest ładowany we właściwym kierunku — możesz świetnie zrobić rzecz, która nie adresuje realnego problemu.
Spodziewam się, że AI development — jakikolwiek kształt przyjmie za trzy czy pięć lat — również wypaczymy. Mamy do tego skłonność: etykietujemy zespół jako „scrumowy” i uznajemy, że automagicznie jest zwinny. Jako branża zepsuliśmy już Agile i DevOps, bo łatwiej iść na skróty niż zmienić model mentalny, strategię i kulturę.
Kompetencje przyszłości stoją na motywacji
Mówimy o kompetencjach miękkich — choć odchodzimy od tej nazwy na rzecz poznawczych, emocjonalnych i społecznych.
Kluczowa jest ekspertyza domenowa: świadomość, o czym klient Ci nie powie, i na jakich niuansach rozbije się produkt. To zdolność zadawania pytań, aktywnego słuchania, radzenia sobie z dezorientacją i ciągłego uczenia się. Chciałbym tu pozytywnie zmotywować osoby techniczne: Wasza ekspertyza nie idzie do kosza. Do niedawna nasza zdolność tworzenia kodu była niezastępowalna. Dziś na rynku jest zdolność, która robi to szybciej i taniej. Musimy więc przekalibrować i odpowiedzieć: gdzie jest nasza wartość?
Tu wracamy do Kahnemana i pułapek myślenia.
Im dłużej byłeś skuteczny w wąskiej domenie, tym mocniej mózg kotwiczy Cię w starym myśleniu — i tym trudniej zauważyć zmianę. Lubię prosty model mentalny: czy bardziej cenisz pytania, czy odpowiedzi? Odpowiedzi się dezaktualizują, pytania pozostają otwarte. Książka „Kto zabrał mój ser?” jest tu trafną alegorią — schematy, które świetnie się sprawdzały, po czasie mogą zwietrzeć, więc warto regularnie „wąchać”, czy ser się nie zepsuł.
To się da wyćwiczyć — ale najpierw trzeba chcieć.
Nie ma korbki, która sprawi, że zaczniesz chcieć. To musi stać na motywacji. Kompetencji poznawczych i społecznych nie zbudujesz, odsłuchując webinar o krytycznym myśleniu czy empatii — to nie jest nauka kolejnego narzędzia, lecz budowanie postawy. A do tego potrzeba całego środowiska: roli przywództwa i organizacji pracy. To gra zespołowa. Dlatego właśnie Agile i DevOps tak często się nie udawały — nie da się ich wdrożyć jednym, drugim i trzecim szkoleniem, bez wsparcia strategicznego.
Od wyrobnika do partnera
Jaka jest najbardziej praktyczna rada?
Pomyśl, że biznesowi najwygodniej byłoby obdarzyć Cię odpowiedzialnością za pewien obszar — klienta, subdomenę, cokolwiek. Nie tak, że reaktywnie przyjmujesz strumień ticketów. Bierzesz ownership: biznes zrzuca dany obszar ze swojej głowy, a Tobie wyznacza kierunki i cele, niekiedy współtworząc z Tobą KPI. To fundamentalna różnica — przestajesz być wyrobnikiem, a stajesz się partnerem.
Pod warunkiem, że po drugiej stronie masz biznes gotowy dać Ci zaufanie i empowerment.
Oczywiście. Z niektórymi organizacjami będzie to łatwiejsze, z innymi trudniejsze, a z częścią — niewykonalne. Niektóre będą wręcz karać za taką postawę kulturowo. Dlatego warto sprawdzić, czy w Twojej organizacji jest przywództwo gotowe na ten rodzaj pracy. To naprawdę gra zespołowa.
Kuźnia mistrzów czy mainstream?
Jest taka szkoła fotografii w Pradze, gdzie przez całe studia obowiązuje zakaz technologii cyfrowej — wszystko analogowo, żeby nauczyć się widzieć i kalibrować oko. Czy ta analogia trafia w to, co dzieje się z kodowaniem?
To ogromna analogia — pytanie tylko, jak przetrwa zderzenie z biznesem. Taka szkoła jest kuźnią realnych guru swojego fachu, ale nigdy nie wyskaluje się do mainstreamu, bo wykształcenie takiej osoby jest po prostu zbyt drogie dla większości zastosowań. Pytanie, na ile człowiek musi sam pisać kod, a na ile może się wspierać, jest dziś otwarte także na politechnikach. Moja odpowiedź to mieszanka jednego i drugiego. Spór toczy się o proporcje.
Rada dla nastolatków wybierających przyszłość
Co powiedziałbyś kilkunastolatkom myślącym o karierze w IT?
Dziesięć lat to zbyt długa perspektywa, by cokolwiek prognozować. Powiem za to, że osoby bez technologicznego backgroundu znajdą miejsce w IT — jeśli zbudują w sobie zainteresowanie klientem i jego perspektywą. Mając subskrypcję narzędzia w rodzaju Claude Code czy Lovable, można pójść do klienta i w ramach MVP zrobić klikalne makiety — bliższe lub dalsze kodowi produkcyjnemu. Nie potrzebujesz do tego całego kosztu seniorskiego doświadczenia, a wartość dla biznesu jest realna.
Wcześniej barierą było samo tworzenie kodu. Dziś pojawi się osobna specjalizacja — ktoś, kto buduje proof of concept ramię w ramię z klientem. Będą ją wykonywać i osoby spoza IT, i osoby z branży.
Kluczem jest praca z klientem.
Oraz basic knowledge: doświadczenie pozwalające przewidzieć, o co dopytać. Bo z praktyki wiesz, że czegoś dziś nie trzeba, ale za trzy miesiące temat wróci jak huragan.
Kim jest developer jutra?
Na koniec — definicja.
To osoba, która podchodzi do pracy proaktywnie, nie reaktywnie. Nie jest sfokusowana wąsko na jednej technologii — osią jej działania jest wartość dla biznesu, a jeśli trzeba dostosować się do nowej technologii, po prostu to robi. Dzięki wiedzy architektonicznej rozumie, gdzie w „ścianach kodu” wyprodukowanych przez AI będą prawdopodobne niedociągnięcia. Szuka złotego środka między kodem człowieka a kodem maszyny. To człowiek jest pilotem, a nie pasażerem.
Jak nie odmóżdżyć się po drodze?
Sprawdza mi się konstruktywne powątpiewanie w to, co generuje model, i stawianie sobie kryteriów sukcesu: ile czasu zająłbym sam, ile zajmie AI, co stanie się z systemem za dwa, trzy lata. Ktoś powie: przecież robiliśmy to przed AI. No właśnie — całe dobrodziejstwo software engineering nigdzie się nie wybiera. Fałszywa jest narracja, że nie musimy już uczyć się architektury ani programowania. Jest dokładnie odwrotnie. Architektura jest dziś potrzebna bardziej niż kiedykolwiek — i powinna być terminem znacznie bardziej sexy, niż jest. Bez kontekstu nie podchodź.
Naszym gościem był Tomasz Ducin — software generalist, lider zespołów programistycznych i trener, współautor programu „Developer Jutra”. Rozmawiał Iwo Zmyślony w ramach cyklu „Limity AI”, powstającego we współpracy z Business Program AI, partnerem strategicznym MIT Sloan Management Review Polska.
