Інтерв’ю
Нодар Данієля, 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, ця瓶頸 стала неможливою для ігнорування.
Раптом розробники могли генерувати повні додатки за хвилини, але ці додатки одразу ж натrafили на стіну. Штучний інтелект може написати код, але він не може надійно конфігурувати та керувати хмарними ресурсами. Розрив, який ми намагалися вирішити, став ще ширшим і ще більш терміновим. Міліони людей зараз будують прототипи, але лише мала частина з них досягає виробництва.
Бачення еволюціонувало від “зробити інфраструктуру легшою для розробників” до “зробити інфраструктуру, яка працює для цілого нового покоління будівельників” – сольні засновники, малі команди та агенти штучного інтелекту, які можуть створювати код бекенду, але не мають інтересу до боротьби з конфігурацією хмари. Ми більше не обслуговуємо лише традиційних інженерів. Аудиторія вибухнула.
Інструменти штучного інтелекту, такі як 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.
