Кодекс — це відповідальність (а не актив). Технічні керівники цього не розуміють. Вони вважають, що ШІ чудовий, бо він виробляє у 10 000 разів більше коду, ніж програміст, але це просто означає, що він створює у 10 000 разів більше зобов'язань. 1/

Якщо ви хочете прочитати або поділитися версією цієї теми у форматі есе, ось посилання на неї в моєму блозі без спостереження, без реклами та трекерів: 2/

ШІ — це азбест, який ми впиваємо у стіни нашого високотехнологічного суспільства: Кодекс — це ризик. *можливості* коду — це активи. 3/

Мета технічного магазину — мати код, можливості якого приносять більше доходу, ніж витрати, пов'язані з його роботою. 4/

Довгий час компанії плекали хибне переконання, що код коштує дешевше виконувати з часом: після початкового періоду перевірки, під час якого виявляються та усуваються помилки в коді, код перестає потребувати суттєвого обслуговування. 5/

Адже код — це машина без рухомих частин, вона не зношується; Він навіть не зношується. Це теза книги Пола Мейсона 2015 року *Postcapitalism*, яка збереглася дивовижно погано (хоча, можливо, не так погано, як політична довіра самого Мейсона). 6/

Код — це не нескінченно відтворювана машина, яка не потребує зусиль. Натомість це крихка машина, яка вимагає дедалі героїчніших заходів для підтримки робочого стану і зрештою «зношується» (тобто потребує повного рефакторингу). 7/

Щоб зрозуміти, чому код є тягарем, потрібно розуміти різницю між «написанням коду» та «програмною інженерією». «Писати код» — це надзвичайно корисне, веселе та захопливе заняття. 8/

Вона передбачає розбиття складних завдань на окремі кроки, настільки чітко описані, що комп'ютер може надійно їх виконати, оптимізуючи продуктивність шляхом пошуку розумних способів мінімізації вимог коду до ресурсів комп'ютера, таких як оперативна пам'ять і цикли процесора. 9/

Тим часом «програмна інженерія» — це дисципліна, що включає «написання коду», але з акцентом на довгострокові операції *системи*, частиною якої є код. 10/

Інженерія програмного забезпечення займається процесами, які генерують дані, отримані системою. Вона стосується процесів, які передають оброблену інформацію системі. 11/

Він стосується сусідніх систем, які отримують дані від тих самих процесів і/або передають дані до тих самих процесів, куди передає система. 12/

«Писати код» — це створювати код, який *добре працює*. «Програмна інженерія» — це створення коду, який *добре провалюєсь*. Йдеться про створення коду, який читається — функції якого можуть зрозуміти треті сторони, яких можуть попросити підтримувати його. 13/

Ці треті сторони можуть бути запрошені адаптувати процеси нижче, вище або поруч із системою, щоб запобігти її поломкам. 14/

Ось у чому справа: будь-який нетривіальний код має взаємодіяти із зовнішнім світом, і зовнішній світ не статичний, він *динамічний*. Зовнішній світ постійно руйнує припущення, зроблені авторами програмного забезпечення, і щоразу, коли це трапляється, програмне забезпечення потрібно виправляти. 16/

Пам'ятаєте Y2K? Це був день, коли ідеально функціональний код, що працював на абсолютно функціональному апаратному забезпеченні, переставав працювати — не тому, що код змінився, а тому, що *час плив вперед*. 17/

До проблеми Y2038 залишилося 12 років, коли всі 32-бітні версії Unix перестануть працювати, бо вони теж вичерпають обчислювані секунди. 18/

Існування «світу» — це неминучий фактор, який зношує програмне забезпечення і вимагає його відновлення, часто з величезними витратами. Чим довше код діє, тим більша ймовірність, що він зустріне «світ». 20/

Візьмемо код, який пристрої використовують для повідомлення про своє фізичне місцезнаходження. Спочатку це використовувалося для таких речей, як білінг — щоб визначити, яку мережу оператора чи провайдера ви використовуєте і чи роумінгуєте ви. 21/

Потім наші мобільні пристрої використовували цей код, щоб допомогти визначити ваше місцезнаходження і надати вам покрокові вказівки у навігаційних додатках. Потім цей код знову перепрофілювали, щоб допомогти нам знайти загублені пристрої. 22/

Це стало способом знаходити *вкрадені* пристрої, що різко відрізнялося від пошуку загублених пристроїв. Під час пошуку загубленого пристрою вам не доведеться стикатися з можливістю, що зловмисник вимкнув функцію «знайти мій загублений пристрій». 23/

Ці додаткові сценарії використання — upstream, downstream і суміжні — виявили помилки в оригінальному коді, які ніколи не з'являлися в попередніх застосунках. 24/

Наприклад, усі служби визначення місцезнаходження повинні мати якусь стандартну поведінку у (дуже поширеному) випадку, коли вони не зовсім впевнені, де вони знаходяться. 25/

Можливо, у них є загальне рішення — наприклад, вони знають, до якої стільникової щогли підключені, або знають, де були *востаннє* коли отримали точне визначення місцезнаходження — або, можливо, вони зовсім заблукали. 26/

Виявляється, що в багатьох випадках додатки для визначення місцезнаходження малювали коло навколо всіх місць, де вони *могли* бути, а потім встановлювали своє місцезнаходження в середину цього кола. 27/

Це нормально, якщо коло має лише кілька футів у діаметрі, або якщо додаток швидко замінює це наближення на більш точне місцезнаходження. Але що, якщо локація на милі й милі в діаметрі, і виправлення локації *ніколи* не покращується? 28/

Що, якщо місцезнаходження будь-якої IP-адреси без визначеного місця вказане як *центр континентальної частини США*, і будь-який додаток, який не знає, де вона знаходиться, повідомляє, що вона знаходиться в будинку в Канзасі? 29/

А в моєму місті Бербанк, де сервіс обміну місцезнаходженням Google колись повідомив нам, що наша тоді 11-річна донька (телефон якої ми не могли дотягнутися) знаходиться за 12 миль, на з'їзді з автомагістралі в неінкорпорованому районі округу Лос-Анджелес. 32/

(Вона була в найближчому парку, але поза зоною досяжності, і додаток оцінив її місцезнаходження як центр регіону, де востаннє її фіксував.) (Це були важкі кілька годин.) 33/

Базовий код — код, який використовує колись нешкідливий стандарт для підробки невідомих локацій — потребує оновлення *постійно*, оскільки upstream, downstream та суміжні процеси, підключені до нього, змінюються *постійно*. 34/

Чим довше цей код там стоїть, тим більш застарілими стають його початкові поведінки, і тим більш бароковими, шорсткими і прихованими стають пластирі, накладені на нього. 35/

Код — це не актив, це зобов'язання. Чим довше працює комп'ютерна система, тим більше технологічного боргу вона представляє. Чим важливіша система, тим складніше її повністю переробити. 36/

Натомість поверх нього накладаються нові шари коду, і де б вони не зустрічалися, є тріщини, де ці системи поводяться не зовсім одне одного. 37/

Ще гірше: коли дві компанії об'єднуються, їхні розщеплені, тріщини ІТ-системи стикаються, і тепер з'являються *суміжні* джерела технологічного боргу, а також тріщини вгору і вниз по мережі: 38/

Ось чому гігантські компанії так вразливі до атак програм-вимагачів — вони переповнені несумісними системами, які вмовляють у копію сумісності з різними формами цифрової шпаклівки, мотузки та дротів для тюків. 39/

Вони не є водонепроникними і не можна зробити водонепроникними. Навіть якщо їх не знищують хакери, вони іноді просто падають і їх вже не можна підняти. 40/

Пам'ятаєте, як комп'ютери Southwest Airlines зламалися весь різдвяний тиждень 2022 року, залишивши мільйони мандрівників у пастці? 41/

Авіакомпанії особливо погані, бо вони рано комп'ютеризували і ніколи не можуть вимкнути старі комп'ютери, щоб замінити їх новими. Ось чому їхні додатки такі жахливі. 42/

Ось чому так жахливо, що авіакомпанії звільнили своїх працівників служби підтримки і вимагають, щоб пасажири користувалися додатками для *всього*, хоча вони не працюють. Ці додатки ніколи не працюватимуть. 43/

Причина, чому додаток British Airways показує «Сталася невідома помилка» 40-80% випадків, не в тому, що вони звільнили весь ІТ-персонал і передали їх найнижчим гравцям за кордоном. 44/

Це так, звісно — але й те, що перші комп'ютери BA працювали на електромеханічних клапанах, і все з того часу має бути сумісним із системою, яку один із учнів Алана Тюрінга відгриз із цілого колоди своїми передніми зубами. 45/

Код — це зобов'язання, а не актив (новий додаток BA відстає на роки). Кодекс — це ризик. Сервери для терміналів Bloomberg, які перетворили Майкла Блумберга на мільярдера, який працює на RISC-чіпах. 46/

Це означає, що компанія змушена використовувати зменшену кількість спеціалізованих постачальників обладнання та дата-центрів, платити спеціалізованим програмістам і створювати крихкі ланцюги коду для з'єднання цих RISC-систем із їхніми менш екзотичними аналогами у світі. Код — це не актив. 47/

ШІ може писати код, але не може займатися програмною інженерією. Інженерія програмного забезпечення — це про мислення через *контекст* — що буде до цієї системи? Що буде після цього? Що буде поруч із цим? Як зміниться світ? 48/

Програмна інженерія вимагає дуже широкого «контекстного вікна» — того, чого ШІ не має і не може мати. Контекстне вікно ШІ вузьке і поверхневе. Лінійне збільшення контекстного вікна ШІ вимагає *геометричних* розгортань у обчислювальних вимогах: 49/

Писати код, який працює, не враховуючи, як він може вийти з ладу, — це рецепт катастрофи. Це спосіб створити технологічний борг у великому масштабі. Він засовує азбест у стіни нашого технологічного суспільства. 50/

Керівники *не знають*, що код — це тягар, а не актив. Ось чому вони не перестануть замовкнути про чат-ботів, які видають у 10 000 разів більше коду, ніж будь-який людський програміст. 51/

Вони думають, що знайшли машину, яка виробляє *активи* у 10 000 разів швидше, ніж людський програміст. Вони цього не зробили. Вони знайшли машину, яка виробляє *відповідальність* у 10 000 разів швидше, ніж будь-який людський програміст. 52/

Обслуговуваність — це не просто важко здобутий досвід, який навчає, де знаходяться пастки. 53/

Це також вимагає розвитку «Fingerspitzengefühl» — «відчуття кінчиків пальців», яке дозволяє розумно припускати, де можуть виникнути раніше не бачені пастки. 54/

Це форма знання процесу. Це неминуче. Вона не є прихованою навіть у найбільшому корпусі коду, який можна використати як навчальні дані: *Ого* технічні боси цього не розуміють. 55/

Візьмемо, наприклад, Microsoft. Їхня велика ставка зараз — на «агентний ШІ». Вони хочуть встановити шпигунське програмне забезпечення на ваш комп'ютер, яке захоплює кожен натиск клавіші, кожне повідомлення, кожен екран, який ви бачите, і надсилає це в хмару Microsoft, надаючи до нього доступ цілій колекції чат-ботів. 56/

Вони стверджують, що ви зможете сказати своєму комп'ютеру: «Забронюй мені поїзд до Кардіффа і знайди той готель, про який згадував Корі минулого року, і забронюй мені там номер», і це спрацює. Це надзвичайно нездійсненна ідея. 57/

Жоден чат-бот не здатен робити все це, і Microsoft це вільно обґрунтовує. Замість того, щоб робити це з одним чат-ботом, Microsoft пропонує розбити це на десятки чатботів, кожен з яких сподівається забезпечити до 95% надійності. 58/

Це сам по собі абсолютно неправдоподібний стандарт чат-ботів, але подумайте ось про що: ймовірності *множні*. Система, що містить два процеси з надійністю 95%, має чисту надійність 90,25% (0,95 * 0,95). 59/

Якщо розбити завдання на кілька десятків ботів із точністю 95%, ймовірність того, що це завдання буде виконано правильно, зростає до *нуля*. 60/

Тим часом один із керівників Microsoft потрапив у неприємності минулого грудня, коли оголосив на Linkedin про намір переписати *усе* код Microsoft через ШІ. 63/

Рефакторинг кодової бази Microsoft має сенс. Microsoft — як і British Airways та інші традиційні компанії — має багато дуже старого коду, який відображає нежиттєздатний технологічний борг. 64/

Дехто з вас *є* інженерами-програмістами, які знайшли чат-ботів надзвичайно корисними для написання коду для себе. Це поширений парадокс ШІ: чому деякі люди, які користуються ШІ, вважають його справді корисним, а інші — ненавидять? 66/

Чи тому, що ті, хто не любить ШІ, «погано розбираються в ШІ»? Чи це тому, що фанати ШІ ліниві і їм байдуже до якості їхньої роботи? 67/

Без сумніву, є і те, і інше, але навіть якщо навчити всіх бути експертами з ШІ і виключити з вибірки всіх, хто не пишається своєю роботою, парадокс залишиться. 68/

Справжнє рішення парадоксу ШІ полягає в теорії автоматизації та концепції «кентаврів» і «зворотних кентаврів»: 69/

У теорії автоматизації «кентавр» — це людина, якій допомагає машина. «Зворотний кентавр» — це людина, яку примусили *допомагати машині*. 70/

Уявімо, що ви інженер-програміст, який використовує ШІ для написання рутинного коду, який у вас є час і досвід перевірити, застосовуючи свої знання Fingerspitzengefühl і процеси, щоб переконатися, що це відповідає призначенням. 71/

Мені легко зрозуміти, чому використання ШІ (коли ви вирішуєте це у своїх темпах) може бути корисним. Але уявіть, що ви інженер-програміст, якому наказали створювати код у 10x, 100x або 10 000x швидше, ніж попередні. 72/

Припустимо, єдиний спосіб зробити це — через штучний інтелект, і немає людського способу переглянути цей код і переконатися, що він не зламається при першому контакті зі світом, тобі це не сподобається: 73/

(Ви ще більше зненавидите, якщо вас перетворили на «поглинувач» ШІ, особисто відповідальний за його помилки.) Існує ще один спосіб, яким інженери-програмісти вважають код, створений ШІ, надзвичайно корисним: коли цей код *ізольований*. 74/

Якщо ви робите один проєкт — наприклад, конвертуєте одну партію файлів у інший формат, лише один раз — вам не потрібно турбуватися про процеси на нижчому рівні, вгору чи суміжні процеси. Їх немає. 75/

Ви пишете код, щоб зробити щось один раз, не взаємодіючи з іншими системами. *Багато* програмування — це такий утилітарний проєкт. Це нудно, невдячно і готове до автоматизації. 76/

Багато особистих проєктів належать до цієї категорії, і, звісно, за визначенням особистий проєкт — це проєкт кентавра. Ніхто не змушує вас використовувати штучний інтелект у особистому проєкті — завжди ваш вибір, як і коли ви особисто користуєтеся будь-яким інструментом. 77/

Але той факт, що програмісти іноді можуть покращити свою роботу за допомогою ШІ, не скасовує того факту, що код — це ризик, а не актив, і що код ШІ означає масштабне виробництво зобов'язань. 78/

У історії технологічного безробіття існує ідея, що нові технології створюють нові робочі місця, одночасно роблячи старі застарілими: на кожного коваля, якого автомобіль залишив без роботи, припадає робота механіка. 79/

За роки після того, як бульбашка ШІ почала роздуватися, ми чули багато варіантів: ШІ створюватиме робочі місця для «інженерів-підказок» — або навіть створюватиме робочі місця, які ми не можемо уявити, бо вони не існуватимуть, доки ШІ не змінить світ до невпізнання. 80/

Я б не розраховував на роботу у фантазійній професії, яку буквально неможливо уявити, бо наші свідомості не настільки змінені ШІ, щоб вони набули здатності уявляти ці нові способи роботи. 81/

Але якщо ви *шукаєте* роботу, яку ШІ точно створить мільйонами, у мене є пропозиція: цифрове видалення азбесту. 82/

Код ШІ — написаний у 10 000 разів швидше за будь-якого людського програмера, створений для якісної роботи, але не для гідного провалу — це цифровий азбест, яким ми наповнюємо наші стіни. Наші нащадки поколіннями викопуватимуть азбест зі стін. 83/

Буде багато роботи над виправленням того, що ми зламали через найнебезпечніший психоз ШІ — галюцинаторну віру, що «писати код» — це те саме, що й «програмна інженерія». 84/

З такими темпами ми матимемо повну зайнятість на покоління прибиральників азбесту. 85/