Чому доменна експертиза стає дефіцитним навиком в епоху агентного кодування

Модель перед кодом

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

Що змінив агентний ШІ

Агентний ШІ розірвав зв'язок між цими двома речами, пише автор: тепер програмне забезпечення можна виробляти, жодного разу не збудувавши модель, а це ламає припущення, на якому трималася вся професія. Поширена думка — зокрема й самого автора рік тому — полягає в тому, що ці інструменти підсилюють досвідчених розробників, бо в них є судження. Це правда, але неповна. Головне обмеження, пише він, змістилося від питання чи можеш ти це збудувати до питання чи можеш ти визначити, чи воно правильне.

Дві людини, дві невдачі

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

Який шлях зник і на що варто ставити

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