Професор Еран Яхав, співзасновник і співгенеральний директор Tabnine – Серія інтерв’ю

Професор Еран Яхав, співзасновник і співгенеральний директор Tabnine, є професором комп’ютерних наук в Техніоні – Ізраїльському технологічному інституті, чиї дослідження зосереджені на мовах програмування, машинному навчанні та інженерії програмного забезпечення, особливо на синтезі програм та великомасштабному аналізі коду. Паралельно з академічною роботою він співзаснував Tabnine (спочатку Codota), щоб застосувати роки досліджень до практичних інструментів для розробників, допомагаючи впровадити кодування, кероване штучним інтелектом, та автоматизацію. Його робота поєднує академію та промисловість, з акцентом на те, щоб зробити код, згенерований штучним інтелектом, більш надійним, безпечним та контекстно-чутливим для реальних підприємств.

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

Ви провели роки, досліджуючи аналіз програм та синтез у Техніоні, і раніше працювали в IBM Research. Яка проблема у розробці програмного забезпечення переконала вас співзасновати Tabnine, і як ваша академічна робота сформувала первинну бачення компанії?

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

Я починав з синтезу програм для паралельних програм, намагаючись автоматизувати створення паралельних програм з послідовних. Потім я перейшов до більш загального застосування синтезу програм за допомогою машинного навчання.

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

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

Tabnine стала піонером у сфері інструментів кодування, керованих штучним інтелектом, за роки до того, як генеративний штучний інтелект став популярним завдяки інструментам типу OpenAI. Оглянувшись назад, як змінилася роль штучного інтелекту у розробці програмного забезпечення з тих перших днів, і які уроки галузь вивіла з першої хвилі копілотів кодування?

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

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

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

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

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

Програмні системи – це складні мережі відносин. Одна зміна може вплинути на кілька служб, API чи компонентів нижнього рівня.

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

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

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

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

Генерація, доповнена пошуком, – це корисна техніка. Вона дозволяє моделям витягувати відповідні документи або фрагменти коду під час генерації відповіді.

Але пошук сам по собі не створює розуміння. Він надає доступ до інформації, а не структуру.

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

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

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

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

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

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

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

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

Ключовим питанням є не те, скільки коду генерує штучний інтелект, а скільки корисної роботи він фактично виконує.

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

Організації також повинні дивитися на час, витрачений розробниками на переробку, а також час очікування змін від розробки до виробництва.

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

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

Довіра – одне з найважливіших факторів прийняття підприємств штучного інтелекту.

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

Вирішення цього виклику залежить від двох критичних стовпів:

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

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

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

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

Бази даних стали основою для управління даними. Платформи хмарних обчислень стали основою для виконання застосунків у масштабі.

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

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

У цьому сенсі контекст стає спільною основою для підприємств штучного інтелекту.

Багато компаній будують інструменти кодування, тісно пов’язані з однією основною моделлю. Tabnine натомість дозволяє підприємствам підключати різні моделі залежно від їхніх потреб. Чому гнучкість моделі важлива для довгострокової еволюції інструментів розробки підприємств штучного інтелекту?

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

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

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

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

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

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

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

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

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

Дякуємо за велике інтерв’ю. Читачам, які бажають дізнатися більше, рекомендуємо відвідати Tabnine.