Нодар Данієля, 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, але вони не можуть автоматично створити базу даних, сховище, чергу, мережу, права доступу або конвеєр розгортання. Інфраструктура бекенду не поспішала за генерацією коду.

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

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

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

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

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

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.