Udało mu się zakończyć dekompilację tajemniczego oprogramowania przekazanego mu przez Korsewicza, a zastosowane w nim algorytmy były co prawda genialne w swojej prostocie i perfekcyjne w wykonaniu, ale również nieco przestarzałe względem obecnie stosowanych w informatyce. [...] Można by powiedzieć, że tego rodzaju oprogramowanie mogłoby być pewnego rodzaju podpisem Kontrolera jako jego autora.
Wojciech Zieliński, „Kontroler"
Deklaracja
Zanim przejdę do rzeczy, muszę powiedzieć, z jakiej perspektywy piszę, bo jest ona nieco sprzeczna wewnętrznie.
Wiele lat byłem programistą oraz architektem oprogramowania. Mam mocne, wewnętrzne przekonanie, że pisanie kodu ręcznie jest sztuką: pracą, w której każda linia jest decyzją, a suma decyzji ma autora rozpoznawalnego po stylu. Zresztą pisanie książek postrzegam niejako jako aktywność w pewnym stopniu spokrewnioną z programowaniem. W obydwu przypadkach tworzy się coś nowego, a satysfakcja z działającego, zbudowanego samodzielnie świata jest bardzo podobna co w przypadku, jak kod, który piszesz nagle zaczyna poprawnie działać (o 03:00 w nocy, i jeszcze do końca nie rozumiesz dlaczego).
Jednocześnie od dwudziestu pięciu lat jestem w IT, od dwudziestu kieruję zespołami programistycznymi oraz interdyscyplinarnymi, a obecnie jako CIO w firmie handlowej decyduję, za które umiejętności firma płaci, a za które nie.
Te dwie role nie są proste do pogodzenia. Ukryty we mnie programista chce bronić sztuki. Szef IT wie, że nikt nie zapłaci więcej za moduł rozliczeń tylko dlatego, że napisano go ręcznie.
Ten tekst jest próbą pogodzenia obu punktów widzenia. Niestety, wychodzi na to, że artysta we mnie ma znacznie słabsze karty, niż chciałby.
Trzy warstwy – i poprawka
Żeby odpowiedzieć na pytanie, kto zapłaci, trzeba najpierw ustalić, za co w ogóle może płacić – czyli gdzie kończy się to, co maszyna potrafi. Pisałem o tym szerzej w tekście Wszystko, co ma metrykę, przegra - tu tylko rdzeń argumentu.
Pracę programisty warto rozbić na trzy warstwy.
Produkcja
Tłumaczenie intencji na składnię – jest przegrana. Każda poprzednia fala, od języków wysokiego poziomu po low-code, zabierała człowiekowi właśnie ją.
Optymalizacja
Lepsze rozwiązanie znanego problemu z mierzalną metryką – właśnie przechodzi na drugą stronę: AlphaEvolve DeepMind poprawił w 2025 roku wynik Strassena, którego nikt nie poprawił od 56 lat. Przechodzi jednak pod warunkiem: metryka musi być tania i automatyczna. Tam, gdzie ewaluatorem jest człowiek (księgowa, audytor, klient) maszyna na razie przyspiesza, a nie wygrywa.
Sformułowanie problemu
Zauważenie, że pytanie w ogóle istnieje. To zostaje po stronie człowieka, bo nie ma tam funkcji celu, a maszyna bez funkcji celu nie ma czego optymalizować.
Z tego wynika, że sztuka w kodzie, praca w warstwie, do której maszyna nie sięga, zostaje. Ale zostaje tak, jak zostało malarstwo po fotografii: jako sztuka tak, jako zawód prawie nie. Garstka gwiazd, reszta uczy i maluje (lub pisze książki - jak co poniektórzy) w weekendy. Jeśli programowanie ręczne jest sztuką, najbardziej prawdopodobny scenariusz to dokładnie ten: powołanie dla niewielu, hobby dla wielu, praca dla prawie nikogo.
Poprzedni tekst kończył się zdaniem, że dzięki temu, co robią rękami, ocaleją tylko ci, którzy potrafią zadać pytanie bez metryki. Pozostali przetrwają, jeśli ktoś będzie miał powód im zapłacić. Zostawiłem tam pytanie, kto i za co. Tu próbuję na nie odpowiedzieć.
Warunek
W sztuce premia za wykonanie przez człowieka ma znany mechanizm. Badania z 2023 roku pokazały, że ludzie obniżają wartość dzieł oznaczonych jako AI nawet wtedy, gdy nie potrafią ich odróżnić od ludzkich, a efekt napędzają postrzegany wysiłek i historia stojąca za dziełem. Philip K. Dick opisał to samo pół wieku wcześniej w Czy androidy marzą o elektrycznych owcach? (powieść będąca inspiracją dla kultowego Łowcy Androidów, choć wątek, do którego się tutaj odwołuje nie wybrzmiał w filmie). Elektryczna owca jest nie do odróżnienia od prawdziwej, a cała wartość społeczna polega na tym, że nie jest prawdziwa.
Ten mechanizm ma jednak warunek: odbiorca musi widzieć dzieło. Musi wiedzieć, że jest ręcznie wykonane, aby za to zapłacić. Odbiorca oprogramowania nie widzi kodu. Widzi ekran logowania i fakturę. Kod ogląda kompilator, a kompilator nie płaci premii za wysiłek.
Rynek dla artysty-programisty istnieje wyłącznie tam, gdzie autorstwo kodu staje się z jakiegoś powodu widoczne – albo tam, gdzie ktoś jest zmuszony za nie zapłacić niezależnie od tego, czy je widzi. Przychodzą mi do głowy cztery takie miejsca. Żadne z nich nie płaci za piękno. A co ważniejsze, tylko jedno z nich płaci za pisanie.
Cztery rachunki
Odpowiedzialność
Awionika. Urządzenia medyczne. Automotive.
Tu trzeba być precyzyjnym, bo łatwo o wygodny mit: że regulator wymaga człowieka za każdą linią kodu. Nie wymaga.
Standardy takie jak DO-178C w lotnictwie czy ISO 26262 w motoryzacji nie zakazują ani generatorów kodu, ani automatycznych audytorów. Mówią coś innego: narzędzie, którego wynik nie jest w pełni sprawdzany dalej w procesie, musi zostać zakwalifikowane – DO-330 nazywa to poziomem TQL, ISO 26262-8 poziomem TCL. A kwalifikacja narzędzia zakłada, że narzędzie jest deterministyczne: ten sam wsad daje ten sam wynik, a certyfikat da się odtworzyć na żądanie.
Dzisiejsze modele językowe tego warunku nie spełniają. Ten sam prompt daje różne odpowiedzi, a model zmienia się bez ostrzeżenia, gdy dostawca podmieni wersję. Dlatego dzisiejszy agent AI audytujący kod jest w tych procesach dokładnie tym, czym generator: narzędziem niekwalifikowanym, którego wynik musi sprawdzić coś, co kwalifikację ma. Audyt AI jest więc kolejną bramką, ale bramką, która sama wymaga bramki za sobą. Tym czymś jest albo deterministyczne narzędzie – analizator statyczny, model checker z pakietem kwalifikacyjnym – albo człowiek. Człowiek nie siedzi w tej pętli dlatego, że jest lepszy od maszyny. Siedzi, bo jest jedyną instancją, której nie trzeba kwalifikować.
Drugi filar to prawo, nie standardy. Od grudnia 2026 roku dyrektywa 2024/2853 traktuje oprogramowanie jako produkt objęty odpowiedzialnością bez winy: za szkodę odpowiada producent niezależnie od tego, kto lub co napisało kod. To nie wymaga ludzkiego audytora. Ale sprawia, że producent chce mieć osobę, która przed sądem wyjaśni, dlaczego kod robi to, co robi – a taką osobę można mieć tylko wtedy, gdy ktoś ten kod naprawdę przeczytał. I zrozumiał.
To nie jest premia za sztukę ani za ręczne pisanie. To premia za podpis – a podpisać można tylko to, co się rozumie. Płaci producent, bo musi, i płaci ludziom, którzy potrafią kod czytać, nie tylko generować. Rynek jest duży.
Trzeba jednak powiedzieć wprost: to jest zamykające się okno. Zamyka się z dwóch stron. Z jednej regulatorzy pracują nad kwalifikacją systemów uczących się – EASA ma na to mapę drogową, która sięga po pełną autonomię po 2035 roku. Z drugiej pojawiają się procesy hybrydowe: model proponuje, a deterministyczne narzędzie formalne – model checker, asystent dowodowy, wystawia certyfikat. W takim układzie model nie potrzebuje kwalifikacji, bo jego wynik jest w pełni weryfikowany dalej, a to, co zostało formalnie zweryfikowane, nie potrzebuje już człowieka. Ludzka bramka nie znika. Cofa się o krok: do pytania, czy specyfikacja, względem której maszyna dowiodła poprawności, jest tą właściwą. A to pytanie nie ma metryki – czyli jesteśmy z powrotem w warstwie trzeciej.
Isaac Asimov opisał pierwszego płatnika za ręczną umiejętność w opowiadaniu Poczucie mocy z 1958 roku. Technik odkrywa na nowo liczenie na papierze w świecie, gdzie wszyscy liczą maszynami. Wojsko jest zachwycone: człowiek-kalkulator jest tańszy od komputera w rakiecie (przy galopujących cenach tokenów może to kolejne proroctwo?). Nikt tam nie płaci za elegancję rachunku. Płaci za to, że jest kto ponieść koszt.
Zaufanie do fundamentów
Kernel. Kompilatory. Biblioteki kryptograficzne. Protokoły, na których stoi wszystko inne.
Płacą fundacje i big tech. Nie dlatego, że kod jest ładny. Płacą, ponieważ koszt błędu w fundamencie jest nieograniczony i nie da się go ubezpieczyć. Rynek to jednak kilkuset, może kilka tysięcy ludzi na świecie. To jedyne miejsce w IT, gdzie kod jest czytany przez innych ludzi, ma podpis, styl i publiczność – czyli najbliżej sztuki w tym sensie, w jakim większość z nas używa tego słowa.
To także ci ludzie, których badało METR w 2025 roku (pisałem o tym tutaj): doświadczeni programiści open source na własnych repozytoriach, którym AI spowalniało pracę o 19 procent. Rok później METR sam osłabił ten wynik, ale jedno zostało: w kodzie, który ktoś zna od lat i za który odpowiada nazwiskiem, koszt weryfikacji cudzej propozycji jest wysoki, a zaufanie niskie. Ponownie - strażnik biblioteki kryptograficznej może przyjąć łatkę od maszyny. Płaci mu się nie za to, że jej nie przyjmie, tylko za to, że ją przeczyta tak, jak nikt inny na świecie nie potrafi.
Frank Herbert zbudował na tym całą cywilizację. W „Diunie" ludzkość po Dżihadzie Butleriańskim zakazała maszyn myślących: Nie będziesz czynił maszyny na obraz i podobieństwo umysłu ludzkiego, i wyhodowała Mentatów: ludzi-komputery, którym płaci się fortunę za to, że liczą sami. Herbert zrobił z tego zakaz religijny, my robimy z tego normę branżową. Mechanizm jest jednak analogiczny: ktoś zdecydował, że pewnych obliczeń nie wolno oddać czemuś, czego nie da się pociągnąć do odpowiedzialności. Mentat to programista biblioteki kryptograficznej.
Tożsamość
Gry indie. Narzędzia z kultem - jeden autor, dwadzieścia lat rozwoju, społeczność, która zna jego nazwisko. Oprogramowanie sprzedawane historią: zrobił to jeden człowiek.
To jest jedyne miejsce w IT, gdzie etykieta human-made działa tak jak w galerii. Steam od stycznia 2024 roku wymaga od wydawców deklaracji użycia AI, a wśród graczy istnieje grupa, dla której ta deklaracja jest kryterium zakupu. Płaci konsument, za narrację, tak jak płaci za winyl. Rynek jest mały. Ale to jest dosłownie cyfrowy odpowiednik płyty winylowej: funkcjonalnie równy lub nawet gorszy od produktu przemysłowego, ceniony jednak za to, kto go zrobił i jak. I to jest jedyny z czterech rachunków, który płaci za pisanie ręczne jako takie.
Nowe pytania
Badania. Algorytmika. Laboratoria.
Płacą granty i firmy, którym opłaca się mieć kogoś, kto zauważy problem przed konkurencją – bo w warstwie, gdzie nie ma jeszcze funkcji celu, maszyna nie ma czego optymalizować. Najmniej ludzi ze wszystkich czterech grup. Największa dźwignia.
Rachunek za czytanie
Kiedy położyć te cztery rachunki obok siebie, widać asymetrię, która w pewnym stopniu jest clue tego tekstu. Rachunek pierwszy i drugi płacą za rozumienie kodu: za to, że ktoś potrafi go przeczytać, przewidzieć skutki i wziąć za to odpowiedzialność. Czwarty płaci za pytania. Tylko trzeci płaci za ręczne pisanie – i jest z nich najmniejszy.
Rynek ręcznego pisania kodu kurczy się więc do niszy płyt winylowych. Rynek ręcznego czytania kodu jest duży i rośnie (przynajmniej jak na razie) dokładnie w tym tempie, w jakim rośnie ilość kodu, którego nikt nie napisał.
Im więcej kodu generuje maszyna, tym więcej jest do przeczytania i tym mniej ludzi, którzy potrafią to zrobić, bo umiejętność czytania kodu bierze się z pisania kodu. To jest sprzeczność, której żaden z czterech płatników jeszcze nie rozwiązał.
Rachunek za czytanie też ma datę ważności. W przypadku odpowiedzialności zamyka się okno w tempie, w jakim tanieje formalna weryfikacja. Zaufanie do fundamentów topnieje wolniej, bo tam bramką nie jest regulator, tylko zaufanie społeczności – a społeczności zmieniają normy wolniej niż urzędy. Kierunek jest jednak ten sam: wszystko, co da się sprawdzić względem specyfikacji, przestanie potrzebować ludzkiego czytelnika. Zostanie pytanie o specyfikację.
Wracając do pytania z tytułu. Poza tymi czterema rachunkami – odpowiedzialnością, zaufaniem, tożsamością i nowymi pytaniami – odpowiedź na pytanie kto zapłaci za ręcznie stworzony kod jest brutalna: nikt.
Za ręcznie napisany moduł rozliczeń, sklep internetowy czy integrację z kurierem nikt nie zapłaci więcej niż za wygenerowany, bo nikt nie płaci więcej za ręcznie malowany portret do dowodu osobistego. Odbiorca nie widzi kodu i nie ma powodu, żeby go obchodziło, jak powstał.
Nie jestem w tej ocenie sam ani odosobniony po żadnej ze stron. W styczniu 2026 roku esej Alexa Wennerberga o kodzie i rzemiośle wywołał na Hacker News dyskusję na ponad 150 komentarzy, która toczyła się dokładnie wokół tego pytania. Jedna strona twierdziła, że kowal wciąż istnieje, wymaga tych samych umiejętności co dwieście lat temu, tylko nie ma na niego popytu. Druga odpowiadała, że nikt nie zapłaci za odśnieżanie parkingu szuflą, jeśli można użyć pługu. I głos trzeci, który uważam za najtrafniejszy: rzemiosło to nie piękny kod, to wyrobiony osąd, których rogów nie wolno ścinać – a ten osąd bierze się z tego, że kiedyś się je ścięło i poniosło konsekwencje.
Co mówię własnemu zespołowi
Na co dzień kieruję zespołem, który między innymi utrzymuje duży system klasy ERP, od kilku lat intensywnie rozszerzany przez kod customowy. Dokumentacja jest przestarzała, wiedza o zależnościach rozproszona po ludziach (a czasem już poza organizacją). I wbrew pozorom nie jest to sytuacja wyjątkowa. Tak wygląda większość systemów, na których stoi handel, bankowość, czy administracja.
Vernor Vinge opisał ten zawód w A Deepness in the Sky: flota Qeng Ho używa oprogramowania starszego niż jej własna cywilizacja, a jednym z najważniejszych fachów na pokładzie jest programista-archeolog – ktoś, kto kopie w warstwach kodu, którego nikt już nie rozumie, żeby dowiedzieć się, dlaczego dana rzecz istnieje. Vinge pisał to w 1999 roku o gwiezdnej flocie. Ja widzę to w dzisiejszych działach IT.
I tu można zauważyć granicę między trzema warstwami na własne oczy, razem z warunkiem o taniej metryce.
Tam, gdzie problem jest sformułowany, a wynik da się sprawdzić – to rozszerzenie trzeba przenieść na nowy interfejs, ten test ma przejść AI już pomaga. Tam, gdzie problem jest sformułowany, ale ewaluatorem jest człowiek – ten raport liczy się źle i tylko księgowa wie, co znaczy „dobrze" – AI proponuje, człowiek sprawdza, i to sprawdzanie jest wąskim gardłem. Tam, gdzie nikt nie wie, dlaczego dane rozszerzenie istnieje, kto je zamówił i co się stanie, gdy zniknie – AI nie ma czego optymalizować, bo nie ma jeszcze pytania. Tę ostatnią pracę wykonują ludzie i za tę pracę trzeba płacić. Nie dlatego, że jest piękna. Dlatego, że nie ma metryki.
W praktyce oznacza to, że w moim zespole rachunek pierwszy i drugi z listy powyżej są jednym rachunkiem: płacę za ludzi, którzy potrafią przeczytać lata cudzego kodu i podpisać się pod tym, co z nim zrobią. Niezależnie od tego, czy nową wersję napisali sami, czy kazali ją napisać maszynie.
Ręczne znaczy: decyzje
Trzeba zredefiniować słowo ręczne, bo w potocznym użyciu stało się synonimem odmowy. Malarz po fotografii nie przestał używać aparatu – używa zdjęć jako referencji i nikt nie mówi, że jego obraz przez to nie jest ręczny. Ręczne w sztuce nigdy nie oznaczało pracy mięśni. Oznaczało autorstwo decyzji.
Jeśli przyjąć tę definicję, artysta-programista to nie ten, kto odmawia AI. To ten, kto każdą decyzję w kodzie podejmuje świadomie i potrafiłby ją podjąć bez maszyny, a maszynę traktuje jak aparat: narzędzie, które przyspiesza wykonanie decyzji, ale jej nie podejmuje. Kod, który powstaje w ten sposób, jest ręczny w jedynym sensie, który kiedykolwiek miał znaczenie, choć maszyna wygenerowała każdy jego znak.
Z tego wynika wniosek mniej sentymentalny niż AI zabija sztukę. Liczba artystów-programistów maleje nie dlatego, że AI ich wypiera. Maleje, bo większość ludzi piszących kod nigdy nie chciała podejmować tych decyzji – chciała mieć działający program. AI tego nie spowodowało. AI to ujawniło.
Iain M. Banks dał tej sytuacji najspokojniejszy komentarz, jaki przyszedł mi na myśl przygotowując ten artykuł. W jego "Graczu" Umysły wygrałyby każdą grę, a Gurgeh, gra dalej – nie dlatego, że jest za co, ale dlatego, że jest po co. Kod ręczny jako luksus istnieje i będzie istnieć. Kiedyś nazywał się Demoscena. Nikomu nie płaci rachunków i nie musi.
Podpis
Wracając do Kontrolera z samego początku artykułu. Pisząc tę książkę, chciałem przedstawić istotę działającą czysto logicznie, pozbawioną uczuć i emocji – coś, co dziś nazwalibyśmy AI. I dałem tej istocie kod, który jest rozpoznawalny. jeden z bohaterów dekompiluje program i widzi jest w stanie rozpoznać jego autora: paradygmat funkcyjny wybrany nie z mody, lecz dlatego, że „był dalece bardziej logiczny i ścisły" niż to, co stosowano powszechnie; algorytmy proste i perfekcyjne, ale celowo przestarzałe; obliczenia rozproszone i ukryte w sposób, który sam jest stylem. Kod Kontrolera ma podpis.
Kontrolera pisałem w 2020 roku i okazało się, że nie doceniłem rozwoju AI (zresztą pomyliłem się tam w kilku innych przypadkach również - do których to pomyłek planuje się otwarcie przyznać w trzeciej części trylogii Kula Światów) Dzisiejsze modele, zostawione same sobie, mają dokładnie odwrotnie. Ich kod jest anonimowy, uśredniony, „mid by nature" – jak nazwał go ktoś w dyskusji na Hacker News. Nie ma podpisu, bo model pozostawiony bez decyzji nie wybiera. Uśrednia. Można mu narzucić styl i będzie go trzymał, ale to jest wtedy styl narzucającego, nie modelu – tak jak fotografia z aparatu ustawionego ręcznie jest zdjęciem fotografa, nie aparatu.
I to prowadzi do właściwego pytania. Nie brzmi ono: czy kod pisany z AI ma podpis. Brzmi: czyj podpis nosi. Kontroler miał podpis nie dlatego, że nie miał emocji, tylko dlatego, że każdy jego wybór dało się uzasadnić, a suma wyborów była rozpoznawalna. Programista, który podejmuje decyzje, a maszynie zostawia wykonanie, zostawia w kodzie swój podpis – dokładnie tak samo, jak zostawiał go bez maszyny. Programista, który decyzje oddaje maszynie, zostawia kod bez podpisu – i to jest ta większość, o której pisałem wyżej. Uśrednienie nie jest cechą modelu. Jest cechą braku decyzji.
Sztuka w kodzie nigdy nie była kwestią emocji. Była kwestią konsekwentnie podejmowanych decyzji. Dopóki decyzje podejmuje człowiek, artysta-programista ma rynek – cztery rachunki powyżej to jego wielkość: odpowiedzialność, zaufanie, tożsamość, nowe pytania. Ani jeden z nich nie jest rachunkiem za piękno. Trzy z nich są rachunkami za to, że ktoś potrafi cudzy kod przeczytać i wziąć za niego odpowiedzialność – i przynajmniej jeden z nich ma widoczną datę ważności.
Dzień, w którym model zacznie sam podejmować decyzje o stylu i umieć je uzasadnić – w którym da się rozpoznać nie tylko, który model napisał kod, ale dlaczego wybrał tak, a nie inaczej – będzie dniem, w którym ten tekst trzeba będzie napisać od nowa. Wtedy okaże się, czy Kontroler był fikcją.
Dane z datą stanu na wrzesień 2026.
Przypisy
- Google DeepMind, AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms, 14.05.2025, artykuł: arXiv:2506.13131
- C. B. Horton, M. W. White, S. S. Iyengar, Bias against AI art can enhance perceptions of human creativity, Scientific Reports (2023)
- L. Bellaiche i in., Humans versus AI: whether and why we prefer human-created compared to AI-created artwork, Cognitive Research: Principles and Implications(2023)
- Philip K. Dick, Do Androids Dream of Electric Sheep? (1968); wyd. polskie Czy androidy marzą o elektrycznych owcach?
- RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification (2011), RTCA DO-330, Software Tool Qualification Considerations (poziomy TQL-1–TQL-5); ISO 26262-8:2018, Confidence in the use of software tools (poziomy TCL1–TCL3).
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2024/2853 z 23.10.2024 w sprawie odpowiedzialności za produkty wadliwe, – oprogramowanie (w tym systemy AI) jako produkt; transpozycja do 9.12.2026; stosowana do produktów wprowadzonych na rynek po tej dacie.
- EASA, Artificial Intelligence Roadmap 2.0 (2023) oraz koncepcja learning assurance; harmonogram: wsparcie człowieka do 2025, współpraca człowiek–maszyna 2025–2030, pełna autonomia po 2035.
- Przykład badań nad hybrydowymi procesami weryfikacji (LLM proponuje, narzędzie formalne certyfikuje) i problemem niedeterminizmu LLM w kontekście DO-178C/ISO 26262/IEC 61508: przegląd ESBMC, arXiv:2605.26169 (2026), sekcja o reprodukowalności.
- Isaac Asimov, The Feeling of Power (1958); wyd. polskie „Poczucie mocy" (tytuł przekładu do weryfikacji)
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10.07.2025,
- METR, aktualizacja z 24.02.2026
- Frank Herbert, Dune (1965); wyd. polskie Diuna.
- Steamworks, AI Content Disclosure, styczeń 2024,
- Alex Wennerberg, AI code and software craft, 25.01.2026,
- Vernor Vinge, A Deepness in the Sky (1999); wyd. polskie „Otchłań w niebie"
- Iain M. Banks, The Player of Games (1988); wyd. polskie „Gracz"
