Коли вам хтось казатиме, що штучний інтелект замінить програмістів – це не станеться в найближчому майбутньому. Так, штучний інтелект здатний відповідати на питання рівня наукового аспіранта. Однак ШІ не здатний сприймати контекст в цілому, тому він не здатний створити бодай простий додаток – у коді буде купа помилок і створена ШІ програма просто не запуститься. Однак на порозі уже друге покоління навичок програмування у штучного інтелекту. Розробники ШІ обіцяють, що на цьому рівні штучний інтелект уже дійсно розумітиме, що він повинен зробити і сам виправлятиме помилки.
«Це щось, що дуже захоплює розробників», — розповів Джаред Каплан, головний науковець компанії Anthropic. «Це справжнє розуміння проблем у коді та їх виправлення».
Copilot, інструмент, створений на основі великих мовних моделей від компанії OpenAI та запущений компанією GitHub (що належить Microsoft) у 2022 році, нині використовується мільйонами програмістів по всьому світу. Ще мільйони користуються універсальними чатботами, такими як Claude від Anthropic, ChatGPT від OpenAI та Gemini від Google DeepMind, для щоденної допомоги.
«Сьогодні понад чверть усього нового коду в Google створюється за допомогою ШІ, а потім перевіряється й затверджується програмістами», — заявив генеральний директор Alphabet Сундар Пічаї під час телефонної розмови щодо фінансових результатів у жовтні. «Це допомагає нашим програмістам працювати продуктивніше та швидше». Очікується, що інші технологічні компанії або вже наздогнали, або скоро наздоженуть.
Це стосується не лише великих корпорацій, які впроваджують інструменти ШІ для написання коду. На цей перспективний ринок виходить безліч нових стартапів. Новачки, такі як Zencoder, Merly, Cosine, Tessl (який оцінили в 750 мільйонів доларів за кілька місяців після створення) і Poolside (оцінений у 3 мільярди доларів ще до випуску продукту), змагаються за свою частку ринку.
«Схоже, програмісти дійсно готові платити за таких “копілотів”», — каже Нейтан Бенайч, аналітик інвестиційної компанії Air Street Capital. «Тому код є одним із найпростіших способів монетизації ШІ».
Такі компанії обіцяють підняти генеративні помічники для програмного коду на новий рівень. Замість того, щоб просто надавати розробникам потужну функцію автозаповнення, як більшість існуючих інструментів, наступне покоління зможе створювати прототипи, тестувати та виправляти код замість програміста. У результаті програмісти можуть перетворитися на менеджерів, які більше часу витрачають на перевірку та корекцію коду, створеного моделлю, аніж на написання його з нуля.
Але це ще не все. Багато хто з тих, хто створює генеративних помічників для написання коду, вважають, що вони можуть стати швидким шляхом до створення загального штучного інтелекту (AGI) — гіпотетичної технології з можливостями людського інтелекту, яку низка провідних компаній називають своєю кінцевою метою.
«Вперше ми побачимо економічно надзвичайно важливу діяльність, яка досягне людського рівня здібностей, у сфері розробки програмного забезпечення», — говорить Айзо Кант, генеральний директор і співзасновник Poolside. (OpenAI вже похвалилася, що її новітня модель o3 перемогла головного науковця компанії у змаганні з написання коду.)
Ласкаво просимо до другої хвилі ШІ для написання коду.
Правильний код
Інженери-програмісти говорять про два типи правильності коду.
Перший — це правильність синтаксису програми (її «граматика»), що означає, що всі слова, числа та математичні оператори розташовані на своїх місцях. Це має набагато більше значення, ніж граматична правильність у природній мові. Зробіть одну маленьку помилку в тисячах рядків коду — і код не запуститься.
Перше покоління помічників для написання коду вже досить добре справляється зі створенням коду, правильного з цього погляду. Завдяки навчанню на мільярдах фрагментів існуючого програмного коду вони засвоїли поверхневі структури багатьох типів програм.
Але є ще один рівень правильності — функціональність програми: так, вона запускається, але чи виконує вона те, що ви задумали? Саме на цей другий рівень правильності націлена нова хвиля генеративних помічників для коду — і саме це може докорінно змінити спосіб розробки програмного забезпечення.
«Великі мовні моделі можуть писати код, який компілюється, але вони не завжди пишуть програму, яку ви хотіли», — говорить Алістер Пуллен, співзасновник Cosine. «Щоб це стало можливим, потрібно відтворити процес мислення, через який проходить людина-кодер, щоб досягти бажаного результату».
Проблема в тому, що дані, на яких навчали більшість помічників для коду (мільярди фрагментів коду з онлайн-репозиторіїв), не відображають цих процесів мислення. Вони представляють готовий продукт, але не те, як він створювався. «Існує багато коду», — зазначає Кант. «Але ці дані не відображають процесу розробки програмного забезпечення».
Пуллен, Кант та інші доходять висновку, що для створення моделі, яка зможе створювати корисні програми, тестувати їх і виправляти помилки — потрібно показати їй більше, ніж просто готовий код. Їй потрібно показати, як цей код створювався.
Мета — створити моделі, які не просто імітують вигляд хорошого коду (незалежно від його працездатності), але й імітують процес, що призводить до створення такого коду.
Хлібні крихти
Щоб досягти цього, потрібен набір даних, який відображає сам процес створення програми — кроки, які може зробити людина-програміст під час написання коду. Уявіть ці кроки як слід із хлібних крихт, який машина могла б повторити, щоб самостійно створити схожий фрагмент коду.
Спершу потрібно визначити, які матеріали слід використовувати: які частини існуючої кодової бази та які інші джерела інформації потрібні для виконання конкретного програмного завдання?
«Контекст має вирішальне значення», — каже засновник Zencoder Ендрю Філев. «Перше покоління інструментів дуже погано працювало з контекстом, вони зазвичай просто переглядали відкриті вкладки. Але ваш репозиторій [кодова база] може містити 5000 файлів, і вони пропустять більшість із них».
Zencoder найняла команду ветеранів пошукових систем, щоб створити інструмент, який може аналізувати великі кодові бази та визначати, що є релевантним, а що — ні. Такий детальний контекст зменшує кількість помилкових результатів (галюцинацій) і покращує якість коду, який можуть генерувати великі мовні моделі, пояснює Філев: «Ми називаємо це аналізом репозиторію (repo grokking)».
У Cosine також вважають контекст ключовим. Вони збирають усі можливі «хлібні крихти» та використовують їх для створення нового типу набору даних. Компанія попросила десятки програмістів записувати всі свої дії під час виконання сотень різних програмних завдань. «Ми просили їх записувати все», — каже Пуллен. «Чому ви відкрили цей файл? Чому прокрутили його до половини? Чому закрили його?» Також вони попросили програмістів анотувати готові фрагменти коду, позначаючи частини, для створення яких знадобилося б знання інших частин коду чи конкретної документації.
Після цього Cosine обробляє всю цю інформацію та створює великий синтетичний набір даних, який відображає типові кроки програмістів і джерела інформації, на які вони спираються, щоб створити готові фрагменти коду. Цей набір даних використовується для навчання моделі, яка може визначити, який шлях із «хлібних крихт» їй потрібно пройти, щоб створити певну програму, а потім слідувати цьому шляху.
Компанія Poolside, яка базується у Сан-Франциско, також створює синтетичний набір даних, який відображає процес написання коду, але вона більше покладається на техніку, відому як RLCE — навчання з підкріпленням на основі виконання коду (Reinforcement Learning from Code Execution). Cosine також використовує цей підхід, але меншою мірою.
RLCE аналогічний техніці, яка використовується для того, щоб зробити чат-ботів, як-от ChatGPT, плавними у спілкуванні. Ця техніка відома як RLHF — навчання з підкріпленням на основі зворотного зв’язку від людини (Reinforcement Learning from Human Feedback). У RLHF модель навчають генерувати текст, який більше відповідає тому, що людські тестери вважають кращим. У RLCE модель навчають генерувати код, який більше відповідає тому, що працює так, як передбачалося, коли код запускається (виконується).
Обхід системи
Компанії Cosine і Poolside заявляють, що черпали натхнення з підходу, який використовувала компанія DeepMind зі своєю моделлю для гри AlphaZero. AlphaZero було надано набір кроків, які вона могла виконувати, — ходів у грі, — і потім вона грала сама із собою раз за разом, визначаючи методом проб і помилок, яка послідовність ходів була виграшною, а яка — ні.
«Вони дозволили моделі досліджувати всі можливі ходи на кожному етапі гри, симулювати стільки ігор, скільки дозволяють обчислювальні ресурси, — і це зрештою привело до перемоги над Лі Седолем», — говорить Пінмін Ван, науковий співробітник-основоположник Poolside, посилаючись на корейського гросмейстера з Ґо, якого AlphaZero перемогла у 2016 році. До роботи в Poolside Ван працював у Google DeepMind над застосуванням AlphaZero поза межами настільних ігор, зокрема над FunSearch, версією, натренованою для вирішення складних математичних завдань.
Коли підхід AlphaZero застосовується до програмування, кроки, які потрібні для створення фрагмента коду, стають доступними ходами в грі, а правильно створений додаток стає перемогою в цій грі. Залишена самій собі, модель може вдосконалюватись набагато швидше, ніж це здатна зробити людина. «Людський програміст пробує й зазнає невдачі один раз за один разом», — пояснює Канті. «Моделі можуть пробувати 100 варіантів одночасно».
Основна відмінність між Cosine і Poolside полягає в тому, що Cosine використовує спеціальну версію GPT-4o, надану OpenAI, що дозволяє тренувати модель на більшому наборі даних, ніж це можливо для базової моделі. Poolside ж створює власну велику мовну модель з нуля.
Канті з Poolside вважає, що навчання моделі на коді з самого початку дасть кращі результати, ніж адаптація існуючої моделі, яка вже поглинула не лише мільярди фрагментів коду, але й більшість інтернету. «Мене абсолютно влаштовує, якщо наша модель забуде про анатомію метеликів», — каже він.
Cosine стверджує, що її генеративний асистент для кодування, названий Genie, займає перше місце у рейтингу SWE-Bench — стандартному наборі тестів для моделей кодування. Poolside ще будує свою модель, але стверджує, що те, що вже створено, відповідає рівню продуктивності GitHub Copilot.
«Я особисто твердо вірю, що великі мовні моделі зможуть повністю зрівнятися з можливостями програміста», — каже Канті.
Однак не всі згодні з цим.
Нелогічні мовні моделі
Для Джастіна Готчліча, генерального директора та засновника Merly, великі мовні моделі є неправильним інструментом для цієї задачі — і крапка. Він наводить приклад свого собаки: «Жодна кількість навчання не зможе навчити мого собаку програмувати, цього просто не станеться», — каже він. «Він може робити багато інших речей, але не здатен на такий глибокий рівень когніції».
Пропрацювавши над генерацією коду понад десятиліття, Готчліч має схожу проблему з великими мовними моделями. Програмування вимагає здатності вирішувати логічні завдання з бездоганною точністю. Незалежно від того, наскільки добре мовні моделі навчаться імітувати те, що роблять програмісти, у своїй основі вони все ще залишаються, за його словами, статистичними слот-машинами: «Я не можу навчити нелогічну систему ставати логічною».
Замість того, щоб навчати мовну модель створювати код, подаючи їй безліч прикладів, Merly взагалі не показує своїй системі коду, написаного людьми. Це тому, що, за словами Готчліча, для того, щоб дійсно побудувати модель, здатну генерувати код, потрібно працювати на рівні логіки, яка лежить в основі коду, а не з самим кодом.
Система Merly тренується на проміжному представленні — чомусь на кшталт машинозчитуваної нотації, до якої більшість мов програмування перетворюються перед виконанням.
Готчліч не розкриває точних деталей, як виглядає це представлення чи як працює процес. Але він наводить аналогію: у математиці є ідея, що єдині числа, які обов’язково повинні існувати, — це прості числа, тому що всі інші числа можна обчислити, використовуючи лише прості. «Застосуйте цю концепцію до коду», — каже він.
Такий підхід не лише йде прямо до логіки програмування, але й швидкий, тому що мільйони рядків коду зводяться до кількох тисяч рядків проміжної мови перед тим, як система їх аналізує.
Зміна мислення
Ваше ставлення до цих конкуруючих підходів може залежати від того, чого саме ви очікуєте від генеративних помічників програмування.
У листопаді компанія Cosine заборонила своїм програмістам використовувати будь-які інструменти, окрім власних продуктів. Наразі вона спостерігає вплив інструмента Genie на своїх програмістів, які часто просто спостерігають, як інструмент створює код за них. “Тепер ви повідомляєте моделі результат, якого хочете досягти, і вона сама вирішує, як реалізувати це,” каже Ян Лі, ще один співзасновник Cosine.
Пуллен визнає, що це може бути спантеличуючим і вимагає зміни мислення. “У нас є програмісти, які виконують кілька завдань одночасно, переходячи між вікнами,” каже він. “Поки Genie виконує код в одному вікні, вони можуть змушувати його виконувати інше завдання в іншому.”
Ці інструменти також дозволяють створювати кілька версій системи одночасно. Наприклад, якщо ви розробляєте програмне забезпечення, яке потребує інтеграції платіжної системи, ви можете попросити помічника програмування спробувати одразу кілька варіантів — Stripe, Mango, Checkout — замість того, щоб реалізовувати кожен вручну по черзі.
Genie може працювати над виправленням помилок цілодобово. Більшість команд програмного забезпечення використовують інструменти для звітів про помилки, які дозволяють користувачам завантажувати описи виявлених проблем. Genie може прочитати ці описи й запропонувати виправлення. Потім людині залишається лише переглянути їх перед оновленням коду додатку.
Ніхто з людей не здатен зрозуміти трильйони рядків коду у сучасних найбільших програмних системах, каже Лі, і зі збільшенням кількості коду, який пишеться іншим програмним забезпеченням, обсяг лише зростатиме.
Це зробить помічників програмування, які підтримуватимуть цей код, життєво необхідними. «Вузьким місцем стане те, наскільки швидко люди зможуть переглядати код, створений машиною», – каже Лі.
Як ставляться до цього інженери Cosine? За словами Пуллена, доволі позитивно. «Якщо я даю вам складну проблему, ви все одно думаєте, як її описати для моделі», каже він. «Замість написання коду вам потрібно викласти його природною мовою. Але це все одно вимагає багато розумової роботи, тому ви не позбавляєтеся радості від інженерії. Творчий інтерес зберігається».
Дехто адаптується швидше за інших. Cosine запрошує потенційних працівників провести кілька днів у кодингу з їхньою командою. Кілька місяців тому компанія попросила одного з кандидатів створити віджет, який би дозволяв співробітникам ділитися цікавими фрагментами програмного забезпечення у соціальних мережах.
Завдання було непростим і потребувало знання кількох розділів із мільйонів рядків коду Cosine. Проте кандидат виконав його за кілька годин. «Ця людина, яка ніколи раніше не бачила нашої кодової бази, прийшла у понеділок, а у вівторок після обіду вже все було готово,» – каже Лі. «Ми думали, що це займе у нього весь тиждень». Ту людину найняли на роботу.
Але є й інший аспект. Багато компаній використовуватимуть цю технологію для скорочення кількості програмістів. Лі вважає, що скоро ми побачимо нові рівні програмістів. З одного боку, будуть елітні розробники з мільйонними зарплатами, які зможуть діагностувати проблеми помилок, створених штучним інтелектом. З іншого боку, менші команди з 10-20 людей виконуватимуть роботу, яка раніше потребувала сотень програмістів.
«Це буде схоже на те, як банкомати змінили банківську сферу», – каже Лі. «Тепер усе, що ви хочете зробити, визначатиметься обчислювальними потужностями, а не кількістю співробітників. Я думаю, що всі розуміють: епоха, коли компанії наймали ще кілька тисяч програмістів, завершилася».
Перевершення людських можливостей
Для Готчшліха, машини, які кодують краще за людей, стануть незамінними. На його думку, це єдиний спосіб створити величезні, складні програмні системи, які нам одного дня знадобляться. Як і багато хто у Кремнієвій долині, він передбачає майбутнє, коли люди переміщуватимуться на інші планети. Це стане можливим лише завдяки тому, що ШІ розробить необхідне програмне забезпечення, каже він: “Справжня мета Merly — доставити нас на Марс.”
Готчшліх воліє говорити про “машинне програмування,” а не “помічників програмування,” бо вважає, що це неправильна постановка питання. «Я не думаю, що ці системи мають допомагати людям — я думаю, що люди мають допомагати їм», – каже він. «Вони можуть рухатися зі швидкістю ШІ. Навіщо обмежувати їхній потенціал?»
«Є такий мультфільм — Флінстоуни, де машини їдуть лише тоді, коли водії штовхають їх ногами», – каже Готчшліх. «Це трохи схоже на те, як більшість людей зараз використовує ШІ у програмних системах».
«Але те, що будує Merly, по суті, — це космічні кораблі», – додає він. І він не жартує. «І я не думаю, що космічні кораблі повинні працювати завдяки людським педалям. Космічні кораблі повинні працювати на варп-двигунах».
Якщо це звучить дико — так і є. Але тут важливо інше: ті, хто розробляє цю технологію, мають амбітну кінцеву мету.
Готчшліх не єдиний зі своїм “космічним” баченням. Попри їхню увагу до продуктів, якими розробники можуть користуватися вже сьогодні, більшість цих компаній прагне набагато більшого.
На сайті Cosine компанія називає себе «Лабораторією людського мислення». Вона бачить програмування лише як перший крок до універсальної моделі, яка зможе імітувати людиноподібне розв’язання проблем у різних сферах.
Poolside має схожі цілі: компанія прямо заявляє, що створює штучний загальний інтелект (AGI). «Код — це спосіб формалізації мислення», – каже Кант.
Ван говорить про агентів. Уявіть собі систему, яка може створювати власне програмне забезпечення для виконання будь-яких завдань на льоту, каже він. «Якщо ви досягнете моменту, коли ваш агент зможе вирішувати будь-яке обчислювальне завдання через створення програмного забезпечення, це фактично буде демонстрацією AGI».
Поки що такі системи залишаються мрією. Водночас програмна інженерія змінюється швидше, ніж багато хто на передовій очікував.
«Ми ще не на тому етапі, коли все робиться лише машинами, але ми точно відходимо від звичного уявлення про роль програміста», – каже Пуллен із Cosine. «Ми бачимо перші іскри нового робочого процесу — те, що означатиме бути програмістом у майбутньому».
За матеріалами: MIT Technology Review
