Нодар Данієля, CEO і співзасновник Shuttle – Інтерв’ю Серія

Нодар Данієля, CEO і співзасновник Shuttle – Інтерв’ю Серія: Нодар Данієля є співзасновником та CEO Shuttle з моменту заснування компанії у 2019 році, очолюючи її зростання від раннього стартапу YC Summer 2020 до компанії з платформної інженерії, орієнтованої на розробників; до Shuttle він обіймав посади, включаючи директора з управління ризиками в Provenance Technologies Ltd, де він працював над кількісними стратегіями хедж-фондів, а раніше займав посади у сферах технологій та даних в Лондоні та в Google.

Shuttle – це відкрита платформа інфраструктури хмарних обчислень, яка спрощує розробку та розгортання бекенду, виводячи інфраструктуру з анотацій коду, щоб розробники могли зосередитися на написанні коду на Rust або іншій мові без управління окремими конфігураційними файлами чи складної настройки хмарної інфраструктури; платформа дозволяє швидко розгортати, забезпечувати ресурси та масштабувати без проблем, і нею користуються десятки тисяч інженерів з більш ніж 130 000 розгортань, маючи на меті поширити свій підхід із нульовою конфігурацією та допомогою ШІ на всі мови й інтегруватися з такими інструментами, як GitHub Copilot та Cursor.

Який момент або яке розчарування зрештою спонукали вас до співзаснування Shuttle, і яку проблему ви намагалися вирішити на самому початку?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замість того, щоб заставляти розробників перекладати своє застосування в інфраструктуру хмарних обчислень, Neptune розуміє застосування і генерує інфраструктуру навколо нього. Ваш код – це креслення. Neptune будує середовище, необхідне для його виконання. Ні Dockerfile, ні Terraform, ні нескінченної конфігурації.

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

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

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

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

Зміна, яку ми зробили, полягала у переході від “Штучний інтелект вирішує” до “Штучний інтелект пропонує в межах обмежень”. Це різниця між цікавим демо і чимось, чому можна довіряти, коли це має значення. Розробники не витрачають менше часу на прийняття рішень – вони витрачають менше часу на набір тексту та більше часу на рішення про те, що повинно існувати, що є прийнятним, які компроміси мають сенс. Найкращі команди ставляться до штучного інтелекту як до дуже здатного молодшого інженера: корисного, продуктивного, але не того, хто ухвалює остаточні рішення.

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

Профіль змінився драматично. Спочатку на стороні Rust у нас був різноманітний базис – окремі розробники, ранні стартапи, масштабовані компанії, навіть підприємства в автомобільній, IoT, фінансовій, криптовій сфері, будь-де, де мають значення надійність та продуктивність. Ці команди хотіли силу Rust без навантаження управління складною хмарною інфраструктурою.

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

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

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

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

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

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

Оглядаючи вперед, як ви бачите роль Neptune у екосистемі, де системи штучного інтелекту все частіше будують, розгортають та керують іншими програмними системами?

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

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

Наша довгострокова мета – стати системою за замовчуванням для DevOps, підтримуваного штучним інтелектом – по суті, інженером платформи штучного інтелекту. Чи написаний код розробником у Cursor, чи згенерований автономно агентом штучного інтелекту, Neptune повинен бути шаром, який бере його від коду до повністю запущеного, масштабованого виробничого сервісу.

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

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