Чи можна автоматизувати роботу програміста?

Штучний інтелект, Low-code і генерація коду: наскільки реально повністю автоматизувати програміста?

Чи можна автоматизувати роботу програміста?
INGELLO / BUSINESS2238

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

Ми більше не пишемо кожен символ

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

У нас в Ingello цей шлях почався задовго до нейромереж. Fractal, наш генератор, виріс із простої думки: систему не треба набирати руками, її треба описати, а код, схему бази, API й адмінку хай породжує машина. Спершу це працювало за суворими правилами, тепер до правил додалися ШІ-агенти. Але сенс не змінився: програміст перестає бути друкаркою і стає диригентом. Він не грає на кожному інструменті, він відповідає за те, щоб оркестр звучав як музика, а не як налаштування перед концертом.

Що автоматизувати не виходить

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

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

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

Кого все-таки автоматизують

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

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

Нові ризики, про які варто знати

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

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

Що це означає для замовника

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

Саме так ми й працюємо в Systems: проєктування, аналітика й архітектура лишаються за людьми з досвідом, а генерацію коду, схем та інтерфейсів беруть на себе Fractal і ШІ-агенти. Чи можна автоматизувати програміста? Можна автоматизувати те, що програміст робив руками. А те, що він робить головою, стало тільки ціннішим.