Railway: The Agent-Native Cloud — Jake Cooper
Jake Cooper, основатель Railway, рассказывает о том, как платформа из медленно растущего PaaS превратилась в облако нового поколения для эпохи агентов. Railway привлёкла $124 млн, командой из 35 человек обслуживает 3 млн пользователей и добавляет около 100 000 регистраций в неделю. Компания построила собственные bare metal дата-центры со сроком окупаемости 3 месяца и маржой 70%, причём стоимость их оборудования теперь превышает весь привлечённый капитал из-за роста цен на RAM. Cooper утверждает, что pull request умирает, а будущее за агентами, которым нужны версионирование, наблюдаемость и оркестрация в 1000 раз больших масштабах. Обсуждаются Railpack, Nixpacks, Temporal, content-addressable файловые системы, форки production-окружений, feature flags и почему CLI становится важнее визуального canvas в мире агентов. Cooper также делится опытом соло-основателя, рассказывает о том, как Railway пережила потери $500K в месяц, и объясняет, почему строит новое облако с нуля, а не копирует гиперскейлеров.
Railway: облако нативное для агентов — Jake Cooper
Пройдите опрос AI Engineering Survey 2026 и получите кредитов на сумму более $2k и билеты на AIE WF!
Запись была сделана до того, как у Railway случился крупный сбой GCP 19 мая, несмотря на multi-AZ, multi-zone mesh-кольцо с HA fiber interconnects между их Metal <> GCP <> AWS, потому что обнаружение нагрузок по недосмотру всё ещё было привязано к GCP. Всё уже решено, опубликован post-mortem.
Railway не начиналась как компания AI-инфраструктуры.
Она была основана в 2020 году — за годы до того, как агенты стали способом мышления о деплое софта по умолчанию. Jake Cooper, ранее работавший в Bloomberg и Uber, основал Railway с простой одержимостью: энергия активации для выкатывания чего-либо в продакшн должна быть близка к нулю. Пушишь код, получаешь URL, итерируешь. Никаких Docker-файлов, никаких манифестов Kubernetes, никаких скриптов Ansible поверх скриптов Ansible.
Многие годы это была медленная работа. Railway потратила первые 18 месяцев на ручное привлечение первых 100 пользователей: Jake лично приветствовал каждую регистрацию в Discord на втором мониторе.
Сегодня Railway привлекла $124 млн и растёт очень быстро. Команда из 35 человек поддерживает 3 миллиона пользователей, добавляя около 100 000 регистраций в неделю. Их bare metal дата-центры окупаются за 3 месяца по сравнению с арендой в облаке, а маржа 70% финансирует агрессивный cloud bursting при необходимости. Принадлежащие им серверы фактически выросли в цене вместе с ростом цен на RAM — это означает, что стоимость их оборудования теперь превышает капитал, который они привлекли.
От перестройки сетевого overlay Railway за выходные до переноса подавляющего большинства нагрузок на собственные bare metal дата-центры — Jake Cooper пытается построить новое облако для мира, нативного для агентов. В этом эпизоде основатель Railway и «дирижёр» присоединяется к swyx и Alessio, чтобы разобраться, почему следующая эра инфраструктуры ПО — это не просто «Heroku, но новее», что нужно агентам, чего не требовалось людям, и почему старый цикл деплоя из Git, PR, CI/CD и статичных облачных ресурсов может быть на пороге переписывания.
Мы подробно разбираем инфраструктурный стек Railway: собственные дата-центры на железе, трёхмесячные сроки окупаемости в облаке, cloud bursting, долговое финансирование дата-центров, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable файловые системы, безопасные для агентов форки продакшна, и почему CLI может стать важнее canvas в мире агентов. Jake также делится историей основателя Railway, рассказывает, как компания пережила потери $500K в месяц, почему сейчас она обслуживает миллионы пользователей всего 35 сотрудниками, и почему он считает, что pull request умирает.
Мы обсуждаем:
Как Railway прошла путь от медленного шестилетнего марафона до 100 000 пользователей в неделюКак Railway думает об агентах как о следующем доминирующем виде ПОПочему агентам нужны версионный контроль, наблюдаемость, compute, хранилище и оркестрация на масштабе 1000xЭкономика собственных дата-центров Railway и трёхмесячная окупаемостьКак Railway использует cloud bursting при масштабировании собственной инфраструктурыПочему долговое финансирование дата-центров может быть лучшим инструментом, чем venture debt, для инфра-стартаповCentral Station — внутренняя система Railway для кластеризации клиентского фидбэка и инцидентовПочему ответственное раскрытие и избыточная коммуникация важны для платформПочему feature flags, постепенные роллауты и shadow traffic необходимы для агентовСильные и болезненные стороны Temporal и почему workflow важны для агентовRailpack, Nixpacks, Nix и lazy-loaded content-addressable файловые системыПочему «cattle, not pets» может измениться, если можно клонировать pet’овПочему Railway строит новое облако с нуля, а не копирует гиперскейлеровПуть соло-основателя, фокус, письмо и как Jake думает о построении компании
Railway:
Jake Cooper:
Таймкоды
00:00:00 Введение: Что такое Railway?00:02:07 Путь Jake к Railway00:06:13 История роста Railway за шесть лет00:08:52 Перестройка бизнеса после free tier00:11:17 Агенты как следующая платформа ПО00:13:29 Инфраструктурная философия Railway00:15:42 Bare metal, экономика облака и compute crunch00:17:22 Cloud bursting и сеть из пяти облаков00:20:20 Долговое финансирование дата-центров и инфра-финансирование00:23:31 Дата-центры в космосе00:25:24 Что нужно агентам от инфраструктуры00:28:24 CLI, canvas и UX, нативный для агентов00:35:15 Central Station, инциденты и ответственное раскрытие00:40:30 Безопасные роллауты, SRE-агенты и форки продакшна00:45:00 AI SRE, спеки, код и тесты00:48:24 Самореплицирующаяся инфраструктура и новый serverless00:53:18 Heroku, Temporal и workflow-движки01:04:07 Railpack, Nixpacks и lazy-loaded файловые системы01:06:01 Coding-агенты, расходы на токены и ускорение roadmap01:10:56 Pull request умирает01:12:28 Feature flags и SDLC эры агентов01:16:15 Cattle, pets и клонирование машин01:19:29 Уроки соло-основателя01:24:12 Фокус, GPU и построение нового облака01:28:20 Завершающие мысли
Транскрипт
Alessio [00:00:00]: Привет всем. Добро пожаловать в подкаст Latent Space. Это Alessio, основатель Kernel Labs, со мной Swyx, редактор Latent Space.
Swyx [00:00:10]: Привет-привет. Сегодня у нас в студии Jake Cooper из Railway.
Alessio [00:00:14]: Дирижёр Railway.
Swyx [00:00:15]: Дирижёр в Railway. Да.
Alessio [00:00:16]: Чух-чух.
Swyx [00:00:17]: У тебя это где-нибудь правда написано? На визитке, например?
Jake [00:00:20]: Мы называем некоторых наших волонтёров-модераторов дирижёрами (conductors). У меня нет визитки. Мы пока не настолько большие. В какой-то момент будет. Мне вручили красивую визитку ребята из Supermicro, и я подумал: «Чёрт, это довольно официально».
Swyx [00:00:30]: Визитки возвращаются.
Jake [00:00:32]: Они классные. Они модные. С дирижёром норм. Мы пытаемся придумать, как называть друг друга внутри компании. Кто-то считает, что это супер-кринж и говорит: «Не нужно никакого названия для людей внутри». Кто-то хочет как-то называть друг друга. У нас пока нет действительно хорошего варианта.
Jake [00:00:55]: У нас были New Railcrews, Trainiacs. Ничего пока не прижилось.
Swyx [00:01:00]: Мне нравится Trainiac. Trainiac звучит хорошо. Railwayians. Для тех, кто не знает — что такое Railway? Дадим людям чёткое определение в начале.
Jake [00:01:09]: Railway — это самый простой способ выкатить что угодно. Заходишь на canvas или говоришь с Claude и говоришь: «Разверни инстанс Postgres, разверни мой GitHub-репозиторий, запусти этот код», — и ты в деле.
Swyx [00:01:22]: У вас классная анимация на лендинге.
Jake [00:01:24]: Спасибо. Кстати, ни одна из них не моя. Меня больше не подпускают к дизайнерским штукам.
Jake [00:01:25]: Мы хотим сделать тривиально простым не только деплой, но и эволюцию приложений со временем. Большинство сегодняшнего тулинга наслаивает энтропию на энтропию: Docker, Kubernetes, скрипты Ansible и всё остальное. Если мы можем версионировать весь ваш софт и отслеживать все изменения, мы можем сделать тривиальным клонирование окружений, форк в параллельную вселенную, получение копий production-данных, копий любых сервисов, внесение изменений, их валидацию и сворачивание обратно — без воспроизведения всего этого в staging-окружении.
История Railway: от систем Uber к новому облаку
Swyx [00:02:07]: Я смотрел твой бэкграунд: Bloomberg, Uber. Ничто сразу не говорит: «Этот парень основает следующую великую PaaS-платформу». Что подготовило тебя к Railway?
Jake [00:02:21]: Это любопытство — желание копать глубже. Я начинал с фронтенда, работал над Wolfram Mathematica и портированием. Потом ненадолго перешёл в Bloomberg, а затем в Uber и распределённые системы — взял системы Jump Bikes и перенёс их на распределённую систему, построенную на Cadence, пра-Temporal.
Swyx [00:02:44]: О котором я, кстати, с радостью поговорю — плюсы и минусы.
Jake [00:02:48]: Полностью.
Swyx [00:02:51]: Но давай сначала историю Railway.
Jake [00:02:52]: Это была непрерывная серия шагов в желании получить определённый опыт. Будь то подойти к велосипеду, разблокировать его и чтобы всё работало без трения, или что-то ещё — глубина, необходимая для этого, следует из самого опыта. Большая часть работы, которую делаю я и команда, — в служении этому опыту. Нам фундаментально всё равно, насколько глубоко придётся копать. Мы доплывём до дна бассейна, чтобы получить нужный опыт.
Jake [00:03:17]: У меня нет PhD по физике. У меня EECS-диплом. Это всегда было о том, как сделать следующий шаг: как туда попасть? Это и привело к основанию Railway ради такого опыта, а потом к движению вплоть до bare metal дата-центров. На этой неделе я добавлял патчи в ядро, чтобы получить нужный опыт — потому что я вижу, насколько лучше всё может быть.
Swyx [00:03:49]: Другие патчи в ядро Linux на этой неделе?
Jake [00:03:51]: Да. Не upstream. В нашем форке.
Swyx [00:03:52]: Это флекс. Railpack? Нет, это другое. Это ОС поверх Railpack?
Jake [00:03:57]: Нет, это реальный патч в ядро. Всегда буквально один вопрос: что нам нужно сделать, чтобы получить этот опыт? А потом разобраться, как. Всё разрешимо.
Swyx [00:04:10]: Отправите ли вы патч upstream, или он не подходит для других use case?
Jake [00:04:13]: Может быть. Нам надо доработать опыт внутри. Это связано со слоем хранения, который мы строим для агентских штук. Возможно, он будет полезен upstream, но для нас внутри он глубоко полезен.
Open Source, форки и недетерминированное версионирование
Swyx [00:04:29]: Ты упомянул open source. Как ты думаешь о том, чтобы начинать с open source, а потом coding-агенты позволяют сделать гораздо больше с форками?
Jake [00:04:38]: Первородный грех GitHub в том, что это почти набор сломанных указателей. У тебя есть штука, ты её клонируешь, и теперь ты потерял весь upstream. Как сделать тривиальным для людей модифицировать совсем маленькие куски?
Jake [00:04:51]: Мы думаем о Git дискретно: я либо внёс изменение и смержил upstream, либо нет. Как бы это выглядело, если бы оно было процентным, чуть более недетерминированным или потоком изменений, которые пользователи проходят по мере раскатки в процентах и накатываются вплоть до конца?
Jake [00:05:13]: У нас есть open-source kickback-программа, и мы позволяем разворачивать шаблоны, потому что хотим сделать тривиальным для людей версионирование этих шардов со временем. Это решает большую проблему вокруг аутентификации, авторизации и безопасности. У NPM есть способ задать: «Не бери новые пакеты». Идеальное конечное состояние — когда ты постепенно раскатываешь пользователям с минимальной зоной поражения и продолжаешь раскатку. JPMorgan, наверное, должен быть последним в патч-линии — ради всех нас, потому что там наши деньги и средства к существованию.
Jake [00:05:53]: Это ок, если Johnny Vibe Coder получит сломанный патч, потому что в системе столько энтропии, что резина должна где-то соприкоснуться с дорогой. Тестировать надо на разных уровнях.
Долгий марафон: первые пользователи, free tier и работа над бизнесом
Swyx [00:06:13]: Я хотел показать этот великолепный график. Это use или количество ежедневных регистраций?
Jake [00:06:22]: Ежедневные регистрации, кажется.
Swyx [00:06:24]: Вы начали шесть лет назад. Был медленный марафон, а теперь вы на ракете. Ты говоришь: «Не сомневайся в своём бою и не сдавайся». Может, выберешь ключевые точки перелома для компании.
Jake [00:06:40]: В начале всё упирается в получение первых 100 пользователей — кровь из носу. У нас был сайт и саппорт-ссылка. Саппорт-ссылка вела в Discord. У меня были включены уведомления и два монитора: один — рабочий, второй — Discord. Если кто-то заходил, я тут же: «Привет, как дела?» Это случалось редко, так что заставить первых 100 пользователей вернуться — это и был старт.
Jake [00:07:14]: Потом ты строишь консалтинговую фабрику, потому что пользователи хотят всё подряд. Приходится возвращаться к доске и спрашивать: «Какой реально продукт я хочу построить поверх этого?»
Jake [00:07:28]: VC хотят графики, всегда уходящие вверх и вправо, но в реальности тебе необязательно нужны такие графики. У нас были периоды расширения, когда мы добавляли фичи для тестирования use case, и периоды сжатия, когда мы спрашивали: «Если опыт у нас хороший — как сделать его значительно лучше?» Может, выкинуть фичи, которые больше не подходят нашему ICP.
Jake [00:07:57]: Бум с 2022 по 2023 пришёл с free tier. Все, кому не лень, им пользовались.
Swyx [00:08:09]: Куча Reddit-ботов и Discord-ботов.
Jake [00:08:12]: И крипто-майнеры. Когда строишь открытый продукт в интернете, где может зарегистрироваться кто угодно, — интернет ужасное место с массой штук. Проходишь периоды: «Как охватить как можно больше людей?» Потом: «Как точно попасть в use case тех людей, которые реально важны и реально увлечены этой конкретной штукой?»
Jake [00:08:39]: Потом был двухлетний период — заставить бизнес работать. В эпоху free tier мы теряли около полумиллиона долларов в месяц.
Swyx [00:08:59]: На банковском счёте в $20 миллионов.
Jake [00:09:02]: На банковском счёте в $20 миллионов при выручке, может, $50 000 в месяц. Это ужасный бизнес. Не знаю, как кто-то вообще в него инвестировал. Но через это нужно пройти и сказать: «У нас опыт, который людям нравится, но бизнес должен работать».
Jake [00:09:17]: Есть две школы мысли. Можно тянуть ужасный бизнес наверх с плохими маржами, либо вернуться и заставить его работать. Мы всегда хотели супер-маленькую команду. Сейчас нас 35 человек. Это очень мало.
Swyx [00:09:36]: Уже поддерживаете три миллиона?
Jake [00:09:38]: Да. Сейчас добавляем 100 000 пользователей в неделю, так что растёт быстро. Мы не хотим нанимать ради найма или бросать тела на проблемы. Мы хотим строить системы. Сложно строить системы во время расширения, потому что ты добавляешь в систему вещи, потому что их просят люди или потому что что-то ломается.
Jake [00:10:00]: Нам пришлось отрубить free-пользователей на какое-то время, перестроить бизнес и убедиться, что он работает. Мы хотим охватить как можно больше людей, потому что софт — это важно. Создавать вещи в физическом мире стало сложно, поэтому важно, чтобы людям было легко строить в виртуальном мире и иметь доступ к творчеству. Но у этого пути есть этапы.
Jake [00:10:30]: На графиках видны провалы. Если посмотреть между 2025 и 2026, это либо лето, либо зима. Люди уезжают в отпуск с семьями.
Swyx [00:10:50]: Это так сильно влияет?
Jake [00:10:51]: Да. Это отчасти B2C и отчасти B2B. Люди постоянно деплоят, потом останавливаются. Наша кривая активации теперь показывает, что больше людей активируется в будни — у нас больше бизнес-пользователей, и со временем это сглаживается.
Агенты как новый интерфейс к деплою
Swyx [00:11:17]: Был ли момент, когда вы начали приоритизировать разработку под AI или агентов?
Jake [00:11:24]: Мы приоритизировали агентов как вершину воронки. За последние шесть месяцев мы глубоко приоритизировали агентов как механизм построения и деплоя, потому что считаем, что кривая настолько крутая и именно так люди будут строить и деплоить софт.
Jake [00:11:42]: Почти не важно, дот-ком это или нет, потому что мы все и так в интернете. Если агенты будут разворачивать кучу всего, и мы упрёмся в стену inference в какой-то момент — мы решим эти проблемы. Доминирующий вид на ближайшие 10 лет — мы прошли путь от ассемблера к C, к C++, к JavaScript и к словам. Этот цикл нужно замкнуть.
Swyx [00:12:13]: Когда ты говоришь «это дот-ком», ты имеешь в виду покупку домена или общий случай?
Jake [00:12:17]: Я имею в виду эпоху дот-комов, когда у компаний был огромный взлёт, потому что люди понимали, что интернет важен. Потом упёрлись в бутылочные горлышки, фундаментальные законы физики, математика не сошлась, и все спустились обратно на землю. Но это не имело значения, потому что интернет стал настолько влиятельным. Если работаешь на достаточно длинном горизонте, всё равно стоит строить эти штуки, потому что видишь, куда всё идёт.
Jake [00:12:45]: Думаю, на этом этапе сейчас много агентских штук. Доходишь до момента, когда запускаешь тысячи агентов параллельно. Какая цена inference? Какая цена compute? Как сделать это эффективным? Как всё это координировать? У нас проблемы с координацией людей; у нас даже для этого нет хорошего тулинга. Теперь надо понять, как заставить агентов координироваться, безопасно версионировать изменения и знать, когда поднять руку, чтобы кто-то вмешался. Иначе это становится фабрикой прерываний.
Инфраструктурный тезис Railway: сеть, compute, хранилище и железо
Swyx [00:13:19]: Перейдём к технической стороне. Какие основные инфраструктурные или архитектурные убеждения Railway позволяют вам делать то, что вы делаете?
Jake [00:13:29]: Примитивы для нас очень важны. Нам нужны сеть, compute, хранилище и оркестрация вокруг них. Над многими из этих вещей нужен контроль. Мы много говорили о том, что не очень-то используем Kubernetes, потому что хотим высокоуровневого контроля над размещением нагрузок в очень конкретных местах.
Jake [00:13:48]: Причина в том, что с агентами нужно быть очень эффективным: переиспользование памяти и прочее, иначе массово раздуешь свою стоимостную структуру. Возможность собрать собственные серверы и построить собственное железо открывает производительность и стоимость. Опыт, где ты запускаешь 1000 агентов параллельно, не становится запредельно дорогим.
Jake [00:14:13]: Использование токенов и compute взрывается. Со временем эти вещи должны стать намного эффективнее. Можно получить большую маржу, чтобы сделать этот опыт надёжным, построив собственное железо. Всё это в служении тому, чтобы предложить дифференцированный опыт максимально возможному количеству людей.
Swyx [00:14:51]: У вас есть дата-центр в Сингапуре.
Jake [00:14:53]: Да. В каждом другом регионе теперь по два. В Сингапуре добавим второй в Q3.
Swyx [00:14:58]: А как это устроено? Я никогда не строил дата-центр. Идёшь в Equinix и говоришь: «Хочу слотов?»
Jake [00:15:05]: Да. Equinix. Идёшь и говоришь: «Хочу электричество и клетку». Они говорят: «Отлично, вот сколько это будет стоить». Арендуешь клетку на какой-то период, наполняешь её стойками и серверами, и подключаешь интернет. Это все части.
Swyx [00:15:36]: Дальше ты разбираешься со всем остальным.
Jake [00:15:37]: Со всем остальным сам.
Swyx [00:15:39]: Какова математика по сравнению с тем, чтобы это делали облака?
Jake [00:15:43]: Если бы мы арендовали в облаке, наш срок окупаемости перехода на железо — около трёх месяцев.
Swyx [00:15:50]: Это безумие.
Jake [00:15:51]: Это безумно. Это четыре года амортизированного оборудования. Compute crunch ещё проявит себя, потому что гиперскейлеры скупают всё подряд. Мы работаем напрямую с OEM, дистрибьюторами и людьми, собирающими эти машины: Supermicro, Dell и другими.
Jake [00:16:11]: Upstream идёт куча давления на предложение. Когда мы поднимали последний раунд, между размещением капитала на серверы и сейчас, объём поднятых нами денег меньше, чем сумма наших денег в банке плюс стоимость серверов, — потому что серверы выросли в цене, так как подорожала RAM. Безумно, насколько ценным стало оборудование.
Jake [00:16:50]: Если посмотреть на гиперскейлеров, в этом году они разместили примерно $80 миллиардов капитальных затрат, а в следующем будет больше. Это массовое инфраструктурное строительство. Смотришь и думаешь, что это безумие — они тратят гораздо больше, чем Манхэттенский проект. Но если у каждого человека будут запускаться десятки или сотни агентов параллельно, ты концептуально не представляешь, сколько compute нужно, чтобы этот опыт состоялся, даже если ты глубоко эффективен и шеришь ресурсы. И это даже не считая inference.
Swyx [00:17:22]: Как ты планируешь стройку? График роста настолько вертикальный. Вы обычно на 100% утилизации сразу, как только стойки в работе? Насколько вперёд вы планируете?
Jake [00:17:33]: Мы всё ещё поддерживаем облачное присутствие для bursting. Работаем с AWS, GCP и парой других облаков. Можем арендовать, и как только получаем место или электричество — компактифицируем эти нагрузки прочь из облака. Мы начинали с облаков, потом построили систему миграции на собственное железо. Ничто не мешает делать это снова и снова — именно это мы и делаем. Мы никогда не хотим быть compute constrained.
Jake [00:18:09]: В начале года мы как раз стали compute constrained, потому что один upstream-провайдер не мог дать нам квоту на нужной скорости, а железо было медленнее. Я провёл выходные, перестраивая весь наш сетевой overlay, чтобы мы могли работать через пять облаков: Oracle, AWS, мы сами, GCP и ещё одно. Сейчас можем больше.
Jake [00:18:38]: Мы оказались в ситуации, когда пытались плотно упаковывать инстансы, потому что не могли получить достаточно compute. Это привело к нескольким проблемам с надёжностью, которые сейчас уже позади. Я написал твит о том, что становится всё сложнее приобретать compute с той скоростью, с которой эти модели требуют compute. Нас на этом и поймало.
Swyx [00:19:15]: Как вы думаете о ценообразовании, зная, что собственное железо может быть доступно не всегда? Вы заводите дополнительную маржу на случай, если придётся уходить в облако?
Jake [00:19:26]: Поскольку мы построили собственные металлические дата-центры, наши маржи на железе около 70%. Мы можем глубоко субсидировать облачный бизнес, если хотим масштабироваться разумными темпами. У нас несколько рычагов: железо, дающее маржи; cloud burst; долг на покупку серверов; и венчурный капитал. Это интересная операционная задача: сколько у нас наличных, сколько надо поднять, как быстро мы можем это разместить и можем ли мы масштабировать выручку так же быстро, как масштабируем compute?
Jake [00:20:05]: Если мы продолжаем делать тривиально простым для людей строить и деплоить, то чем быстрее мы замыкаем этот цикл и чем операционно эффективнее работаем с капиталом, тем быстрее может масштабироваться бизнес. Это почти прямая линейная скорость размещения.
Финансирование инфраструктуры: долг под железо, VC и операционный леверидж
Swyx [00:20:20]: Думаю, привлечение долга инфра-стартапами — инструмент, которым люди не пользуются и о котором мало знают. Что ты можешь рассказать? Долг обеспечен вашими CPU?
Jake [00:20:32]: Он обеспечен нашим железом.
Swyx [00:20:37]: Какие ставки? Кто кредиторы?
Jake [00:20:39]: Мы платим prime плюс спред, и можем рефинансировать любую часть долга по мере снижения ставок. Условия довольно хорошие. К сожалению, у Twitter нет полутонов, поэтому люди говорят: «Venture debt — плохо». Но как и со всем, есть конкретные инструменты и области, где можно действовать осмысленно, а не использовать один инструмент как молоток. Венчурный капитал — не молоток для всего. Надо исследовать и понимать, что работает.
Swyx [00:21:12]: VC обычно самое дорогое финансирование, какое можно получить.
Jake [00:21:15]: Да. Ещё я думаю, что люди неправильно думают о VC с точки зрения привлечения капитала. Большинство думают: «Как поднять как можно больше денег у того, кто, вероятно, лучший из доступных в этот момент?» Это близко к правде, но мы пытались выяснить, какое нечестное преимущество мы можем купить за это equity.
Jake [00:21:34]: Это самое дорогое equity, которое ты отдаёшь в этот момент, в предположении, что компания продолжит расти. Как использовать это, чтобы работать с кем-то выдающимся, кто дополняет тебя? На seed-стадии я никогда не основывал компанию. У Ray Tonsing были хорошие советы, и я мог писать ему в любой момент. Он был очень быстрым. Круто.
Jake [00:22:01]: Потом с John и Erica в Unusual они сказали: «Ты примерно знаешь, что делаешь при построении продукта. Мы по большей части тебя не трогаем и будем доступны для советов». Замечательно. Потом мы дошли до Series A, и бизнес был операционным пожаром, потому что мы не умели масштабировать бизнес. Работа с Erica, плюс Jordan в Redpoint, так что бонус.
Jake [00:22:28]: Сейчас мы подняли деньги от TQ и FPV, по мере того как двигаемся в enterprise. На каждом этапе мы спрашивали: с кем мы можем партнёриться в этот конкретный момент, чтобы открыть следующий участок пути? Я не знаю enterprise sales. Как инженер я могу прикинуть, какие фичи могут понадобиться, и у нас внутри есть прекрасные люди, которые могут помочь. Но хочется boardroom-динамики, где все согласованы и спрашивают: «Как нам победить?», а не препираются о стратегии.
Дата-центры в космосе и физика compute
Swyx [00:23:31]: У тебя был твит про дата-центры в космосе. Почему не дата-центры в космосе?
Jake [00:23:37]: Это не «нет дата-центрам в космосе». Моё горячее мнение — что это решаемо. Я просто никогда не видел, чтобы кто-то это решил.
Swyx [00:23:49]: Ты сказал: «Как вы собираетесь рассеивать столько тепла в вакууме?» Это физическое утверждение.
Jake [00:23:55]: Я не видел, чтобы кто-то доказал, как собирается рассеивать столько тепла в вакууме. Это не значит, что невозможно. Это значит, что никто пока этого не предъявил.
Swyx [00:24:05]: Astrophage.
Jake [00:24:06]: Не знаю, что это.
Swyx [00:24:07]: Из «Марсианина». Ладно, ты очень логичный.
Jake [00:24:09]: Может сработать. Многие ставят телегу впереди лошади. Говорят: «Поставим дата-центры в космос». Ок, но как? «Будет время разобраться». Это как в «Марсианине», где спрашивают, как они перехватят что-то, и говорят: «Разберёмся».
Swyx [00:24:36]: Ставка на человеческую изобретательность — странная штука, потому что ты слепо веришь, что это решаемо. Но с физикой есть first-principles границы, которые можно поставить. А может и нет. Может, ты просишь путешествовать во времени или нарушить фундаментальный закон термодинамики.
Jake [00:24:57]: Не понимаю, как VC это делают. Как ты понимаешь, что невозможно и грифт, а что возможно, но звучит абсолютно безумно? «Мы поставим дата-центры в космос». Подбрасывание монетки, что из этого правда, и через 10 лет узнаешь. Это один цикл.
Что нужно агентам: версионирование, наблюдаемость и масштаб 1000x
Swyx [00:25:23]: Возвращаясь к агентам. Ветвление, быстрый спин-ап и оркестрация, которые вы делаете, выглядят как preparatory work, оказавшаяся ровно тем, что хотят агенты. Чего агенты хотят иначе, чем люди?
Jake [00:25:37]: Они хотят возможность версионировать вещи. Это не сильно отличается; материализуется чуть иначе. Агенты хотят способ инкрементально тестировать изменения. У инженеров есть feature flags. Есть ли причина, почему агенты не могут использовать feature flags? Не думаю.
Jake [00:25:54]: Им нужен контроль версий. Можно использовать Git или не Git? Это под вопросом. Думаю, что-то вне Git появится для того, как мы версионируем эти вещи со временем. Им нужна наблюдаемость. Нужно опрашивать, что произошло, когда, какие шаги упали, трейсы, логи, метрики и прочее. Им нужны сеть, compute и хранилище. Им нужно писать файлы, сохранять файлы, итерировать по файлам, делать снапшоты файловых систем.
Jake [00:26:25]: Многое из того, что нужно людям, совпадает с тем, что нужно агентам. Ветвление и форкинг не отличаются; просто мы движемся в 1000 раз быстрее. Может казаться, что нужно что-то массово другое, но нужно что-то массово лучше существующего. Нужна оркестрация массово лучше Kubernetes. Нужна сеть, вероятно, лучше Envoy. И так весь стек насквозь.
Jake [00:26:55]: Если профиль нагрузки не столько меняется, сколько массово сжимается, потому что нужны тысячи таких штук — какие предположения меняются? etcd расплавится. Надо заменить чем-то другим. Можно пройтись по всему стеку и сказать: «Эта часть должна измениться, эта часть должна измениться, и эта часть должна измениться».
Jake [00:27:19]: Интересная штука в супер-экспоненциальной кривой: нужно строить системы, где можно выдрать эти части в любой момент, потому что может появиться новое бутылочное горлышко. Ты хорошо разобрался с параллельными агентами — ломается другая часть системы. Так что похоже на то, что нужно людям, но в масштабе 1000x.
Jake [00:27:55]: Как делать code review в эпоху агентов?
Swyx [00:28:00]: Бросать больше агентов.
Jake [00:28:01]: Не сделаешь. А кто тогда ревьюит CVE и прочее?
Swyx [00:28:07]: Больше агентов.
Jake [00:28:08]: И вот так упираемся в стену inference. Можно непрерывно бросать агентов на проблему, но, думаю, есть предел количеству агентов, которых можно бросить на проблему.
CLI, ручки для агентов и замыкание цикла
Swyx [00:28:24]: У тебя уже был CLI, ещё до того, как это стало модно. Как меняется форма того, что вы экспонируете, если вообще меняется?
Jake [00:28:28]: CLI всегда были классными. CLI меняется, потому что мы думаем о том, как дать Claude, Codex, ChatGPT или любой модели опору.
Jake [00:28:50]: CLI — это одна команда: deploy, get logs и так далее. Вещи, которые были запретительно раздражающими для людей, для агентов не раздражающие. Они приятные. Если я тебе вручу CLI с 40 аргументами и 600 флагами, ты подумаешь: «Я никогда всё это не использую». Но если вручишь агенту, он скажет: «Это превосходно. У меня столько ручек для работы».
Jake [00:29:24]: Если ты собираешься экспонировать вещи агентам таким образом, хочется как можно больше ручек, где они могут получить информацию, опросить динамическую информацию и быстро замкнуть цикл. Большинство проблем сейчас в том, как замкнуть цикл максимально быстро. Где агент застревает и как это убрать?
Jake [00:29:49]: Телеметрия важна. Если ты можешь по CLI понять, где агент застревает, и сказать: «12% людей отклоняются от happy path из-за этого, теперь добавлю этот аргумент и снизю до 2%», — ты массово увеличиваешь скорость замыкания цикла.
Jake [00:30:03]: Так мы думаем не только о CLI, но и о каждой точке в дашборде. Это пользовательский путь: я слышу о Railway. Я что-то деплою. Я получаю свой первый зелёный билд или ага-момент. Я вижу эндпоинт, логи, что угодно. Потом итерирую. Цикл итерации бесконечен. Пользователь хочет задеплоить новую штуку, инстанс Postgres, изменить код, продолжать итерировать.
Jake [00:30:36]: Если фокусируешься на итерационных циклах и на том, что блокирует их быстрое замыкание, — одна вещь, которую мы говорим внутри: ты больше никогда не хочешь ждать compute. Ты всегда хочешь ждать интеллект. Если ждёшь compute, есть бутылочное горлышко, которое надо уничтожить, потому что в конце концов оно становится таким большим, что появляется другой workflow, чтобы его поменять.
Jake [00:31:04]: Мы построили продукт, где ты пушишь код, билдишь его и так далее. Но я фундаментально верю, что push-pull-цикл уходит. Мы дойдём до точки, где ты делаешь маленькое изменение в продакшне, это изменение версионируется в твоей инфраструктуре, ты работаешь рядом с copy-on-write версиями своей базы и инфраструктуры, потом мержишь — и оно мгновенно живое. Это святой Грааль циклов. Push-pull-rebuild — это точка трения, которую мы убираем полностью.
Canvas как вывод: дашборды, якоря контекста и гиперструктуры
Swyx [00:31:43]: Это невероятно быстро. Если кто-то не пробовал — этот быстрый фидбэк прекрасен. Моё горячее мнение: Railway была знаменита своим canvas, который визуализирует инфраструктуру и позволяет манипулировать ей визуально. Но это было для людей. Для следующей фазы роста Railway CLI важнее canvas.
Jake [00:32:05]: Canvas забавный, потому что это механизм показа изменений во времени. Ты прав, что раньше мы много использовали его как input. В будущем его задача больше как output. Ты идёшь в canvas, делаешь изменения, видишь их и наблюдаешь, как эволюционирует твоя инфраструктура. Теперь у агентов есть доступ к CLI и они могут делать эти изменения. Так что canvas становится output’ом: какая информация нужна человеку в этот момент, чтобы принять подходящее решение о запросах контроля? Одобряю это или нет?
Jake [00:32:57]: Он также должен быть якорем для твоего контекста, портом в шторме. Думай о нём как о слоях в файловой системе. Ты начинаешь с проекта, потом дрейфуешь в сервисы, потом в функцию или код, потому что хочешь представить всю штуку не только в голове, но и в canvas. Другие люди могут разделить это представление, думать на одной волне и быстро двигаться.
Jake [00:33:33]: Многие организации попадают в беду при масштабировании, потому что весь контекст живёт в чьей-то голове. «Как работает этот микросервис?» «Понятия не имею, спроси этого человека». Потом появляются целые категории продуктов вокруг обнаружения контекста. Многое из этого тает, если у тебя есть надёжная иерархия и ты можешь бесконечно вкладывать сервисы, код, контекст и всё остальное насквозь. Это и позволяет строить эти структуры со временем.
Jake [00:34:18]: Это также то, что позволяет нам строить то, что я называл гиперструктурами: вещи, которые гораздо больше. Смотришь на мост Golden Gate и спрашиваешь: «Как мы его построили?» Есть мем, что мы потеряли технологии. В какой-то степени да, потому что координация, построившая эти штуки, эволюционировала и изменилась. Мы потеряли часть искусства построения структуры, когда впихнули всё в Slack.
Swyx [00:34:52]: Но ты впихиваешь всё в Discord.
Jake [00:34:53]: Та же история. Не важно. Это передача сообщений и прерывания, передача сообщений и прерывания.
Swyx [00:35:00]: Так ты говоришь, что должно быть что-то лучше и структурированнее Slack?
Jake [00:35:04]: Да. Точно. Думаю, Slack ужасен, и Discord тоже ужасен.
Central Station: маршрутизация контекста, поддержка и кластеры инцидентов
Swyx [00:35:09]: Это эквивалент моего теста для мамы. Что вы сделали в качестве своего решения?
Jake [00:35:15]: Внутри мы построили инструмент Central Station, который агрегирует весь контекст от наших пользователей. Каждая часть фидбэка, каждое обращение в саппорт — всё агрегируется в кластеры. Если назревает инцидент, мы можем определить, сколько пользователей затронуто, и отколоть обсуждение на этой основе.
Jake [00:35:40]: Это полезнее, чем долгоживущие каналы, где ты пытаешься решить, в какой канал положить что-то. Если можешь динамически агрегировать информацию и динамически маршрутизировать её к правильному человеку по контексту — работает лучше. Мы знаем внутри, что эти четверо людей близки к сети. Если видим что-то про сеть, можем сразу направить к ним. Если это другая часть, можем посмотреть коммиты. Это больше не ручной процесс внутри.
Jake [00:36:13]: Если зайдёшь на station или help.railway.com — вот зачем мы это построили. Мы хотели масштабироваться с массовым плечом за счёт агрегации фидбэка.
Swyx [00:36:27]: Это построено самостоятельно?
Jake [00:36:28]: Ага.
Swyx [00:36:29]: Помню, помогал тут с Angelo в 2023. Вы много масштабируетесь очень маленькой командой.
Jake [00:36:38]: Да. Сейчас мы в 10 раз больше.
Swyx [00:36:40]: У тебя тут полный код разработчика? Очень круто.
Jake [00:36:44]: Если зайдёшь на railway.com/stats, мы экспонируем это как pub-sub-штуку. Это все realtime-метрики. Где-то есть способ получить это как JSON, если интересно.
Jake [00:37:01]: Мы большие фанаты того, чтобы строить всё публично и говорить о том, над чем работаем. У нас были проблемы в прошлом, и мы говорили: «Вот как мы их исправляем». Получали комплименты и критику за incident-репорты. Мы всегда стараемся делать их лучше и общаться с людьми.
Инциденты, раскрытие и постепенные роллауты
Swyx [00:37:20]: У вас недавно был большой инцидент. Мне понравилось, что он был ограничен 3000 пользователями. Видимо, вы использовали Central Station. Расскажи, что случилось и как вы это решаете внутри команды.
Jake [00:37:38]: Внутри этот реально отстойный. Он был связан с upstream-провайдером, который не делал того, что заявлено в его документации, что прискорбно — учитывая, что они и написали RFC о том, как поведение должно работать. Мы выкатили эти штуки, и Central Station поймал это сначала, когда пара пользователей сказала, что кеши не инвалидируются. Мы это сразу выключили.
Jake [00:38:03]: Когда раскатываешь на большую базу из трёх миллионов человек, получаешь много разнообразного поведения. Мы тестировали в staging, у нас были тесты, но мы попали в edge case. Мы укрепили эти системы, и теперь можем сделать лучше. Но это был тяжёлый случай.
Swyx [00:38:39]: Мне всегда интересно, как должно работать приватное раскрытие, если люди находят проблему. Им нужно сначала связаться с вами? Когда управляешь платформой, такие вещи случаются. По каким каналам люди должны идти, чтобы тихо разрулить, прежде чем это станет большим инцидентом?
Jake [00:38:59]: Есть ответственное раскрытие. Мы склоняемся к избыточному раскрытию и оповещению о проблеме, нежели к тому, чтобы провайдер заставил тебя сомневаться в реальности. Мы склонились к публичному обсуждению этих штук, даже если они затрагивают небольшую часть пользователей. Это внутреннее решение. У нас четыре ценности. Одна из них — честь. Честный поступок — оповещать людей в максимально широком кругу затронутых или потенциально затронутых проблемой, а потом встречать её лицом к лицу: почему это произошло, что мы можем сделать лучше?
Swyx [00:39:45]: Не всю базу пользователей. Это из-за инкрементальных роллаутов и прочего?
Jake [00:39:50]: Да. Постепенные роллауты.
Swyx [00:39:54]: Это должно быть нормой на всех крупных платформах.
Jake [00:39:58]: Должно. Многие компании так и делают. Есть цитата, что Meta запускает 10 000 разных версий Meta. К нашему более раннему пункту об агентах — им нужно то же самое. Им нужен shadow traffic и все остальное. Мы выстроили столько церемонии вокруг священного продакшна, что нам надо сделать тривиально простым тестировать разные поведения в безопасном окружении. Тогда можно делать ошибки в безопасном окружении.
Безопасный AI SRE: клиентские агенты, форкнутые окружения и паритет с продакшном
Alessio [00:40:30]: Видишь ли ты мир, где эти штуки автоматически отлавливаются — не обязательно твоим агентом, а агентом твоего клиента? Проблема с инвалидацией кеша кажется простой для проверки, если знаешь, что искать.
Jake [00:40:44]: Сложно, потому что чтобы определить, нам почти нужно подключиться к вашей observability-инфраструктуре. Вот почему у нас есть template-цикл на платформе — чтобы можно было постепенно раскатывать. Можно сначала раскатить на Johnny Vibe Coder или запушить шард, который кто-то потребляет в удобном для него темпе. Или раскатить за недели: 0.1% людей, 1% людей, early adopters, потом вплоть до конца. Это и есть тот недетерминированный version control, о котором мы говорили ранее.
Jake [00:41:30]: Я считаю, что туда и должны идти большинство вещей, потому что большинство компаний в итоге строят системы поэтапной раскатки своими силами. Это одна и та же штука, перестроенная снова и снова в каждой компании. Огромная возможность консолидировать долг разработчиков.
Alessio [00:41:45]: У вас должен быть free tier. Провайдеры моделей дают бесплатные токены, если разрешишь им использовать данные. Можно давать бесплатный compute, если кто-то — шард номер один, который выкатывается и позволяет вам подключиться к их observability.
Jake [00:41:55]: Мы так делаем. Поэтому говорили о влиянии на 3000 человек. Мы начинаем с людей с меньшим импактом. Более крупные компании на платформе получают эти раскатки последними, чтобы у них была глубоко стабильная версия платформы.
Alessio [00:42:16]: У меня три сервиса, так что я уверен, что получаю первую раскатку. Можете в любой момент снести мою штуку. Есть все эти SRE-агентские компании. Observability-люди тоже хотят агентов, которые чинят upstream-проблемы. У вас сейчас свой агент в canvas. Как ты видишь это развитие?
Jake [00:42:39]: Это проблема накопления энтропии. Если у тебя нет примитивов для безопасной итерации в продакшне, это становится сложно. Если ты observability-провайдер и говоришь: «Вот фикс этой ошибки», — допустим, 80% хороши и имеют смысл. Но в оставшихся 20% длинного хвоста сложных проблем, если позволишь кому-то это применять, ты создаёшь возможность для инцидента.
Jake [00:43:08]: Поэтому форкнутые окружения важны. У людей есть staging, но он всегда дрейфует от продакшна. Нужны примитивы, workflow и опыт, построенные первой стороной на платформе, чтобы можно было форкнуть любой сервис в любой момент.
Jake [00:43:33]: Я думаю о canvas как о листе прозрачной бумаги. Агент — это маленький парень, которого ты заталкиваешь наверх в canvas. Он должен сказать: «Мне надо скопировать этот сервис и этот сервис, чтобы протестировать эти две вещи». Он получает read-only копию продакшна. Всё, что является PII, помечается как трансформация при клонировании базы — создаём copy-on-write версию или читаем из неё. Потом агент делает изменения и спрашивает: «Это реально работает?» — как можно ближе к продакшну.
Jake [00:44:22]: Вот насколько близко надо быть, иначе будет массовый дрейф. Система становится нестабильной. Это видно в массивных системах, построенных на Docker для локалки, Kubernetes для продакшна и какой-то отдельной штуке для чего-то ещё. Эта сложность замедляет разработчиков и становится нестабильной на масштабе, делая итерацию сложной. Мы хотим сильно это сжать и сказать: «Максимально близко к проду — это туда, куда мы хотим».
От скептика AISRE к верующему в агентов
Swyx [00:45:00]: Я списывался с Erica насчёт вопросов, и она говорит, что изначально ты не был верующим в AISRE. Передумал?
Jake [00:45:10]: Я перевернулся, но всё ещё не верующий в AISRE, если нет примитивов, чтобы сделать его безопасным. Если выпустишь AISRE на продакшн-инфраструктуру без безопасных примитивов для копирования томов и проверки, что всё ок, он снесёт твою продакшн-базу. Это не вопрос если, а когда. Я большой верующий в то, чтобы делать эти циклы безопасными.
Jake [00:45:33]: Я был глубоким AI-скептиком до 2023. В 2024 я подумал: «Может, я смогу примерно заставить эту штуку это сделать». В 2025 — «теперь я могу её удержать». Зимой все вернулись говоря: «Удержать практически невозможно».
Swyx [00:46:01]: Видел ли ты это на Claude docs? CloudBot? OpenCloud?
Jake [00:46:06]: Дошло до момента, когда сложнее держать неправильно, чем правильно. Есть сцена в «Мстителях», где Vision поднимает молот Тора и говорит, что он отлично сбалансирован. Самобалансируется и работает хорошо. Я в этой точке глубокий верующий, что это будет доминирующий вид: ассемблер, C, C++, JavaScript, слова.
Swyx [00:46:35]: Это кажется большим скачком.
Jake [00:46:37]: Так и есть. Но это не значит, что отказываешься от CPU-based дискретной логики и сразу переходишь к нечёткой логике. Нужно и то, и другое. Твои навыки должны вызывать код, приложения или какую-то статическую структуру. Можно использовать навыки, чтобы дистиллировать, какой должна быть процедура или как должен вести себя код.
Jake [00:47:02]: Я прихожу к тезису: нужны три точки. Нужна чёткая спецификация, описывающая систему, код и тесты. Когда говоришь это вслух — если ты достаточно долго в инжиниринге — думаешь: «Конечно. Это RFC, тесты и код». Но они все важны. Когда они вместе, они подкрепляют друг друга: спека и тесты совпадают, но код нет — примиряй. Или тесты и код совпадают, но спека нет — примиряй это. Это и есть цикл итерации.
Jake [00:47:41]: Поэтому видишь, как люди говорят о software factories, документации и согласовании. Часть этого — архитектурная астрономия, если не реализуешь, но этот цикл — туда, куда придёт большинство вещей.
Swyx [00:48:07]: Для слушателей: мы говорим об этом в подкасте три года — святая троица спецификаций и тестов. Itamar Friedman из Qodo — референс, если хотите посмотреть.
Самомодифицирующаяся инфраструктура и конец push-pull-rebuild
Swyx [00:48:18]: Хочу упомянуть про идею OpenCloud — самомодификацию. Не знаю, как Railway будет это поддерживать, но у меня есть мой OpenClaw, и я просто говорю ему, что у него есть Railway CLI, и он может делать что угодно. В теории, какие бы возможности или новая инфра ему ни понадобились, он может вызвать Railway CLI, поднять и добавить к себе. Агент может модифицировать собственную инфру.
Jake [00:48:45]: Это безумно. У меня настроен цикл, где ты ставишь Railway CLI поверх чего-то, работающего на Railway. Ты аутентифицирован как текущий box и можешь вносить в него любые изменения. Потом вызываешь railway deploy, и он деплоит сам себя.
Jake [00:49:04]: Это как: «Мне надо поднять этот инстанс этого окружения. Я уже существую в этом окружении. Прекрасно, у меня теперь есть доступ к инстансу Postgres». Туда мы и хотим идти с агентской самореплицирующейся инфраструктурой. Это и есть твой цикл: итерируй в продакшне. Продолжаешь делать изменения. Если работает, мержь upstream. Если нет — выбрасывай.
Jake [00:49:37]: Как сделать тривиальным и супердешёвым создание одноразовых копий? Эра «у меня AWS-инстанс с 4 vCPU и 16 гигами RAM» будет уничтожена. Если ты так делаешь для агентов, тебе нужна тысяча таких машин. Это запретительно дорого по сравнению с тем, над чем мы потратили кучу времени: атомарной единицей деплоя, называй её isolates, sandboxes или как-то ещё. Платишь только за то, что используешь, поднимаешь мгновенно и замыкаешь цикл максимально быстро.
Jake [00:50:15]: Если система может безопасно реплицироваться и сказать: «Это моё окружение, я делаю эти изменения», она может вернуться с «Норм выглядит? Это новое состояние инфраструктуры с учётом этого промпта. Думаю, я её решил». Потом ты говоришь: «На самом деле выглядит иначе». Цикл снова. Потом ты говоришь: «Круто. Применяй».
Swyx [00:50:38]: Это ретроспективно очевидно, что является самым полезным видом очевидности. Ещё комментарии про деплой агентов на Railway?
Jake [00:50:51]: С каждым днём становится лучше. Я в X или Twitter. Можете всегда орать на меня про те части, которые работают не так хорошо, как должны, — много чего должно работать намного лучше.
Новый serverless: stateful, долгоиграющий, pay-for-what-you-use Linux
Swyx [00:51:04]: На этом этапе, когда людям нужен массивный или embarrassingly parallel compute, они обычно говорят про serverless. Чувствую, есть новый serverless по сравнению с предыдущими пятью годами serverless. Вы в этом новом ведре. Есть ли сравнения или философские отличия, которые ты хочешь обозначить?
Jake [00:51:31]: Это где-то посередине. Возможность запускать stateful, долгоживущие workflow или executions.
Swyx [00:51:42]: У Vercel есть Fluid Compute, у Cloudflare какая-то контейнерная штука, у Google App Runner и другие.
Jake [00:51:55]: Туда примерно всё и идёт, и поэтому мы работаем над этим шесть лет. Мы считаем, что пользователям нужен доступ к компьютеру: коробке, говорящей на Linux. Им нужно деплоить, что они хотят. Другие системы меняют поверхность того, что можно построить. Для нас пользователям нужен компьютер и возможность задеплоить что угодно. Поэтому мы фокусируемся на примитивах: сеть, compute, хранилище. Если мы дадим эти и экспонируем так, чтобы ты мог запускать вещи бесконечно, — туда, мы считаем, всё и движется.
Jake [00:52:43]: У Twitter нет полутонов, поэтому все говорят «серверы» или «serverless». Это всегда где-то посередине: я хочу запускать долго, но не хочу резервировать ресурс статически или платить за то, что не использую. Это был наш тезис с первого дня: платить только за то, что используешь, запускать бесконечно, и это полноценный Linux.
Swyx [00:53:12]: Поэтому мне нравится название Fluid. Текучий. Гибкий.
Heroku, фокус и нести факел, не становясь прошлым
Swyx [00:53:18]: Ещё одна веха — официальный deprecation Heroku. Вы один из предполагаемых новых Heroku. «Новый Heroku» — это категория, сколько я в developer tooling. Это наконец произошло. Каково это было? Какие-то закулисные «вот этот момент»?
Jake [00:53:42]: Есть люди, про которых думаешь: «Ты что, запускаешь это здесь? Ты, как компания?» Безумие, что названия, которые ты бы знал, запускаются на этом, и теперь приходят к нам со словами: «Мы хотим много чего отсюда перевезти».
Swyx [00:54:00]: Какие-то закулисные мысли о том, почему Salesforce дала Heroku загнить?
Jake [00:54:05]: Могу только гадать. Сложно, когда это не твой бизнес. Бизнес Salesforce — построить отличный CRM. Это их фокус. А потом ты приобретаешь compute-бизнес как ответвление. Многие ранние сотрудники Meta говорят о фокусе. У Boz есть пост про то, как в ранние дни Meta у них не было денег, поэтому им приходилось фокусироваться. Потом включили денежное дерево, и не стало причины не дробить фокус.
Jake [00:54:52]: Но это разбавляет продукт. Появляются ответвления, про которые спрашиваешь: «Это фокус бизнеса?» Если не основной — затухает. Многие компании попадают в беду, когда раздваивают фокус, потому что ведут многофронтовую войну, не только внешне, но и внутренне за выравнивание. Куда мы идём? Что мы делаем? Какова наша цель?
Jake [00:55:24]: Если ты Salesforce-built и mission-driven, ты хочешь работать над Salesforce. Heroku — сбоку. Не основной бизнес. Получить ресурсы, бюджет, фокус и внутреннее выравнивание становится сложно. Это был вопрос времени.
Swyx [00:56:06]: Респект за то, что заявили, а не оставили неизвестным.
Jake [00:56:12]: Их анонс был странноват. Они заявили, но не сказали, что закрывают. Закулисно, кажется, они выпустили сообщения людям, что те должны закрывать аккаунты и что они будут постепенно депрекейтить и убирать вещи.
Jake [00:56:30]: Безумно, потому что мой первый опыт деплоя был на Heroku. Начинаешь с перетаскивания вещей в FTP-сервер, потом пытаешься завести деплой, и вот Heroku. Это был наш on-ramp. Но колесо крутится. Появляются новые штуки. Мы рады нести факел во многом из этого. Но мы не хотим быть новым Heroku. Мы хотим быть способом, которым люди строят и деплоят софт, и в конечном счёте — способом, которым люди монетизируют софт со временем.
Swyx [00:57:19]: Это всё ещё большая корона — быть новым Heroku. 50 компаний боролись за неё.
Jake [00:57:23]: Каждый держит какую-то часть. Мы рады поддерживать людей и компании. Платформа работает иначе. Игровой цикл похож, но мы догматичны в том, куда эти штуки идут: примитивы, агенты, fan-out. Что-то подходит, какие-то workflow должны меняться. У нас есть аппроксимация Heroku pipelines с environment-системой. Это волнующе. У нас уйма людей, которых мы можем поддержать, и это сильно растёт.
Temporal, workflow-движки и конечные автоматы
Swyx [00:58:12]: У меня ещё один технический вопрос про Temporal. Я продал свои акции. Ты power user и один из наших самых ранних клиентов. Я познакомился с тобой через Temporal. Ты строил на Temporal. У тебя есть жалобы. Это может быть самый нейтральный и информированный разговор о Temporal, который кто-либо услышит без участия сотрудника компании.
Jake [00:58:39]: Справедливо. Я использую Temporal почти 10 лет — через Cadence в Uber.
Swyx [00:58:52]: Дай людям представление, чем был Cadence в Uber.
Jake [00:58:57]: Cadence был предшественником Temporal. Он питал trip actions, поездки — когда ты арендуешь Jump-байк, самокат или машину. Ты запускаешь workflow на какой-то период и говоришь: «Эта поездка будет идти, пока не закончится». Прикрепляешь информацию: ты остановился в этой зоне — добавь это начисление в счёт. Когда заканчиваешь поездку, workflow завершён. Этот опыт тогда питался Cadence.
Swyx [00:59:34]: Я раньше говорил, что это как программировать весь user journey сверху вниз одной функцией.
Jake [00:59:39]: Это мощная идея и важная. Она также важна для следующей фазы агентского пути. Хочется, чтобы агент сделал конкретную задачу, был complete или incomplete по этой задаче и перешёл к следующему. Нужен способ динамически управлять workflow.
Jake [00:59:59]: Temporal всегда был хорош в теории и хорош, когда заставлял его работать так, как тебе надо, в продакшне. Но он требовал держать весь путь в голове. Если не держал, можно было создать проблемы, где реплей состояния workflow вызывает недетерминизм.
Swyx [01:00:25]: Потому что он работает на детерминированной истории workflow.
Jake [01:00:28]: Точно. Я описываю это как реактивный двигатель. Если ты знаешь, как его эксплуатировать и запускать, — отлично. Но нельзя выдавать его людям, пытающимся строить сложные вещи, если у них нет всего состояния в голове.
Jake [01:00:48]: Мы крутим весь наш deployment pipeline поверх него. Это разумно сложный workflow: pre-commit-хуки, signaling, queueing и прочее. Мы наткнулись на то же самое в Uber. По мере того, как выражаешь большой workflow, он усложняется, в state machine больше состояний, которые надо отображать обратно в workflow.
Swyx [01:01:15]: Это куча if’ов.
Jake [01:01:16]: Точно. В Uber мы построили систему для работы со state machine и её тестирования. Мы начали строить такие штуки тут, потому что это сильно выросло. Это не совсем love-hate. Когда работает хорошо, работает супер хорошо. Но если кто-то без полного контекста добавляет что-то в систему, что инвалидирует состояние или вызывает недетерминизм, или порождает кучу activities, приходится следить за подкапотными SRE-ручками вроде слотов activity. Они должны масштабироваться с памятью, vCPU и так далее. Становится тяжело масштабировать.
Swyx [01:02:10]: Нужен способный сисадмин, ведущий дела за кулисами. Если бы ты съехал — что бы сделал?
Jake [01:02:19]: Построили бы свой workflow-движок. У нас есть несколько внутри, над которыми мы работали.
Swyx [01:02:27]: Это один из тех классов вещей, которые обычно не стал бы вайб-кодить, но интересно, можно ли.
Jake [01:02:33]: Я всё ещё не думаю, что это надо вайб-кодить. Всё равно нужны нормальные тесты, чтобы убедиться, что работает.
Swyx [01:02:39]: Timo тоже не изобретал это с нуля. Есть библиотеки, которые можно запустить. На самом деле это state machine, которую надо размапить. В конечном счёте, ты определяешь инструкции и пропускаешь их через state machine.
Jake [01:03:00]: Очень делаемо. Workflow-штуки интересные. Restate делает классные вещи здесь.
Swyx [01:03:10]: Ты завязан на JavaScript. Ты JavaScript-макси?
Jake [01:03:13]: Внутри у нас TypeScript, Rust и Go. Языки не добавляем. На самом деле у нас немного C, потому что мы пишем BPF-код и хуки. Но это языки.
Swyx [01:03:28]: Это для sidecar’ов?
Jake [01:03:32]: Нет. Это для сетевого стека, томов и подобного. Мы много используем TypeScript, потому что он питает дашборд, но переносим много workflow-вещей из dashboard-стека в инфраструктурный.
Railpack, Nixpacks и content-addressable файловые системы
Swyx [01:04:00]: Круто. Ещё какие-то технические инфраструктурные штуки? Railpacks?
Jake [01:04:07]: Мы построили движок для определения зависимостей по исходному коду. Называется Railpack. Сначала построили первую версию, Nixpacks, поверх Nix, потом перешли.
Swyx [01:04:17]: Меня уже четыре года уговаривают адоптить Nix и NixOS. Это вообще когда-нибудь произойдёт?
Jake [01:04:23]: Не знаю. Мы рады за это, но у этого есть болевые точки. Думай о нём как о стопке версионированных бинарей в конкретных временных срезах. Если хочешь версию X и версию Y, ты раздуваешь пакетное пространство, что взрывает размер образа и делает реальные нагрузки сложными.
Swyx [01:04:53]: Но ты content-address это и кешируешь. В теории есть оптимизации.
Jake [01:05:00]: В теории — да. Но при достаточно большой пользовательской базе и достаточно разных машинах ты сталкиваешься с проблемой, которую Meta описала в статье XFAAS — их внутренней serverless-системе. Это становится сложно на масштабе, если не выделять конкретные runtime.
Jake [01:05:24]: Мы не хотели так делать, потому что хотели реально позволять деплоить что угодно. Это была наша первоначальная задумка с Nix. Но мы пошли в сторону интересной работы вокруг content-addressable файловых систем, которые могут lazy-load что угодно из любой точки и подгружать в память.
Swyx [01:05:48]: Шикарно.
Jake [01:05:49]: Будущее очень светлое. Это безумие, и будет ещё безумнее.
Расходы coding-агентов, дорожные карты и ROI токенов
Swyx [01:05:54]: Founder-journey штуки?
Alessio [01:05:56]: Твоё облачное использование: ты твитнул, что собираешься потратить $300K в этот месяц?
Jake [01:06:01]: Думаю, дошли до $200K.
Alessio [01:06:02]: Coding-агенты?
Jake [01:06:03]: Да.
Swyx [01:06:04]: По всей компании?
Alessio [01:06:05]: У вас всего 35 человек, так что уверен, не все тратят $10K в месяц. Какое распределение?
Jake [01:06:10]: Думаю, у меня около $25K. У нас power users по всему спектру. Мы вернулись с зимних каникул, и я в принципе сказал: «Если ты пишешь код руками — ты делаешь это неправильно». Инструменты сейчас достаточно хороши, чтобы двигаться очень быстро. Есть проблемы и болевые точки, но ты должен ревьюить тот код, который пишешь, вместо того чтобы писать его руками.
Jake [01:06:40]: Архитектурные паттерны сейчас важны как никогда, но ты не должен тратить время на генерацию кода, который написал бы сам. Если знаешь, как написать, проси агента написать и согласовывай, пока не будет выглядеть как у тебя.
Jake [01:06:58]: Люди ошибочно связывают мою склонность подталкивать людей к агентам с нашим ростом и какими-то проблемами с надёжностью. Они не обязательно связаны. Инструменты достаточно хороши, чтобы двигаться очень быстро и строить вещи гораздо больше, чем раньше.
Jake [01:07:19]: К более раннему пункту про охлаждение дата-центров в космосе: я не знаю. Но с софтом можно спросить: «Как бы я построил блочное хранилище с нуля? Как бы я делал эти вещи?» У меня есть идеи, потому что у меня есть история и я читал статьи. Дай я их продумаю и построю массивные тестовые стенды с тысячами тестов — теперь они бесплатно пишутся. Если ты не используешь AI-системы, чтобы спринтом проходить roadmap и согласовывать существующую систему с будущим, ты упускаешь большую часть происходящего.
Alessio [01:08:12]: Какой путь к $3 миллионам в месяц? Это ограничено идеями и тем, сколько клиенты могут поглотить?
Jake [01:08:19]: Для большинства компаний это сейчас ограничено деплоем. Поэтому мы видим массовый бум пользователей и компаний — от Fortune 50 и ниже, — которые спрашивают, как заставить разработчиков двигаться быстрее. Ты, наверное, упрёшься в CFO раньше, чем в любой технический предел, потому что они посмотрят на астрономические суммы, потраченные на токены. Стоимость inference должна упасть, но сейчас мы inference constrained. Будет открытие цены вокруг того, что имеет смысл для организации.
Jake [01:09:06]: Думаю, придём к концепции F1-пилота. Если кто-то реально хорош в этих штуках, имеет смысл посадить его в машину за $3 миллиона. Если нет — наверное, не имеет. Возьмёшь нескольких людей и скажешь: «Вы можете водить F1-машину. Нам надо в этом направлении. Выясните, работает ли, и спрототипируйте».
Jake [01:09:33]: Мы это частично сделали и сильно ускорили roadmap. Думали, что-то поставим через несколько лет; теперь, наверное, поставим за несколько месяцев, потому что мы это валидировали и не приходится строить инкрементально. Можем перескакивать шаги и двигаться к видению.
Alessio [01:09:58]: Многие осознают, что roadmap не всегда имеет бизнес-импакт, поэтому говорят, что токены слишком дорогие. Но если бы roadmap была построена так, чтобы зарабатывать больше денег к моменту построения, у тебя были бы токены под её цену, как у тебя с продажами. Ты бы потратил миллиард долларов на продажи, если бы знал, что получишь $2 миллиарда выручки.
Jake [01:10:19]: Именно. Наивный способ измерить это — процент токенов, попавших в продакшн. Если можешь измерить импакт, потому что эти токены попали в продакшн, — круто. Но планка доказательства будет расти. Внутри у нас растущее количество PR, которые не смержились. Вопрос становится: как затащить это в продакшн? Это о том, как быстро ты можешь строить и деплоить софт, что волнующе, потому что это и есть наша основная штука.
Сдвиг SDLC: prompt request, feature flags и безопасные роллауты
Swyx [01:10:56]: SDLC меняется. Один тезис — pull request умирает. Это будет prompt request. Кроме того, code review тоже отчасти умирает, если на месте остальные системы. Что ещё меняется в SDLC?
Jake [01:11:19]: AISRE и инструменты, чтобы это сделать. AISRE — это аспирационная мечта в облаках. Что нужно, чтобы получить AISRE? Какие инструменты надо построить?
Swyx [01:11:32]: В какой-то момент стоит экспонировать свой тулинг клиентам. Командный центр Central Station.
Jake [01:11:39]: У нас есть для майнтейнеров шаблонов. Майнтейнеры шаблонов могут деплоить и поддерживать шаблоны и получают фидбэк. Будем экспонировать эти штуки инкрементально.
Swyx [01:11:51]: Кластеризация вокруг инцидентов. У всех есть какая-то версия этого, но не думаю, что кто-то это решил.
Jake [01:11:56]: Не скажу, что мы решили это внутри, но это стало настолько хорошим, что мы видим инциденты формирующимися довольно быстро. В какой-то момент это будут либо штуки, которые построит кто-то ещё, либо мы. Мы всегда строили вещи, заточенные под нас. Если имеет смысл сделать полезным для пользователей, монетизировать или превратить этот цикл из центра затрат в центр прибыли — мы хотим это делать.
Jake [01:12:28]: Pull request определённо умирает.
Swyx [01:12:29]: Делаете ли вы first-party feature flagging и инкрементальные роллауты?
Jake [01:12:34]: У нас есть движок feature flagging, который мы построили внутри и в итоге выкатим.
Swyx [01:12:38]: Я не вижу его как пользователь. Как так, что вы не дали нам то, что у вас есть?
Jake [01:12:43]: Нам надо его бета-тестировать. Мы сильно заботимся о качестве вещей. Мы много чего использовали внутри, что не доходит до конца, потому что не выдерживает. Работает для одного сервиса, но не для нескольких. Нам пришлось бы строить для нескольких сервисов и знать, что если выпустим — будем перестраивать снова и снова. Что-то стоит того, многое же информирует roadmap.
Jake [01:13:18]: Мы не хотим разбавлять опыт, говоря: «Это работает, но только для этого сервиса», — если только это не основная инициатива. В ближайшие месяцы будем выкатывать вещи, которые работают для одного сервиса, потом нескольких сервисов, потом нескольких сервисов поверх окружения. Надо быть осмысленным. Иначе создаёшь сломанные разрозненные опыты и нагрузку на саппорт, потому что люди спрашивают, как пользоваться фичей.
Jake [01:13:52]: Это тот же паттерн расширения и сжатия. Расширяешь компанию, чтобы получить фичи, потом сжимаешь и сглаживаешь, чтобы опыт был великолепный. Ты сказал мне в коридоре: «Стало намного лучше». Внутри говорим: «Эта часть реально отстой. Нужно сделать значительно лучше».
Swyx [01:14:11]: Могу подтвердить за последние три года, наблюдая, как ты строишь Railway. Для слушателей: feature flagging — большая часть культуры Uber. Настолько, что у них слишком много feature flags и ещё одна штука для удаления feature flags. У Facebook есть Gatekeeper. Агентам это понадобится. Это фундаментально для инкрементальных роллаутов. OpenAI купила Statsig. GPT-5 маршрутизирует и флагует через разные модели.
Jake [01:14:56]: Это супер важно. Если software development lifecycle изменится, потому что мы делаем вещи в 1000 раз быстрее и в 1000 раз параллельнее, что становится важным на масштабе?
Jake [01:15:16]: До того, как я основал Railway, я построил feature-flagging-продукт и пытался его продать. Это была более простая версия LaunchDarkly. Я столкнулся с проблемой: любой достаточно маленький, чтобы адоптить твою технологию, не парится про feature flags, а любому достаточно большому, чтобы feature flags понадобились, нужен такой масштаб, что приходится строить всю инфраструктуру. Я его прикрыл.
Jake [01:15:42]: Но что было старым — новое снова. Компании пытаются двигаться быстро, но нельзя выкатить вайб-коженую штуку прямо в продакшн. Надо сказать: «Вот мой blast radius, мой импакт, и я хочу затенять для этих пользователей». Feature flags. Понадобятся инструменты, которые большие компании строили для поддержания своих структур. Всё сжимается в 1000x, чтобы все могли быстро строить эти структуры.
Jake [01:16:07]: Это ровно туда, куда мы движемся: сжимаем software development lifecycle, потом расширяем и добавляем больше новых штук.
Cattle, pets и клонируемая инфраструктура
Swyx [01:16:15]: Другой термин, который приходит на ум для новых разработчиков, — «cattle, not pets». Люди относятся к продакшну как к питомцу. У него есть имя. Ты его балуешь и поддерживаешь жизнь. С cattle можно массово фармить, выкатывать, разделять и убивать.
Jake [01:16:37]: Думаю, это может измениться. Можно двигаться в сторону pets, если у тебя есть машина для клонирования pets.
Swyx [01:16:52]: Да.
Jake [01:16:52]: Если можешь снапшотить каждую вещь на каждом кадре, не важно, что что-то снесли, потому что у тебя есть снапшот. Те штуки, которые мы построили сейчас, спроектированы для блокировки изменений на герметично запечатанной DevOps-линии. Тебе приходится писать Dockerfile, потому что нужен конкретный срез файловой системы.
Jake [01:17:14]: Что если у тебя есть вся файловая система? Что если ты снапшотишь её и ленниво подгружаешь всю файловую систему? Тогда обходишь эту проблему полностью. Не нужна церемония с Dockerfile, скриптами Ansible или другими вещами. Можешь итерировать, снапшотить, спрашивать, правильный ли это цикл или состояние, и мержить в продакшн. Мержить файловую систему.
Swyx [01:17:45]: А почему нет?
Jake [01:17:46]: Будет весело.
Swyx [01:17:47]: Это совсем другая банка червей, но если ты каталогизируешь stateful-вещи в VM и разработаешь специальные решения для каждой, проблему можно сильно урезать. Удивительно, что люди не пробовали до сих пор.
Jake [01:18:04]: Меня всегда удивляло, потому что это именно те штуки, над которыми мы бы работали. Это очевидно.
Swyx [01:18:11]: От первых принципов — они нужны. Всем они нужны в теории. Но крупные облака этого не делают, и ты предполагаешь, что это невозможно.
Jake [01:18:18]: Точно. Думаешь: «У Meta все эти люди, пишущие eBPF-код, и они с ними что-то делают». Но нужна именно такая работа для решения этих проблем. Что нужно — насколько глубоко нам надо идти — мы пойдём вниз вплоть до TCP/IP-стека ядра, если потребуется. Если надо что-то модифицировать, чтобы заработала ментальная модель вселенной впереди, — мы это сделаем и продолжим вниз.
Swyx [01:18:52]: Звучит весело.
Jake [01:18:53]: Это так весело. Приходится отрывать себя от классных интересных проблем, чтобы убедиться, что мы можем масштабировать компанию работающим способом. Так много весёлых проблем: переносить информацию от клиентов к саппорту к человеку, который построил это внутри, безопасная итерация, контекст от дашборда до пользователей, спуск к инфраструктурному слою, управление оркестрацией как realtime-операционной системой против системы обратной связи. Это просто очень весело.
Уроки соло-основателя: одержимость, письмо и фокус
Swyx [01:19:29]: Кстати о стороне основателя — ты знаменито вне YC/SF-консенсуса. Идёшь в YC, находишь сооснователя, делаешь всё это. Ты не сделал ничего из этого.
Jake [01:19:40]: Ничего.
Swyx [01:19:45]: В лифте ты сказал, что сооснователь имеет смысл, если один — технарь, а другой — биздев. Но тебе самому приходится содержать в себе эти множества. Как ты это делаешь?
Jake [01:19:58]: Я стараюсь спать восемь часов.
Swyx [01:20:11]: Есть ли баланс: 50/50, 30/30/30? Какова ментальная модель соло-основателя?
Jake [01:20:17]: Никакого баланса. Надо думать обо всех этих вещах и быть ими одержимым. Быть одержимым тем, как люди думают о твоём продукте с точки зрения go-to-market, и одержимым kernel-level изменением, которое делает так, что SSH-соединение пользователя никогда не падает. Я хочу вселенную, где можно снапшотить всё, и это ощущается как итерация на VM.
Jake [01:20:47]: Надо быть одержимым на каждом слое стека. Это и упрощает дело для меня. Некоторые люди одержимы разными частями пути компании, и если можешь хорошо разделить эти линии и быть ясным насчёт владения — будешь в порядке.
Jake [01:21:12]: Я говорил, что два — худшее число сооснователей, потому что нет tiebreak. Не согласны — как разрешить?
Swyx [01:21:38]: Обычно кто-то CEO, так что у него tiebreaker.
Jake [01:21:43]: Полностью. Сложно как ни крути. Сложно, если получаешь помощь, и сложно, если делаешь сам. Управлять — сложно, но это так вознаграждающе и весело.
Swyx [01:21:56]: Что ты находил полезным? Коуч? Какие-то полезные советы?
Jake [01:22:01]: Я люблю много писать. Часто попадаю в неприятности из-за Twitter. Я однажды сказал, что если работаешь по выходным — у тебя проблемы с планированием. Я туда-сюда по этому, потому что сейчас экстраординарное время, когда имеет смысл работать больше. Цели чётко в голове. Если у тебя есть видение и знаешь, куда идёшь — работай усерднее, чтобы дистиллировать видение и делать эти вещи.
Jake [01:22:33]: Если ты не уверен и нужна ясность — отключайся и относись к выходным серьёзно. Пиши о том, где ты, что хочешь делать, куда хочешь идти и какие проблемы решаешь.
Jake [01:22:56]: Письмо важно. Не люблю слово медитация, но что бы ни приводило тебя к ментальной ясности — это важно, когда пытаешься сказать: «Мы здесь, и нам надо быть здесь», или «Мы здесь, и я думаю, нам надо быть в этом пространстве, чтобы это сработало».
Jake [01:23:22]: Отключайся, общайся с теми, кого любишь, и работай тяжело, когда работаешь. Я стараюсь работать от рассвета до заката, с понедельника по пятницу, на все деньги. Отключаюсь в субботу и возвращаюсь в воскресенье днём, чтобы писать, планировать неделю и делать всё остальное. У меня это работает.
Jake [01:23:43]: Ещё горячее мнение: большинство советов надо переварить и выбросить в окно. Если будет полезно — вернётся. Узнаешь это через опыт. Мы сделали неудачу очень дорогой как общество, и из-за этого людям сложно сходить с протоптанных дорог.
GPU, фокус и доминирующая роль агентов
Swyx [01:24:03]: Что-то, чего ты ещё не твитнул и за что не попадал, что хочешь предварить миру?
Jake [01:24:12]: Агентские штуки безумные. Это будет доминирующий способ, которым люди делают практически всё, при условии, что мы сможем получить нужный inference, чтобы это произошло. В ближайшие 10 лет увидишь фундаментальный сдвиг в том, как люди думают об авторстве логики в голове.
Swyx [01:24:36]: Один способ это сформулировать: если Allbirds может стать GPU-провайдером, то и Railway может.
Jake [01:24:44]: Думаю, есть много «все становятся GPU-провайдерами», что на самом деле не становление GPU-провайдером. Тебя больше определяет то, чего ты не делаешь, чем то, что ты делаешь, потому что легко сказать «да» куче всего.
Jake [01:24:56]: Anthropic потрясающие и заходят в разные зоны. Заходят в Figma-подобные штуки.
Swyx [01:25:09]: Прямо как мы записываем — Mike Krieger был в совете Figma, его убрали в понедельник, и сегодня они запустили это.
Jake [01:25:18]: Вещи сейчас движутся быстро. Но агенты будут способом, которым люди работают.
Swyx [01:25:25]: Так твой ответ — фокус: пока без GPU, но никогда не говори никогда.
Jake [01:25:27]: Фокус. Мы сейчас не будем делать GPU, но 100% будем делать GPU в какой-то момент в будущем. Это не я сливаю наш roadmap — у нас нет планов делать GPU. Это просто функция нужды во FLOPS в какой-то момент. Если ты полностью вертикально интегрирован и хочешь сделать тривиальным итерации, построение и деплой, тебе нужен доступ к этой core части фундаментальной логики.
Новое облако от первых принципов
Swyx [01:25:57]: Видимо, трафик ваших собственных дата-центров сейчас — меньшая часть нагрузки, но есть ли точка, когда это большинство или вы отключите публичные облака?
Jake [01:26:10]: В какой-то момент мы дошли до 100% дата-центров: наших собственных. Сейчас подавляющее большинство того, что существует на платформе, на наших bare-metal дата-центрах.
Swyx [01:26:21]: То есть вы уже там.
Jake [01:26:23]: Да. Переход был завершён в какой-то момент, потом мы выросли так быстро, что пришлось откатиться. Дошло до 100% на дашборде Datadog, потом опустилось обратно в 90-е, потому что мы добавляли ёмкость.
Swyx [01:26:45]: Вы буквально строите новое независимое облако, и люди считают, что такое уже невозможно после AWS.
Jake [01:26:53]: Сложно. Будем разбираться с кучей штук, чтобы убедиться, что платформа глубоко надёжна. Но надо вспахивать новую почву, когда решаешь строить облако с нуля, не копируя гиперскейлеров.
Jake [01:27:10]: Мы были осмыслены в том, чтобы изобретать свою инфраструктуру с нуля на основе чтения кучи статей, обещая себе не копировать чужую домашку. Если копируем кого-то — проигрываем. Со временем становишься им. Нужен core-тезис, почему этот бизнес должен существовать сейчас.
Jake [01:27:33]: Для нас энергия активации, нужная для развёртывания чего-то в продакшне на гиперскейлерах, слишком высока. Мы считаем, что должно быть мгновенно. Не должно быть трения между твоей мыслью и реальностью, которая получается и которой можно поделиться с друзьями. Это то, к чему мы строим на каждом слое стека. Если надо спуститься до энергии — спустимся до энергии.
Jake [01:27:58]: Это имеет значение для того, чтобы дать людям доступ к этому тулингу. Это закрыто не только для citizen developers, которые сейчас вайб-кодят. У тебя несколько слоёв: citizen developer, фронтенд-разработчик, бэкенд-разработчик, DevOps-человек и так далее. Эти слои должны исчезнуть, чтобы люди могли просто шипить.
Swyx [01:28:20]: Шикарно. Это будущее облака.
Jake [01:28:22]: Круто. Спасибо, что пришёл. Спасибо, что позвали. Было замечательно.
Обсуждение этого эпизода
