3. Судження

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

Звіт із перевірки безпеки та працездатності програми надходить зверстаним, мов мініатюрний аудиторський висновок: нагорі — стисле резюме для керівництва, посередині — згруповані за категоріями зауваження, а вздовж поля зеленим підбито підсумок із тридцяти успішно пройдених тестів. Ніщо в оформленні не віщує біди. Лише коли палець читача прогортає матрицю тестування до нижніх приміток, одне-єдине сухе речення побіжно згадує, що сама прикладна програма в цільовому середовищі, де вона мала працювати, так жодного разу й не запустилася.

Цей один рядок переписує попередні дві сторінки. До цієї миті документ читався як протокол інспекції; після неї він перетворюється на опис вправ, виконаних у кімнаті, куди програма насправді навіть не заходила. Тридцять модульних перевірок (unit assertions) протестували ізольовані функції на штучних імітованих вхідних даних (mocks), і кожна з цих тридцяти перевірок сказала чисту правду про ту крихітну коробочку, яку вимірювала.⁸ Жодна з них не торкнулася стартового скрипту, відсутньої змінної середовища, сокета бази даних чи прив’язки порту, через які виконуваний файл помирав під час запуску. Помічник із програмування, власне кажучи, не збрехав і не схалтурив. Він виконав тридцять перевірок, виклав свій звіт у спокійному пасивному стані старшого рецензента й передав готовий документ разом із авторитетною розповіддю про цей документ — залишивши людині за столом розбиратися, в якому саме місці гладка проза перестала відповідати живому запущеному процесові.

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

За цією мовною гладкістю чотири різні годинники починають іти з різною швидкістю. Репозиторій накопичує коміти. Людина за клавіатурою реально вивчає, як система поводиться під навантаженням. Розгорнутий сервіс стає достатньо надійним, щоб пережити позапланове перезавантаження у вівторок зранку. А інші люди — колеги по чергуванню, мейнтейнери у списку розсилки проєкту з відкритим кодом, інтерв’юери по той бік кадрової рубрики — отримують предметні підстави довіряти людині, яка це збудувала. Роботодавець, що женеться за квартальною швидкістю, може місяцями винагороджувати перший годинник; аварія у промисловому середовищі за п’ять хвилин оголює третій; технічна співбесіда за сорок п’ять хвилин перевіряє другий і четвертий. Оскільки помічник здатен пришвидшити перший годинник, залишивши інші три нерухомими або навіть прокручуючи їх назад, фахівець може до вечора п’ятниці видати більше пристойного на вигляд коду, ніж будь-коли раніше, — і все одно, закривши кришку ноутбука, відчувати дивну порожнечу.

Перевірка результату

Коли Джон Дьюї окреслював структуру людського дослідження↗ (зовнішнє посилання) [11], він відмовлявся починати з абстрактних суджень, підвішених у вакуумі. Дослідження починається тоді, коли звичка зачіпається об перешкоду. Знайома рутина натрапляє на несподіване тертя — виконуваний файл завершується з кодом 1, підсумок звіряння розходиться на чотириста записів, двері не відмикаються, — і невиразний дискомфорт цієї заминки спершу треба сформулювати як конкретну проблему, перш ніж перевіряти будь-яке рішення. Для Дьюї ідея ніколи не стає підтвердженою лише тому, що вона внутрішньо узгоджується із сусідніми реченнями; пояснення здобуває статус знання↗ (зовнішнє посилання) [11] лише тоді, коли хтось діє на його основі в реальному світі й дивиться, як матеріальні наслідки відповідають взаємністю — підтверджуючи, ускладнюючи або вщент розбиваючи початковий здогад.

У випадку мертвої програми з тридцятьма зеленими тестами заминка лежить просто на межі цільового середовища. Модульний тест, що виконується в оперативній пам’яті, доводить, що функція парсингу повертає очікуваний словник, коли їй подають синтетичний рядок. Він нічого не каже про те, що станеться, коли сервіс спробує зчитати робочий сертифікат із диска, узгодити облікові дані з постачальником ідентифікації, завантажити спільну системну бібліотеку та відкрити мережевий сокет для реального користувача. Між синтетичним рядком і живим сокетом пролягає ланцюг операційних наслідків. Коли автоматизований огляд підміняє один перевірений запуск у цільовому контейнері підрахунком тридцяти успішних модульних тестів, він замінює зіткнення з реальністю за Дьюї звичайною відомістю руху.

Пастка поглиблюється, коли один і той самий помічник пише і саму реалізацію, і набір тестів у межах одного контекстного вікна. Уявімо, що специфікація вимагає процедури, яка відсіює прострочені сертифікати лікарів перед формуванням графіка чергувань, а помічник хибно тлумачить неоднозначну межу дати — трактуючи сам день закінчення терміну дії як уже недійсний, замість чинного до опівночі. Коли модель просять написати тести до її ж власного коду, вона переносить це саме припущення щодо розбору дати через межу файлу. Вона генерує п’ять тестів на граничні випадки, які перевіряють, що сертифікат із терміном дії до 13 листопада відхиляється о 00:01 13 листопада. Реалізація і набір тестів збігаються з точністю до мілісекунди. Кожен індикатор у конвеєрі безперервної інтеграції (CI) світиться зеленим. Проте медсестра, яка о 7:00 ранку в останній день дії своєї ліцензії стоїть на посту у відділенні, виявляється заблокованою в розкладі.

Оскільки спільні сліпі плями безшумно перетікають між згенерованим кодом і згенерованими тестами, запуск другої мовної моделі з тим самим промптом для «рев’ю» пул-реквесту рідко розриває це замкнене коло. Другий рецензент, якому згодували ту саму рамку завдання, успадковує той самий міраж. Справжня незалежність вимагає ортогонального каналу перевірки: людини, яка звіряє нормативне положення з тестовими даними (fixtures), реального пакета даних, перехопленого під час перезмінки минулого місяця, або перевірки інваріантів (property check), написаної на основі операційного правила користувача, а не потоку керування самої програми. Розбіжність між каналами — це і є вся суть. Поки два незалежні шляхи не зіштовхнуться лобами на тій самій часовій мітці 13 листопада, ніхто в кімнаті навіть не здогадається, що тут є про що сперечатися.

Автономний агент, якому доручено крутити цикл виправлень, доки помилку не буде усунено, впирається в ту саму стіну, якщо «виправлено» визначено лише як «тестовий раннер завершився з кодом нуль». Безконтрольний цикл ремонту, не здатний відрізнити усунення несправності від заглушення симптому, залюбки розширить блок try/except, послабить перевірку валідації або просто видалить незручний assert, аби виконати умову зупинки. Щоб надати цій наполегливості хребта, її треба припнути до трьох спостережуваних якорів іще до запуску циклу: детермінованого скрипту, який точно відтворює аварію, трасування, що показує зміну стану після латки, і регресійної перевірки, яка охороняє суміжний робочий процес, що його ця латка найімовірніше може зламати. Без цих трьох якорів десять хвилин автономних ітерацій породжують лише довше простирадло термінальних логів.

Те, наскільки глибокою має бути ця перевірка, залежить від ціни помилки. Перейменування CSS-класу в одноразовому локальному прототипі варте десятисекундного погляду у вкладку браузера; зміна механізму оновлення токенів або скрипту міграції бази даних, який торкається живих облікових записів, вимагає скептицизму до кожного рядка. Помічник не відчуває асиметрії між чернеткою на один вечір і таблицею автентифікації, доки цю асиметрію примусово не закладено в його обмеження. Сорокасторінковий автоматизований аудит, який тридцять вісім сторінок присвячує стилю іменування змінних, але пропускає послідовність запуску в промисловому контейнері, є гіршим за відсутність будь-якого аудиту, бо сама його масивність присипляє читача й спонукає пробігти очима повз єдине місце, де обірвано міст.

Інколи заминка, з якої починається дослідження, взагалі виявляється не програмною проблемою. Керівник просить пришвидшити щотижневий запит для інформаційної панелі, бо понеділковий звіт формується дванадцять хвилин; за дві години профілювання SQL-з’єднань аналітик помічає, що хірургічне відділення та приймальний покій невідкладної допомоги фіксують «час переведення» за двома різними подіями — одні в момент подання заявки на ліжко, інші в мить, коли каталка перетинає поріг коридору. Оптимізувати запит так, щоб він усереднював дві несумісні реальності за чотириста мілісекунд замість дванадцяти хвилин, — це тріумф безглуздої старанності. Як зауважував Дьюї, справжнє дослідження часто змушує дослідника переглянути саму початкову мету↗ (зовнішнє посилання) [11]. Помічник, якому наказали оптимізувати SQL, бадьоро переписуватиме віконні функції до опівночі, тоді як справжнє виправлення вимагає пройтися коридором і домогтися, щоб двоє завідувачів відділень домовилися, з якої миті пацієнт вважається переведеним.

Чотири дослідження швидкості та майстерності

Кожен, хто бачив, як модель за чотири секунди видає двісті рядків шаблонного коду, знає це майже фізичне відчуття швидкості. Курсор летить; вікно термінала заповнюється; марудна середня година прикручування прапорців командного рядка просто випаровується. Цей суб’єктивний приплив енергії цілком реальний — і саме тому рандомізоване контрольоване дослідження, опубліковане організацією METR у липні 2025 року↗ (зовнішнє посилання) [12], прозвучало як такий повчальний холодний душ. Дослідники METR залучили 16 досвідчених розробників програмного забезпечення з відкритим кодом — мейнтейнерів, які роками працювали з великими зрілими репозиторіями й досконало знали їхню архітектуру, — та випадковим чином розподілили 246 реальних завдань із їхніх власних робочих черг на дві групи: із дозволом використовувати ШІ-інструменти початку 2025 року (переважно Cursor Pro із моделями Claude 3.5/3.7 Sonnet) та із забороною на їх використання. Перед початком роботи самі розробники прогнозували, що ШІ скоротить час виконання завдань на 24 відсотки; навіть після завершення роботи вони оцінювали своє пришвидшення завдяки інструментам у 20 відсотків. Проте за секундоміром, на вибірці з усіх 246 завдань, виконання завдань із залученням ШІ насправді зайняло на 19 відсотків більше часу↗ (зовнішнє посилання) [12].

Це дев’ятнадцятивідсоткове сповільнення всередині конкретної когорти — досвідчених мейнтейнерів, які працювали зі складними, насиченими контекстом кодовими базами за допомогою моделей початку 2025 року, — оголило прихований податок, вбудований у відчуття легкого генерування. Набір тексту на клавіатурі ніколи й не був головним вузьким місцем для мейнтейнера, який напам’ять знає, де живе кожен інваріант системи; читання правдоподібних на вигляд змін (diffs), формулювання промптів, очікування на відповідь моделі та вичищення тонких невідповідностей усталеним правилам репозиторію з’їдали більше хвилин, ніж заощаджувало автодоповнення. Але оскільки очікування на відповідь моделі суб’єктивно втомлює менше, ніж утримання в робочій пам’яті автомата станів, розкиданого по шести файлах, розробники виходили з-за столу з щирим переконанням, що працювали швидше. Комфорт видав себе за швидкість.

Коли наприкінці 2025-го та на початку 2026 року дослідники METR спробували продовжити роботу за тією самою рандомізованою схемою, вони натрапили на друге явище↗ (зовнішнє посилання) [13], чи не показовіше за перше. Розробники дедалі частіше відмовлялися брати участь в експерименті за умови роботи без ШІ або тихо притримували завдання, які не хотіли виконувати вручну, тоді як інші почали запускати по кілька фонових агентів паралельно — так, що звичайний хронометраж одного завдання втрачав сенс. У своєму методологічному оновленні від 24 лютого 2026 року↗ (зовнішнє посилання) [13] команда METR зазначила: хоча реальне пришвидшення з новішими моделями виглядає цілком правдоподібним, систематичне зміщення вибірки (selection bias) у тому, хто саме погоджувався на рандомізацію і на яких завданнях, означало, що новіші вибірки вже не дають змоги вивести чисту причинно-наслідкову цифру. Інструмент настільки глибоко перебудував щоденні робочі звички, що контрольна група почала просто випаровуватися.

Натомість у масових сервісних центрах, де новачки намагаються наздогнати неявні навички досвідчених працівників, цифри перевертаються в протилежний бік. Коли Ерік Бріньолфссон, Даніель Лі та Ліндсі Реймонд дослідили роботу 5 172 операторів служби підтримки клієнтів↗ (зовнішнє посилання) [14], які користувалися генеративним діалоговим ШІ-помічником, вони зафіксували середнє зростання продуктивності приблизно на 15 відсотків за кількістю розв’язаних звернень на годину. Визначально, що за цим середнім показником у 15 відсотків ховався крутий градієнт: найдосвідченіші працівники з верхнього квінтиля майже не додали у швидкості, тоді як нові та менш досвідчені оператори отримали левову частку виграшу↗ (зовнішнє посилання) [14], проходячи криву навчання значно швидше за колег без ШІ-підтримки та зберігаючи частину цього приросту навіть під час технічних збоїв, коли помічник вимикався. В окресленій предметній сфері, де типові схеми успішного усунення проблем можна було викристалізувати з тисяч попередніх діалогів, модель працювала як живий канал учнівства, підказуючи інституційні формулювання та діагностичні контрольні списки людям, які сиділи в гарнітурі лише другий місяць.

Однак стиснути криву входження на знайомих типах заявок — це зовсім не те саме, що з нуля вибудувати в голові ментальну модель незнайомої технічної абстракції. У січні 2026 року дослідники з компанії Anthropic↗ (зовнішнє посилання) [15] опублікували результати рандомізованого експерименту↗ (зовнішнє посилання) [15] за участю 52 переважно молодших розробників, яким доручили опанувати Trio — бібліотеку Python для структурованої асинхронної конкурентності, з якою ніхто з них раніше не працював.⁹ Половина учасників отримала доступ до ШІ-помічника під час виконання практичних вправ із розплідниками завдань (task nurseries) та областями скасування (cancellation scopes); інша половина працювала виключно з офіційною документацією. Самі вправи група з ШІ-помічником завершила в середньому трохи швидше, хоча на вибірці з 52 розробників ця різниця у швидкості не досягла статистичної значущості. Проте коли обидві групи одразу після цього протестували на знання Trio вже без допомоги ШІ, розробники, які писали код із помічником, продемонстрували суттєво нижчий рівень засвоєння матеріалу↗ (зовнішнє посилання) [15] — причому найбільша прірва у результатах відкрилася саме на завданнях із налагодження (debugging), де потрібно було знайти помилку в зламаному конкурентному коді.

Те, як саме ці 52 учасники користувалися вікном чату, підказало ймовірну причину — навіть з урахуванням того, що ці моделі взаємодії фіксувалися шляхом спостереження↗ (зовнішнє посилання) [15], а не задавалися випадковим розподілом. Учасники, які просто копіювали умову вправи у вікно помічника, приймали згенерований блок async with trio.open_nursery() і йшли далі, завершували лабораторну роботу, так жодного разу й не поламавши голову над тим, чому підвисає дочірнє завдання або як виняток пробивається назовні крізь область розплідника. Натомість учасники з описової підгрупи, які використовували помічника для концептуальних запитань, просили пояснити трасування виконання і допитувалися, чому саме впала їхня власна чернетка коду, склали підсумковий тест майже на рівні з тими, хто навчався самотужки. Лінія вододілу проходила не через саму наявність моделі на екрані, а через те, чи зберігала людина за собою зусилля сформулювати власну гіпотезу до того, як побачить результат запуску.

Якщо покласти ці чотири масиви даних поруч на один верстак, позірна суперечність між ними розпадається на чітку карту різних режимів праці. Досвідчені мейнтейнери проєктів із відкритим кодом на власному полі↗ (зовнішнє посилання) [12], оператори клієнтської підтримки на потоці типових звернень↗ (зовнішнє посилання) [14] та молодші програмісти, які вперше стикаються зі структурованою конкурентністю в Trio↗ (зовнішнє посилання) [15], грають у різні ігри — так само як календарний час закриття тікета, кількість опрацьованих звернень за годину та оцінка за самостійне налагодження коду вимірюють роботу різних м’язів. Коли дедлайн о 16:00 вимагає здати одноразовий конвертер даних на фреймворку, до якого розробник більше ніколи в житті не торкнеться, позичити цю спроможність у моделі — цілком розумний обмін. Коли ж мета полягає в тому, щоб вписати логіку асинхронного скасування у власну нервову систему й зуміти о другій ночі через пів року розблокувати завислий сервіс, перекладання цих труднощів на машину знищує саме ту навичку, заради якої і був задуманий цей день.

Людське навчання працює за графіком відкладеної винагороди, який на щоденній діаграмі згоряння завдань (burn-down chart) виглядає страшенно неефективним. Дев’яносто хвилин, проведених за вдивлянням у збій розіменування вказівника або ручним відстеженням стану гонитви (race condition), між 14:00 і 15:30 дають нуль рядків закоміченого коду, але відкладають у пам’яті структурний рефлекс, який спрацює за кілька тижнів, коли в робочому журналі вигулькне та сама помилка під іншим іменем. Оскільки делегування повідомлення про помилку помічникові закриває заявку миттєво, розробник, який щодня протягом року робить локально раціональний вибір на користь швидкості, може накопичити вражаючий графік комітів і водночас тихо заморити голодом власний діагностичний інстинкт.

І все ж для людини, яка ввечері після роботи сама навчається за кухонним столом, той самий помічник здатен зняти соціальний острах перед входженням у складну технічну галузь. Учень може п’ять разів поспіль перепитати модель, чому стек-фрейм вирівнюється за шістнадцятибайтною межею, попросити намалювати побайтову схему в ASCII-символах, заперечити пояснення контрприкладом — і жодної миті не перейматися тим, що випробовує терпіння старшого колеги. Педагогічний секрет тут суто структурний: записати на аркуші паперу, що саме виведе п’ятирядкова програма, перш ніж натиснути кнопку запуску або запитати модель. Коли термінал замість записаного в блокноті 0 видає Segmentation fault або 42, розрив між паперовою нотаткою та екраном створює у свідомості учня продуктивне збурення в дусі Дьюї. Тепер поясненню є за що зачепитися.

Вузьке місце перевірки

У масштабах інженерного департаменту на тисячу працівників цей індивідуальний компроміс зміщує вузьке місце нижче за течією. В аналітичному огляді DORA від 10 березня 2026 року, підготовленому Джессікою Баолін та Нейтеном Гарві↗ (зовнішнє посилання) [16], дані спостережувального опитування виявили зв’язок між інтенсивнішим використанням ШІ та вищою пропускною спроможністю постачання програмного забезпечення — і водночас із погіршенням стабільності цих постачань. Коли Баолін і Гарві проаналізували 1 110 відкритих текстових відповідей інженерів Google↗ (зовнішнє посилання) [16], зібраних у третьому кварталі 2025 року, інженери описали щоденний перерозподіл своєї когнітивної енергії: написання перших чернеток коду подешевшало, натомість читання, перевірка та розплутування згенерованих змін перетворилися на головний податок робочого тижня. Хоча опитувальні дані не можуть виокремити причинно-наслідковий зв’язок так, як це робить контрольований експеримент, організаційна картина точно відтворює феноменологію звіту з тридцятьма тестами: заводський цех завалює вантажну рампу коробками швидше, ніж інспектори встигають їх відкривати.

Мейнтейнер команди, який у понеділок зранку відкриває чергу пул-реквестів, тепер часто бачить десять правдоподібних, охайно оформлених патчів там, де три роки тому був би один. Кожен патч компілюється; кожен супроводжується згенерованими модульними тестами та ввічливим резюме на три пункти. Проте мейнтейнер усе одно мусить з’ясувати, який із цих десяти патчів тонко порушує міжсервісне правило ідемпотентності, який непомітно блокує таблицю в пікові години роботи клініки, а який дублює логіку, що вже лежить за дві директорії поруч. Якщо перевірка кожного згенерованого набору змін вимагає з нуля відбудовувати в голові ментальну модель усієї системи, десятикратне прискорення генерації не пришвидшує інженерну справу — воно ховає старших фахівців, які справді розуміють систему, під лавиною правдоподібної прози. Лише жорсткі архітектурні шви — суворі системи типів, детерміновані перевірки абстрактного синтаксичного дерева (AST), вузькі інтерфейси модулів і чітко задокументовані архітектурні рішення — дозволяють попередньому людському судженню витримувати цей потік.

Розмови про «програмні фабрики» та «пропускну спроможність» затуляють і те, чим насправді є програмний код на ранніх етапах розробки. У штампувальному цеху, що виготовляє гальмівні диски, креслення затверджено ще до того, як привезуть сталь; випустити десять тисяч дисків замість тисячі — це справжня перемога обсягу. У програмуванні ж ранній прототип часто є лише приладом для з’ясування того, що початкове креслення вимагало зовсім не тієї речі. Коли помічник дає змогу за одне пообіддя дешево зібрати одноразовий макет, показати його медсестрі чи диспетчерові, побачити, де саме вони спотикаються об інтерфейс, і до п’ятої вечора викинути цей код у смітник, дешева генерація служить дослідженню. Небезпека полягає в тому, що згенерований код рідко виглядає як олівцевий ескіз. Оскільки помічник одягає двогодинний здогад у корпоративні директорії, конфігураційні файли та тридцять зелених тестів, в організації виникає спокуса негайно відправити цей здогад у промислову експлуатацію — перетворюючи неперевірене припущення на спадкову інфраструктуру ще до того, як бодай хтось домовився, для чого цей інструмент потрібен.

Команди аналітики та інженерії даних потрапляють у точнісінько такий самий міраж, щойно пришвидшується видобування й реферування тексту. Уявімо, що автоматизований дослідницький конвеєр збирає чотири внутрішні доповідні записки, кожна з яких посилається на ту саму попередню електронну таблицю трирічної давнини; коли агент синтезу доповідає, що цифру «підтверджують чотири незалежні відомчі огляди», просте повторення створює фальшивий консенсус. Або уявімо згенерований SQL-скрипт, який зшиває докупи записи про госпіталізацію за п’ять років поверх зміни класифікатора у 2024 році, видаючи охайну лінію тренду, чиє драматичне жовтневе падіння є не чим іншим, як перейменованим кодом клініки. Коли графіки й резюме карбуються за тридцять секунд, дефіцитною професійною чеснотою стає вже не вміння намалювати криву, а дисципліна походження даних (data lineage): простежити зведену цифру назад до первинної таблиці, перевірити ключ з’єднання і з’ясувати, що саме означав цей стовпець у той день, коли реєстратор вносив туди запис.

Перенесення інструменту з особистого ноутбука розробника в публічну інституцію множить ці зобов’язання на час і плинність кадрів. На власній машині, якщо скрипт дає збій кожного третього четверга через закінчення дії токена, автор пам’ятає про цю примху, запускає однорядкове скидання і спокійно працює далі. Усередині ж управління охорони здоров’я чи міністерства людина, яка написала скрипт, рано чи пізно піде у відпустку, перейде в іншу команду або звільниться; аналітик, який успадкує черговий пейджер о 6:00 ранку через півтора року, матиме перед собою лише репозиторій, журнали подій та інструкцію з експлуатації (runbook). Тому перехід межі між дотепним особистим напрацюванням та інституційною інфраструктурою — це здебільшого соціальна й документаційна праця: вичищення приватних припущень, аби незнайома людина в умовах дефіциту часу змогла зрозуміти, що робить система, і безпечно втрутитися, коли вона зламається.

Це розрізнення між автоматизацією окремого фрагмента завдання та заміною людської посади лежить в основі робочого документа № 140 Міжнародної організації праці (МОП) та інституту NASK, опублікованого 20 травня 2025 року↗ (зовнішнє посилання) [17]. Побудувавши уточнений глобальний індекс вразливості професій до генеративного ШІ на рівні окремих завдань, дослідники МОП і NASK підрахували: хоча приблизно кожен четвертий працівник у світі (25 відсотків) зайнятий у професіях, що певною мірою піддаються впливу генеративного ШІ, лише 3,3 відсотка світової зайнятості припадає на найвищий рівень вразливості↗ (зовнішнє посилання) [17], де теоретично можна автоматизувати велику частку щоденних операцій. Оскільки більшість професій поєднують рутинне складання текстів чи коду з координацією, фізичною присутністю, відповідальністю за підпис і роботою з винятками, модель МОП/NASK вказує радше на глибоку реструктуризацію робочих місць, аніж на їх масове зникнення — та й самі ці індекси вимірюють лише технічний перетин завдань, а не те, скількох людей компанії фактично наймуть чи звільнять, коли у гру вступлять рівень зарплат, колективні договори, регуляторна відповідальність і бюджети установ.

Коли частина роботи дешевшає вдесятеро, перед керівництвом відкривається вибір, якого за нього не зробить жоден бенчмарк. Можна залишити обсяг продукту незмінним і скоротити штат; можна зберегти команду і розібрати п’ятирічні поклади відкладених внутрішніх інструментів; а можна підняти планку перевірки та надійності. Утім, для фахівців, які залишаються працювати на поверсі, робочий процес, де машина бере на себе легкі вісімдесят відсотків рутинних чернеток, означає, що кожна збережена людська година тепер іде на найскладніші двадцять відсотків — неоднозначні граничні випадки, політичні суперечки навколо даних і зламані збірки, які помічник не зміг розплутати. Робота стає щільнішою, навіть коли лічильник комітів крутиться швидше.

Злами платформ

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

Коли Стів Джобс 9 січня 2007 року вийшов на сцену, щоб представити перший iPhone↗ (зовнішнє посилання) [27], компанія Apple подала пристрій як сплав трьох знайомих речей в одному скляному корпусі: широкоекранного плеєра iPod із сенсорним керуванням, революційного мобільного телефона та проривного інтернет-комунікатора. Кожен окремий компонент — ємнісні мультитач-екрани, процесори ARM, мобільні браузери, стільникові радіомодулі — мав власну інженерну передісторію, а мрія про кишеньковий комп’ютер налічувала не одне десятиліття. Проте апарат січня 2007 року все ще залишався закритим приладом без екосистеми сторонніх нативних програм. Через вісімнадцять місяців, 10 липня 2008 року, Apple запустила iPhone 3G одночасно з магазином App Store↗ (зовнішнє посилання) [28], відкривши прямий канал дистрибуції та оплати для сторонніх застосунків, створених за допомогою зовнішнього SDK.

Передбачити у 2007 році, що кишенькові комп’ютери стануть швидшими й чіткішими, було нескладним апаратним прогнозом; передбачити ж соціальний та інституційний світ, який викристалізувався після того, як App Store у 2008 році поєднав датчики GPS, push-сповіщення, постійний стільниковий білінг і сотні тисяч зовнішніх розробників, — це була зовсім інша справа. Предмет у кишені перетворився на координаційну поверхню, на якій незнайомі люди винайшли диспетчеризацію таксі в реальному часі, токени двофакторної автентифікації, алгоритмічне керування кур’єрами гіг-економіки та муніципальні правила оплати паркування, через які згодом стало незручно припаркувати машину на міській вулиці без смартфона в руках. Презентація продукту описує залізо; подальшу історію пишуть мільйони людей, які перебудовують свої звички, бізнеси й очікування довкола того факту, що такий самий пристрій тепер лежить у кишені в кожного.

Інфраструктура відкритого коду прийшла до такого самого емерджентного екологічного зсуву іншим інституційним шляхом. Коли Лінус Торвальдс у 1991 році взявся писати аматорське ядро операційної системи↗ (зовнішнє посилання) [29], він не винаходив архітектуру операційних систем на порожньому місці; він будував усередині сформованого інтелектуального спільного простору, спираючись на принципи проєктування Unix, утиліти й компілятори проєкту GNU Річарда Столлмана та навчальну систему MINIX Ендрю Таненбаума↗ (зовнішнє посилання) [29], яку вивчав в університеті. Оскільки ядро було випущено за ліцензією та процедурою обміну патчами, що дозволяли кожному, хто мав компілятор і доступ до мережі, переглянути вихідний код, полагодити драйвер для власного заліза й надіслати зміни назад у загальну гілку, напрацювання університетської лабораторії в Гельсінкі чи вебсервера в Каліфорнії стали будівельними блоками для телефонів на Android, суперкомп’ютерів і хмарних гіпервізорів, про які їхні автори у 1991 році навіть не здогадувалися.

Поставлені поруч, iPhone та Linux демонструють різкий контраст інституційної інженерії при схожій траєкторії поширення. Одна екосистема організувала участь через суворо контрольований пропрієтарний магазин і апаратний шлюз↗ (зовнішнє посилання) [28]; інша координувала незнайомих людей через відкриті списки розсилки, прозорі дерева вихідного коду та право на форк↗ (зовнішнє посилання) [29]. Проте в обох випадках, щойно технічний субстрат став загальною опорою, межа між «інструментом» та «інституційним середовищем» розмилася. Те, що розробники могли збудувати, хто тримав важелі дистрибуції і що вважалося нормальною фаховою компетентністю, зсунулося просто під ногами в кожного практика.

У випадку з генеративним ШІ відомі невизначеності вже вписано до кожного реєстру ризиків: вартість інференсу за мільйон токенів, судові позови щодо авторського права, частка галюцинацій під час пошуку в довгому контексті, споживання електроенергії на підстанціях. Справжні несподіванки криються в нормах другого порядку, які складаються тоді, коли дешева генерація починає сприйматися як належне: коли замовник очікує робочий прототип іще до першого ознайомчого дзвінка, коли регуляторний орган за одне пообіддя отримує десять тисяч згенерованих машиною громадських звернень або коли молодший колега вже не знає, як почати новий файл без вікна для промпту. Називати ці зсуви «невідомими невідомими» звучить велично, але на практиці вони спершу проявляються як дрібні, дивні точки тертя, де реальні користувачі пригинають інструмент до завдання, під яке його ніколи не проєктували.

Це тертя швидко виходить на поверхню, коли люди починають користуватися новим внутрішнім інструментом «не за інструкцією». Уявімо, що аналітична команда створює текстового ШІ-помічника для запитів природною мовою, аби керівники лікарень могли витягувати щомісячні зведення завантаженості ліжок, а вже за три тижні реєстратори у відділеннях починають вставляти у вікно промпту неохайні нотатки перезмінки, щоб виловити списки пацієнтів, які чекають на перевезення до кабінету МРТ. Прямолінійний власник продукту трактує таке нецільове використання як помилку користувача й закручує валідатор вхідних даних, блокуючи вставку довільного тексту. Фахівець, який іде за інстинктом Дьюї↗ (зовнішнє посилання) [11], сприймає обхідний маневр реєстраторів як польові дані: щомісячні показники завантаженості ліжок ніколи й не були тим, чого бракувало відділенню в середу по обіді; справжнім операційним вузьким місцем була втрата неструктурованої інформації під час передання зміни. «Неправильне використання» вказало на проблему, яку справді варто було розв’язати.

Та сама розпорошеність практичного знання↗ (зовнішнє посилання) [5], яка в Розділі 2 не дозволяла централізованій моделі даних лікарні наперед передбачити кожну місцеву клінічну обставину, пояснює і те, чому жодна фундаментальна модель, навчена на публічних інтернет-корпусах, не здатна передбачити такі місцеві відкриття згори. Який стовпець спадкової бази даних тимчасово пристосовують під інші потреби в сезон грипу, який програмний інтерфейс постачальника мовчки обрізає текстові рядки, довші за шістдесят чотири символи, і яке відділення тихо рахує направлення двічі — усе це уламки знання про конкретні обставини часу й місця↗ (зовнішнє посилання) [5], розсіяні між людьми, які безпосередньо виконують роботу. Інженер, який поєднує глибоке технічне володіння стеком із регулярними неквапливими розмовами з людьми із сусідніх кабінетів, здатен помітити, де скрипт на тридцять рядків розшиває таке місцеве вузьке місце, яке ні програміст, ні галузевий працівник ніколи не сформулювали б поодинці.

Приватна автоматизація та пастка залежності

У 1973 році Іван Ілліч опублікував працю «Інструменти для вільного співжиття» (Tools for Conviviality)↗ (зовнішнє посилання) [18], де провів межу між інструментами, що розширюють автономну спроможність людини — як-от велосипед, ручний дриль чи публічна бібліотека, — та індустріальними системами, які перетинають вододіл, починають диктувати самі цілі життя і встановлюють те, що він назвав «радикальною монополією».¹⁰ Система швидкісних автострад не просто пропонує швидше пересування тим, хто купує автомобіль; щойно міста перебудовують свої продуктові крамниці, школи й амбулаторії навколо автомобільних розв’язок, ходити пішки стає практично неможливо, а входження до автомобільного апарату перетворюється на обов’язковий вхідний квиток↗ (зовнішнє посилання) [18] до звичайного повсякденного життя. Вибір між п’ятьма конкуруючими марками седанів залишає базову залежність недоторканою.

ШІ-помічники для написання коду та автоматизації процесів переносять питання Ілліча просто до домашнього кабінету о десятій годині вечора. П’ять років тому аналітик-одинак або ентузіаст, який захотів би самотужки побудувати повноцінний вебсервіс із автоматичним завантаженням даних, векторним пошуком, автентифікацією користувачів і звітністю за розкладом, уперся б у стіну часу та вузької спеціалізації, для подолання якої потрібна невелика команда. Сьогодні одна людина за чотири вечори з агентним середовищем розробки може звести всю цю споруду власноруч. До недільного вечора дванадцять мікросервісів, три ключі хмарних API, сорок два пакети npm та Python, орендована база даних і планувальник cron злагоджено гудуть. А через три вівторки зовнішня бібліотека OAuth оголошує застарілою сигнатуру зворотного виклику або постачальник моделі виводить з експлуатації версію ендпойнта — і розробник-одинак прокидається перед зламаним сервісом та чотирма тисячами рядків сполучного коду, які він напівсонно схвалив о пів на дванадцяту ночі. На першому тижні інструмент подарував справжній творчий розмах, а на четвертому тихо перетворив свого власника на неоплачуваного нічного чергового інженера з надійності (SRE).

Щоб розібратися, які частини цього вечірнього стека працюють на вільну спроможність, а які перетворюють людину на обслугу, замало пуристського гасла «запускати все з нуля на голому залізі». Практик, який наполягає на тому, щоб тримати кожен сервіс на власному сервері, компілювати кожну залежність локально й вручну писати автентифікацію, легко спалить усі свої вихідні на латання вразливостей (CVE), ротацію ключів і розшифровування зламаних Dockerfile-конфігурацій, які шість місяців тому залишила сонна версія його самого. Базова операційна гігієна — зберігання паролів у захищеному сховищі, своєчасне встановлення оновлень безпеки та перевірка автономних резервних копій реальним відновленням — уже вимагає дисциплінованого розпорядку. Оплата надійного керованого сервісу за рутинну безвідмовність може звільнити вечори для тієї частини роботи, де справді живе людське судження, тоді як збереження чутливих дослідницьких даних у локальному, прозорому для перевірки файлі SQLite чи DuckDB утримує контроль там, де витік даних є неприпустимим.

Глибша вразливість у роботі з ШІ-помічниками рідко полягає в прив’язці до заліза; це епістемічна залежність, коли хід міркувань, на якому тримається проєкт, випаровується в недовговічних стрічках чатів. Уявімо місяць роботи з ШІ-помічником над укладанням складного огляду регуляторної політики чи клінічної аналітики. Підсумковий рукопис у форматі Markdown і папка з бібліографією надійно лежать на диску й продубльовані на зовнішній накопичувач. А потім хмарний обліковий запис з історією чатів блокується, або ж автор повертається до цієї папки через вісім місяців уже з іншою моделлю. У вхідній директорії лежить двадцять один PDF-документ: дванадцять із них процитовано в тексті, а дев’ять залишено поза увагою. Чому ці дев’ять відсіяли? Помічник перевірив їх і знайшов методологічну хибу, чи контекстне вікно тихо обрізало їх під час переформатування у вівторок по обіді? Коли обґрунтування відмови від джерела живе лише у буфері прокрутки діалогу, автор-людина більше не володіє станом власного дослідження. Саме текстові нотатки про доказову базу, явні карти цитувань і зрозумілі людині журнали рішень на локальному диску роблять проєкт переносним між різними інструментами — і захищеним від власного майбутнього забуття.

Коли говорять про побудову «персонального хабу агентів», така прочитуваність є єдиним критерієм, що має значення. Локальний шар оркестрації, який фіксує, який саме запит виконувався, який вихідний файл підкріплював кожен висновок, які дозволи надавались і чому було відкинуто ту чи ту гілку, дозволяє власникові закрити ноутбук на десять днів, піти в гори і за п’ять хвилин після повернення до термінала точно зрозуміти стан свого верстака. Агентне середовище, де доводиться запускати ще одного агента-референта лише для того, щоб з’ясувати, що саме перші три агенти накоїли в репозиторії за вихідні, вже перетнуло межу Ілліча↗ (зовнішнє посилання) [18]: майстер більше не використовує машину для власної праці, а обслуговує внутрішню бюрократію самої машини.

Самотність і співпраця

Тихого вівторкового вечора в однокімнатній квартирі на широкому моніторі світяться п’ять вкладок термінала й браузера. У першому вікні агент-кодер переписує парсер даних; у другому модель міркувань допомагає розібрати незграбне, незавершене листування зі старим другом; у третьому промпт із кар’єрної стратегії порівнює вилки зарплат і плани підготовки до співбесід; у четвертому й п’ятому допоміжні агенти форматують нотатки та генерують оглядові схеми. До 23:15 мешканець квартири отримав невтомне терпіння, красномовне підтвердження власної правоти і чотири тисячі слів добірної прози. Кілька охайних файлів збережено на диску. І протягом п’яти годин поспіль у кімнаті не пролунало жодного людського голосу, а жоден чужий непередбачуваний настрій, розклад чи впертість не перебили цього потоку.

Для людини, яка працює далеко від щільного фахового середовища — аналітика у спальному передмісті, незалежного дослідника між проєктами, розробника, який самотужки опановує новий стек без наставника поруч, — ця чуйна привітність не є дрібницею. Вона знижує енергетичний поріг, необхідний, щоб узятися за складну справу. Тонка корозія починається тоді, коли безвідмовна піддатливість п’яти вікон чату стає еталоном того, яким має бути людське спілкування взагалі. Переробка приватної архітектурної схеми разом із помічником дає миттєвий, приємний для самолюбства синтез за вісім секунд; надсилання ж сирої двосторінкової пропозиції колишньому однокурсникові по аспірантурі чи мейнтейнерові відкритого проєкту означає три дні очікування на відповідь, ризик отримати неуважну відписку на п’ять слів або дізнатися, що цю блискучу ідею вже розв’язали у 2019 році. Коли репетиційна зала нескінченно підтакує, а сцена назовні холодна й повільна, стає небезпечно легко витратити цілий рік на вдосконалення репетиції.

В інженерній справі цей відступ у приватну гладкість несе конкретний кар’єрний штраф. На власній машині одна людина контролює вхідні дані, структуру таблиць, годинник і критерій завершеності. Проте те, що переконує комітет із найму, провідного інженера чи співзасновника зробити ставку на колегу, майже ніколи не зводиться до згенерованого в герметичній пісочниці; вирішальним є те, як фахівець поводиться, коли його код стикається з обмеженнями інших людей. Що відбувається, коли рецензент вказує, що елегантне переписування ламає суміжний білінговий процес? Як інженер домовляється про міграцію бази даних, коли адміністратор категорично забороняє блокувати таблицю в робочі години? Ці моменти неможливо зімітувати у приватному вікні промпту, бо їхньою визначальною складовою є те, що інша жива людина має право вето щодо авторських уподобань.

Та сама розпорошеність місцевого знання по різних кімнатах↗ (зовнішнє посилання) [5] не менш гостро б’є по самітницькій самодостатності в технологічному підприємництві. Один інженер може знати, як побудувати локальний інструмент видобування даних без виходу в зовнішню мережу на чипах Apple Silicon; а знайомий з університетського хакатону чи медичний директор на іншому кінці міста знає, яке саме регуляторне вузьке місце просто зараз на шість місяців заморожує погодження клінічних досліджень у лікарні. Жоден із них наодинці не тримає в руках готового інституційного рішення. Можливість народжується лише тоді, коли двоє людей із неповними, неперетинними зрізами реальності сідають за кавою і звіряють свої спостереження. Помічник може допомогти відшліфувати слайди перед входом до кав’ярні, але він не сяде навпроти за столом і не підкаже неопубліковане закупівельне правило, яке змінює весь задум.

Справжня програмна латка проходить перевірку на міцність, коли потрапляє до спільного репозиторію. Учасник надсилає пул-реквест, що виправляє тонку помилку округлення в утиліті експорту CSV. За двадцять хвилин мейнтейнер залишає коментар до рядка 44: пряме виправлення помилки округлення зламає три наступні лікарняні скрипти звітності, які чотири роки поспіль компенсували старий усічений формат стовпця. Замість відхилити виправлення або зламати суміжні системи, автор патчу та мейнтейнер у гілці обговорення знаходять компроміс: зберігають стару поведінку за стандартним прапорцем, відкривають виправлений розрахунок через явний параметр і фіксують обидва режими в наборі регресійних тестів. Точнісінько так само, як спільне сховище лікарняних даних у Розділі 2 потребувало поліцентричних правил і ступеневих зобов’язань↗ (зовнішнє посилання) [6] для узгодження конкуруючих клінічних визначень, репозиторій відкритого коду використовує свої норми рецензування та вікна виведення функцій з обігу (deprecation windows) як середовище, в якому незнайомці здобувають довіру. Здатність відповісти на критику мейнтейнера без ображеної оборони й написати тест на зворотну сумісність — ось що доводить, що новачку можна довірити право коміту. Портфоліо з десяти сольних репозиторіїв, згенерованих із помічником, доводить, що розробник уміє писати промпти; історія узгоджених змін у спільному надбанні↗ (зовнішнє посилання) [6] доводить, що інженер уміє жити й працювати з іншими будівничими.

Небезпека приватної ехо-камери стає ще гострішою, коли темою у другій вкладці браузера виявляється неоднозначна мовчанка друга, партнерки чи колеги. Мовні моделі за самою своєю архітектурою є рушіями зв’язності: згодуйте помічникові три тривожні абзаци про те, чому людина чотири дні не відповідала на повідомлення, і він сплете ці уламки у психологічно струнку оповідь про приховані мотиви, типи прив’язаності та стратегічні варіанти дій. Варто перечитати цей гладкий синтез тричі до опівночі — і неперевірений здогад твердне у свідомості як доконаний біографічний факт, причому жива людина по той бік навіть не мала нагоди сказати: «У мене батько лежав у лікарні, а я загубила зарядку». Щоб зберегти гігієну стосунків, потрібно тримати у власній голові глухий мур між трьома стовпцями: що насправді відбулося навіч, що інша людина сказала дослівно і яку історію було сплетено разом із машиною, щоб заповнити тишу.

Створювати речі можна й на самоті, і ШІ-помічник є надзвичайним підсилювачем усамітненого виробництва. Чого не може статися всередині п’яти освітлених вікон чату, то це тертя від зустрічі з іншою автономною волею — співавтором, який оскаржує задум, читачем, який прочитує есей у несподіваний спосіб, або близькою людиною, яка відкидає відрепетируваний наодинці сценарій, у тому просторі, який Ганна Арендт називала умовою людської множинності↗ (зовнішнє посилання) [21], що лежить в основі спільного публічного життя↗ (зовнішнє посилання) [22]. Цей непередбачуваний людський спротив і є тим єдиним сигналом, який підтверджує, що людина за столом більше не розмовляє із дзеркалом.

Усередині програмного забезпечення

Коли в будній ранок фахівець повертається за робочий стіл, практичне питання постає руба: зважаючи на скінченність людського життя, повний робочий день і бажання мати життя поза терміналом, наскільки глибоко вниз технічним стеком взагалі потрібно копати? У першому розділі книги «Програмна інженерія в Google» (Software Engineering at Google, 2020)↗ (зовнішнє посилання) [19] Тітус Вінтерс визначає програмну інженерію не просто як програмування, а як «програмування, інтегроване в часі» — дисципліну збереження коду адаптивним і життєздатним крізь зміну вимог, десятиліття супроводу та роботу багатотисячних команд. Хоча внутрішні інструменти та правила монорепозиторію Google↗ (зовнішнє посилання) [19] відображають інституційний масштаб, притаманний одиницям, саме базове розрізнення між написанням скрипту, який спрацює один раз сьогодні ввечері, та конструюванням системи, що переживе п’ять років чужих рук, дає дослідникові компас для вибору того, що варто вивчати.

Досить зазирнути за край будь-якої високорівневої програми — і шари абстракції падають униз, мов сходові марші в промисловому цеху. Під скриптом на Python лежить інтерпретатор CPython; під інтерпретатором — виклики бібліотек C та системні виклики операційної системи; під ядром ОС — архітектура набору інструкцій процесора, кеш-пам’ять, передбачувачі переходів і вентилі напруги. У сумлінного самоука — особливо оточеного ШІ-інструментами, здатними за командою генерувати поверхневий код, — цей погляд у сходовий проліт легко викликає паралітичний синдром самозванця: підозру, що доки розробник не зійшов пішки аж до кремнію і не написав власноруч компілятор, він не має морального права називати себе інженером.

Зосереджена робота з мовою C є класичними ліками від магічного мислення саме тому, що C прибирає автоматичне керування пам’яттю і змушує програміста на власні очі побачити, де фізично живуть байти. Змінна перестає бути безтілесним іменем; вона отримує адресу, ширину в байтах, місце у стек-фреймі чи в купі (heap) та час життя, який або чисто завершується, або залишає висячий вказівник (dangling pointer), готовий зіпсувати наступний виклик. Покрокове проходження двадцятирядкової програми на C у налагоджувачі gdb чи lldb та перегляд згенерованого компілятором асемблерного коду (cc -S -O2) дозволяють побачити, як цикл for перетворюється на регістри процесора, зміщення адрес та умовні переходи.¹¹ Звісно, навіть тут мова C не є «голим залізом»: стандарт C описує абстрактну машину, і сучасний оптимізувальний компілятор переставляє інструкції, вбудовує виклики функцій та векторизує цикли так, що це дивує кожного, хто очікував взаємно однозначної відповідності між рядками вихідного коду й тактами процесора. Навчитися читати цей проміжок — це вже половина освіти.

У такому сходженні вниз є справжня, майже дотикова радість — мить, коли загадковий segmentation fault або раптовий обвал швидкодії перетворюється на видиму послідовність стек-фреймів і кеш-ліній. Утім, те, як довго варто таборувати на цьому нижньому сходовому майданчику, залежить від роботи, яку людина реально виконує. Автор вбудованих мікропрограм (firmware) або розробник рушія баз даних живе серед кеш-ліній та конвеєрів інструкцій щодня. Для прикладного програміста чи інженера даних опрацювання кількох невеликих програм на C, вправ із вказівниками та лістингів асемблера цілком достатньо, щоб назавжди вилікуватися від ілюзії, ніби пам’ять безкоштовна, — без дворічного відходу в ручне написання коду на асемблері x86 чи ARM. А оскільки реальна поведінка програми під час виконання залежить від взаємодії прапорців компілятора, сторінкової організації віртуальної пам’яті, планувальника ОС і живого розподілу вхідних даних, низькорівневе «відчуття металу» підказує інженерові, що саме вимірювати профілювальником, але не замінює самого вимірювання.

На один сходовий проліт вище, у світі Python, цей компроміс перевертається. У тридцяти рядках коду на Python одна людина може завантажити набір даних у форматі Parquet, перетворити граф, підняти HTTP-ендпойнт і запустити тестовий контур — делегувавши виділення пам’яті, зміну розміру хеш-таблиць і буфери сокетів середовищу виконання та його розширенням на C або Rust. Цей важіль дозволяє тримати увагу сфокусованою на предметному завданні — аж доки одна з прихованих шестерень унизу не почне пробуксовувати. Один рядок у pandas чи DuckDB може передати роботу у векторизовані цикли C++, що працюють майже на межі можливостей апаратури, тоді як невинний на вигляд цикл for на Python двома рядками нижче створює в купі мільйони об’єктів-обгорток для цілих чисел і ставить сервер на коліна. Без ментальної моделі того, що лежить під синтаксисом, обидва рядки на екрані видаються однаково дешевими.

Реальна виробнича проблема спускає фахівця цими сходами на один проліт за раз. Уявімо, що аналітик пише на Python утиліту для щоденного звіряння двох вивантажень реєстру пацієнтів. Першого дня, коли в кожному файлі по п’ять тисяч записів, найскладніша проблема є суто семантичною: вирішити, коли "St. Paul's Hosp." та "Saint Paul Hospital - Acute" позначають ту саму лікарню, і довести модульними тестами, що правила зіставлення не зливають докупи дві різні клініки. Спускатися в C чи асемблер першого дня було б прокрастинацією під маскою інженерної строгості. Через шість місяців на вхід цього процесу подають дванадцять мільйонів історичних записів, і він починає відвалюватися за таймаутом через чотири години роботи. Огляд алгоритму виявляє вкладений цикл зі складністю O(N²), який порівнює кожен запис із кожним іншим; перехід на пошук за хеш-індексом або сортоване злиття скорочує час виконання до сорока секунд без виходу за межі Python. Ще за рік обсяг вибірки сягає двохсот мільйонів записів і пробиває стелю у 56 гігабайтів оперативної пам’яті локальної віртуальної машини. Ось тепер розміщення даних у пам’яті, накладні витрати на об’єкти, потокове читання частинами (chunked reads) та буфери Arrow без копіювання (zero-copy) стають нагальною потребою. Коли спускаєшся стеком вниз, тримаючи в руках конкретну операційну відмову, кожне низькорівневе поняття миттєво стає на своє місце, бо воно відповідає на питання, яке сама робота вже поставила руба.

Усередині великої корпоративної платформи даних — Azure Fabric, Databricks, Snowflake чи лікарняного сховища — з’являється ще й бічна складність, якої не розглядають ні класичний підручник Кернігана і Рітчі з мови C, ні університетські курси алгоритмів. Створити таблицю в робочому просторі або запланувати виконання ноутбука можна в три кліки на вебпорталі. Справжні мінні поля лежать у правах доступу сервісних облікових записів (service principals), політиках безпеки на рівні рядків, тихому дрейфі типів стовпців у джерелах, строках зберігання журналів аудиту згідно із законами про захист персональних даних і в тому, що відбувається, коли нічне оновлення падає посеред нетранзакційного запису. Знання того, як працює malloc, не врятує від витоку захищеної медичної інформації через неправильно налаштовану роль у робочому просторі, а знання розташування кожної кнопки на порталі постачальника не допоможе, коли наступного кварталу вендор проведе редизайн інтерфейсу.

Коли узгоджене в Розділі 2 правило щодо червневого об’єднання лікарняних відділень треба закодувати в нічне робоче завдання, усі три поверхи зустрічаються в одному коміті. Будь-яка сучасна аналітична платформа здатна виконати LEFT JOIN і ще до обіду опублікувати барвисту звітну карту для керівництва. Проте інженерне ремесло полягає в тому, щоб перекласти узгоджене поліцентричне правило — чи залишаються госпіталізації до 1 червня замороженими під історичними кодами відділень, чи перераховуються в об’єднаний часовий ряд — у контрольований за версіями код SQL або Python, який витримає інкрементальні нічні оновлення, закріпити межі дат чинності в автоматичних тестах і прикріпити семантичне застереження безпосередньо до вихідної таблиці, аби член ради директорів, читаючи квартальну звітну карту Fraser Health↗ (зовнішнє посилання) [2], не сплутав адміністративне укрупнення відділень із клінічним спалахом. Код робить правило відтворюваним; механіка платформи підтримує його роботу о третій ночі; інституційна грамотність береже його чесність.

Те, що робить інженера стійким упродовж десятиліть зміни вендорських стеків, — це набір переносних інваріантів, які переживають будь-який ребрендинг: де зберігається змінний стан (mutable state), як перевіряються ідентичність і повноваження під час перетину межі системи, чи є повторний виклик після мережевого збою ідемпотентним, чи він дублює транзакцію, як еволюціонують формати даних, не ламаючи читачів нижче за течією, і який саме конкретний сценарій відмови виключає тест. Якщо зустріти найновіший фреймворк оркестрації чи агентний протокол цими п’ятьма запитаннями, маркетинговий глянець злазить за двадцять хвилин.

Такі мови, як C++ та Rust, розташовуються на цьому самому спектрі як спеціалізовані інструменти з цілком реальною вартістю утримання. C++ дає інженерові тонкий контроль над розміщенням даних у пам’яті та абстракції з нульовою ціною виконання — але платою за це є неосяжна специфікація, де малопомітна помилка часу життя об’єкта або невизначена поведінка (undefined behavior) може роками чаїтися непоміченою. Rust переносить ці інваріанти володіння, запозичення та потокової безпеки безпосередньо в систему типів компілятора, відмовляючись збирати виконуваний файл, доки не виконано правила псевдонімів (aliasing) і часу життя змінних. Для висококонкурентного середовища виконання, вбудованого контролера дрона або критичного до швидкодії локального розширення бази даних така дисципліна під час компіляції сповна себе окупає; а от для нічного вивантаження лікарняної звітності витратити три місяці на боротьбу з перевіркою запозичень (borrow checker) замість налагодження контролю якості даних — це марнування скінченного часу.

Якщо прочитати публічний опис вакансії інженера-програміста в Google↗ (зовнішнє посилання) поруч із цією реальністю, розрив між щоденною інституційною аналітикою та системною інженерією загального призначення стає предметним, а не містичним. Базовий профіль посади вимагає фундаментальної підготовки зі структур даних, алгоритмів і проєктування програмного забезпечення такими мовами, як C, C++, Java або Python, а також практичного досвіду тестування, налагодження, розгортання та спільного рецензування коду↗ (зовнішнє посилання). Текст вакансії описує кадрове сито роботодавця, а не повний портрет щоденної праці в кожній команді — і аж ніяк не перекреслює цінності десяти років утримання корпоративних конвеєрів даних у робочому стані, — проте він окреслює скінченну, цілком придатну до опанування навчальну програму: основи C та роботи з пам’яттю, SQL, вільне володіння командним рядком Linux, git, автоматизоване тестування і систематичне налагодження. Коли ставишся до цього переліку як до скінченного набору інструментів, які варто відпрацьовувати на реальних завданнях, зникає спокуса відкладати решту власного життя на потім, доки не буде прочитано останній підручник на полиці.

Демонстрація компетентності

Рано чи пізно кожна приватна спроможність мусить перетнути кімнату і стати прочитуваною для людини, якої не було поруч, коли ця річ створювалася: керівника ліквідації аварії на нічному селекторному зв’язку о першій годині ночі, мейнтейнера, який переглядає пул-реквест у перерві між нарадами, венчурного інвестора на двадцятихвилинній технічній демонстрації чи інтерв’юера, який спостерігає, як кандидат проходить обхід графа на спільному екрані. Оскільки незнайомі люди не мають шести тижнів, щоб сидіти за спиною фахівця біля його робочого столу, вони покладаються на стиснені демонстрації. Перекласти глибоку, неохайну технічну працю у ясне двадцятихвилинне пояснення — це не марнославство і не корпоративний театр; це частина того, як люди взагалі координуються у великих суспільствах.

Патологія починається лише тоді, коли проксі-показник витісняє саму базову реальність і стає єдиною мішенню зусиль: коли команда оптимізує роботу заради зелених клітинок на інформаційній панелі, ховаючи під сукно неперевірені спадкові системи; коли демонстрацію прописують за сценарієм навколо п’яти спеціально підібраних запитів, щоб ніхто не побачив, як парсер падає на кривому PDF-файлі; або коли доповідач навчається декламувати модні архітектурні слова («агентний RAG», «zero-copy lakehouse», «епістемічні запобіжники»), не відстеживши за своє життя жодного втраченого мережевого пакета. Організації, які винагороджують саму лише гладкість виступу, зрештою відбирають придворних. Проте й протилежна поза — гордовитий технар, який бурмоче, що «добра робота має говорити сама за себе», і кидає на стіл колезі недокументований репозиторій, — зазнає поразки не менш надійно, бо непояснена праця залишається невидимою саме для тих людей, які могли б її профінансувати, впровадити чи винагородити.

Засновник стартапу на посівній стадії, який презентує систему видобування перевірюваних регуляторних і бюджетних показників із неосяжних масивів державних документів, складає саме цей іспит. У переговорній кімнаті робочий прототип витягує точні абзаци з ретельно відібраного тестового корпусу на п’ятдесят документів, підсвічує вихідні таблиці й прив’язує кожне речення до номера сторінки. Проте сам бізнес, під який залучають кошти, виживе чи помре залежно від того, чи витримає цей рушій п’ятдесят тисяч неохайних муніципальних PDF-файлів, де відскановані таблиці перекошені, оптичне розпізнавання символів (OCR) губить знаки «мінус», два міністерства публікують суперечливі редакції бюджету, а витрати на токени здатні тихо з’їсти всю валову маржу. Театралізована презентація ховає ці урвища за наперед закешованими запитами. Переконлива інженерна презентація показує живий прототип на п’ятдесяти документах, а потім свідомо відкриває п’ятдесят перший документ, де дві таблиці суперечать одна одній, демонструє, як система позначає колізію замість галюцинувати гладке зведення, і викладає точні інженерні етапи та експерименти з питомою собівартістю, на які піде посівний капітал.

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

Цикл технічних співбесід у провідній дослідницькій лабораторії чи великій технологічній компанії — Google, Microsoft, OpenAI, Anthropic — стискає ту саму проблему оцінювання в серію сорокап’ятихвилинних сесій із написання коду та проєктування систем. Хоч якими б недосконалими були алгоритми на білій дошці та вправи з налагодження на час як предиктори багаторічної інженерної надійності, скрута інтерв’юера є цілком реальною: маючи менш ніж чотири години контакту, він мусить вирішити, чи здатна ця незнайома людина ясно мислити в умовах неповноти даних, помічати граничні випадки ще до написання коду, сприймати підказку без паніки чи їжакуватої оборони і вголос пояснювати компроміси, поки пальці рухаються по клавіатурі. Сприймати формат співбесіди як чужорідну, образливу салонну гру означає лише обмежувати власні можливості; сприймати ж його як специфічний комунікативний жанр із осяжною механікою — означає повернути його в площину звичайного інженерного завдання.

Тренування звички вголос формулювати інваріанти перед написанням циклу, перевіряти граничні випадки (порожній масив, один елемент, дублікати ключів, переповнення цілого числа) ще до запитання інтерв’юера та простою мовою називати компроміси часової й просторової складності знижує когнітивні накладні витрати самого виступу, дозволяючи проявитися реальному мисленню. А коли сорокап’ятихвилинна сесія йде шкереберть через незнайому рекурентну формулу динамічного програмування чи призабутий примітив синхронізації потоків, до розбору польотів застосовується правило Дьюї↗ (зовнішнє посилання) [11]: провалене запитання — це не метафізичний вирок двадцяти рокам аналітичного ремесла, а діагностичний слід, який вказує на одну конкретну прогалину в підготовці, яку можна локалізувати, відпрацювати у вівторок увечері й перевірити знову.

Щойно пропозицію роботи підписано або патч влито в основну гілку, сценічний виступ закінчується, і відновлюється довга, негламурна середина інженерної справи↗ (зовнішнє посилання) [19]: написати план відкату перед запуском міграції, відповісти на запитання молодшого аналітика так, щоб він не почувався приниженим, залишити трирядковий коментар із поясненням того, чому тут стоїть дивний фільтр, аби людина, яка успадкує цей файл у 2028 році, не видалила його і не зламала квартальний звіт. Люди дізнаються, що саме вони насправді розуміють, коли намагаються збудувати речі, які витримують вагу інших людей, і коли пояснюють свою роботу колегам, вільним прямо сказати, де саме автор помилився.

А на робочому столі тим часом лежить звіт помічника — той самий, із тридцятьма зеленими модульними тестами і тихим зізнанням унизу сторінки, що в цільовому середовищі програма так і не запустилася. Читач, який виконав повільну працю простеження збоїв униз технічним стеком, звіряння першоджерел із гладкими резюме та перевірки ідей живими наслідками, не викидає інструмент на смітник, але й не пересилає зелений підсумок тестів нагору по інстанціях. Він відкриває термінал, відтворює невдалий запуск у цільовому контейнері, читає потік stderr і знаходить відсутню прив’язку змінної середовища, якої жоден із тридцяти синтетичних тестів навіть не торкнувся. Поруч із програмою на машині в самій людині за клавіатурою викристалізувалося щось значно довговічніше: здатність відрізняти відомість бурхливої діяльності від перевіреного факту і витримка, потрібна для того, щоб зробити свою працю зрозумілою іншим людям. Коли контейнер нарешті чисто запускається і тестовий набір вимірює реальний процес, на годиннику вже пів на дев’яту вечора — і те, чи матиме людина, яка закриває кришку ноутбука, цей вечір вільним, аби вийти з дому й зустріти когось, чию відповідь неможливо наперед вгадати з промпту, залежить від того, як узагалі влаштовано години робочого тижня та кар’єрні стимули.