Ще недавно програмування здавалося останньою фортецею «справжнього мислення» — ремеслом, де роки практики відділяли майстра від аматора. Але з появою вайб-кодингу та ШІ код почали писати так само легко, як генерувати мем у чаті. І тут головне питання: це кінець програмної інженерії чи, навпаки, новий щабель її розвитку, де код стає масовим інструментом, а справжня складність зміщується на інший рівень? Відповідь на це питання спробував дати журналіст та програміст The Verge Шеон Хан.
Матеріал українською мовою підготувало Бюро перекладів для бізнесу MK:translations. Ми публікуємо адаптований та скорочений переклад.
З вайб-кодингом кожен може спробувати себе в ролі кодера. Але чи зможе він вирости у справжнього інженера-програміста?
Коли я вперше скористався ChatGPT для написання коду — ще на початку 2023 року, — я згадав твір «Мавпяча лапка» (The Monkey’s Paw), класичне оповідання в жанрі горору про проклятий амулет, який виконує бажання, але завжди у зловісний спосіб: результат настає, проте ціна виявляється надто високою. Подібно до цього, ChatGPT із тією ж безкомпромісною буквальністю виконував зміни, які я просив, але водночас псував десятки сторонніх рядків. Вихідний код зазвичай був перенасичений, з нашаруванням зайвих фрагментів. Хоч траплялися й корисні рядки, та їхнє розплутування скидалося радше на обхідний маневр, ніж на допомогу.
Коли ж я почав використовувати інструменти з підтримкою ШІ цього року, мене охопило відчуття, що я безнадійно відстаю. Це було схоже на парне програмування з геніальним інтерном — здібним, але дивно поступливим, надто вже охочим догодити й переписати все підряд на мою команду. Проте коли завдання були локальними й чітко окресленими, він виконував їх із дивовижною точністю.
Секрет у тому, щоб звузити простір задач. Нещодавно я доручив йому переписати десяток рядків коду, які раніше послідовно працювали по 40 мілісекунд, і він зробив так, що вони почали запускатися одночасно. Завдяки цьому вся задача була виконана за той самий час, що раніше займав один рядок. У певному сенсі це схоже на високоточний 3D-принтер для авіабудування: доручіть йому виготовлення дрібних спеціалізованих деталей — наприклад, гідравлічних ущільнювачів чи ущільнювальних кілець, — і він упорається бездоганно; попросіть цілу кабіну літака — і можете отримати кабіну пілотів за формою, але смертельну пастку по суті зі зламаною панеллю управління та випадково встановленими ручками.
Сучасні моделі досить гнучкі, щоб навіть користувачі без досвіду програмування могли створювати продукти різної якості за допомогою так званого вайб-кодингу — мільярдного модного словечка (Google навіть випустила окремий застосунок для цього під назвою Opal).
Машини завжди допомагали нам зменшити навантаження на розумову діяльність, але вперше ми передаємо машині сам процес мислення.
Для програміста, який себе поважає, хаотичне виправлення багів сприймається недоречно. Згодом я усвідомив: найбільш ефективний спосіб роботи з кодом за допомогою ШІ — це редакторський підхід, майже такий самий, який використовувався у випадку цієї статті. Мій редактор доручив мені цю статтю, окреслив кілька орієнтирів, а я — автор — подав чернетку, яку жоден компетентний редактор не опублікував би без правок (до підходу prompt and pray — «запроси та молись» існував підхід assign and wait — «доручи та чекай»).
Так само й вайб-кодер — але відповідальний, — мусить узяти на себе роль редактора. Розлогі блоки коду, які видає ШІ, спершу потребують структурних правок, а потім — редагування на рівні рядків. Через серію підказок — мов через кілька раундів редагування — редактор-кодер мінімізує відстань між своєю візією та фінальним результатом.
Нерідко найцінніше в цих інструментах навіть не написання коду, а його розуміння.
Коли мені нещодавно довелося працювати з незнайомою кодовою базою, я попросив пояснити її базову логіку. ШІ згенерував блок-схему взаємодії основних компонентів, заощадивши мені цілий день блукань у хащах коду.
У мене двояке ставлення до того, на що здатний вайб-кодинг. Письменник усередині мене радіє: це може знищити певну форму снобізму в Кремнієвій долині — оту неприйнятну зверхність інженерів щодо нетехнічних ролей, розмивши цю надуману межу. Водночас інженерська логіка каже мені, що це пуста риторика, адже побудувати нетривіальний продукт виробничої якості без довгих років виснажливого досвіду у сфері розробки ПЗ — надзвичайно складне завдання.
Я завжди вважав, що найкраща метафора для великої кодової бази — це місто. У коді існують буквально «трубопроводи» — потоки даних, черги подій, брокери повідомлень — і транспортні потоки, що потребують складної маршрутизації. Так само як міста поділяють на райони, бо жодна людина чи команда не здатні впоратися з усією цією складністю, системи поділяють на модулі чи мікросервіси. Є ділянки настільки старі, що торкатися їх небезпечно: можна підірвати все — точнісінько як нерозірвані бомби, що досі зберігаються під європейськими містами (лише цього літа у німецькому Кельні знешкодили три бомби часів Другої світової).
Якщо створення нової функції у продукті схоже на відкриття VIP-зали в аеропорту, то масштабніший проєкт — це радше будівництво другого термінала. У цьому сенсі створення застосунку методом вайб-кодингу більше нагадує відкриття крамниці одного дня прямо в залі очікування: вона автономна й не потребує інтеграції з рештою.
Для окремих програм вайб-кодингу більш ніж достатньо. Але найскладніші проблеми інженерії програмного забезпечення не у створенні самодостатніх блоків, а в тому, щоб з’єднати їх між собою так, аби вони працювали разом. Одна справа — відремонтувати окрему квартиру, й зовсім інша — поєднати систему пожежогасіння та аварійного живлення на всіх поверхах так, щоб вона спрацювала у правильній послідовності.
І ці проблеми виходять далеко за межі «внутрішнього оздоблення». Додавання навіть одного нового вузла в розподілену систему може так само легко порушити мережу, як і поява нової будівлі здатна змінити середовище довкола: її аеродинаміку, рівень освітлення сусідніх будинків, напрям пішохідних потоків і безліч вторинних ефектів, які вона запускає.
Проблеми безпеки, пов’язані з вайб-кодингом, на мою думку, радше нагадують привид.
Йдеться не про виняткову експертизу, а про негласне, виборене досвідом знання — здатність не лише виконати завдання, а й правильно визначити наступний крок. У вайб-кодингу можна витягнути з ШІ майже будь-яку відповідь, але справжній виклик — це знати правильну послідовність питань, щоб дістатися потрібного результату. Якщо ви лише займалися ремонтом інтер’єру, але жодного разу не стояли на будівельному майданчику, де заливають бетон у фундамент, ви ніколи по-справжньому не зрозумієте, як зводиться будівля. Звісно, за допомогою ШІ можна зліпити щось, що виглядатиме функціональним, але, як кажуть у програмуванні: «Якщо думаєте, що хороша архітектура обходиться дорого, спробуйте погану».
Якщо вірити Лінусу Торвальдсу, творцю Linux, у програмному забезпеченні є ще й категорія «смаку». Хороша архітектура коду не постає з одного креслення — вона виростає з тисячі дрібних, але правильних і «смаковитих» рішень, чого моделі не можуть відтворити «з нуля». Така інтуїція з’являється лише після специфічної «нейронної травми», отриманої від безлічі нічних викликів о третій ранку.
Можливо, ці аналогії мають межу. Ще кілька місяців тому ШІ міг надійно працювати лише з одним файлом. Тепер він розуміє контекст між кількома теками, а нині, поки я пишу, — і між кількома кодовими базами. Це ніби фігура на шахівниці, яка ще вчора бачила світ очима одного пішака, а сьогодні раптом отримала стратегічний зір на всю партію. І на відміну від художнього «смаку», який має безліч відтінків, «смак» у програмуванні, можливо, є лише сумою шаблонів проєктування, які ШІ може ввібрати з книжок O’Reilly і багаторічних баталій на Hacker News.
Коли нещодавній збій застосунку Tea призвів до витоку десятків тисяч водійських посвідчень його користувачів — і хвиля коментаторів в інтернеті миттєво звинуватила в усьому вайб-кодинг — це виглядало як довгоочікуваний момент тріумфу для скептиків цього підходу. Як завжди, ми могли розраховувати на «ШІ-інфлюенсерів» у X, які прикрасять стрічку своїми «геніальними» думками, і на певний тип критиків у технологічному середовищі — тих, у кого сформувався стійкий інстинкт «полювання на швидку допомогу», які автоматично проклинають будь-яке використання ШІ. У дивній інверсії звичної ролі цапів-відбувайлів інженери-програмісти раптом піднялися на п’єдестал «охоронців безпеки», скориставшись моментом, аби познущатися із зухвалих вайб-кодерів, що наважилися зайти на їхню професійну територію.
Коли ж з’ясувалося, що вайб-кодинг, ймовірно, взагалі не був причиною інциденту, стало очевидно: він радше висвітлив не проблему вайб-кодингу, а нашу вічну схильність ділити технічні збої на «жертв» і «шахраїв», «пригноблених» і «гнобителів».
Навіть якщо це прозвучить як виправдання для продавців ШІ-хайпу, я вважаю, що страхи довкола вайб-кодингу значною мірою перебільшені — навіть більше, чистий ефект може бути не негативним, бо ШІ здатен допомогти робити код безпечнішим.
Ми, безумовно, бачитимемо нові й нові ролики з курйозними ляпами застосунків та небезпечними рядками коду, якими весело ділитимуться в мережі, але більшість цих помилок, підозрюю, можна було б прибрати простим правилом у чеклісті: «Запусти аудит безпеки для цього запиту на увімкнення змін». Уже зараз автоматизовані інструменти позначають потенційні вразливості. Ці інструменти дали мені змогу згенерувати тестів набагато більше, ніж зазвичай я мав би терпіння написати самостійно.
Ба більше, якщо модель достатньо якісна, то на запит «Гей, мені потрібна база даних для зберігання водійських посвідчень» ШІ може відповісти так: «Звісно, але ти забув про безпеку, генію. Ось код, який забезпечує шифрування номерів водійських посвідчень при зберіганні з використанням AES-256-GCM. Я також налаштував систему керування ключами для їхнього зберігання та ротації й додав вимогу подвійного підтвердження для розшифрування. Навіть у разі викрадення даних їхнє розшифрування триватиме аж до теплової смерті Всесвіту. Можеш не дякувати».
У своїй повсякденній роботі я — старший інженер-програміст, який здебільшого займається серверною частиною, іноді — машинним навчанням, а користувацьким інтерфейсом — якщо вже зовсім доведеться — і то з неохотою. У певних аспектах цієї ролі ШІ справді приніс відчутне полегшення. Більше не треба годинами розбиратися з довжелезною документацією API, якщо модель може пояснити все безпосередньо. Більше не доводиться зносити «ритуальне приниження» від модераторів Stack Overflow, які вирішили, що моє запитання не варте навіть відповіді. Натомість у мене тепер є «напарник-програміст», який не засуджує мене за безглузді питання, які могли б зруйнувати мою кар’єру.
Еволюція програмної інженерії — це історія абстракцій.
На відміну від роботи з текстом, я не надто прив’язаний до блоків коду й охоче дозволяю ШІ їх редагувати чи навіть повністю переписувати. Проте свої слова я захищаю з особливою пильністю. Я не використовую ШІ для написання текстів, бо боюся втратити ті рідкісні миті задоволення, коли мені вдається поставити слова саме туди, де їм судилося бути.
Для мене це не лише сентиментальність. Як письменник, що не пише рідною мовою — або, як кажуть, «екзофонічний» — я добре усвідомлюю, як швидко може зникати набута мовна вправність. Я бачив цей корозійний ефект на власні очі в програмуванні. Першою мовою, яку я вивчив з чистого аркуша вже після появи ШІ, була Ruby — і моє відчуття її нюансів помітно слабше, ніж у будь-якій іншій мові, з якою я працював. Я відчуваю, що навіть у тих мовах, які колись знав досконало, моя вправність починає зникати.
Девід Гайнемайєр Ханссон, творець Ruby on Rails, нещодавно влучно сказав, що він не дозволяє ШІ писати код за нього: «Я буквально відчуваю, як компетентність тане прямо в моїх руках». Деякі тривіальні та рутинні завдання, які я колись міг робити хоч під загальним наркозом, тепер викликають у мене мігрень від самої думки виконувати їх без допомоги ШІ.
Чи може штучний інтелект стати фатальним для професії інженера-програміста? Якщо це станеться, світ зможе хоча б потішитися у дусі schadenfreude (злорадної втіхи), спостерігаючи, як професія, що знищувала робочі місця, сама себе робить непотрібною.
Проте, швидше за все, візьме гору парадокс Джевонса: що ефективніший процес, то більше споживання він породжує — і будь-який приріст продуктивності буде нівельований зростанням обсягу роботи.
Це також можна розглядати як логічну траєкторію програмування: розвиток інженерії програмного забезпечення — це постійне зростання абстракцій, які віддаляють нас від «заліза» та підносять до вищих концептуальних рівнів. Шлях від мови асемблера до Python і далі до ШІ можна порівняти з переходом від інструкції «поверни тіло на 60 градусів і пройди 10 футів» до «поверни праворуч на 14-ту вулицю» і зрештою до простого «відвези мене додому», сказаного GPS.
Як програміст із того, що згодом назвуть «епохою до ChatGPT», я не можу не замислитися: чи не залишаємо ми щось життєво важливе, підіймаючись на новий щабель абстракції? У цьому немає нічого нового — це знайомий цикл, що повторюється знову й знову. Коли у 1970-х з’явилася мова C, програмісти на асемблері могли сприйняти це як втрату тонкого контролю. А для тих, хто пише на C, такі мови, як Python, виглядають страшенно повільними й обмежувальними.
Отже, нині, можливо, найлегший час в історії, щоб стати кодером — але, ймовірно, найважчий, аби вирости у справжнього інженера-програміста. Хороший кодер може написати пристойний код, але великий кодер знає, як розв’язати проблему, взагалі не написавши жодного рядка.
І важко уявити, як можна глибоко осягнути основи комп’ютерних наук без тих виснажливих студентських ночей, проведених за ручною реалізацією, скажімо, алгоритму Дейкстри чи червоно-чорного дерева. Якщо ви колись пробували навчитися програмування, дивлячись лише відео, і зазнали невдачі, то причина проста: єдиний спосіб засвоїти його — це власноруч друкувати код. Неможливо навчитися кидати м’яч у корзину зверху, переглядаючи лише найкращі моменти НБА.
Вердикт присяжних усе ще не винесено: чи справді кодування з підтримкою ШІ пришвидшує роботу, адже принаймні одне гучне дослідження свідчить, що навпаки — може сповільнювати. Я схильний у це вірити. Але водночас я вірю й у те, що аби ШІ став справжнім множником у рівнянні продуктивності, нам потрібна нова навичка — я б назвав її своєрідним «розумовим автоматичним вимикачем»: здатність зловити себе на тому, що ти працюєш у режимі бездумного автопілота, і вимкнути його. Секрет у тому, щоб користуватися ШІ лише настільки, аби подолати перешкоду, а потім знову перемикатися на власні «сірі клітини». Інакше можна втратити саму суть, заради якої завдання взагалі виконується.
У дні, коли я налаштований оптимістично, мені подобається думати, що навіть якщо певні здібності атрофуються, ми пристосуємося й сформуємо нові — так, як завжди робили. Але часом підкрадається песимізм: а що, коли цього разу все інакше? Машини завжди допомагали нам зменшити навантаження на розумову діяльність, але вперше ми передаємо машині сам процес мислення. Я не знаю, куди це нас приведе, але знаю напевно: завжди було певною зарозумілістю вважати, що саме твоє покоління — останнє, яке вміє «справді думати».
Якими б не були здобутки, у всьому цьому є відчуття втрати. У своєму есе для The New Yorker 2023 року A Coder Considers the Waning Days of the Craft Джеймс Сомерс дуже влучно відтворив цю емоцію, коли зізнався, що хотів написати «панахиду» кодуванню, бо воно раптом перетворилося на щось таке, де можна досягати тих самих результатів без мислення й без знань. Минуло менш як два роки відтоді, як вийшло це есе, а почуття, які він тоді висловив, лише стали гучнішими й болючішими.
Я, наприклад, відчуваю менше мотивації вчити нові мови програмування просто для задоволення. Радість від освоєння нового синтаксису та престиж від володіння нішевими мовами на кшталт Haskell чи Lisp зникли — тепер, коли ШІ може «видавати» код будь-якою мовою. Мимоволі замислююся: чи не зникла б мотивація вчити іноземні мови, якби застосунки для автоматичного перекладу стали масовими й бездоганними?
Інженери-програмісти люблять скаржитися на дебагінг, але під цим бурчанням завжди ховалася тихенька гордість: у можливості ділитися «бойовими історіями» та хитрими рішеннями. З приходом ШІ чи залишиться місце для таких розмов?
Є два типи інженерів-програмістів: «міські планувальники» та «мініатюристи». Планувальники мислять масштабами — їх цікавить, як система працює у великому вимірі, а не дрібні деталі коду. Вони можуть і зовсім рідко писати код. Мініатюристи ж підходять до внутрішньої архітектури коду з тією ж ретельністю, з якою годинникар працює над механізмом коштовного годинника. Нова парадигма кодування може стати подарунком для «планувальників», але зробить ґрунт непридатним для «мініатюристів».
Мені раз пощастило побачити великого майстра програмування в дії. У коледжі я відвідував курс Браяна В. Кернігана — живої легенди, людини, яка зробила Hello, world традицією програмування, та члена першої команди Bell Labs, що створила Unix. Просто на наших очах він писав код у реальному часі на аскетичному терміналі, використовуючи мінімалістичний редактор vi (не vim, зауважте!), щоб збудувати синтаксичний аналізатор для складного синтаксичного дерева. Йому були непотрібні сучасні інструменти на кшталт IDE — щобільше, він відповідав на електронні листи через поштовий клієнт у терміналі. У цьому була певна естетика.
Згодом програмування, ймовірно, виглядатиме як набір рухів пальців і магічних формул, які колись становили справжнє ремесло. І так само як ми нині з трепетом згадуємо стару команду Bell Labs, так і рутинна робота з ручного пошуку помилок у паралельних процесах чи написання вебсервера з нуля може здаватися справжнім подвигом. Час від часу ми, можливо, ще побачимо старих романтиків, які смакують кожне натискання клавіші — дію водночас гідну, майстерну й безнадійно відірвану від часу.