Codul este o datorie (nu un activ). Șefii tehnici nu înțeleg asta. Ei cred că AI este grozavă pentru că produce de 10.000 de ori mai mult cod decât un programator, dar asta înseamnă doar că produce de 10.000 de ori mai multe responsabilități. 1/

Dacă doriți o versiune formatată de eseu a acestui subiect pentru a o citi sau a o distribui, iată un link către el pe blogul meu fără supraveghere, fără reclame, fără tracker: 2/

AI este azbestul pe care îl împingem în zidurile societății noastre high-tech: Codul este o responsabilitate. Capabilitățile codului sunt resurse. 3/

Scopul unei companii tech este să aibă cod ale cărui capabilități generează mai multe venituri decât costurile asociate cu menținerea acelui cod în funcțiune. 4/

De mult timp, firmele au cultivat o credință falsă că codul costă mai puțin de rulat în timp: după o perioadă inițială de verificare în care bug-urile din cod sunt identificate și remediate, codul nu mai are nevoie de întreținere semnificativă. 5/

La urma urmei, codul este o mașină fără piese mobile – nu se uzează; Nici măcar nu se uzează. Aceasta este teza cărții lui Paul Mason din 2015, *Postcapitalism*, o carte care a îmbătrânit remarcabil de prost (deși, poate, nu la fel de prost ca propria credibilitate politică a lui Mason). 6/

Codul nu este o mașină infinit reproductibilă care nu necesită muncă. Mai degrabă, este o mașină fragilă care necesită măsuri din ce în ce mai eroice pentru a o menține în stare bună de funcționare și care, în cele din urmă, "se uzează" (în sensul că are nevoie de o refactorizare completă). 7/

Pentru a înțelege de ce codul este o povară, trebuie să înțelegi diferența dintre "scrierea codului" și "ingineria software". "A scrie cod" este o activitate incredibil de utilă, distractivă și captivantă. 8/

Aceasta implică împărțirea sarcinilor complexe în pași discreti, atât de precis descriși încât un calculator le poate executa fiabil, optimizând performanța prin găsirea unor modalități inteligente de a minimiza cerințele pe care codul le impune asupra resurselor calculatorului, cum ar fi memoria RAM și ciclurile procesorului. 9/

Între timp, "ingineria software" este o disciplină care cuprinde "scrierea codului", dar cu un accent pe operațiunile pe termen lung ale *sistemului* din care face parte codul. 10/

Ingineria software se ocupă de procesele upstream care generează datele primite de sistem. Se ocupă de procesele ulterioare către care sistemul emite informații procesate. 11/

Se ocupă de sistemele adiacente care primesc date de la aceleași procese upstream și/sau emit date către aceleași procese downstream către care emite sistemul. 12/

"A scrie cod" înseamnă să faci cod care *rulează bine*. "Ingineria software" înseamnă să creezi cod care *eșuează bine*. Este vorba despre a crea cod care să fie lizibil – ale cărui funcții pot fi înțelese de terți care ar putea fi rugați să-l întrețină. 13/

Aceste terțe părți ar putea fi rugate să adapteze procesele în aval, în amonte sau adiacente sistemului pentru a preveni defectarea acestuia. 14/

Asta e problema: orice cod netrivial trebuie să interacționeze cu lumea exterioară, iar lumea exterioară nu este statică, este *dinamică*. Lumea exterioară sparge presupunerile făcute de autorii de software *tot timpul* și de fiecare dată când o face, software-ul trebuie reparat. 16/

Îți amintești de Y2K? Era o zi în care codul perfect funcțional, rulând pe hardware perfect funcțional, înceta să mai funcționeze – nu pentru că codul s-ar fi schimbat, ci pentru că *timpul trecea mai departe*. 17/

Suntem la 12 ani distanță de problema Y2038, când variantele Unix pe 32 de biți vor înceta să mai funcționeze, pentru că și ele vor fi rămas fără secunde calculabile. 18/

Existența "lumii" este un factor inevitabil care uzează software-ul și necesită reconstrucția acestuia, adesea cu costuri enorme. Cu cât codul funcționează mai mult timp, cu atât este mai probabil să întâlnească "lumea". 20/

Ia codul pe care dispozitivele îl folosesc pentru a raporta locația lor fizică. Inițial, acesta era folosit pentru lucruri precum facturarea – determinarea rețelei operatorului sau furnizorului pe care o folosești și dacă folosești roaming. 21/

Apoi, dispozitivele noastre mobile au folosit acest cod pentru a determina locația ta, pentru a-ți oferi indicații pas cu pas în aplicațiile de navigație. Apoi, acest cod a fost reutilizat din nou pentru a ne ajuta să găsim dispozitivele pierdute. 22/

Aceasta a devenit o modalitate de a localiza dispozitive *furate*, un caz de utilizare care diferă brusc de găsirea dispozitivelor pierdute. Când localizezi un dispozitiv pierdut, nu trebuie să te confrunți cu posibilitatea ca un actor rău intenționat să fi dezactivat funcția "găsește dispozitivul pierdut". 23/

Aceste cazuri suplimentare de utilizare – upstream, downstream și adiacente – au scos la iveală erori în codul original care nu au apărut niciodată în aplicațiile anterioare. 24/

De exemplu, toate serviciile de localizare trebuie să aibă un fel de comportament implicit în evenimentul (foarte comun) în care nu sunt siguri unde se află. 25/

Poate au o soluție generală – de exemplu, știu la ce stâlp de telefonie mobilă sunt conectați, sau știu unde erau *ultima dată* când au obținut o localizare exactă – sau poate sunt complet pierduți. 26/

Se pare că, în multe cazuri, aplicațiile de localizare desenau un cerc în jurul tuturor locurilor în care *ar putea* fi și apoi setau locația lor în mijlocul acelui cerc. 27/

Este în regulă dacă cercul are doar câțiva metri în diametru sau dacă aplicația înlocuiește rapid această aproximare cu o locație mai precisă. Dar ce se întâmplă dacă locația are o lățime de kilometri și fixarea locației *niciodată* nu se îmbunătățește? 28/

Ce se întâmplă dacă locația oricărei adrese IP fără o locație definită este dată ca *centrul SUA continentală* și orice aplicație care nu știe unde se află raportează că se află într-o casă din Kansas? 29/

Și în orașul meu, Burbank, unde serviciul Google de partajare a locației ne-a spus odată că fiica noastră, care avea atunci 11 ani (al cărei telefon nu îl puteam contacta), era la 12 mile distanță, pe o rampă de autostradă într-o zonă neîncorporată a județului LA. 32/

(Era într-un parc din apropiere, dar în afara razei de acțiune, iar aplicația estima locația ei ca fiind centrul regiunii în care fusese fixată ultima dată.) (Au fost câteva ore grele.) 33/

Codul de bază – codul care folosește un fel de implicit odinioară inofensiv pentru a manipula locațiile necunoscute – trebuie actualizat *constant*, deoarece procesele din amonte, din aval și adiacente conectate la el se schimbă *constant*. 34/

Cu cât acel cod stă mai mult acolo, cu atât comportamentele sale originale devin mai învechite, iar patch-urile suprapuse deasupra lor devin mai baroce, murdare și mai obscure. 35/

Codul nu este un atu – este o povară. Cu cât un sistem informatic funcționează de mai mult timp, cu atât reprezintă mai multă datorie tehnologică. Cu cât sistemul este mai important, cu atât este mai greu să-l doboare și să-l refaci complet. 36/

În schimb, noi straturi de cod sunt aplicate peste el, iar oriunde se întâlnesc straturile de cod, există fisuri în care aceste sisteme se comportă în moduri care nu se potrivesc exact. 37/

Și mai rău: când două companii fuzionează, sistemele lor IT cusate și fisurate sunt zdrobite împreună, astfel încât acum există surse *adiacente* de datorii tehnologice, precum și fisuri upstream și downstream: 38/

De aceea, companiile gigante sunt atât de vulnerabile la atacuri ransomware – sunt pline de sisteme incompatibile care au fost convinse să devină compatibile cu diverse forme de plastilină digitală, sfoară și sârmă de balot. 39/

Nu sunt etanșe și nu pot fi făcute etanșe. Chiar dacă nu sunt doborâți de hackeri, uneori pur și simplu cad și nu pot fi puși la loc în picioare. 40/

Îți amintești când calculatoarele Southwest Airlines s-au blocat pe tot parcursul săptămânii de Crăciun din 2022, lăsând milioane de călători blocați? 41/

Companiile aeriene sunt deosebit de slabe, pentru că s-au computerizat devreme și nu pot opri niciodată vechile calculatoare pentru a le înlocui cu altele noi. De aceea aplicațiile lor sunt atât de proaste. 42/

De aceea este atât de groaznic că companiile aeriene și-au concediat personalul de relații cu clienții și obligă pasagerii să folosească aplicațiile pentru *orice*, deși aplicațiile nu funcționează. Aceste aplicații nu vor funcționa niciodată. 43/

Motivul pentru care aplicația British Airways afișează "A apărut o eroare necunoscută" în 40-80% din cazuri nu este (doar) că și-au concediat tot personalul IT și au externalizat către ofertanți mici din străinătate. 44/

Asta este, sigur – dar și faptul că primele calculatoare BA funcționau pe supape electromecanice, iar totul de atunci trebuie să fie compatibil retroactiv cu un sistem pe care unul dintre protejații lui Alan Turing l-a smuls dintr-un buștean întreg cu propriii dinți din față. 45/

Codul este o povară, nu un activ (noua aplicație BA este cu ani întârziere). Codul este o responsabilitate. Serverele pentru terminalele Bloomberg care l-au transformat pe Michael Bloomberg într-un miliardar condus pe cipuri RISC. 46/

Aceasta înseamnă că este blocată să folosească un număr tot mai mic de furnizori specializați de hardware și centre de date, să plătească programatori specializați și să construiască lanțuri fragile de cod pentru a conecta aceste sisteme RISC la echivalentele lor mai puțin exotice din lume. Codul nu este un atu. 47/

AI poate scrie cod, dar AI nu poate face inginerie software. Ingineria software înseamnă să gândești prin *context* – ce va urma înainte de acest sistem? Ce va urma după? Ce va sta alături de ea? Cum se va schimba lumea? 48/

Ingineria software necesită o "fereastră de context" foarte largă, ceea ce AI nu are și nu poate avea. Fereastra de context AI este îngustă și superficială. Creșterile liniare ale ferestrei de context a AI necesită expansiuni *geometrice* ale cerințelor computaționale: 49/

A scrie cod care funcționează, fără să te gândești la modul în care va eșua, este o rețetă pentru catastrofă. Este o modalitate de a crea datorii tehnologice la scară largă. Aruncă azbest în pereții societății noastre tehnologice. 50/

Șefii *nu știu* că codul este o povară, nu un atu. De aceea nu tac naibii despre chatboții care produc de 10.000 de ori mai mult cod decât orice programator uman. 51/

Ei cred că au găsit o mașină care produce *active* cu o rată de 10.000 de ori mai mare decât a unui programator uman. Nu au făcut-o. Au găsit o mașină care produce *responsabilitate* cu o rată de 10.000 de ori mai mare decât orice programator uman. 52/

Mentenanța nu este doar o chestiune de experiență câștigată cu greu care te învață unde sunt capcanele. 53/

De asemenea, necesită cultivarea "Fingerspitzengefühl" – acea "senzație pe vârful degetelor" care îți permite să faci presupuneri rezonabile despre unde ar putea apărea capcanele nemaivăzute până acum. 54/

Este o formă de cunoaștere a proceselor. Este inevitabil. Nu este latent nici măcar în cel mai mare corpus de cod pe care l-ai putea folosi ca date de antrenament: *Doamne* șefii din tehnologie nu înțeleg asta. 55/

Luați Microsoft. Marea lor miză acum este pe "inteligența artificială agentă". Ei vor să instaleze spyware pe calculatorul tău care să captureze fiecare apăsare de tastă, fiecare comunicare, fiecare ecran pe care îl vezi și să le trimită în cloud-ul Microsoft, oferind acces unei multitudini de chatboți. 56/

Ei susțin că vei putea să-i spui calculatorului tău: "Rezervă-mi un tren spre Cardiff și găsește hotelul menționat de Cory anul trecut și rezervă-mi o cameră acolo" și va face asta. Aceasta este o idee extrem de imposibilă. 57/

Niciun chatbot nu este capabil să facă toate aceste lucruri, lucru pe care Microsoft îl presupune liber. În loc să facă acest lucru cu un singur chatbot, Microsoft propune să împartă acest lucru în zeci de chatboți, fiecare dintre care Microsoft speră să aducă până la 95% fiabilitate. 58/

Acesta este un standard complet neverosimil pentru chatbot în sine, dar luați în considerare asta: probabilitățile sunt *multiplicative*. Un sistem care conține două procese care operează cu o fiabilitate de 95% are o fiabilitate netă de 90,25% (0,95 * 0,95). 59/

Împarte o sarcină între câteva zeci de roboți cu o precizie 95% și șansa ca această sarcină să fie îndeplinită corect se reduce la *zero*. 60/

Între timp, un executiv Microsoft a avut probleme în decembrie anul trecut când a postat pe Linkedin anunțându-și intenția ca AI-ul să rescrie *tot* codul Microsoft. 63/

Refactorizarea codului Microsoft are mult sens. Microsoft – la fel ca British Airways și alte firme vechi – are mult cod foarte vechi care reprezintă o datorie tehnologică nesustenabilă. 64/

Unii dintre voi *sunteți* ingineri software care ați găsit chatboții incredibil de utili pentru a scrie cod pentru voi. Acesta este un paradox comun al AI: de ce unii oameni care folosesc AI îl găsesc cu adevărat util, în timp ce alții îl detestă? 66/

Este vorba despre faptul că cei care nu le plac AI sunt "slabi la AI"? Oare fanii AI sunt leneși și nu le pasă de calitatea muncii lor? 67/

Fără îndoială, există unele dintre cele două, dar chiar dacă îi înveți pe toți să fie experți în AI și elimini pe toți cei care nu se mândresc cu munca lor din eșantion, paradoxul va rămâne totuși. 68/

Adevărata soluție la paradoxul AI se află în teoria automatizării și în conceptul de "centauri" și "centauri inverse": 69/

În teoria automatizării, un "centaur" este o persoană asistată de o mașină. Un "centaur invers" este cineva care a fost recrutat să *asiste o mașină*. 70/

Să zicem că ești inginer software și folosește AI pentru a scrie cod de rutină pe care ai timp și experiență să-l validezi, implementând cunoștințele tale despre Fingerspitzengefühl și procese pentru a te asigura că sunt potrivite scopului. 71/

Este ușor de înțeles de ce ai putea găsi utilă folosirea AI-ului (când alegi, în moduri pe care o dorești, într-un ritm pe care îl alegi). Dar să zicem că ești un inginer software căruia i s-a ordonat să producă cod cu 10 ori, 100 sau 10.000 de ori rata anterioară. 72/

Să zicem că singura cale de a face asta este prin AI, și nu există nicio modalitate umană prin care să poți revizui acel cod și să te asiguri că nu se va strica la primul contact cu lumea, îl vei urî: 73/

(Vei urî și mai mult dacă ai fost transformat în responsabilitatea AI-ului, personal responsabil pentru greșelile AI-ului.) Există o altă modalitate prin care inginerii software consideră codul generat de AI extrem de util: atunci când acel cod este *izolat*. 74/

Dacă faci un singur proiect – să zicem, să convertești un lot de fișiere într-un alt format, doar o dată – nu trebuie să-ți faci griji pentru procesele downstream, upstream sau adiacente. Nu există. 75/

Scrii cod pentru a face ceva o singură dată, fără să interacționezi cu alte sisteme. O *mulțime* de programare este genul acesta de proiecte utilitare. Este plictisitor, nerecunoscător și pregătit pentru automatizare. 76/

Multe proiecte personale se încadrează în această categorie și, desigur, prin definiție, un proiect personal este un proiect de centaur. Nimeni nu te obligă să folosești AI într-un proiect personal – este întotdeauna alegerea ta cum și când folosești personal orice instrument. 77/

Dar faptul că inginerii software pot uneori să-și îmbunătățească munca cu AI nu invalidează faptul că codul este o povară, nu un activ, și că codul AI reprezintă producția de datorii la scară largă. 78/

În povestea șomajului tehnologic, există ideea că tehnologia nouă creează locuri de muncă noi chiar dacă le face pe cele vechi învechite: pentru fiecare fierar lăsat fără serviciu de automobil, există un loc de muncă care așteaptă ca mecanic. 79/

În anii de când bula AI a început să se umfle, am auzit multe versiuni ale acestui fenomen: AI ar crea locuri de muncă pentru "ingineri prompt" – sau chiar ar crea locuri de muncă pe care nu ni le putem imagina, pentru că nu vor mai exista până când AI nu va schimba lumea dincolo de orice recunoaștere. 80/

Nu m-aș baza pe a obține un job într-o meserie fantastică care literalmente nu poate fi imaginată pentru că conștiințele noastre nu au fost atât de modificate de AI încât să fi dobândit capacitatea de a conceptualiza aceste noi moduri de lucru. 81/

Dar dacă *cauți* un job pe care AI îl va crea cu siguranță, cu milioanele, am o sugestie: îndepărtarea digitală a azbestului. 82/

Codul AI – scris cu 10.000 de ori viteza oricărui codor uman, conceput să funcționeze bine, dar să nu eșueze grațios – este azbestul digital cu care umplem pereții noștri. Descendenții noștri vor petrece generații săpând azbestul din ziduri. 83/

Va fi multă muncă pentru a repara lucrurile pe care le-am stricat din cauza celei mai periculoase psihoze AI dintre toate – credința halucinoare că "scrisul codului" este același lucru cu "ingineria software". 84/

În ritmul în care mergem, vom avea ocupare deplină pentru generații întregi de factori de îndepărtare a azbestului. 85/