Atelier
Na stronie hand-crafted-code.com można zamówić oprogramowanie pisane ręcznie. Atelier de Logiciel, założone w MMIX roku, przyjmuje zlecenia w trzech wariantach:
- Cottage za 2 400 dolarów: jedna funkcja, napisana za jednym posiedzeniem, odleżana przez noc w chłodnym, ciemnym branchu, z odręcznym commit message i fotografią biurka.
- Estate za 18 000 dolarów: moduł, jeden rzemieślnik w rezydencji na cały sezon, review przy świecach w partiach nie większych niż czterdzieści linii.
- Reclaimed za 140 000 dolarów: cała baza kodu, z pietyzmem odrestaurowana z projektu na SourceForge z 2009 roku, z zachowaną patyną i proweniencją udokumentowaną aż do oryginalnego tarballa.
Każda partia zawiera jedną zmienną globalną nazwaną imieniem kota rzemieślnika. Kolejka wynosi jedenaście miesięcy; rozważano jej skrócenie i zdecydowano, że nie.
Satyra, ale jednocześnie najważniejszy chyba fakt w tym tekście.
Satyra to jeden z najlepszych dowodów, że coś stało się poważne.
W 2022 roku ten żart nie miałby adresata. Któż bowiem zrozumiałby, co jest śmieszne w „każdym średniku postawionym ręcznie".
Dziś rozumie każdy programista.
Ktoś zadał sobie trud zbudowania całej strony, z cennikiem, certyfikatem autentyczności i manifestem, żeby wyśmiać ideę, która trzy lata wcześniej nie istniała. Idea kodu jako rękodzieła weszła do obiegu na tyle mocno, że można ją parodiować.
Pytanie, które chcę zadać, brzmi: czy za tym żartem stoi coś prawdziwego?
Czy w pisaniu kodu ręcznie jest coś, czego maszyna nie sięga – i jeśli tak, to gdzie właściwie leży ta granica. Bo leży w innym miejscu, niż zwykle się mówi.
Historia jako seria wywłaszczeń
Popularna wersja historii programowania mówi, że wymagania wobec programisty z każdą dekadą spadały. Assembler wymagał wiedzy o rejestrach i pamięci. Języki wysokiego poziomu tę wiedzę zdjęły z barków. Programowanie obiektowe zdjęło ręczne zarządzanie strukturą programu. RAD (Delphi, Visual Basic, PowerBuilder) zdjęło pisanie interfejsów i ręczne podpięcia do baz danych. Low-code zlikwidował składnię. Czy AI likwiduje całą resztę?
Ta wersja jest wygodna i nieprawdziwa. W 1998 roku programista Delphi nie musiał wiedzieć mniej niż programista COBOL-u w 1975 – musiał wiedzieć co innego. Każda fala nie obniżała wymagań, tylko je przenosiła: z wiedzy o maszynie na wiedzę o strukturze, ze struktury na domenę, z domeny na intencję. To, co się faktycznie działo, lepiej nazwać wywłaszczeniem. Każda fala odbierała człowiekowi jedną warstwę tłumaczenia intencji na maszynę. I chyba zawsze tę najniższą z pozostałych.
Warto pamiętać o dwóch odnogach, które nie do końca wyszły (albo po prostu nie trafiły w odpowiedni czas). Narzędzia CASE i generowanie kodu z UML-a w latach dziewięćdziesiątych obiecywały, że model zastąpi kod. Nie zastąpił, bo model wystarczająco precyzyjny, żeby wygenerować działający program, sam stawał się kodem – tylko gorszym, bo rysowanym. Low-code wrócił do tego podejścia niemal dwie dekady później i wygrał nisze, nie główny nurt. Oba przypadki uczą tego samego: automatyzacja produkcji kodu działa dokładnie do momentu, w którym trzeba zdecydować, co program ma robić.
Kurt Vonnegut opisał ten mechanizm w 1952 roku, zanim istniało cokolwiek, co dziś nazwalibyśmy językiem programowania. W „Pianoli" inżynierowie nagrywają na taśmę ruchy dłoni Rudy'ego Hertza, mistrza tokarskiego. Od tej chwili maszyny odtwarzają jego ruchy już bez niego. Hertz jest dumny, że wybrano właśnie jego, jednak dopiero po czasie orientuje się, że staje się jednocześnie całkowicie zbędny.
Jeśli zamienić taśmę na repozytorium GitHuba, a Hertza na kilkanaście milionów programistów, którzy przez dwadzieścia lat wrzucali tam kod, dostaje się dość dokładny opis tego, jak powstały dzisiejsze modele językowe. Vonnegut jak się okazało opisał mechanizm, który działa niezależnie od technologii: mistrz nagrany, potem wywłaszczony.
Każda z tych fal miała oczywiście swoich proroków końca zawodu. Co ciekawe, każda skończyła większą liczbą programistów niż przed nią. Obecna fala może być jednak kompletnie inna. Nie dlatego, że jest szybsza, ale dlatego, że po raz pierwszy sięga wyżej niż produkcja. O tym za chwilę.
Lustro
Zawody kreatywne przeszły bardzo podobną drogę już wiele lat, czy nawet dziesięcioleci wcześniej i dzięki temu na ich przykładzie można ekstrapolować, co dzieje się na końcu.
Malarze renesansu tworzyli samodzielnie, po latach studiowania anatomii i światła. Fotografia zdjęła z nich obowiązek wiernego odtwarzania. Grafika komputerowa zdjęła obowiązek fizycznego wykonania. Generatory obrazów wyeliminowały wymaganie jakichkolwiek umiejętności - wystarczy opis.
Popularna wersja tej historii mówi: fotografia nie zabiła malarstwa. To prawda, ale nieprecyzyjna. Fotografia nie zabiła malarstwa – zabiła portrecistów na zamówienie. Ludzi, którzy sprzedawali umiejętność wiernego odtworzenia twarzy i którzy przez trzysta lat stanowili większość zawodowych malarzy. Malarstwo przeżyło, uciekając tam, gdzie aparat fotograficzny nie umiał: w impresjonizm, w abstrakcję, w dzieła nie stanowiące odtworzenia rzeczywistości. Sztuka przetrwała. Zawód, w sensie ekonomicznym, prawie nie. Dziś z malowania utrzymuje się garstka artystów - reszta uczy, robi pracę komercyjną i maluje w weekendy.
Stanisław Lem poszedł o krok dalej. W Cyberiadzie Trurl buduje Elektrybałta – maszynę do pisania wierszy, do której skonstruowania musi najpierw zasymulować całą historię wszechświata, bo poezja okazuje się jej skondensowanym produktem. Ludzcy poeci najpierw Elektrybałta wyśmiewają, potem przegrywają z nim konkursy, wreszcie protestują, a Trurl musi maszynę wyłączyć (to, że nie do końca się to udaje, to inna historia).
Lem napisał opowiadanie 1965 roku gdzie, co dla mojej tezy niewygodne, maszyna wygrywa. Nie ma u Lema pocieszenia, że ręczny wiersz zachowa wartość. Trzeba to zdanie zostawić w tekście, bo argument, który ignoruje najsilniejszy kontrargument, nie jest argumentem.
Pytanie dla programowania brzmi więc nie czy przeżyje, tylko: kto w IT jest portrecistą. Odpowiedź przyjdzie na końcu i będzie mniej pochlebna, niż bym chciał...
Za co się płaci w sztuce ręcznej
Zanim odpowiem, warto sie zastanowić, za co właściwie ludzie płacą, kiedy płacą za dzieło zrobione ręcznie. Tu mamy twarde dane.
W serii sześciu eksperymentów na około trzech tysiącach uczestników, opublikowanej w Scientific Reports w 2023 roku, ludzie konsekwentnie oceniali niżej prace oznaczone jako wygenerowane przez AI – nawet wtedy, gdy nie potrafili ich odróżnić od ludzkich, i nawet wtedy, gdy powiedziano im, że powstały we współpracy z człowiekiem. W jednym z eksperymentów wycena prac oznaczonych jako AI była o 62 procent niższa. Równolegle opublikowane badanie w Cognitive Research pokazało, co ten efekt napędza: postrzegany wysiłek twórcy i narracja stojąca za dziełem.
Wniosek jest prosty i ma konsekwencje. Premia za ręczne to premia za historię i trud, nie za jakość. Ludzie nie płacą więcej, bo obraz jest lepszy. Płacą, bo wiedzą, że ktoś się nad nim męczył. A to działa wyłącznie wtedy, gdy odbiorca widzi dzieło. Odbiorca kodu go nie widzi. Kod ogląda kompilator.
Ted Chiang, autor twardej fantastyki, ujął to w eseju w „New Yorkerze" jeszcze prościej: dzieło sztuki to tysiące decyzji, a prompt to jedna. Wartość ręcznej pracy nie jest w rękach. Jest w liczbie świadomie podjętych wyborów.
Jest jedno badanie, które w tym miejscu przytacza każdy obrońca kodu ręcznego (zresztą sam je również przytaczałem jakiś czas temu), więc trzeba je przytoczyć uczciwie. W lipcu 2025 roku organizacja METR opublikowała randomizowane badanie na szesnastu doświadczonych programistach open source, pracujących na własnych repozytoriach nad 246 realnymi zadaniami. Z narzędziami AI zajmowało im to o 19 procent dłużej niż bez nich. Przed badaniem spodziewali się przyspieszenia o 24 procent; po badaniu, mimo że zmierzono im spowolnienie, nadal wierzyli, że AI przyspieszyło ich o 20. Wygląda jak dowód, że w kodzie, który ktoś zna od lat i traktuje jak dzieło, maszyna przegrywa.
Niestety w lutym 2026 roku METR opublikował aktualizację, w której sam osłabia ten wniosek. Nowe dane są "nierozstrzygające", głównie z powodu efektów selekcji: część programistów odmawiała udziału, jeśli miałaby pracować bez AI, a niektórzy nie zgłaszali do badania zadań, przy których szczególnie chcieli AI użyć.
Można to czytać na dwa sposoby i uczciwość wymaga podania obu:
- Narzędzia w ciągu roku poprawiły się na tyle, że odmowa pracy bez nich była racjonalna. To, co w 2025 spowalniało, w 2026 przyspiesza, i badani wiedzieli o tym wcześniej niż badacze.
- Doświadczeni programiści stracili zainteresowanie pracą ręczną, zanim ktokolwiek wykazał, że ręcznie jest wolniej.
Dane METR nie rozstrzygają, która wersja jest prawdziwa. Ale obie prowadzą do tego samego wniosku: w sztuce ludzie płacą za wysiłek, a w programowaniu programiści wysiłku nie chcą – niezależnie od tego, czy akurat się opłaca. To jest prawdziwy wynik METR i jest ciekawszy niż 19 procent.
E. M. Forster opisał stan końcowy już w 1909 roku w The Machine Stops: ludzkość obsługiwana przez Maszynę traci umiejętność jej naprawy, a gdy Maszyna się zatrzymuje, nikt nie pamięta, jak działała. Forster potrzebował do tego całej cywilizacji. My jesteśmy na początku tej drogi, ale kierunek jest widoczny.
Winyl to nie tranzystor
Zanim pójdziemy dalej, trzeba rozplątać dwie rzeczy, które w każdej dyskusji o kodzie jako sztuce lądują w jednym garnku.
Pierwsza to kod ręczny postrzegany jako luksus.
Demoscena.
TempleOS.
Programiści piszący własne edytory i systemy budowania, bo tak chcą.
Rzeczy funkcjonalnie równe lub gorsze od odpowiedników przemysłowych, cenione za wysiłek i tożsamość. Dokładnie tak, jak płyta winylowa czy zegarek mechaniczny. To jest to, co parodiuje Atelier de Logiciel o którym pisałem na początku tekstu.
Druga to kod ręczny jako granica.
Kryptografia asymetryczna nie jest winylem. Jest tranzystorem: wygrała nie dlatego, że była zbudowana w sposób ręczny, ale dlatego, że robiła coś, czego wcześniej nie było. Pytanie „czy AI wynalazłoby klucz publiczny" nie jest pytaniem o luksus. Jest pytaniem o to, czy istnieje warstwa pracy, nieosiągalna dla maszyny.
Żeby na nie odpowiedzieć, trzeba rozbić pracę programisty na trzy warstwy, a nie – jak zwykle – na dwie.
Trzy warstwy pracy programisty
Produkcja
Tłumaczenie intencji na składnię. Ta warstwa jest przegrana. I to tu właśnie pracowali informatyczni portreciści.
Optymalizacja
Lepsze rozwiązanie znanego problemu, z mierzalną metryką. Tu jest nowość, której większość tekstów o kodzie jako rzemiośle nie zauważa. W maju 2025 roku DeepMind pokazał AlphaEvolve – system, który znalazł sposób mnożenia macierzy 4×4 o wartościach zespolonych przy 48 mnożeniach skalarnych, poprawiając wynik Strassena z 1969 roku, nieosiągalny przez poprzednie 56 lat.
Na ponad pięćdziesięciu otwartych problemach matematycznych AlphaEvolve wyrównał najlepsze znane rozwiązanie w 75 procentach przypadków i znalazł lepsze w 20 – w tym nowe ograniczenie w problemie Erdősa z 1955 roku i rekord w problemie kissing number w jedenastu wymiarach. Niejako "przy okazji" poprawił również heurystykę planowania w systemie Borg, odzyskując 0,7 procent mocy obliczeniowej Google.
Jeszcze dwa lata temu ta warstwa uchodziła za bezpiecznie ludzką. Właśnie przeszła na drugą stronę.
Trzeba jednak od razu powiedzieć, pod jakim warunkiem przeszła, bo ten warunek jest istotą całego tekstu. AlphaEvolve nie wygrywa tam, gdzie problem ma metrykę. Wygrywa tam, gdzie metrykę można policzyć automatycznie, tanio i miliony razy – sam DeepMind mówi to wprost, tłumacząc, dlaczego system skupia się na matematyce, informatyce i optymalizacji infrastruktury.
Mnożenie macierzy ma taką metrykę: wynik sprawdza się w mikrosekundę. Raport finansowy w systemie ERP też ma metrykę „liczy się dobrze albo źle", ale ewaluatorem jest księgowa, która sprawdza go raz na miesiąc i potrzebuje na to dnia. Metryka istnieje, tylko jej wywołanie kosztuje. Tam, gdzie ewaluacja jest droga, wolna albo wymaga człowieka, maszyna na razie pomaga, a nie wygrywa. A na takich systemach, z drogą, ludzką ewaluacją, stoi większość handlu, bankowości i administracji.
Sformułowanie problemu
Zauważenie, że pytanie w ogóle istnieje.
Klucz publiczny nie powstał z pytania „jak szyfrować szybciej". Powstał z pytania, którego nikt nie zadawał: czy szyfrowanie musi być symetryczne? Nie było funkcji celu, bo nie było problemu – dopóki ktoś go nie nazwał.
Uczciwość wymaga tu dwóch zastrzeżeń. Po pierwsze, klucz publiczny wynaleziono niezależnie dwa razy: James Ellis w GCHQ w 1970 roku, a Diffie, Hellman i Merkle publicznie w 1976. Ellis wpadł na pomysł czytając stary raport Bell Labs o dodawaniu szumu do linii telefonicznej, co oznacza, że przełom był kombinacją dwóch idei z obcych dziedzin, a to jest dokładnie ta operacja, w której modele językowe radzą sobie całkiem dobrze. Mit samotnej iskry jest słabszy, niż bym chciał, aby wykorzystać go jako mocny argument (co zresztą poniekąd wykorzystuję w mojej pierwszej książce, "Kontrolerze"). Po drugie, pytanie „czy AI wpadłoby na to w 1975" jest nierozstrzygalne. Sprawdzalne jest inne: czy istnieje dziś problem, którego ludzie nie zauważyli, a maszyna go nazwała. Niestety, nie znam dobrego przykładu.
Ciekawym jest, że Isaac Asimov opisał ten trójpodział w opowiadaniu „Zawód" z 1957 roku. W jego świecie wiedzę wgrywa się ludziom bezpośrednio do mózgu z taśmy; kto się do wgrania nie nadaje, trafia do Domu dla Niedorozwiniętych.
<SPOILER ALERT> Bohater odkrywa pod koniec, że Dom jest miejscem, w którym hoduje się jedynych ludzi zdolnych wymyślić coś, czego jeszcze nie ma na taśmach.</SPOILER ALERT>
Wgrywanie to produkcja i optymalizacja. Niewgrywalni to sformułowanie problemu.
Granica
Granica tego, co AI potrafi z kodem, nie biegnie między „znane" a „nowe". AlphaEvolve robi nowe rzeczy.
Nie biegnie też między „brzydkie" a „eleganckie" – modelowi można kazać pisać elegancko i będzie to robił.
Biegnie między "ma tanią funkcję celu" a "nie ma".
Wszystko, co da się zmierzyć szybko i automatycznie, maszyna zoptymalizuje lepiej niż człowiek - jeśli nawet nie jeszcze dziś, to z pewnością wkrótce. Wszystko, co ma metrykę drogą, powolną albo ludzką, maszyna na razie jest w stanie tylko przyśpieszyć. Tutaj granica przesuwa się w miarę, jak tanieje ewaluacja. Wszystko, co wymaga zauważenia, że problem istnieje, zostaje po stronie człowieka. Tak przynajmniej jest na dziś. 07.09.2026.
Tytuł tego tekstu jest więc hasłem, a nie definicją: „wszystko, co ma metrykę, przegra" znaczy tyle, że metryka jest warunkiem koniecznym przegranej. Nie każda metryka wystarcza. Ale kierunek jest jeden. Ewaluacje tanieją, nie drożeją – i nic z tego, co ma metrykę, nie jest bezpieczne na stałe.
Kto w IT jest więc portrecistą?
Większość. Programowanie nie było nigdy sztuką w większości. Było w większości portretem na zamówienie – i ta część odchodzi. Było też w mniejszości szukaniem pytań – i ta część zostaje.
Satyryczne atelier z początku tekstu myli się w jednym: umieszcza rękodzieło w produkcji, w odręcznym commit message i odleżanym branchu. Tam go nie ma i nigdy nie było. Jest tam, gdzie ktoś zauważa, że pytanie istnieje – i za to nie da się wystawić cennika, bo nie ma jeszcze funkcji celu, którą można by wycenić.
Rzemieślnik nie jest zagrożony dlatego, że jego kod jest ładny albo brzydki. Jest zagrożony dlatego, że wszystko, co robi, da się zmierzyć z każdym rokiem, a nawet z każdym miesiącem taniej. Oczywiście, tokeny kosztują, coraz więcej, ale to, co można za nie "kupić" również rośnie.
Umiejętności zadawania pytań bez metryki żadna z poprzednich fal – RAD, CASE, UML, low-code – nawet nie próbowała zautomatyzować. Obecna próbuje. I na dziś zatrzymuje się dokładnie tam, gdzie kończy się to, co można tanio policzyć.
Czy to znaczy, że ocaleją tylko ci, którzy zadają pytania?
Nie. To znaczy, że tylko oni ocaleją dzięki temu, co robią rękami.
Pozostali, a jest ich więcej, niż sugeruje ten tekst, ocaleją, jeśli ktoś będzie miał powód im zapłacić. Kto i za co – to już osobne pytanie, i osobny tekst.
Wszystkie dane z datą stanu na wrzesień 2026. Część danych o zdolnościach modeli AI zestarzeje się szybko – tekst należy czytać z tą świadomością.
Przypisy
- Hand-Crafted Code – Artisanal Software, Written by Hand, https://hand-crafted-code.com/ (strona satyryczna; dostęp: wrzesień 2026).
- Kurt Vonnegut, Player Piano (1952); wyd. polskie „Pianola".
- Stanisław Lem, Wyprawa pierwsza A, czyli Elektrybałt Trurla, w: Cyberiada (1965).
- 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),
- Ted Chiang, Why A.I. Isn't Going to Make Art, The New Yorker, 31.08.2024
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10.07.2025,
- METR, aktualizacja badania z 24.02.2026
- E. M. Forster, The Machine Stops (1909); wyd. polskie Maszyna zatrzymuje się.
- Google DeepMind, AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms, 14.05.2025, artykuł: arXiv:2506.13131.
- J. H. Ellis, The History of Non-Secret Encryption, GCHQ 1987, odtajnione 1997;
- W. Diffie, M. Hellman, New Directions in Cryptography, IEEE Transactions on Information Theory (1976).
- Isaac Asimov, Profession (1957); wyd. polskie Zawód
