Програмна інженерія мертва. Саме в це хочуть змусити вас повірити найгучніші голоси в тех-Твіттері. Вони діляться записом екрана, де інструменти ШІ створюють цілі застосунки за допомогою одного абзацу тексту, і запитують, навіщо комусь досі платити людині за написання коду. Така паніка зрозуміла, але вона зовсім не в те.
ШІ не прийшов за інженерами. Він прийшов за тими, хто плутає швидкість друку з технічним судженням. Між кодингом та інженерією існує величезна прірва, і саме в цій прірві полягає суть усієї професії.
ШІ-асистент може запропонувати вам п'ять різних способів реалізації функції ще до того, як ви доп'єте свою каву. «Вузьке місце» змістилося. Ми більше не витріщаємося на порожній файл, думаючи, з чого почати. Ми вивчаємо п'ять правдоподібних рішень, гадаючи, яке з них не розвалиться в ту саму мить, коли піде реальний трафік. Саме це прийняття рішення і є інженерією. Все інше — лише синтаксис.
Демонстрація — це не продукт
Подивіться будь-яку демонстрацію кодингу за допомогою ШІ, і ви побачите, як за лічені хвилини створюється чудовий інтерфейс. Але ви не побачите, як пул з'єднань із базою даних вичерпується під навантаженням. Ви не побачите відсутності обмежень частоти запитів (rate limits) на API-ендпоінті, відсутності журналів аудиту або витрат на зберігання кожного логування взаємодії користувача в об'єктному сховищі (object bucket) лише тому, що ШІ вирішив, що це зручне місце для збереження стану (state).
Продуктивні системи потребують масштабованості, безпеки, продуктивності та контролю витрат. Ці якості непомітні під час огляду спринту. Вони проявляються лише тоді, коли приходять реальні користувачі зі своєю непередбачуваною поведінкою, граничними випадками (edge cases) та небажанням натискати кнопки в тому порядку, на який ви розраховували. Я бачив занадто багато проєктів із використанням ШІ, які виглядали бездоганно під час QA, але перетворювалися на дорогі уроки вже через тиждень після запуску.
Робочий код став дешевим. Хороша інженерія — ні.
Що важливо зараз
Інженери, які процвітають у цей період змін, — це не ті, хто найшвидше друкує. Це ті, хто знає, які запитання ставити ще до того, як буде згенеровано хоча б один рядок коду.
Вони чітко визначають проблеми. Модель ШІ з радістю вирішить не ту проблему, якщо ви їй дозволите. Вона побудує складний шар кешування для дашборду з великим навантаженням на читання, яким користуються лише шість внутрішніх аналітиків. Вона не зупиниться, щоб запитати, чи не є справжньою проблемою відсутність індексу в базі даних або фундаментально неправильна модель даних. Досвідчений інженер переформульовує проблему доти, доки рішення не стане очевидним, незалежно від того, чи потребує це рішення коду.
Вони розбивають великі системи на маленькі частини. ШІ чудово справляється з локальним контекстом. Він може написати одну функцію, один компонент, один тест. Але йому важко утримувати в пам'яті цілу розподілену архітектуру. Інженери, які можуть декомпозувати моноліт, розмежувати сервіси та визначити контракти між командами, — це саме ті люди, які перетворюють згенеровані фрагменти на життєздатні системи.
Вони ставлять під сумнів пропозиції ШІ. Впевненість моделі — це лише ілюзія. Вона може запропонувати архітектури, що ігнорують затримку мережі (network latency), рекомендувати бібліотеки, які вже роками вважаються застарілими (deprecated), або реалізовувати функції, яких насправді немає у вимогах.