У 1968 році Філіп Дік опублікував роман «Чи мріють андроїди про електроовець?». Тоді це була фантастика про майбутнє, де межа між людиною і машиною поступово стирається.

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

Тож цікавіше запитати інакше: чи мріють самі програмісти про електромізки? Чи хочуть вони одного дня віддати штучному інтелекту всю свою роботу й залишити собі тільки кнопку «Запустити»?

Схоже, що ні. Але й відмовлятися від нового інструменту розробники явно не збираються.

Хороший програміст не любить робити одну роботу двічі

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

Тому розробники досить швидко взялися за AI-інструменти.

Сьогодні мовна модель може працювати поруч із редактором коду, IDE або терміналом. Хтось використовує хмарні сервіси, хтось запускає локальну модель на робочій станції чи власному VPS-сервері. Мета зазвичай одна: витратити менше часу на механічну частину роботи.

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

Це та сама автоматизація, до якої програмісти завжди тяжіли. Просто тепер інструмент став значно універсальнішим.

Написати код і створити систему — різні речі

З боку програмування часто виглядає як нескінченне введення команд у редакторі. Потрібна функція — програміст її пише. Потрібен API — створює endpoint. З’явилася помилка — виправляє.

У реальній роботі код займає лише частину часу.

Набагато більше проблем виникає до того, як з’явиться перший рядок реалізації. Треба зрозуміти, навіщо взагалі потрібна нова функція, як вона взаємодіятиме з уже наявною системою, що станеться під навантаженням і які обмеження накладає сам бізнес.

Є ще старий код. Іноді дивний.

Дивишся на рішення п’ятирічної давнини й думаєш: навіщо хтось зробив саме так? Потім знаходиш старий issue і з’ясовуєш, що це був єдиний спосіб обійти обмеження стороннього API, яке давно вже зникло.

Модель бачить код. Контекст такої історії вона може взагалі не знати.

Тому AI легко відповість на запит «як реалізувати це технічно», але значно гірше впорається з питанням «чи потрібно це реалізовувати саме так».

Досвід часто починається з питання «навіщо?»

У новачка природно виникає питання: як написати цей код?

У досвідченого інженера перед ним часто з’являється інше: а навіщо ми взагалі його пишемо?

Ця різниця здається невеликою, хоча на практиці вона визначає архітектуру цілих систем.

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

Можна попросити побудувати прекрасні сходи. І отримати їх.

А вже потім помітити, що вони ведуть у стіну.

Людина, яка добре розуміє проєкт, зазвичай починає з уточнень. Що ми хочемо отримати? Хто цим користуватиметься? Які є обмеження? Що станеться, якщо вимоги зміняться через пів року?

Саме тут досвід інженера поки важить більше за швидкість генерації коду.

Різні професії знайшли для ШІ різну роботу

Цікаво, що штучний інтелект увійшов у професії зовсім не однаково.

Дизайнер може за кілька хвилин отримати десятки грубих концепцій і вже з них шукати напрямок. Юрист використовує модель для первинного аналізу документа. Маркетолог просить її підготувати чернетку тексту або розкласти великий масив відгуків за темами. Архітектор може швидко зробити попередню візуалізацію ідеї.

Робота при цьому нікуди не зникає.

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

У програмуванні відбувається приблизно те саме, тільки трохи дивніше.

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

Програміст пише програму, яка допомагає програмісту писати програму.

Досвідчений розробник зазвичай менше захоплюється готовим кодом

Для людини, яка тільки вчиться програмувати, автоматично згенерована функція може виглядати майже магією. Описав задачу звичайною мовою — через кілька секунд отримав код.

І він навіть працює.

Саме слово «працює» тут цікаве.

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

Є помилки, які живуть у production місяцями.

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

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

Є робота, яку електромізки вже роблять чудово

Критикувати генерацію коду легко. Набагато цікавіше подивитися, де вона вже справді економить час.

Старий проєкт на незнайомому фреймворку — хороший приклад. Раніше доводилося годинами переходити між документацією, Stack Overflow, issue-трекером і самим кодом. Тепер частину цього пошуку можна стиснути до кількох діалогів із моделлю.

Те саме відбувається з SQL. Потрібен складний запит із кількома JOIN, групуванням і підзапитом — простіше спочатку отримати чернетку, а потім перевірити її руками.

З тестами схожа історія. Монотонне написання десятків типових сценаріїв добре піддається генерації. ШІ може пояснити чужий код, підказати альтернативну реалізацію, знайти підозрілий фрагмент або швидко переказати документацію бібліотеки.

На окремих задачах це економить хвилини. На великому проєкті з цих хвилин складаються дні.

Тут уже не потрібно вигадувати футуристичні сценарії про повністю автономну розробку. Користь видно просто зараз.

Але вимога «зробіть зручно» все ще починає розмову

Уявімо, що замовник каже: «Хочу, щоб застосунком було зручно користуватися».

Для моделі це дуже нечітке завдання.

Для хорошого розробника, дизайнера або аналітика — цілком нормальний початок.

Зручно кому? Людині, яка заходить у систему раз на місяць, чи оператору, який проводить у ній вісім годин щодня? З комп’ютера чи смартфона? Користувач добре розуміється на предметній області або бачить цей інтерфейс уперше?

Іноді одне уточнення повністю змінює майбутню систему.

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

Код з’явиться пізніше.

І саме тому швидкість написання функцій ще не дорівнює швидкості створення хорошого продукту.

ШІ змушує точніше формулювати думки

Є й несподіваний ефект. Працюючи з мовною моделлю, програміст досить швидко помічає: нечіткий запит часто дає нечітку відповідь.

Доводиться уточнювати.

Які дані приходять на вхід? Який результат очікується? Що робити з помилками? Які обмеження не можна порушувати? Яка версія бібліотеки використовується?

Через кілька ітерацій початкова фраза «напиши мені сервіс для обробки замовлень» перетворюється на досить точний опис поведінки системи.

І тут виникає кумедний момент. Частина роботи вже зроблена самим процесом формулювання.

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

У цьому сенсі AI може працювати як дуже терплячий співрозмовник, якому можна кілька разів поспіль пояснювати одну й ту саму ідею, поки вона нарешті не стане зрозумілою тобі самому.

Програмісти вже переживали «кінець програмування»

Передбачення про зникнення професії виникали задовго до сучасних мовних моделей.

Колись компілятори мали зробити програмістів непотрібними, адже більше не потрібно було вручну писати машинний код. Потім з’явилися високорівневі мови. Пізніше — візуальні конструктори, CMS, low-code-платформи й генератори сайтів.

Кожен новий рівень абстракції прибирав частину ручної роботи.

А програмного забезпечення ставало більше.

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

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

Але проєктування системи, робота з неоднозначними вимогами, вибір компромісів і відповідальність за результат нікуди не зникають.

То про що насправді мріють програмісти

Мабуть, про електромізки все-таки мріють.

Просто мрія виглядає прозаїчніше, ніж у старій науковій фантастиці.

Було б добре більше ніколи не згадувати синтаксис чергового конфігураційного файлу. Не витрачати пів дня на пошук очевидної причини помилки. Швидше читати чужий код. За кілька хвилин отримувати першу версію тестів і не писати вручну сотий майже однаковий SQL-запит.

Нехай машина забере це собі.

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

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

Тож питання найближчих років звучить уже трохи інакше. Не «чи замінить ШІ програмістів?», а «яку частину програмування люди нарешті зможуть перестати робити руками?».