Kod to zobowiązanie (nie aktywa). Szefowie technologii tego nie rozumieją. Myślą, że AI jest świetne, ponieważ produkuje 10 000 razy więcej kodu niż programista, ale to tylko oznacza, że produkuje 10 000 razy więcej zobowiązań. 1/

Jeśli chcesz wersji tego wątku w formacie eseju do przeczytania lub udostępnienia, oto link do niego na moim blogu, wolnym od nadzoru, reklam i trackerów: 2/

AI jest azbestem, który wsypujemy w ściany naszego zaawansowanego technologicznie społeczeństwa: Kod to zobowiązanie. *Możliwości* kodu to aktywa. 3/

Celem sklepu technologicznego jest posiadanie kodu, którego możliwości generują większe przychody niż koszty związane z jego utrzymaniem. 4/

Przez długi czas firmy pielęgnowały fałszywe przekonanie, że kod kosztuje mniej w eksploatacji z upływem czasu: po początkowym okresie weryfikacji, w którym błędy w kodzie są znajdowane i naprawiane, kod przestaje wymagać znaczącej konserwacji. 5/

W końcu kod to maszyna bez ruchomych części - nie zużywa się; nawet się nie wyciera. To teza książki Paula Masona z 2015 roku *Postkapitalizm*, książki, która zestarzała się niezwykle źle (choć może nie tak źle, jak wiarygodność polityczna samego Masona). 6/

Kod nie jest nieskończoną maszyną reprodukcyjną, która nie wymaga pracy. Raczej jest to krucha maszyna, która wymaga coraz bardziej heroicznych działań, aby utrzymać ją w dobrym stanie, i która ostatecznie "zużywa się" (w sensie potrzeby przeprowadzenia gruntownej refaktoryzacji). 7/

Aby zrozumieć, dlaczego kod jest zobowiązaniem, musisz zrozumieć różnicę między "pisaniem kodu" a "inżynierią oprogramowania." "Pisanie kodu" to niezwykle przydatne, zabawne i wciągające zajęcie. 8/

Polega to na rozkładaniu złożonych zadań na dyskretne kroki, tak precyzyjnie opisane, że komputer może je niezawodnie wykonać, optymalizując wydajność poprzez znajdowanie sprytnych sposobów na minimalizowanie wymagań, jakie kod stawia zasobom komputera, takim jak RAM i cykle procesora. 9/

Tymczasem "inżynieria oprogramowania" to dziedzina, która obejmuje "pisanie kodu", ale z naciskiem na długoterminowe operacje *systemu*, którego częścią jest ten kod. 10/

Inżynieria oprogramowania zajmuje się procesami upstream, które generują dane, które system otrzymuje. Zajmuje się również procesami downstream, do których system emituje przetworzone informacje. 11/

Dotyczy to sąsiednich systemów, które otrzymują dane z tych samych procesów upstream i/lub emitują dane do tych samych procesów downstream, do których system emituje. 12/

"Pisanie kodu" polega na tworzeniu kodu, który *działa dobrze*. "Inżynieria oprogramowania" polega na tworzeniu kodu, który *zawodzi dobrze*. Chodzi o tworzenie kodu, który jest czytelny - którego funkcje mogą być zrozumiane przez osoby trzecie, które mogą być poproszone o jego utrzymanie. 13/

Te strony trzecie mogą być poproszone o dostosowanie procesów w dół, w górę lub sąsiadujących z systemem, aby zapobiec jego awarii. 14/

To jest sedno sprawy: każdy nietrywialny kod musi wchodzić w interakcje z otaczającym światem, a otaczający świat nie jest statyczny, jest *dynamiczny*. Otaczający świat łamie założenia stawiane przez autorów oprogramowania *cały czas* i za każdym razem, gdy to robi, oprogramowanie musi być naprawiane. 16/

Pamiętasz Y2K? To był dzień, kiedy doskonale działający kod, działający na doskonale działającym sprzęcie, przestał działać - nie dlatego, że kod się zmienił, ale dlatego, że *czas płynął dalej*. 17/

Mamy 12 lat do problemu Y2038, kiedy 32-bitowe wersje Uniksa przestaną działać, ponieważ również wyczerpią się obliczalne sekundy. 18/

Istnienie "świata" jest nieuniknionym czynnikiem, który zużywa oprogramowanie i wymaga jego przebudowy, często przy ogromnych kosztach. Im dłużej kod jest w użyciu, tym bardziej prawdopodobne jest, że napotka "świat." 20/

Weź kod, który urządzenia używają do raportowania swojej fizycznej lokalizacji. Początkowo był on używany do takich rzeczy jak rozliczenia - ustalanie, z której sieci operatora lub dostawcy korzystasz i czy jesteś w roamingu. 21/

Następnie nasze urządzenia mobilne używały tego kodu, aby pomóc określić Twoją lokalizację w celu dostarczenia wskazówek krok po kroku w aplikacjach nawigacyjnych. Następnie ten kod został ponownie wykorzystany, aby pomóc nam znaleźć nasze zagubione urządzenia. 22/

To stało się sposobem na lokalizowanie *skradzionych* urządzeń, co wyraźnie różni się od znajdowania zagubionych urządzeń. Podczas lokalizowania zagubionego urządzenia nie musisz zmagać się z możliwością, że złośliwy aktor wyłączył funkcję "znajdź moje zagubione urządzenie". 23/

Te dodatkowe przypadki użycia - upstream, downstream i sąsiednie - ujawniły błędy w oryginalnym kodzie, które nigdy nie pojawiły się w wcześniejszych aplikacjach. 24/

Na przykład wszystkie usługi lokalizacyjne muszą mieć jakiś rodzaj domyślnego zachowania w (bardzo powszechnym) przypadku, gdy nie są do końca pewne, gdzie się znajdują. 25/

Może mają ogólne rozwiązanie - na przykład wiedzą, do którego masztu komórkowego są podłączeni, lub wiedzą, gdzie byli *ostatnio*, gdy uzyskali dokładną lokalizację - albo może są całkowicie zagubieni. 26/

Okazuje się, że w wielu przypadkach aplikacje lokalizacyjne rysowały okrąg wokół wszystkich miejsc, w których *mogły* się znajdować, a następnie ustawiały swoją lokalizację na środku tego okręgu. 27/

To w porządku, jeśli okrąg ma tylko kilka stóp średnicy, lub jeśli aplikacja szybko zastępuje to przybliżenie dokładniejszą lokalizacją. Ale co jeśli lokalizacja ma mile i mile szerokości, a ustalenie lokalizacji *nigdy* się nie poprawia? 28/

Co jeśli lokalizacja dla dowolnego adresu IP bez określonej lokalizacji jest podawana jako *centrum kontynentalnych USA*, a każda aplikacja, która nie wie, gdzie to jest, zgłasza, że znajduje się w domu w Kansas? 29/

A w moim mieście Burbank, gdzie usługa udostępniania lokalizacji Google'a kiedyś powiedziała nam, że nasza 11-letnia córka (do której telefonu nie mogliśmy się dodzwonić) była 12 mil dalej, na zjeździe autostrady w nieinkorporowanej części hrabstwa LA. 32/

(Była w pobliskim parku, ale poza zasięgiem, a aplikacja oszacowała jej lokalizację na środek regionu, w którym ostatnio ją zlokalizowano.) (To były trudne kilka godzin.) 33/

Kod źródłowy - kod, który używa jakiegoś niegdyś nieszkodliwego domyślnego ustawienia do maskowania nieznanych lokalizacji - musi być aktualizowany *ciągle*, ponieważ procesy upstream, downstream i sąsiednie, które są z nim powiązane, zmieniają się *ciągle*. 34/

Im dłużej ten kod tam leży, tym bardziej przestarzałe stają się jego pierwotne zachowania, a łatki nałożone na niego stają się coraz bardziej barokowe, złożone i nieczytelne. 35/

Kod nie jest aktywem - to zobowiązanie. Im dłużej system komputerowy działa, tym więcej długu technologicznego reprezentuje. Im ważniejszy jest system, tym trudniej go wyłączyć i całkowicie przebudować. 36/

Zamiast tego, nowe warstwy kodu są nakładane na to, a wszędzie tam, gdzie warstwy kodu się stykają, pojawiają się szczeliny, w których te systemy zachowują się w sposób, który nie do końca się zgadza. 37/

Co gorsza: gdy dwie firmy są łączone, ich połączone, popękane systemy IT są zderzane ze sobą, co powoduje, że teraz istnieją *sąsiednie* źródła długu technologicznego, a także pęknięcia w górę i w dół: 38/

Dlatego wielkie firmy są tak podatne na ataki ransomware - są pełne niekompatybilnych systemów, które zostały zmuszone do udawania kompatybilności za pomocą różnych form cyfrowego plasteliny, sznurka i drutu balingowego. 39/

Nie są one wodoszczelne i nie można ich uczynić wodoszczelnymi. Nawet jeśli nie zostaną zniszczone przez hakerów, czasami po prostu przewracają się i nie można ich ponownie postawić. 40/

Pamiętasz, kiedy komputery Southwest Airlines zawiodły przez cały tydzień świąteczny w 2022 roku, uziemiając miliony podróżnych? 41/

Linie lotnicze są szczególnie złe, ponieważ wcześnie wprowadziły komputeryzację i nigdy nie mogą wyłączyć starych komputerów, aby zastąpić je nowymi. Dlatego ich aplikacje są takie do niczego. 42/

Dlatego tak straszne jest to, że linie lotnicze zwolniły swoich pracowników obsługi klienta i wymagają od pasażerów korzystania z aplikacji do *wszystkiego*, mimo że aplikacje nie działają. Te aplikacje nigdy nie będą działać. 43/

Powodem, dla którego aplikacja British Airways wyświetla "Wystąpił nieznany błąd" 40-80% czasu, nie jest (tylko) to, że zwolnili wszystkich pracowników IT i zlecili to tanim wykonawcom za granicą. 44/

To prawda, ale także to, że pierwsze komputery BA działały na zaworach elektromechanicznych, a wszystko, co od tego czasu powstało, musi być wstecznie kompatybilne z systemem, który jeden z uczniów Alana Turinga wyżłobił z całego kłody własnymi zębami. 45/

Kod jest zobowiązaniem, a nie aktywem (nowa aplikacja BA jest opóźniona o lata). Kod jest zobowiązaniem. Serwery terminali Bloomberg, które uczyniły Michaela Bloomberga miliarderem, działają na chipach RISC. 46/

Oznacza to, że jest zablokowane na korzystaniu z malejącej liczby specjalistycznych dostawców sprzętu i centrów danych, płacąc wyspecjalizowanym programistom i budując kruchy łańcuch kodu, aby połączyć te systemy RISC z ich mniej egzotycznymi odpowiednikami na świecie. Kod nie jest aktywem. 47/

AI potrafi pisać kod, ale AI nie potrafi zajmować się inżynierią oprogramowania. Inżynieria oprogramowania polega na myśleniu o *kontekście* - co będzie przed tym systemem? Co będzie po nim? Co będzie obok niego? Jak świat się zmieni? 48/

Inżynieria oprogramowania wymaga bardzo szerokiego "okna kontekstowego", czego AI nie ma i nie może mieć. Okno kontekstowe AI jest wąskie i płytkie. Liniowy wzrost okna kontekstowego AI wymaga *geometrycznych* rozszerzeń w wymaganiach obliczeniowych: 49/

Pisanie kodu, który działa, bez uwzględnienia tego, jak może zawieść, to przepis na katastrofę. To sposób na tworzenie długu technologicznego w dużej skali. To wsypywanie azbestu w ściany naszego technologicznego społeczeństwa. 50/

Szefowie *nie wiedzą*, że kod to zobowiązanie, a nie aktywa. Dlatego nie przestaną pieprzyć o chatbotach, które wypisują 10 000 razy więcej kodu niż jakikolwiek ludzki programista. 51/

Myślą, że znaleźli maszynę, która produkuje *aktywa* w tempie 10 000 razy szybszym niż ludzki programista. Nie znaleźli. Znaleźli maszynę, która produkuje *zobowiązania* w tempie 10 000 razy szybszym niż jakikolwiek ludzki programista. 52/

Utrzymanie nie jest tylko kwestią ciężko zdobytego doświadczenia, które uczy cię, gdzie są pułapki. 53/

Wymaga to również rozwijania "Fingerspitzengefühl" - "czucia palców", które pozwala na rozsądne zgadywanie, gdzie mogą pojawić się wcześniej nieznane pułapki. 54/

To forma wiedzy procesowej. Jest nieunikniona. Nie jest ukryta nawet w największym zbiorze kodu, który mógłbyś wykorzystać jako dane treningowe: *Chłopcze*, szefowie technologii tego nie rozumieją. 55/

Weźmy Microsoft. Ich dużym zakładem w tej chwili jest "agentyczna AI." Chcą zainstalować oprogramowanie szpiegujące na twoim komputerze, które rejestruje każde naciśnięcie klawisza, każdą komunikację, każdy ekran, który widzisz i wysyła to do chmury Microsoftu, dając menażerii chatbotów dostęp do tych danych. 56/

Twierdzą, że będziesz mógł powiedzieć swojemu komputerowi: "Zarezerwuj mi pociąg do Cardiff i znajdź ten hotel, o którym wspomniał Cory w zeszłym roku, i zarezerwuj mi tam pokój" i on to zrobi. To jest niesamowicie niepraktyczny pomysł. 57/

Żaden chatbot nie jest w stanie zrobić wszystkich tych rzeczy, co Microsoft swobodnie przyznaje. Zamiast robić to za pomocą jednego chatbota, Microsoft proponuje podzielić to na dziesiątki chatbotów, z których każdy ma osiągnąć 95% niezawodności. 58/

To jest całkowicie nieprawdopodobny standard chatbota sam w sobie, ale rozważ to: prawdopodobieństwa są *multiplikatywne*. System zawierający dwa procesy działające z niezawodnością 95% ma łączną niezawodność na poziomie 90,25% (0,95 * 0,95). 59/

Podziel zadanie pomiędzy kilkadziesiąt botów o 95% dokładności, a szansa, że to zadanie zostanie wykonane poprawnie, zbliża się do *zera*. 60/

Tymczasem w grudniu zeszłego roku jeden z dyrektorów Microsoftu miał kłopoty, gdy opublikował na LinkedIn zapowiedź, że zamierza zlecić AI przepisanie *wszystkiego* kodu Microsoftu. 63/

Refaktoryzacja bazy kodu Microsoftu ma sens. Microsoft - podobnie jak British Airways i inne firmy z długą historią - ma wiele bardzo starych kodów, które reprezentują nieodpowiedni dług technologiczny. 64/

Niektórzy z was *są* inżynierami oprogramowania, którzy uznali chatboty za niezwykle przydatne w pisaniu kodu dla siebie. To powszechny paradoks AI: dlaczego niektórzy ludzie, którzy korzystają z AI, uważają to za naprawdę pomocne, podczas gdy inni to nienawidzą? 66/

Czy to tak, że ludzie, którzy nie lubią AI, są "słabi w AI?" Czy to tak, że fani AI są leniwi i nie dbają o jakość swojej pracy? 67/

Niewątpliwie zachodzi tu trochę z obu stron, ale nawet jeśli nauczysz wszystkich, jak być ekspertem w dziedzinie AI, i wyeliminujesz wszystkich, którzy nie są dumni ze swojej pracy, paradoks nadal będzie istniał. 68/

Prawdziwe rozwiązanie paradoksu AI leży w teorii automatyzacji oraz w koncepcji "centaurów" i "odwrotnych centaurów": 69/

W teorii automatyzacji "centaur" to osoba, która jest wspierana przez maszynę. "Odwrócony centaur" to ktoś, kto został powołany do *wspierania maszyny*. 70/

Powiedz, że jesteś inżynierem oprogramowania, który używa AI do pisania rutynowego kodu, który masz czas i doświadczenie, aby zweryfikować, wykorzystując swoje Fingerspitzengefühl i wiedzę procesową, aby upewnić się, że jest odpowiedni do celu. 71/

Łatwo zrozumieć, dlaczego możesz uznać korzystanie z AI (kiedy chcesz, w sposób, w jaki chcesz, w tempie, które wybierzesz) za przydatne. Ale powiedzmy, że jesteś inżynierem oprogramowania, któremu nakazano produkować kod w tempie 10x, 100x lub 10 000x swojego poprzedniego tempa. 72/

Powiedz, że jedynym sposobem, aby to zrobić, jest AI, a nie ma ludzkiego sposobu, abyś mógł przejrzeć ten kod i upewnić się, że nie zawiedzie przy pierwszym kontakcie ze światem, będziesz go nienawidzić: 73/

(Będziesz nienawidzić tego jeszcze bardziej, jeśli zostałeś przemieniony w zrzut odpowiedzialności AI, osobiście odpowiedzialny za błędy AI.) Jest jeszcze jeden sposób, w jaki inżynierowie oprogramowania uważają, że kod generowany przez AI jest niezwykle pomocny: gdy ten kod jest *izolowany*. 74/

Jeśli realizujesz pojedynczy projekt - powiedzmy, konwertując jedną partię plików na inny format, tylko raz - nie musisz się martwić o procesy downstream, upstream czy sąsiednie. Nie ma ich. 75/

Piszesz kod, aby zrobić coś raz, bez interakcji z innymi systemami. *Wiele* kodowania to tego rodzaju projekt użyteczności. To żmudne, niewdzięczne i gotowe do automatyzacji. 76/

Wiele osobistych projektów mieści się w tej kategorii, a oczywiście, z definicji, projekt osobisty to projekt centaur. Nikt nie zmusza cię do korzystania z AI w projekcie osobistym - zawsze to ty decydujesz, jak i kiedy wykorzystasz jakiekolwiek narzędzie do osobistych celów. 77/

Jednak fakt, że inżynierowie oprogramowania czasami mogą poprawić swoją pracę dzięki AI, nie unieważnia faktu, że kod jest zobowiązaniem, a nie aktywem, i że kod AI reprezentuje produkcję zobowiązań na dużą skalę. 78/

W historii technologicznego bezrobocia istnieje pomysł, że nowa technologia tworzy nowe miejsca pracy, nawet gdy czyni stare nieaktualnymi: dla każdego kowala, który stracił pracę przez samochód, czeka praca jako mechanik. 79/

W latach od momentu, gdy bańka AI zaczęła się powiększać, słyszeliśmy wiele wersji tego: AI stworzy miejsca pracy dla "inżynierów promptów" - a nawet stworzy miejsca pracy, których nie możemy sobie wyobrazić, ponieważ nie będą istnieć, dopóki AI nie zmieni świata nie do poznania. 80/

Nie liczyłbym na zdobycie pracy w fantazyjnym zawodzie, który dosłownie nie może być wyobrażony, ponieważ nasze świadomości nie zmieniły się na tyle dzięki AI, aby zyskały zdolność do konceptualizacji tych nowych sposobów pracy. 81/

Ale jeśli *szukasz* pracy, którą AI z pewnością stworzy, w milionach, mam sugestię: usuwanie azbestu cyfrowego. 82/

Kod AI - napisany w 10 000 razy szybszym tempie niż jakikolwiek ludzki programista, zaprojektowany, aby działał dobrze, ale nie aby zawodzić w sposób elegancki - to cyfrowy azbest, którym wypełniamy nasze ściany. Nasze potomstwo spędzi pokolenia na wydobywaniu tego azbestu ze ścian. 83/

Będzie mnóstwo pracy przy naprawianiu rzeczy, które zepsuliśmy dzięki najbardziej niebezpiecznej psychozie AI - halucynacyjnemu przekonaniu, że "pisanie kodu" jest tym samym co "inżynieria oprogramowania." 84/

Przy tempie, w jakim idziemy, będziemy mieli pełne zatrudnienie dla pokoleń usuwaczy azbestu. 85/