Нодар Даниэлия, генеральный директор и сооснователь Shuttle – Интервью

Нодар Даниэлия, генеральный директор и сооснователь Shuttle – Интервью: Нодар Даниэлия занимает должность сооснователя и генерального директора Shuttle с момента основания компании в 2019 году, руководя ее ростом от ранней стадии стартапа до платформы для разработки программного обеспечения; до Shuttle он занимал должности, включая начальника управления рисками в Provenance Technologies Ltd, где он работал над стратегиями количественного хедж-фонда, и ранее занимал технические и данные роли в Лондоне и в Google.

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

Какой момент или разочарование в конечном итоге заставило вас стать сооснователем Shuttle, и какую проблему вы пытались решить в самом начале?

Переломный момент наступил во время моего пребывания на посту руководителя торговли в количественном хедж-фонде. У нас были исключительные инженеры – кандидаты наук, старшие специалисты по платформам, исследователи в области машинного обучения – но даже с таким талантом облачная инфраструктура была постоянным узким местом. Создание торговой модели или бэкенд-сервиса не было сложной задачей. Проблемой было развертывание: получение его в живом, безопасном, масштабируемом виде, подключение облачных сервисов. Вот где все замедлялось. В один момент более половины нашей инженерной команды занималась работой по DevOps только для поддержания систем в рабочем состоянии.

Что запомнилось, так это не сложность кода или математики. Это было наблюдение за тем, как высококвалифицированные люди тратят большую часть своего времени на борьбу с облаком, а не на создание того, что действительно важно. Никто не хотел делать эту работу, но она была неизбежна. Этот разрыв – разрыв между “Я создал что-то” и “оно работает надежно” – это то, что Shuttle был создан для решения.

Shuttle был основан в 2019 году, до нынешней волны инструментов кодирования ИИ. Как ваша первоначальная концепция эволюционировала, поскольку разработка с помощью ИИ стала мейнстримом?

Основная проблема осталась прежней, но ИИ усилил ее значительно. Когда мы начали, инфраструктура уже была ограничивающим фактором для сильных инженерных команд. Когда появились инструменты, такие как Copilot, Cursor и Claude, эта проблема стала невозможно игнорировать.

Внезапно разработчики могли генерировать полные приложения за несколько минут, но эти приложения сразу же сталкивались с проблемой. ИИ может написать код, но он не может надежно настроить и управлять облачными ресурсами. Разрыв, который мы пытались решить, стал намного шире и намного более срочным. Миллионы людей теперь строят прототипы, но только небольшая часть из них доходит до производства.

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

Инструменты ИИ, такие как Cursor и GitHub Copilot, изменили то, как разработчики пишут код. С вашей точки зрения, какие части цикла разработки программного обеспечения улучшились больше всего, и где команды все еще сталкиваются с трудностями?

Генерация кода сделала огромный шаг вперед. Эта часть почти решена. Вы можете описать функцию, и ИИ создаст ее. Особенно это касается frontend, поскольку закономерности хорошо поняты – компоненты, стили, макеты.

Где команды сталкиваются с трудностями, так это во всем, что происходит после: развертывание, инфраструктура, эксплуатация. Инструменты ИИ могут сгенерировать конечную точку 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.