Railway: The Agent-Native Cloud — Jake Cooper

Railway: The Agent-Native Cloud — Jake Cooper

Railway: облако нативное для агентов — Jake Cooper

Take the 2026 AI Engineering Survey and get >$2k in credits and AIE WF tickets!

Пройдите опрос AI Engineering Survey 2026 и получите кредитов на сумму более $2k и билеты на AIE WF!

This was recorded before Railway suffered a major GCP outage on May 19, despite being a multi-AZ, multi-zone mesh ring, with HA fiber interconnects between their Metal <> GCP <> AWS, because workload discoverability was unintentionally still tied to GCP. All has been resolved with a post-mortem.

Запись была сделана до того, как у Railway случился крупный сбой GCP 19 мая, несмотря на multi-AZ, multi-zone mesh-кольцо с HA fiber interconnects между их Metal <> GCP <> AWS, потому что обнаружение нагрузок по недосмотру всё ещё было привязано к GCP. Всё уже решено, опубликован post-mortem.

Railway did not start as an AI infrastructure company.

Railway не начиналась как компания AI-инфраструктуры.

It was founded in 2020 years before agents became the default way people thought about deploying software. Jake Cooper, formerly at Bloomberg and Uber, started Railway with a simple obsession: the activation energy to ship something to production should be near zero. Push code, get a URL, iterate. No Docker files, no Kubernetes manifests, no Ansible scripts stacked on Ansible scripts.

Она была основана в 2020 году — за годы до того, как агенты стали способом мышления о деплое софта по умолчанию. Jake Cooper, ранее работавший в Bloomberg и Uber, основал Railway с простой одержимостью: энергия активации для выкатывания чего-либо в продакшн должна быть близка к нулю. Пушишь код, получаешь URL, итерируешь. Никаких Docker-файлов, никаких манифестов Kubernetes, никаких скриптов Ansible поверх скриптов Ansible.

For years, this was a slow grind. Railway spent its first 18 months hand-acquiring its first 100 users with Jake personally greeting every Discord signup on a second monitor.

Многие годы это была медленная работа. Railway потратила первые 18 месяцев на ручное привлечение первых 100 пользователей: Jake лично приветствовал каждую регистрацию в Discord на втором мониторе.

Today, Railway has raised $124m and is growing very fast. A 35-person team supports 3 million users, adding roughly 100,000 signups a week. Their bare metal data centers have a 3-month payback period vs. renting in the cloud, with 70% margins funding aggressive cloud bursting when needed. The servers they own have actually appreciated in value as RAM prices have climbed basically meaning the value of their hardware now exceeds the capital they've raised.

Сегодня Railway привлекла $124 млн и растёт очень быстро. Команда из 35 человек поддерживает 3 миллиона пользователей, добавляя около 100 000 регистраций в неделю. Их bare metal дата-центры окупаются за 3 месяца по сравнению с арендой в облаке, а маржа 70% финансирует агрессивный cloud bursting при необходимости. Принадлежащие им серверы фактически выросли в цене вместе с ростом цен на RAM — это означает, что стоимость их оборудования теперь превышает капитал, который они привлекли.

From rebuilding Railway’s network overlay over a weekend to moving the vast majority of workloads onto its own bare metal data centers, Jake Cooper is trying to build a new cloud for an agent-native world. In this episode, Railway’s founder and “conductor” joins swyx and Alessio to unpack why the next era of software infrastructure is not just “Heroku but newer,” what agents need that humans did not, and why the old deployment loop of Git, PRs, CI/CD, and static cloud resources may be heading for a rewrite.

От перестройки сетевого overlay Railway за выходные до переноса подавляющего большинства нагрузок на собственные bare metal дата-центры — Jake Cooper пытается построить новое облако для мира, нативного для агентов. В этом эпизоде основатель Railway и «дирижёр» присоединяется к swyx и Alessio, чтобы разобраться, почему следующая эра инфраструктуры ПО — это не просто «Heroku, но новее», что нужно агентам, чего не требовалось людям, и почему старый цикл деплоя из Git, PR, CI/CD и статичных облачных ресурсов может быть на пороге переписывания.

We go deep on Railway’s infrastructure stack: own-metal data centers, three-month cloud payback periods, cloud bursting, data center debt, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable filesystems, agent-safe production forks, and why the CLI may become more important than the canvas in an agent world. Jake also shares the founder journey behind Railway, how the company survived losing $500K/month, why it now serves millions of users with only 35 people, and why he believes the pull request is dying.

Мы подробно разбираем инфраструктурный стек Railway: собственные дата-центры на железе, трёхмесячные сроки окупаемости в облаке, cloud bursting, долговое финансирование дата-центров, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable файловые системы, безопасные для агентов форки продакшна, и почему CLI может стать важнее canvas в мире агентов. Jake также делится историей основателя Railway, рассказывает, как компания пережила потери $500K в месяц, почему сейчас она обслуживает миллионы пользователей всего 35 сотрудниками, и почему он считает, что pull request умирает.

We discuss:

Мы обсуждаем:

Как 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:

Railway:

Сайт: https://railway.com/X: https://x.com/Railway

Jake Cooper:

Jake Cooper:

LinkedIn: https://www.linkedin.com/in/thejakecooper/X: https://x.com/JustJake

Timestamps

Таймкоды

00:00:00 Introduction: What Is Railway?
00:02:07 Jake’s Path to Railway
00:06:13 Railway’s Six-Year Growth Story
00:08:52 Rebuilding the Business After the Free Tier
00:11:17 Agents as the Next Software Platform
00:13:29 Railway’s Infrastructure Philosophy
00:15:42 Bare Metal, Cloud Economics, and the Compute Crunch
00:17:22 Cloud Bursting and Five-Cloud Networking
00:20:20 Data Center Debt and Infra Financing
00:23:31 Data Centers in Space
00:25:24 What Agents Need From Infrastructure
00:28:24 CLIs, Canvas, and Agent-Native UX
00:35:15 Central Station, Incidents, and Responsible Disclosure
00:40:30 Safe Rollouts, SRE Agents, and Production Forks
00:45:00 AI SRE, Specs, Code, and Tests
00:48:24 Self-Replicating Infrastructure and the New Serverless
00:53:18 Heroku, Temporal, and Workflow Engines
01:04:07 Railpack, Nixpacks, and Lazy-Loaded Filesystems
01:06:01 Coding Agents, Token Spend, and Roadmap Acceleration
01:10:56 The Pull Request Is Dying
01:12:28 Feature Flags and the Agent-Era SDLC
01:16:15 Cattle, Pets, and Cloning Machines
01:19:29 Solo Founder Lessons
01:24:12 Focus, GPUs, and Building a New Cloud
01:28:20 Closing Thoughts

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 Завершающие мысли

Transcript

Транскрипт

Alessio [00:00:00]: Hey, everyone. Welcome to the Latent Space Podcast. This is Alessio, founder of Kernel Labs, and I’m joined by Swyx, editor of Latent Space.

Alessio [00:00:00]: Привет всем. Добро пожаловать в подкаст Latent Space. Это Alessio, основатель Kernel Labs, со мной Swyx, редактор Latent Space.

Swyx [00:00:10]: Hey, hey, hey. Today we’re in the studio with Jake Cooper of Railway.

Swyx [00:00:10]: Привет-привет. Сегодня у нас в студии Jake Cooper из Railway.

Alessio [00:00:14]: Conductor of Railway.

Alessio [00:00:14]: Дирижёр Railway.

Swyx [00:00:15]: Conductor at Railway. Yeah.

Swyx [00:00:15]: Дирижёр в Railway. Да.

Alessio [00:00:16]: Choo-choo.

Alessio [00:00:16]: Чух-чух.

Swyx [00:00:17]: Do you actually have that anywhere, like on your business card?

Swyx [00:00:17]: У тебя это где-нибудь правда написано? На визитке, например?

Jake [00:00:20]: We call some of our volunteer moderators conductors. I don’t have a business card. We’re not that big yet. At some point I will. I got handed a nice business card from the Supermicro folks, and I was like, “Damn, this is pretty official.”

Jake [00:00:20]: Мы называем некоторых наших волонтёров-модераторов дирижёрами (conductors). У меня нет визитки. Мы пока не настолько большие. В какой-то момент будет. Мне вручили красивую визитку ребята из Supermicro, и я подумал: «Чёрт, это довольно официально».

Swyx [00:00:30]: Business cards are coming back.

Swyx [00:00:30]: Визитки возвращаются.

Jake [00:00:32]: They’re cool. They’re hip. The conductor thing is good. We’re trying to figure out what we want to call each other internally. Some people think it’s super cringe and say, “You don’t need a name for people internally.” Some people want to call each other something. We still don’t have a really good one.

Jake [00:00:32]: Они классные. Они модные. С дирижёром норм. Мы пытаемся придумать, как называть друг друга внутри компании. Кто-то считает, что это супер-кринж и говорит: «Не нужно никакого названия для людей внутри». Кто-то хочет как-то называть друг друга. У нас пока нет действительно хорошего варианта.

Jake [00:00:55]: We’ve got New Railcrews, Trainiacs. Nothing has stuck yet.

Jake [00:00:55]: У нас были New Railcrews, Trainiacs. Ничего пока не прижилось.

Swyx [00:01:00]: I like Trainiac. Trainiac sounds good. Railwayians. For those who don’t know, what is Railway? Let’s give people a crisp definition up front.

Swyx [00:01:00]: Мне нравится Trainiac. Trainiac звучит хорошо. Railwayians. Для тех, кто не знает — что такое Railway? Дадим людям чёткое определение в начале.

Jake [00:01:09]: Railway is the easiest way to ship anything. You go to the canvas, or you talk with Claude, and you say, “Deploy a Postgres instance, deploy my GitHub repository, run this code,” and you’re off to the races.

Jake [00:01:09]: Railway — это самый простой способ выкатить что угодно. Заходишь на canvas или говоришь с Claude и говоришь: «Разверни инстанс Postgres, разверни мой GitHub-репозиторий, запусти этот код», — и ты в деле.

Swyx [00:01:22]: You’ve got a nice animation on the landing page.

Swyx [00:01:22]: У вас классная анимация на лендинге.

Jake [00:01:24]: Thank you. None of my work, by the way. They don’t let me touch the design stuff anymore.

Jake [00:01:24]: Спасибо. Кстати, ни одна из них не моя. Меня больше не подпускают к дизайнерским штукам.

Jake [00:01:25]: We want to make it trivially easy not just to deploy things, but to evolve applications over time. Most tooling right now stacks entropy on top of entropy: Docker, Kubernetes, Ansible scripts, and all these other things. If we can version all of your software and keep track of all the changes, then we can make it trivial to clone environments, fork into a parallel universe, get copies of production data, get copies of any services, make changes, validate them, and collapse them back in without reproducing everything across a staging environment.

Jake [00:01:25]: Мы хотим сделать тривиально простым не только деплой, но и эволюцию приложений со временем. Большинство сегодняшнего тулинга наслаивает энтропию на энтропию: Docker, Kubernetes, скрипты Ansible и всё остальное. Если мы можем версионировать весь ваш софт и отслеживать все изменения, мы можем сделать тривиальным клонирование окружений, форк в параллельную вселенную, получение копий production-данных, копий любых сервисов, внесение изменений, их валидацию и сворачивание обратно — без воспроизведения всего этого в staging-окружении.

The Railway Origin Story: From Uber Systems to a New Cloud

История Railway: от систем Uber к новому облаку

Swyx [00:02:07]: I was looking at your background: Bloomberg, Uber. Nothing immediately stands out as, “This guy is going to found the next great platform as a service.” What prepared you for Railway?

Swyx [00:02:07]: Я смотрел твой бэкграунд: Bloomberg, Uber. Ничто сразу не говорит: «Этот парень основает следующую великую PaaS-платформу». Что подготовило тебя к Railway?

Jake [00:02:21]: It was curiosity to keep going deeper. I started out on front-end stuff, working on Wolfram Mathematica and porting it over. Then I briefly moved to Bloomberg, then toward Uber and distributed systems, taking the Jump Bikes systems and moving them to a distributed system built on top of Cadence, the pre-Temporal Temporal.

Jake [00:02:21]: Это любопытство — желание копать глубже. Я начинал с фронтенда, работал над Wolfram Mathematica и портированием. Потом ненадолго перешёл в Bloomberg, а затем в Uber и распределённые системы — взял системы Jump Bikes и перенёс их на распределённую систему, построенную на Cadence, пра-Temporal.

Swyx [00:02:44]: Which, by the way, I’m happy to talk about, pros and cons.

Swyx [00:02:44]: О котором я, кстати, с радостью поговорю — плюсы и минусы.

Jake [00:02:48]: Totally.

Jake [00:02:48]: Полностью.

Swyx [00:02:51]: But let’s do the Railway story.

Swyx [00:02:51]: Но давай сначала историю Railway.

Jake [00:02:52]: It has been a continual step of wanting an experience. Whether it’s walking up to a bike, unlocking it, and having it work frictionlessly, or something else, the depth required to make that happen follows from the experience. A lot of the work I do, and a lot of the team does, is in service of that experience. We fundamentally don’t care how deep we have to go. We will swim to the bottom of the swimming pool to get the experience.

Jake [00:02:52]: Это была непрерывная серия шагов в желании получить определённый опыт. Будь то подойти к велосипеду, разблокировать его и чтобы всё работало без трения, или что-то ещё — глубина, необходимая для этого, следует из самого опыта. Большая часть работы, которую делаю я и команда, — в служении этому опыту. Нам фундаментально всё равно, насколько глубоко придётся копать. Мы доплывём до дна бассейна, чтобы получить нужный опыт.

Jake [00:03:17]: I don’t have a physics PhD. I did an EECS degree. It has always been about figuring out the next step: how do we get there? That’s what led to starting Railway for that experience and then moving all the way to bare metal data centers. I was adding patches to the kernel this week to get the experience there because I can see how much better it can be.

Jake [00:03:17]: У меня нет PhD по физике. У меня EECS-диплом. Это всегда было о том, как сделать следующий шаг: как туда попасть? Это и привело к основанию Railway ради такого опыта, а потом к движению вплоть до bare metal дата-центров. На этой неделе я добавлял патчи в ядро, чтобы получить нужный опыт — потому что я вижу, насколько лучше всё может быть.

Swyx [00:03:49]: Other patches to the Linux kernel this week?

Swyx [00:03:49]: Другие патчи в ядро Linux на этой неделе?

Jake [00:03:51]: Yeah. Not upstream. Our fork.

Jake [00:03:51]: Да. Не upstream. В нашем форке.

Swyx [00:03:52]: That’s a flex. Railpack? No, this is different. This is the OS on top of Railpack?

Swyx [00:03:52]: Это флекс. Railpack? Нет, это другое. Это ОС поверх Railpack?

Jake [00:03:57]: No, this is an actual kernel patch. It’s always literally: what do we have to do to get that experience? Then figure it out. Anything is figureoutable.

Jake [00:03:57]: Нет, это реальный патч в ядро. Всегда буквально один вопрос: что нам нужно сделать, чтобы получить этот опыт? А потом разобраться, как. Всё разрешимо.

Swyx [00:04:10]: Would you send the patch upstream, or does it not fit other use cases?

Swyx [00:04:10]: Отправите ли вы патч upstream, или он не подходит для других use case?

Jake [00:04:13]: Maybe. We have to work out the experience internally. It has to do with the storage layer we’re building for some of the agentic stuff. Maybe it’ll be useful upstream, but it’s deeply useful for us internally.

Jake [00:04:13]: Может быть. Нам надо доработать опыт внутри. Это связано со слоем хранения, который мы строим для агентских штук. Возможно, он будет полезен upstream, но для нас внутри он глубоко полезен.

Open Source, Forks, and Non-Deterministic Versioning

Open Source, форки и недетерминированное версионирование

Swyx [00:04:29]: You mentioned open source before. How do you think about starting from open source, and then coding agents letting you do a lot more from forks of it?

Swyx [00:04:29]: Ты упомянул open source. Как ты думаешь о том, чтобы начинать с open source, а потом coding-агенты позволяют сделать гораздо больше с форками?

Jake [00:04:38]: GitHub’s original sin is that it’s almost a series of broken pointers. You have this thing, then you clone it, and now you’ve lost the whole upstream. How do we make it trivial for people to modify really small pieces of it?

Jake [00:04:38]: Первородный грех GitHub в том, что это почти набор сломанных указателей. У тебя есть штука, ты её клонируешь, и теперь ты потерял весь upstream. Как сделать тривиальным для людей модифицировать совсем маленькие куски?

Jake [00:04:51]: We think of Git in a discrete sense: I’ve either made a change and merged upstream, or I haven’t. What would it look like if it were percentage-based, a little more non-deterministic, or a stream of changes that users traverse as a percentage rolled out in general and then rolled all the way up?

Jake [00:04:51]: Мы думаем о Git дискретно: я либо внёс изменение и смержил upstream, либо нет. Как бы это выглядело, если бы оно было процентным, чуть более недетерминированным или потоком изменений, которые пользователи проходят по мере раскатки в процентах и накатываются вплоть до конца?

Jake [00:05:13]: We have the open-source kickback program and let you deploy templates because we want to make it trivial for people to version these shards over time. It solves a large problem around authentication, authorization, and security. NPM has a way to define, “Don’t take any new packages.” The ideal end state is that you roll out progressively to users with the minimum impact zone and continue rolling up. JPMorgan should probably be the last one on the patch line, for all our sakes, because our money and livelihoods are there.

Jake [00:05:13]: У нас есть open-source kickback-программа, и мы позволяем разворачивать шаблоны, потому что хотим сделать тривиальным для людей версионирование этих шардов со временем. Это решает большую проблему вокруг аутентификации, авторизации и безопасности. У NPM есть способ задать: «Не бери новые пакеты». Идеальное конечное состояние — когда ты постепенно раскатываешь пользователям с минимальной зоной поражения и продолжаешь раскатку. JPMorgan, наверное, должен быть последним в патч-линии — ради всех нас, потому что там наши деньги и средства к существованию.

Jake [00:05:53]: It’s okay if Johnny Vibe Coder gets a broken patch because there’s so much entropy in the system that the rubber has to meet the road at some point. You have to test at varying levels.

Jake [00:05:53]: Это ок, если Johnny Vibe Coder получит сломанный патч, потому что в системе столько энтропии, что резина должна где-то соприкоснуться с дорогой. Тестировать надо на разных уровнях.

The Long Grind: First Users, Free Tier, and Making the Business Work

Долгий марафон: первые пользователи, free tier и работа над бизнесом

Swyx [00:06:13]: I wanted to pull up this glorious chart, which is your usage or number of daily signups?

Swyx [00:06:13]: Я хотел показать этот великолепный график. Это use или количество ежедневных регистраций?

Jake [00:06:22]: Daily signups, I think.

Jake [00:06:22]: Ежедневные регистрации, кажется.

Swyx [00:06:24]: You started six years ago. It was a slow grind, and now you’re on a rocket ship. You say, “Don’t doubt your fight and don’t quit.” Maybe pick out certain points that were key inflections for the company.

Swyx [00:06:24]: Вы начали шесть лет назад. Был медленный марафон, а теперь вы на ракете. Ты говоришь: «Не сомневайся в своём бою и не сдавайся». Может, выберешь ключевые точки перелома для компании.

Jake [00:06:40]: At the start, it’s about getting your first 100 users, hell or high water. We had a website and a support link. The support link was the Discord channel. I had notifications on with two monitors: the monitor I was working on and the other monitor with Discord. If anybody came in, I was immediately like, “Hey, how’s it going?” It was rare, so getting those first 100 users to come back was the start.

Jake [00:06:40]: В начале всё упирается в получение первых 100 пользователей — кровь из носу. У нас был сайт и саппорт-ссылка. Саппорт-ссылка вела в Discord. У меня были включены уведомления и два монитора: один — рабочий, второй — Discord. Если кто-то заходил, я тут же: «Привет, как дела?» Это случалось редко, так что заставить первых 100 пользователей вернуться — это и был старт.

Jake [00:07:14]: Then you build a consultancy factory because users want all these things. You have to go back to the board and ask, “What is the actual product offering I want to build on top of this?”

Jake [00:07:14]: Потом ты строишь консалтинговую фабрику, потому что пользователи хотят всё подряд. Приходится возвращаться к доске и спрашивать: «Какой реально продукт я хочу построить поверх этого?»

Jake [00:07:28]: VCs want charts that always go up and to the right, but in reality you don’t necessarily want charts that look like that. For us, there have been periods of expansion where we add features to test use cases, and periods of compaction where we ask, “If the experience we have is good, how do we make it significantly better?” Maybe we strip out features that don’t fit our ICP anymore.

Jake [00:07:28]: VC хотят графики, всегда уходящие вверх и вправо, но в реальности тебе необязательно нужны такие графики. У нас были периоды расширения, когда мы добавляли фичи для тестирования use case, и периоды сжатия, когда мы спрашивали: «Если опыт у нас хороший — как сделать его значительно лучше?» Может, выкинуть фичи, которые больше не подходят нашему ICP.

Jake [00:07:57]: The boom from 2022 to 2023 came from the free tier. Everybody under the sun was using it.

Jake [00:07:57]: Бум с 2022 по 2023 пришёл с free tier. Все, кому не лень, им пользовались.

Swyx [00:08:09]: A lot of Reddit bots and Discord bots.

Swyx [00:08:09]: Куча Reddit-ботов и Discord-ботов.

Jake [00:08:12]: And crypto miners. When you build an open product on the internet where anybody can sign up, the internet is a horrible place with so many things. You go through periods of asking, “How do I reach as many people as possible?” Then, “How do I fit the exact use case for the people who really matter and are really excited about this specific thing?”

Jake [00:08:12]: И крипто-майнеры. Когда строишь открытый продукт в интернете, где может зарегистрироваться кто угодно, — интернет ужасное место с массой штук. Проходишь периоды: «Как охватить как можно больше людей?» Потом: «Как точно попасть в use case тех людей, которые реально важны и реально увлечены этой конкретной штукой?»

Jake [00:08:39]: Then there was a two-year period of making the actual business work. During the free-tier era, we were losing about half a million dollars a month.

Jake [00:08:39]: Потом был двухлетний период — заставить бизнес работать. В эпоху free tier мы теряли около полумиллиона долларов в месяц.

Swyx [00:08:59]: On a $20 million bank account.

Swyx [00:08:59]: На банковском счёте в $20 миллионов.

Jake [00:09:02]: On a $20 million bank account with maybe $50,000 a month in revenue. That’s a horrible business. I don’t know how anybody invested. But you have to go through it and say, “We have an experience people love, but the business has to work.”

Jake [00:09:02]: На банковском счёте в $20 миллионов при выручке, может, $50 000 в месяц. Это ужасный бизнес. Не знаю, как кто-то вообще в него инвестировал. Но через это нужно пройти и сказать: «У нас опыт, который людям нравится, но бизнес должен работать».

Jake [00:09:17]: There are two schools of thought. You can run the horrible business all the way up with bad margins, or you can go back and make it work. We’ve always wanted a super lean team. We’re 35 people right now. It’s very small.

Jake [00:09:17]: Есть две школы мысли. Можно тянуть ужасный бизнес наверх с плохими маржами, либо вернуться и заставить его работать. Мы всегда хотели супер-маленькую команду. Сейчас нас 35 человек. Это очень мало.

Swyx [00:09:36]: Supporting three million already?

Swyx [00:09:36]: Уже поддерживаете три миллиона?

Jake [00:09:38]: Yeah. We’re adding 100,000 users a week right now, so it’s growing fast. We don’t want to add headcount for the sake of headcount or throw bodies at problems. We want to build systems. It’s hard to build systems during expansion because you’re adding things to the system because people are asking for them or things are breaking.

Jake [00:09:38]: Да. Сейчас добавляем 100 000 пользователей в неделю, так что растёт быстро. Мы не хотим нанимать ради найма или бросать тела на проблемы. Мы хотим строить системы. Сложно строить системы во время расширения, потому что ты добавляешь в систему вещи, потому что их просят люди или потому что что-то ломается.

Jake [00:10:00]: We had to cut off the free users for a little while, rebuild the business, and make sure it worked. We want to reach as many people as possible because software is important. It’s become difficult to create things in the physical world, so it’s important to make it easy for people to build in the virtual world and have access to creation. But there are legs to that journey.

Jake [00:10:00]: Нам пришлось отрубить free-пользователей на какое-то время, перестроить бизнес и убедиться, что он работает. Мы хотим охватить как можно больше людей, потому что софт — это важно. Создавать вещи в физическом мире стало сложно, поэтому важно, чтобы людям было легко строить в виртуальном мире и иметь доступ к творчеству. Но у этого пути есть этапы.

Jake [00:10:30]: You can see divots in the charts. If you follow between 2025 and 2026, it’s either summer or winter. People go on holiday with family.

Jake [00:10:30]: На графиках видны провалы. Если посмотреть между 2025 и 2026, это либо лето, либо зима. Люди уезжают в отпуск с семьями.

Swyx [00:10:50]: It affects that much?

Swyx [00:10:50]: Это так сильно влияет?

Jake [00:10:51]: Yeah. It’s kind of B2C and kind of B2B. People are shipping constantly, then they stop. Our activation curve now shows more people activating on weekdays because we have more business users, so it smooths out over time.

Jake [00:10:51]: Да. Это отчасти B2C и отчасти B2B. Люди постоянно деплоят, потом останавливаются. Наша кривая активации теперь показывает, что больше людей активируется в будни — у нас больше бизнес-пользователей, и со временем это сглаживается.

Agents as the New Interface to Deployment

Агенты как новый интерфейс к деплою

Swyx [00:11:17]: Was there a point where you started prioritizing AI development or agent development?

Swyx [00:11:17]: Был ли момент, когда вы начали приоритизировать разработку под AI или агентов?

Jake [00:11:24]: We’ve prioritized agentic as a top-of-funnel thing. Over the last six months, we’ve deeply prioritized agentic as a mechanism to build and deploy things because we believe the curve is so steep and that is how people will build and deploy software.

Jake [00:11:24]: Мы приоритизировали агентов как вершину воронки. За последние шесть месяцев мы глубоко приоритизировали агентов как механизм построения и деплоя, потому что считаем, что кривая настолько крутая и именно так люди будут строить и деплоить софт.

Jake [00:11:42]: It almost fundamentally doesn’t matter whether this is dot-com or not because we’re all on the internet anyway. If agents are going to deploy a bunch of things and we hit an inference wall at some point, we’ll fix those problems. The dominant species over the next 10 years is that we’ve moved from assembly to C to C++ to JavaScript to words. You’re going to need to close that loop.

Jake [00:11:42]: Почти не важно, дот-ком это или нет, потому что мы все и так в интернете. Если агенты будут разворачивать кучу всего, и мы упрёмся в стену inference в какой-то момент — мы решим эти проблемы. Доминирующий вид на ближайшие 10 лет — мы прошли путь от ассемблера к C, к C++, к JavaScript и к словам. Этот цикл нужно замкнуть.

Swyx [00:12:13]: When you say this is dot-com, did you mean buying the domain, or the general case?

Swyx [00:12:13]: Когда ты говоришь «это дот-ком», ты имеешь в виду покупку домена или общий случай?

Jake [00:12:17]: I mean the dot-com era, when companies had a huge run-up because people understood the internet was important. Then they hit bottlenecks, fundamental laws of physics, math didn’t work, and everybody came back down to earth. But it didn’t matter because the internet became so impactful. If you operate on a long enough time horizon, you should build these things anyway because you can see where it’s going.

Jake [00:12:17]: Я имею в виду эпоху дот-комов, когда у компаний был огромный взлёт, потому что люди понимали, что интернет важен. Потом упёрлись в бутылочные горлышки, фундаментальные законы физики, математика не сошлась, и все спустились обратно на землю. Но это не имело значения, потому что интернет стал настолько влиятельным. Если работаешь на достаточно длинном горизонте, всё равно стоит строить эти штуки, потому что видишь, куда всё идёт.

Jake [00:12:45]: That’s where I think a lot of agent stuff is. You get to a point where you’re running thousands of agents in parallel. What is the inference cost? What is the compute cost? How do you make that efficient? How do you coordinate all this? We have issues coordinating humans; we don’t even have good tooling for that. Now we have to figure out how to get agents to coordinate, safely version changes, and know when to raise their hand for someone to intervene. Otherwise it becomes an interrupt factory.

Jake [00:12:45]: Думаю, на этом этапе сейчас много агентских штук. Доходишь до момента, когда запускаешь тысячи агентов параллельно. Какая цена inference? Какая цена compute? Как сделать это эффективным? Как всё это координировать? У нас проблемы с координацией людей; у нас даже для этого нет хорошего тулинга. Теперь надо понять, как заставить агентов координироваться, безопасно версионировать изменения и знать, когда поднять руку, чтобы кто-то вмешался. Иначе это становится фабрикой прерываний.

Railway’s Infrastructure Thesis: Network, Compute, Storage, and Metal

Инфраструктурный тезис Railway: сеть, compute, хранилище и железо

Swyx [00:13:19]: Let’s go right into the technical side. What are the core infrastructure or architectural beliefs of Railway that allow you to do what you do?

Swyx [00:13:19]: Перейдём к технической стороне. Какие основные инфраструктурные или архитектурные убеждения Railway позволяют вам делать то, что вы делаете?

Jake [00:13:29]: The primitives matter a lot for us. We need network, compute, storage, and orchestration around it. You need control over a lot of those things. We’ve talked a lot about how we don’t really use Kubernetes because we want higher-order control to place workloads in very specific places.

Jake [00:13:29]: Примитивы для нас очень важны. Нам нужны сеть, compute, хранилище и оркестрация вокруг них. Над многими из этих вещей нужен контроль. Мы много говорили о том, что не очень-то используем Kubernetes, потому что хотим высокоуровневого контроля над размещением нагрузок в очень конкретных местах.

Jake [00:13:48]: The reason is that you have to be very efficient with agents: memory reuse and all these other things, or you’re going to massively blow up your cost structure. Being able to rack and stack your own servers and build your own metal unlocks performance and cost. Experiences where you’re running 1,000 agents in parallel are not massively cost prohibitive.

Jake [00:13:48]: Причина в том, что с агентами нужно быть очень эффективным: переиспользование памяти и прочее, иначе массово раздуешь свою стоимостную структуру. Возможность собрать собственные серверы и построить собственное железо открывает производительность и стоимость. Опыт, где ты запускаешь 1000 агентов параллельно, не становится запредельно дорогим.

Jake [00:14:13]: Token use and compute use are blowing up. Over time, those things have to get a lot more efficient. You can get a lot of margin to make those experiences solid by building your own metal. That’s all in service of offering a differentiated experience to as many people as humanly possible.

Jake [00:14:13]: Использование токенов и compute взрывается. Со временем эти вещи должны стать намного эффективнее. Можно получить большую маржу, чтобы сделать этот опыт надёжным, построив собственное железо. Всё это в служении тому, чтобы предложить дифференцированный опыт максимально возможному количеству людей.

Swyx [00:14:51]: You have a data center in Singapore.

Swyx [00:14:51]: У вас есть дата-центр в Сингапуре.

Jake [00:14:53]: Yeah. We have two in every other region now. In Singapore, we’re adding a second one in Q3.

Jake [00:14:53]: Да. В каждом другом регионе теперь по два. В Сингапуре добавим второй в Q3.

Swyx [00:14:58]: What’s it like? I’ve never built a data center. Do you go to Equinix and say, “I want some slots?”

Swyx [00:14:58]: А как это устроено? Я никогда не строил дата-центр. Идёшь в Equinix и говоришь: «Хочу слотов?»

Jake [00:15:05]: Yeah. Equinix. You basically go and say, “I want power and I want a cage.” They say, “Great, here’s what it’s going to be.” You rent the cage for a period of time, fill it with racks and servers, and hook up internet to it. That’s all the pieces.

Jake [00:15:05]: Да. Equinix. Идёшь и говоришь: «Хочу электричество и клетку». Они говорят: «Отлично, вот сколько это будет стоить». Арендуешь клетку на какой-то период, наполняешь её стойками и серверами, и подключаешь интернет. Это все части.

Swyx [00:15:36]: Then you handle everything else.

Swyx [00:15:36]: Дальше ты разбираешься со всем остальным.

Jake [00:15:37]: You handle everything else.

Jake [00:15:37]: Со всем остальным сам.

Swyx [00:15:39]: What’s the math versus clouds doing it for you?

Swyx [00:15:39]: Какова математика по сравнению с тем, чтобы это делали облака?

Jake [00:15:43]: If we rented in the cloud, our payback period when we go to metal is about three months.

Jake [00:15:43]: Если бы мы арендовали в облаке, наш срок окупаемости перехода на железо — около трёх месяцев.

Swyx [00:15:50]: Which is crazy.

Swyx [00:15:50]: Это безумие.

Jake [00:15:51]: It’s nuts. That’s four years of depreciated hardware. You’re going to see a lot of this compute crunch because hyperscalers are buying up a lot of stuff. We’re working directly with OEMs, resellers, and people building these machines: Supermicro, Dell, and others.

Jake [00:15:51]: Это безумно. Это четыре года амортизированного оборудования. Compute crunch ещё проявит себя, потому что гиперскейлеры скупают всё подряд. Мы работаем напрямую с OEM, дистрибьюторами и людьми, собирающими эти машины: Supermicro, Dell и другими.

Jake [00:16:11]: Upstream, there’s a bunch of supply pressure. When we raised our last round, between deploying capital for servers and now, the amount of money we’ve raised is less than the amount of money we have in the bank plus the value of the servers because the servers have appreciated as RAM has gone up. It’s nuts how valuable hardware has become.

Jake [00:16:11]: Upstream идёт куча давления на предложение. Когда мы поднимали последний раунд, между размещением капитала на серверы и сейчас, объём поднятых нами денег меньше, чем сумма наших денег в банке плюс стоимость серверов, — потому что серверы выросли в цене, так как подорожала RAM. Безумно, насколько ценным стало оборудование.

Jake [00:16:50]: If you look at hyperscalers, they deployed around $80 billion of capital expenditures this year, and next year will be more. That’s a massive infrastructure build-out. You look at that and think it’s crazy that they’re spending way more than the Manhattan Project. But if every person is going to run dozens or hundreds of agents in parallel, you have no conceptual idea how much compute is required to make that experience happen, even if you’re deeply efficient and sharing resources. And that doesn’t even count inference.

Jake [00:16:50]: Если посмотреть на гиперскейлеров, в этом году они разместили примерно $80 миллиардов капитальных затрат, а в следующем будет больше. Это массовое инфраструктурное строительство. Смотришь и думаешь, что это безумие — они тратят гораздо больше, чем Манхэттенский проект. Но если у каждого человека будут запускаться десятки или сотни агентов параллельно, ты концептуально не представляешь, сколько compute нужно, чтобы этот опыт состоялся, даже если ты глубоко эффективен и шеришь ресурсы. И это даже не считая inference.

Swyx [00:17:22]: How do you plan the build-out? The growth chart is so vertical. Are you usually at 100% utilization as soon as racks are live? How far ahead are you planning?

Swyx [00:17:22]: Как ты планируешь стройку? График роста настолько вертикальный. Вы обычно на 100% утилизации сразу, как только стойки в работе? Насколько вперёд вы планируете?

Jake [00:17:33]: We still maintain cloud presence for bursting. We work with AWS, GCP, and a few other clouds. We can rent, and then the moment we get space or power, we compact those workloads off the cloud. We started on the clouds, then built a system to migrate to our own metal. There’s nothing that says you can’t continually do that again, and that’s exactly what we do. We never want to be compute constrained.

Jake [00:17:33]: Мы всё ещё поддерживаем облачное присутствие для bursting. Работаем с AWS, GCP и парой других облаков. Можем арендовать, и как только получаем место или электричество — компактифицируем эти нагрузки прочь из облака. Мы начинали с облаков, потом построили систему миграции на собственное железо. Ничто не мешает делать это снова и снова — именно это мы и делаем. Мы никогда не хотим быть compute constrained.

Jake [00:18:09]: At the start of the year, we actually became compute constrained because one upstream provider wasn’t able to give us quota at the rate we needed, and the hardware was slower. I spent a weekend rebuilding our entire network overlay so we could straddle five clouds: Oracle, AWS, ourselves, GCP, and one other one. We can do more than that now.

Jake [00:18:09]: В начале года мы как раз стали compute constrained, потому что один upstream-провайдер не мог дать нам квоту на нужной скорости, а железо было медленнее. Я провёл выходные, перестраивая весь наш сетевой overlay, чтобы мы могли работать через пять облаков: Oracle, AWS, мы сами, GCP и ещё одно. Сейчас можем больше.

Jake [00:18:38]: We got into a spot where we were trying to pack instances tight because we couldn’t get enough compute. That led to a few reliability issues, which are now past us. I made a tweet pointing out that it’s becoming harder and harder to acquire compute at the rate these models need to acquire compute. We got bit by it.

Jake [00:18:38]: Мы оказались в ситуации, когда пытались плотно упаковывать инстансы, потому что не могли получить достаточно compute. Это привело к нескольким проблемам с надёжностью, которые сейчас уже позади. Я написал твит о том, что становится всё сложнее приобретать compute с той скоростью, с которой эти модели требуют compute. Нас на этом и поймало.

Swyx [00:19:15]: How do you think about pricing knowing you might not have your own metal available at all times? Are you pricing assuming you need extra margin if you end up going into the cloud?

Swyx [00:19:15]: Как вы думаете о ценообразовании, зная, что собственное железо может быть доступно не всегда? Вы заводите дополнительную маржу на случай, если придётся уходить в облако?

Jake [00:19:26]: Because we’ve built out our metal data centers, our margins on metal are around 70%. We can deeply subsidize the cloud business if we want to scale at a reasonable rate. We have a few levers: metal, which makes the margins; cloud burst; debt to buy servers; and venture capital. It’s an interesting operational problem: how much cash do we have, how much should we raise, how quickly can we deploy it, and can we scale revenue as quickly as we scale compute?

Jake [00:19:26]: Поскольку мы построили собственные металлические дата-центры, наши маржи на железе около 70%. Мы можем глубоко субсидировать облачный бизнес, если хотим масштабироваться разумными темпами. У нас несколько рычагов: железо, дающее маржи; cloud burst; долг на покупку серверов; и венчурный капитал. Это интересная операционная задача: сколько у нас наличных, сколько надо поднять, как быстро мы можем это разместить и можем ли мы масштабировать выручку так же быстро, как масштабируем compute?

Jake [00:20:05]: If we continue making it trivially easy for people to build and deploy, then the faster we close that loop and the more operationally excellent we are with capital, the faster the business can scale. It’s almost a straight linear deployment rate.

Jake [00:20:05]: Если мы продолжаем делать тривиально простым для людей строить и деплоить, то чем быстрее мы замыкаем этот цикл и чем операционно эффективнее работаем с капиталом, тем быстрее может масштабироваться бизнес. Это почти прямая линейная скорость размещения.

Financing Infrastructure: Hardware Debt, VC, and Operational Leverage

Финансирование инфраструктуры: долг под железо, VC и операционный леверидж

Swyx [00:20:20]: I think infra startups raising debt is a tool people don’t utilize enough or know enough about. What can you tell us about that? Is it secured against your CPUs?

Swyx [00:20:20]: Думаю, привлечение долга инфра-стартапами — инструмент, которым люди не пользуются и о котором мало знают. Что ты можешь рассказать? Долг обеспечен вашими CPU?

Jake [00:20:32]: It’s secured against our hardware.

Jake [00:20:32]: Он обеспечен нашим железом.

Swyx [00:20:37]: What rates do you get? Who are the lenders?

Swyx [00:20:37]: Какие ставки? Кто кредиторы?

Jake [00:20:39]: We pay prime plus a spread, and we can refinance any of the debt as rates go down. The terms are pretty good. The unfortunate thing is that Twitter has no nuance, so people say, “Venture debt bad.” But as with all things, there are specific tools and areas where you can be deliberate instead of using one tool as a hammer. Venture capital is not the hammer for everything. You have to explore and figure out what works.

Jake [00:20:39]: Мы платим prime плюс спред, и можем рефинансировать любую часть долга по мере снижения ставок. Условия довольно хорошие. К сожалению, у Twitter нет полутонов, поэтому люди говорят: «Venture debt — плохо». Но как и со всем, есть конкретные инструменты и области, где можно действовать осмысленно, а не использовать один инструмент как молоток. Венчурный капитал — не молоток для всего. Надо исследовать и понимать, что работает.

Swyx [00:21:12]: VC is usually the most expensive financing you can get.

Swyx [00:21:12]: VC обычно самое дорогое финансирование, какое можно получить.

Jake [00:21:15]: Yeah. I also think people think about VC incorrectly from a capital-raising perspective. Most people think, “How do I raise as much money as possible from whoever is probably the best I can get at that time?” That’s close to right, but what we’ve tried to do is figure out what unfair advantage we can buy with that equity.

Jake [00:21:15]: Да. Ещё я думаю, что люди неправильно думают о VC с точки зрения привлечения капитала. Большинство думают: «Как поднять как можно больше денег у того, кто, вероятно, лучший из доступных в этот момент?» Это близко к правде, но мы пытались выяснить, какое нечестное преимущество мы можем купить за это equity.

Jake [00:21:34]: It’s the most expensive equity you’re going to give away at that point in time, assuming the company keeps getting better. How do you use it to work with someone stellar who complements you? In the seed stage, I had never started a company. Ray Tonsing had good advice, and I could text him all the time. He was really fast. Awesome.

Jake [00:21:34]: Это самое дорогое equity, которое ты отдаёшь в этот момент, в предположении, что компания продолжит расти. Как использовать это, чтобы работать с кем-то выдающимся, кто дополняет тебя? На seed-стадии я никогда не основывал компанию. У Ray Tonsing были хорошие советы, и я мог писать ему в любой момент. Он был очень быстрым. Круто.

Jake [00:22:01]: Then with John and Erica at Unusual, they said, “You roughly know what you’re doing building a product. We’ll mostly leave you alone and be available for advice.” Amazing. Then we got to Series A and the business was an operational tire fire because we didn’t know how to scale a business. Work with Erica, and Jordan is over at Redpoint, so bonus.

Jake [00:22:01]: Потом с John и Erica в Unusual они сказали: «Ты примерно знаешь, что делаешь при построении продукта. Мы по большей части тебя не трогаем и будем доступны для советов». Замечательно. Потом мы дошли до Series A, и бизнес был операционным пожаром, потому что мы не умели масштабировать бизнес. Работа с Erica, плюс Jordan в Redpoint, так что бонус.

Jake [00:22:28]: Now we’ve raised from TQ and FPV as we’re moving into enterprises. Every step of the way, we’ve asked: who can we partner with at this specific time to unlock the next section of the journey? I don’t know enterprise sales. As an engineer, I can eyeball what features we might need, and we have wonderful people internally who can help. But you want boardroom dynamics where everyone is aligned and asking, “How do we win this?” instead of bickering about strategy.

Jake [00:22:28]: Сейчас мы подняли деньги от TQ и FPV, по мере того как двигаемся в enterprise. На каждом этапе мы спрашивали: с кем мы можем партнёриться в этот конкретный момент, чтобы открыть следующий участок пути? Я не знаю enterprise sales. Как инженер я могу прикинуть, какие фичи могут понадобиться, и у нас внутри есть прекрасные люди, которые могут помочь. Но хочется boardroom-динамики, где все согласованы и спрашивают: «Как нам победить?», а не препираются о стратегии.

Data Centers in Space and the Physics of Compute

Дата-центры в космосе и физика compute

Swyx [00:23:31]: You had a tweet about data centers in space. Why no data centers in space?

Swyx [00:23:31]: У тебя был твит про дата-центры в космосе. Почему не дата-центры в космосе?

Jake [00:23:37]: It’s not “no data centers in space.” My hot take is that I think it is solvable. I’ve just never seen anybody solve it.

Jake [00:23:37]: Это не «нет дата-центрам в космосе». Моё горячее мнение — что это решаемо. Я просто никогда не видел, чтобы кто-то это решил.

Swyx [00:23:49]: You said, “How are you going to dissipate that much heat in a vacuum?” You’re making a physics claim.

Swyx [00:23:49]: Ты сказал: «Как вы собираетесь рассеивать столько тепла в вакууме?» Это физическое утверждение.

Jake [00:23:55]: I haven’t seen anybody prove how you’re going to dissipate that much heat in a vacuum. It doesn’t mean it’s not possible. It just means nobody has brought it up yet.

Jake [00:23:55]: Я не видел, чтобы кто-то доказал, как собирается рассеивать столько тепла в вакууме. Это не значит, что невозможно. Это значит, что никто пока этого не предъявил.

Swyx [00:24:05]: Astrophage.

Swyx [00:24:05]: Astrophage.

Jake [00:24:06]: I don’t know what that is.

Jake [00:24:06]: Не знаю, что это.

Swyx [00:24:07]: The Martian thing. Okay, you’re very logical.

Swyx [00:24:07]: Из «Марсианина». Ладно, ты очень логичный.

Jake [00:24:09]: It could work. A lot of people are putting the cart before the horse. They say, “We’re going to put data centers in space.” Okay, but how? “We have time to figure it out.” It’s like in The Martian where they ask how they’re going to intercept something and say, “We’ll figure it out.”

Jake [00:24:09]: Может сработать. Многие ставят телегу впереди лошади. Говорят: «Поставим дата-центры в космос». Ок, но как? «Будет время разобраться». Это как в «Марсианине», где спрашивают, как они перехватят что-то, и говорят: «Разберёмся».

Swyx [00:24:36]: Making a bet on human invention is weird because you blind trust that it can be solved. But with physics, there are first-principles bounds you can put on it. Maybe not. Maybe you’re asking to travel time or break a fundamental thermodynamic law.

Swyx [00:24:36]: Ставка на человеческую изобретательность — странная штука, потому что ты слепо веришь, что это решаемо. Но с физикой есть first-principles границы, которые можно поставить. А может и нет. Может, ты просишь путешествовать во времени или нарушить фундаментальный закон термодинамики.

Jake [00:24:57]: I don’t know how VCs do this either. How do you know what’s not possible and a grift versus what’s possible but sounds completely insane? “We’re going to put data centers in space.” Coin flip as to which it is, and I guess you’ll know in 10 years. That’s one cycle.

Jake [00:24:57]: Не понимаю, как VC это делают. Как ты понимаешь, что невозможно и грифт, а что возможно, но звучит абсолютно безумно? «Мы поставим дата-центры в космос». Подбрасывание монетки, что из этого правда, и через 10 лет узнаешь. Это один цикл.

What Agents Need: Versioning, Observability, and 1,000x Scale

Что нужно агентам: версионирование, наблюдаемость и масштаб 1000x

Swyx [00:25:23]: Moving back to agents. The branching, fast spin-up, and orchestration you do feels like pre-work that happened to be exactly what agents want. What do agents want differently than humans?

Swyx [00:25:23]: Возвращаясь к агентам. Ветвление, быстрый спин-ап и оркестрация, которые вы делаете, выглядят как preparatory work, оказавшаяся ровно тем, что хотят агенты. Чего агенты хотят иначе, чем люди?

Jake [00:25:37]: They want the ability to version things. It’s not that different; it materializes slightly differently. Agents want a way to test changes incrementally. Engineers have feature flags. Is there a reason agents can’t use feature flags? I don’t think so.

Jake [00:25:37]: Они хотят возможность версионировать вещи. Это не сильно отличается; материализуется чуть иначе. Агенты хотят способ инкрементально тестировать изменения. У инженеров есть feature flags. Есть ли причина, почему агенты не могут использовать feature flags? Не думаю.

Jake [00:25:54]: They want version control. Can we use Git or not Git? That one is up in the air. I think something outside Git will emerge for how we version these things over time. They need observability. You need to query what happened, when it happened, which steps failed, traces, logs, metrics, and all the rest. They need network, compute, and storage. They need to write files, save files, iterate on files, and snapshot file systems.

Jake [00:25:54]: Им нужен контроль версий. Можно использовать Git или не Git? Это под вопросом. Думаю, что-то вне Git появится для того, как мы версионируем эти вещи со временем. Им нужна наблюдаемость. Нужно опрашивать, что произошло, когда, какие шаги упали, трейсы, логи, метрики и прочее. Им нужны сеть, compute и хранилище. Им нужно писать файлы, сохранять файлы, итерировать по файлам, делать снапшоты файловых систем.

Jake [00:26:25]: A lot of what humans needed is in line with what agents need. Branching and forking are not different; we’re just moving 1,000 times quicker. It can look like you need something massively different, but what you need is something massively better than what existed. You need orchestration massively better than Kubernetes. You need networking probably better than Envoy. It goes all the way down the stack.

Jake [00:26:25]: Многое из того, что нужно людям, совпадает с тем, что нужно агентам. Ветвление и форкинг не отличаются; просто мы движемся в 1000 раз быстрее. Может казаться, что нужно что-то массово другое, но нужно что-то массово лучше существующего. Нужна оркестрация массово лучше Kubernetes. Нужна сеть, вероятно, лучше Envoy. И так весь стек насквозь.

Jake [00:26:55]: If the workload profile doesn’t change so much as it gets massively compressed because you need thousands of these things, what assumptions change? etcd is going to melt. You need to replace it with something. You can go all the way down the stack and say, “That part has to change, that part has to change, and that part has to change.”

Jake [00:26:55]: Если профиль нагрузки не столько меняется, сколько массово сжимается, потому что нужны тысячи таких штук — какие предположения меняются? etcd расплавится. Надо заменить чем-то другим. Можно пройтись по всему стеку и сказать: «Эта часть должна измениться, эта часть должна измениться, и эта часть должна измениться».

Jake [00:27:19]: The interesting thing about the super-exponential curve is that you have to build systems where you can rip out those parts at any time because a new bottleneck might emerge. You get good at parallel agents, and a different part of the system breaks. So it’s similar to what humans needed, but at 1,000x scale.

Jake [00:27:19]: Интересная штука в супер-экспоненциальной кривой: нужно строить системы, где можно выдрать эти части в любой момент, потому что может появиться новое бутылочное горлышко. Ты хорошо разобрался с параллельными агентами — ломается другая часть системы. Так что похоже на то, что нужно людям, но в масштабе 1000x.

Jake [00:27:55]: How do you do code review in the age of agents?

Jake [00:27:55]: Как делать code review в эпоху агентов?

Swyx [00:28:00]: You throw more agents at it.

Swyx [00:28:00]: Бросать больше агентов.

Jake [00:28:01]: You don’t. But then who reviews for CVEs and all these other things?

Jake [00:28:01]: Не сделаешь. А кто тогда ревьюит CVE и прочее?

Swyx [00:28:07]: More agents.

Swyx [00:28:07]: Больше агентов.

Jake [00:28:08]: And that’s how we hit the inference wall. You can continually throw agents at the problem, but I think there’s a limit to the number of agents you can throw at a problem.

Jake [00:28:08]: И вот так упираемся в стену inference. Можно непрерывно бросать агентов на проблему, но, думаю, есть предел количеству агентов, которых можно бросить на проблему.

CLI, Agent Handles, and Closing the Loop

CLI, ручки для агентов и замыкание цикла

Swyx [00:28:24]: You already had a CLI before it was cool. How is the shape of what you’re exposing changing, if at all?

Swyx [00:28:24]: У тебя уже был CLI, ещё до того, как это стало модно. Как меняется форма того, что вы экспонируете, если вообще меняется?

Jake [00:28:28]: CLIs have always been cool. The CLI changes because we think about how to give Claude, Codex, ChatGPT, or any model a handhold.

Jake [00:28:28]: CLI всегда были классными. CLI меняется, потому что мы думаем о том, как дать Claude, Codex, ChatGPT или любой модели опору.

Jake [00:28:50]: A CLI is a single command: deploy, get logs, and so on. Things that were prohibitively annoying to humans are not annoying to agents. They’re nice. If I handed you a CLI with 40 arguments and 600 flags, you’d think, “I’m never going to use all of this.” But if you hand it to an agent, it says, “This is excellent. I have so many handles to work with.”

Jake [00:28:50]: CLI — это одна команда: deploy, get logs и так далее. Вещи, которые были запретительно раздражающими для людей, для агентов не раздражающие. Они приятные. Если я тебе вручу CLI с 40 аргументами и 600 флагами, ты подумаешь: «Я никогда всё это не использую». Но если вручишь агенту, он скажет: «Это превосходно. У меня столько ручек для работы».

Jake [00:29:24]: If you’re going to expose things to agents that way, you want as many handles as possible where they can get information, query dynamic information, and close the loop quickly. Most problems right now are about how to close the loop as quickly as possible. Where does the agent get stuck, and how can you remove that?

Jake [00:29:24]: Если ты собираешься экспонировать вещи агентам таким образом, хочется как можно больше ручек, где они могут получить информацию, опросить динамическую информацию и быстро замкнуть цикл. Большинство проблем сейчас в том, как замкнуть цикл максимально быстро. Где агент застревает и как это убрать?

Jake [00:29:49]: Telemetry is important. If you can tell where the agent gets stuck from the CLI and say, “12% of people deviate from the happy path because of this, and now I add this argument and drive it down to 2%,” you massively increase the rate of loop closure.

Jake [00:29:49]: Телеметрия важна. Если ты можешь по CLI понять, где агент застревает, и сказать: «12% людей отклоняются от happy path из-за этого, теперь добавлю этот аргумент и снизю до 2%», — ты массово увеличиваешь скорость замыкания цикла.

Jake [00:30:03]: That’s how we think about not just the CLI, but every point in the dashboard. It’s a user journey: I hear about Railway. I get something deployed. I get my first green build or aha moment. I see an endpoint, logs, whatever. Then I iterate. The iteration loop is indefinite. The user wants to deploy a new thing, a Postgres instance, change code, and keep iterating.

Jake [00:30:03]: Так мы думаем не только о CLI, но и о каждой точке в дашборде. Это пользовательский путь: я слышу о Railway. Я что-то деплою. Я получаю свой первый зелёный билд или ага-момент. Я вижу эндпоинт, логи, что угодно. Потом итерирую. Цикл итерации бесконечен. Пользователь хочет задеплоить новую штуку, инстанс Postgres, изменить код, продолжать итерировать.

Jake [00:30:36]: If you focus on the iteration loops and what’s blocking them from closing quickly, one thing we say internally is: you never want to be waiting on compute anymore. You always want to be waiting on intelligence. If you’re waiting on compute, there’s a bottleneck that needs to be destroyed because eventually that bottleneck becomes so large that another workflow emerges to change it.

Jake [00:30:36]: Если фокусируешься на итерационных циклах и на том, что блокирует их быстрое замыкание, — одна вещь, которую мы говорим внутри: ты больше никогда не хочешь ждать compute. Ты всегда хочешь ждать интеллект. Если ждёшь compute, есть бутылочное горлышко, которое надо уничтожить, потому что в конце концов оно становится таким большим, что появляется другой workflow, чтобы его поменять.

Jake [00:31:04]: We’ve built a product where you push code, build it, and so on. But I fundamentally believe the push-pull loop is going away. We’ll get to a point where you make a small change in production, that change is versioned across your infrastructure, you’re working alongside copy-on-write versions of your database and infrastructure, and then you merge it in and it’s instantaneously live. That’s the holy grail of loops. The push-pull-rebuild thing is a point of friction that we’re removing entirely.

Jake [00:31:04]: Мы построили продукт, где ты пушишь код, билдишь его и так далее. Но я фундаментально верю, что push-pull-цикл уходит. Мы дойдём до точки, где ты делаешь маленькое изменение в продакшне, это изменение версионируется в твоей инфраструктуре, ты работаешь рядом с copy-on-write версиями своей базы и инфраструктуры, потом мержишь — и оно мгновенно живое. Это святой Грааль циклов. Push-pull-rebuild — это точка трения, которую мы убираем полностью.

Canvas as Output: Dashboards, Context Anchors, and Hyperstructures

Canvas как вывод: дашборды, якоря контекста и гиперструктуры

Swyx [00:31:43]: It’s incredibly fast. If anyone hasn’t tried it, that fast feedback is great. My hot take is that Railway was famous for its canvas, which visualizes your infrastructure and lets you manipulate it visually. But that was for humans. For the next phase of growth, Railway CLI is more important than canvas.

Swyx [00:31:43]: Это невероятно быстро. Если кто-то не пробовал — этот быстрый фидбэк прекрасен. Моё горячее мнение: Railway была знаменита своим canvas, который визуализирует инфраструктуру и позволяет манипулировать ей визуально. Но это было для людей. Для следующей фазы роста Railway CLI важнее canvas.

Jake [00:32:05]: The canvas is funny because it’s a mechanism to show changes over time. You’re right that previously we used it a lot as an input. Moving forward, its goal is more like an output. You would go to the canvas, make changes, see them, and watch your infrastructure evolve. Now agents have access to the CLI and can make those changes. So the canvas becomes an output: what information does the human need at this moment to make suitable decisions about control requests? Do I approve this or not?

Jake [00:32:05]: Canvas забавный, потому что это механизм показа изменений во времени. Ты прав, что раньше мы много использовали его как input. В будущем его задача больше как output. Ты идёшь в canvas, делаешь изменения, видишь их и наблюдаешь, как эволюционирует твоя инфраструктура. Теперь у агентов есть доступ к CLI и они могут делать эти изменения. Так что canvas становится output’ом: какая информация нужна человеку в этот момент, чтобы принять подходящее решение о запросах контроля? Одобряю это или нет?

Jake [00:32:57]: It also has to be an anchor for your context, a port in the storm. Think of it like layers in a file system. You start with a project, then drill down into services, then into a function or code, because you want to represent the entire thing not just in your head, but in the canvas. Other people can share that representation, think on the same wavelength, and move quickly.

Jake [00:32:57]: Он также должен быть якорем для твоего контекста, портом в шторме. Думай о нём как о слоях в файловой системе. Ты начинаешь с проекта, потом дрейфуешь в сервисы, потом в функцию или код, потому что хочешь представить всю штуку не только в голове, но и в canvas. Другие люди могут разделить это представление, думать на одной волне и быстро двигаться.

Jake [00:33:33]: A lot of organizations get in trouble as they scale because all the context lives in someone’s head. “How does this microservice work?” “I have no idea; go ask this person.” Then you have whole categories of products built around context discovery. A lot of that melts away if you have a solid hierarchy and can infinitely nest services, code, context, and everything else all the way down. That’s what lets you build these structures over time.

Jake [00:33:33]: Многие организации попадают в беду при масштабировании, потому что весь контекст живёт в чьей-то голове. «Как работает этот микросервис?» «Понятия не имею, спроси этого человека». Потом появляются целые категории продуктов вокруг обнаружения контекста. Многое из этого тает, если у тебя есть надёжная иерархия и ты можешь бесконечно вкладывать сервисы, код, контекст и всё остальное насквозь. Это и позволяет строить эти структуры со временем.

Jake [00:34:18]: It’s also what lets us build what I’ve called hyperstructures: things that are way bigger. You look at the Golden Gate Bridge and ask, “How did we build that?” There’s a meme that we lost the technology. To some extent, yes, because the coordination that built those things evolved and changed. We lost some of the art of building structure as we jammed everything into Slack.

Jake [00:34:18]: Это также то, что позволяет нам строить то, что я называл гиперструктурами: вещи, которые гораздо больше. Смотришь на мост Golden Gate и спрашиваешь: «Как мы его построили?» Есть мем, что мы потеряли технологии. В какой-то степени да, потому что координация, построившая эти штуки, эволюционировала и изменилась. Мы потеряли часть искусства построения структуры, когда впихнули всё в Slack.

Swyx [00:34:52]: But you jam everything in Discord.

Swyx [00:34:52]: Но ты впихиваешь всё в Discord.

Jake [00:34:53]: Same point. It doesn’t matter. It’s message passing and interrupts, message passing and interrupts.

Jake [00:34:53]: Та же история. Не важно. Это передача сообщений и прерывания, передача сообщений и прерывания.

Swyx [00:35:00]: So you’re arguing there should be something better and more structured than Slack?

Swyx [00:35:00]: Так ты говоришь, что должно быть что-то лучше и структурированнее Slack?

Jake [00:35:04]: Yeah. For sure. I think Slack is awful, and Discord is awful too.

Jake [00:35:04]: Да. Точно. Думаю, Slack ужасен, и Discord тоже ужасен.

Central Station: Context Routing, Support, and Incident Clusters

Central Station: маршрутизация контекста, поддержка и кластеры инцидентов

Swyx [00:35:09]: This is the equivalent of my mom test. What have you done that has your solution to this?

Swyx [00:35:09]: Это эквивалент моего теста для мамы. Что вы сделали в качестве своего решения?

Jake [00:35:15]: Internally, we’ve built a tool called Central Station that aggregates all the context from our users. Every piece of feedback, every customer support item, everything gets aggregated into clusters. If an incident is brewing, we can determine how many users are affected and break off a discussion based on that.

Jake [00:35:15]: Внутри мы построили инструмент Central Station, который агрегирует весь контекст от наших пользователей. Каждая часть фидбэка, каждое обращение в саппорт — всё агрегируется в кластеры. Если назревает инцидент, мы можем определить, сколько пользователей затронуто, и отколоть обсуждение на этой основе.

Jake [00:35:40]: That is more helpful than long-running channels where you’re trying to decide which channel to put something in. If you can dynamically aggregate information and dynamically route it to the right person based on context, it works better. We know internally that these four people are close to networking. If we see a networking thing, we can drill it down to those four people. If it’s with this part, we can look at the commits. This is no longer a manual process internally.

Jake [00:35:40]: Это полезнее, чем долгоживущие каналы, где ты пытаешься решить, в какой канал положить что-то. Если можешь динамически агрегировать информацию и динамически маршрутизировать её к правильному человеку по контексту — работает лучше. Мы знаем внутри, что эти четверо людей близки к сети. Если видим что-то про сеть, можем сразу направить к ним. Если это другая часть, можем посмотреть коммиты. Это больше не ручной процесс внутри.

Jake [00:36:13]: If you go to station or help.railway.com, that’s why we built it. We wanted to scale with a massive amount of leverage by aggregating feedback.

Jake [00:36:13]: Если зайдёшь на station или help.railway.com — вот зачем мы это построили. Мы хотели масштабироваться с массовым плечом за счёт агрегации фидбэка.

Swyx [00:36:27]: This is built in-house?

Swyx [00:36:27]: Это построено самостоятельно?

Jake [00:36:28]: Yep.

Jake [00:36:28]: Ага.

Swyx [00:36:29]: I remember helping out on this one with Angelo in 2023. You scale a lot with a very small team.

Swyx [00:36:29]: Помню, помогал тут с Angelo в 2023. Вы много масштабируетесь очень маленькой командой.

Jake [00:36:38]: Yeah. We’re about 10 times bigger now.

Jake [00:36:38]: Да. Сейчас мы в 10 раз больше.

Swyx [00:36:40]: You have your full developer code here? Very cool.

Swyx [00:36:40]: У тебя тут полный код разработчика? Очень круто.

Jake [00:36:44]: If you go to railway.com/stats, we expose this as a pub-sub-able thing. It’s all real-time metrics. There’s a way to get it as JSON somewhere if you care.

Jake [00:36:44]: Если зайдёшь на railway.com/stats, мы экспонируем это как pub-sub-штуку. Это все realtime-метрики. Где-то есть способ получить это как JSON, если интересно.

Jake [00:37:01]: We’re big on trying to build everything in public and talk about what we’re working on. We’ve had issues in the past, and we’ll say, “Here’s how we’re fixing these things.” We’ve gotten compliments and flak for incident reports. We’re always trying to make them better and talk with people.

Jake [00:37:01]: Мы большие фанаты того, чтобы строить всё публично и говорить о том, над чем работаем. У нас были проблемы в прошлом, и мы говорили: «Вот как мы их исправляем». Получали комплименты и критику за incident-репорты. Мы всегда стараемся делать их лучше и общаться с людьми.

Incidents, Disclosure, and Progressive Rollouts

Инциденты, раскрытие и постепенные роллауты

Swyx [00:37:20]: You had a big one recently. I liked that it was scoped to 3,000. You presumably used Central Station. Talk through what happened and how you address it internally as a team.

Swyx [00:37:20]: У вас недавно был большой инцидент. Мне понравилось, что он был ограничен 3000 пользователями. Видимо, вы использовали Central Station. Расскажи, что случилось и как вы это решаете внутри команды.

Jake [00:37:38]: Internally, this one really sucked. It had to do with an upstream provider that didn’t do the behavior it said it documented, which is unfortunate given they wrote the RFC for how the behavior should work. We rolled those things out, and Central Station caught it initially when a couple users said caches weren’t invalidating. We turned it off immediately.

Jake [00:37:38]: Внутри этот реально отстойный. Он был связан с upstream-провайдером, который не делал того, что заявлено в его документации, что прискорбно — учитывая, что они и написали RFC о том, как поведение должно работать. Мы выкатили эти штуки, и Central Station поймал это сначала, когда пара пользователей сказала, что кеши не инвалидируются. Мы это сразу выключили.

Jake [00:38:03]: When you roll out to a large user base of three million people, you get a lot of disparate behaviors. We tested in staging and had tests, but we hit an edge case. We’ve hardened those systems, and now we can make that better. But it was a tough one.

Jake [00:38:03]: Когда раскатываешь на большую базу из трёх миллионов человек, получаешь много разнообразного поведения. Мы тестировали в staging, у нас были тесты, но мы попали в edge case. Мы укрепили эти системы, и теперь можем сделать лучше. Но это был тяжёлый случай.

Swyx [00:38:39]: I always wonder how private disclosure is supposed to work if people find an issue. Are they supposed to contact you first? When you run a platform, these things will happen. What channels should people pursue to quietly resolve it before it becomes a bigger incident?

Swyx [00:38:39]: Мне всегда интересно, как должно работать приватное раскрытие, если люди находят проблему. Им нужно сначала связаться с вами? Когда управляешь платформой, такие вещи случаются. По каким каналам люди должны идти, чтобы тихо разрулить, прежде чем это станет большим инцидентом?

Jake [00:38:59]: There’s responsible disclosure. We err on the side of over-disclosing and letting you know something is wrong versus having your provider gaslight you. We’ve erred on sharing those things more publicly, even if they impact a small subset of users. That’s a decision we’ve made internally. We have four values. One is honor. The honorable thing is to notify people to the widest degree at which they may have been affected or there was an issue, and then confront it head-on: why did it happen, what can we do better?

Jake [00:38:59]: Есть ответственное раскрытие. Мы склоняемся к избыточному раскрытию и оповещению о проблеме, нежели к тому, чтобы провайдер заставил тебя сомневаться в реальности. Мы склонились к публичному обсуждению этих штук, даже если они затрагивают небольшую часть пользователей. Это внутреннее решение. У нас четыре ценности. Одна из них — честь. Честный поступок — оповещать людей в максимально широком кругу затронутых или потенциально затронутых проблемой, а потом встречать её лицом к лицу: почему это произошло, что мы можем сделать лучше?

Swyx [00:39:45]: Not the whole user base. That’s because of incremental rollouts and other things?

Swyx [00:39:45]: Не всю базу пользователей. Это из-за инкрементальных роллаутов и прочего?

Jake [00:39:50]: Yeah. Progressive rollouts.

Jake [00:39:50]: Да. Постепенные роллауты.

Swyx [00:39:54]: That should be the norm at all large platforms.

Swyx [00:39:54]: Это должно быть нормой на всех крупных платформах.

Jake [00:39:58]: It should. A variety of companies do this. There’s the quote that Meta runs 10,000 different versions of Meta. To our earlier point about agents, they need the same thing. They need shadow traffic and all these other things. We’ve built so much ceremony around production being sacred that we need to make it trivially easy to test different behaviors in a safe environment. Then you can make mistakes in a safe environment.

Jake [00:39:58]: Должно. Многие компании так и делают. Есть цитата, что Meta запускает 10 000 разных версий Meta. К нашему более раннему пункту об агентах — им нужно то же самое. Им нужен shadow traffic и все остальное. Мы выстроили столько церемонии вокруг священного продакшна, что нам надо сделать тривиально простым тестировать разные поведения в безопасном окружении. Тогда можно делать ошибки в безопасном окружении.

Safe AI SRE: Customer Agents, Forked Environments, and Production Parity

Безопасный AI SRE: клиентские агенты, форкнутые окружения и паритет с продакшном

Alessio [00:40:30]: Do you see a world where these things get automatically caught, not necessarily by your agent, but by your customer’s agent? The cache invalidation issue seems easy to check if you know to look for it.

Alessio [00:40:30]: Видишь ли ты мир, где эти штуки автоматически отлавливаются — не обязательно твоим агентом, а агентом твоего клиента? Проблема с инвалидацией кеша кажется простой для проверки, если знаешь, что искать.

Jake [00:40:44]: It’s hard because to determine it, we almost need to hook into your observability infrastructure. That’s why we have the template loop on the platform: so you can roll things out progressively. You can roll out to Johnny Vibe Coder initially, or push a shard that someone consumes at their own leisure. Or you can roll it out over weeks: 0.1% of people, 1% of people, early adopters, then all the way up. That’s the non-deterministic version control we talked about earlier.

Jake [00:40:44]: Сложно, потому что чтобы определить, нам почти нужно подключиться к вашей observability-инфраструктуре. Вот почему у нас есть template-цикл на платформе — чтобы можно было постепенно раскатывать. Можно сначала раскатить на Johnny Vibe Coder или запушить шард, который кто-то потребляет в удобном для него темпе. Или раскатить за недели: 0.1% людей, 1% людей, early adopters, потом вплоть до конца. Это и есть тот недетерминированный version control, о котором мы говорили ранее.

Jake [00:41:30]: I believe that’s where most things should go, because most companies end up building staged rollout systems in-house. It’s the same thing built again and again at every company. There’s a massive opportunity to consolidate developer debt.

Jake [00:41:30]: Я считаю, что туда и должны идти большинство вещей, потому что большинство компаний в итоге строят системы поэтапной раскатки своими силами. Это одна и та же штука, перестроенная снова и снова в каждой компании. Огромная возможность консолидировать долг разработчиков.

Alessio [00:41:45]: You should have a free tier. Model providers give free tokens if you let them use the data. You could give free compute if someone is the number-one shard that goes out and lets you plug into their observability.

Alessio [00:41:45]: У вас должен быть free tier. Провайдеры моделей дают бесплатные токены, если разрешишь им использовать данные. Можно давать бесплатный compute, если кто-то — шард номер один, который выкатывается и позволяет вам подключиться к их observability.

Jake [00:41:55]: We do that. That’s why we talked about the impact on 3,000 people. We start with lower-impact people. Larger companies on the platform are last to receive those rollouts so they have a version of the platform that’s deeply stable.

Jake [00:41:55]: Мы так делаем. Поэтому говорили о влиянии на 3000 человек. Мы начинаем с людей с меньшим импактом. Более крупные компании на платформе получают эти раскатки последними, чтобы у них была глубоко стабильная версия платформы.

Alessio [00:42:16]: I have three services, so I’m sure I get the first rollout. You can nuke my thing at any time. There are all these SRE agent companies. Observability people also want agents that fix upstream problems. You have your own agent in the canvas now. How do you see that playing out?

Alessio [00:42:16]: У меня три сервиса, так что я уверен, что получаю первую раскатку. Можете в любой момент снести мою штуку. Есть все эти SRE-агентские компании. Observability-люди тоже хотят агентов, которые чинят upstream-проблемы. У вас сейчас свой агент в canvas. Как ты видишь это развитие?

Jake [00:42:39]: It’s the stacking entropy problem. If you don’t have primitives to make iteration in production safe, it becomes difficult. If you’re an observability provider saying, “Here’s the fix to this error,” assume 80% are good and make sense. But in the last 20% long tail of complex issues, if you let somebody stamp it, you create an opportunity for an incident.

Jake [00:42:39]: Это проблема накопления энтропии. Если у тебя нет примитивов для безопасной итерации в продакшне, это становится сложно. Если ты observability-провайдер и говоришь: «Вот фикс этой ошибки», — допустим, 80% хороши и имеют смысл. Но в оставшихся 20% длинного хвоста сложных проблем, если позволишь кому-то это применять, ты создаёшь возможность для инцидента.

Jake [00:43:08]: That’s why forked environments are important. People have staging, but it always drifts from production. You need primitives, workflows, and experience built first-party on the platform so you can fork any service at any point in time.

Jake [00:43:08]: Поэтому форкнутые окружения важны. У людей есть staging, но он всегда дрейфует от продакшна. Нужны примитивы, workflow и опыт, построенные первой стороной на платформе, чтобы можно было форкнуть любой сервис в любой момент.

Jake [00:43:33]: I think of the canvas as a sheet of transparency paper. The agent is a little guy you push up into the canvas. It should say, “I need to copy that service and that service so I can test these two things.” It gets a read-only copy of production. Anything that’s PII gets marked as a transform when we clone the database, create a copy-on-write version, or read from it. Then the agent makes changes and asks, “Does this actually work?” as close to production as possible.

Jake [00:43:33]: Я думаю о canvas как о листе прозрачной бумаги. Агент — это маленький парень, которого ты заталкиваешь наверх в canvas. Он должен сказать: «Мне надо скопировать этот сервис и этот сервис, чтобы протестировать эти две вещи». Он получает read-only копию продакшна. Всё, что является PII, помечается как трансформация при клонировании базы — создаём copy-on-write версию или читаем из неё. Потом агент делает изменения и спрашивает: «Это реально работает?» — как можно ближе к продакшну.

Jake [00:44:22]: That’s how close you have to be, or you get massive drift. The system becomes unstable. You see this with massive systems built on Docker for local, Kubernetes for production, and a specific thing for something else. That complexity slows developers and becomes unstable at scale, making it hard to iterate. We want to compress that way down and say, “As close to prod as possible is where we want to be.”

Jake [00:44:22]: Вот насколько близко надо быть, иначе будет массовый дрейф. Система становится нестабильной. Это видно в массивных системах, построенных на Docker для локалки, Kubernetes для продакшна и какой-то отдельной штуке для чего-то ещё. Эта сложность замедляет разработчиков и становится нестабильной на масштабе, делая итерацию сложной. Мы хотим сильно это сжать и сказать: «Максимально близко к проду — это туда, куда мы хотим».

From AISRE Skeptic to Agent Believer

От скептика AISRE к верующему в агентов

Swyx [00:45:00]: I was texting Erica for questions, and she says you were originally not a believer in AISRE. Have you come around on it?

Swyx [00:45:00]: Я списывался с Erica насчёт вопросов, и она говорит, что изначально ты не был верующим в AISRE. Передумал?

Jake [00:45:10]: I flipped, but I’m still not a believer in AISRE if you don’t have the primitives to make it safe. If you unleash AISRE on production infrastructure without safe primitives for copying volumes and making sure things are fine, it’s going to nuke your production database. It’s not a matter of if, but when. I’m a big believer in making those loops safe.

Jake [00:45:10]: Я перевернулся, но всё ещё не верующий в AISRE, если нет примитивов, чтобы сделать его безопасным. Если выпустишь AISRE на продакшн-инфраструктуру без безопасных примитивов для копирования томов и проверки, что всё ок, он снесёт твою продакшн-базу. Это не вопрос если, а когда. Я большой верующий в то, чтобы делать эти циклы безопасными.

Jake [00:45:33]: I was a deep AI skeptic until 2023. In 2024, I thought, “Maybe I can roughly make this thing do it.” In 2025, I thought, “Now I can hold this.” Over winter break, everybody came back saying, “It’s almost impossible to hold this.”

Jake [00:45:33]: Я был глубоким AI-скептиком до 2023. В 2024 я подумал: «Может, я смогу примерно заставить эту штуку это сделать». В 2025 — «теперь я могу её удержать». Зимой все вернулись говоря: «Удержать практически невозможно».

Swyx [00:46:01]: Did you see this on the Claude docs? CloudBot? OpenCloud?

Swyx [00:46:01]: Видел ли ты это на Claude docs? CloudBot? OpenCloud?

Jake [00:46:06]: It’s gotten to a point where it’s harder to hold it wrong than to hold it right. There’s a scene in Avengers where Vision picks up Thor’s hammer and says it’s terribly well-balanced. It self-balances and works well. I’m a deep believer at this point that this will be the dominant species: assembly, C, C++, JavaScript, words.

Jake [00:46:06]: Дошло до момента, когда сложнее держать неправильно, чем правильно. Есть сцена в «Мстителях», где Vision поднимает молот Тора и говорит, что он отлично сбалансирован. Самобалансируется и работает хорошо. Я в этой точке глубокий верующий, что это будет доминирующий вид: ассемблер, C, C++, JavaScript, слова.

Swyx [00:46:35]: It feels like a big jump.

Swyx [00:46:35]: Это кажется большим скачком.

Jake [00:46:37]: It is. But it’s not like you abandon CPU-based discrete logic and move straight to fuzzy logic. You need both. Your skills should call code or applications or some static structure. You can use skills to distill what the procedure should be or how the code should act.

Jake [00:46:37]: Так и есть. Но это не значит, что отказываешься от CPU-based дискретной логики и сразу переходишь к нечёткой логике. Нужно и то, и другое. Твои навыки должны вызывать код, приложения или какую-то статическую структуру. Можно использовать навыки, чтобы дистиллировать, какой должна быть процедура или как должен вести себя код.

Jake [00:47:02]: I’m coming to a thesis: you need three points. You need a clear spec defining the system, the code, and the tests. When you say it out loud, if you’ve been in engineering long enough, you’re like, “Of course. That’s an RFC, tests, and code.” But they all matter. Having them together lets them reinforce each other: the spec and tests match, but the code doesn’t, so reconcile it. Or the tests and code match but the spec doesn’t, so reconcile that. That’s the iteration loop.

Jake [00:47:02]: Я прихожу к тезису: нужны три точки. Нужна чёткая спецификация, описывающая систему, код и тесты. Когда говоришь это вслух — если ты достаточно долго в инжиниринге — думаешь: «Конечно. Это RFC, тесты и код». Но они все важны. Когда они вместе, они подкрепляют друг друга: спека и тесты совпадают, но код нет — примиряй. Или тесты и код совпадают, но спека нет — примиряй это. Это и есть цикл итерации.

Jake [00:47:41]: That’s why you’re seeing people talk about software factories, docs, and reconciliation. Some of that is architectural astronomy if you don’t implement it, but that loop is where most things will end up.

Jake [00:47:41]: Поэтому видишь, как люди говорят о software factories, документации и согласовании. Часть этого — архитектурная астрономия, если не реализуешь, но этот цикл — туда, куда придёт большинство вещей.

Swyx [00:48:07]: For listeners, we’ve been talking about this on the pod for three years: the holy trinity of specs and tests. Itamar Friedman from Qodo is the reference if people want to look it up.

Swyx [00:48:07]: Для слушателей: мы говорим об этом в подкасте три года — святая троица спецификаций и тестов. Itamar Friedman из Qodo — референс, если хотите посмотреть.

Self-Modifying Infrastructure and the End of Push-Pull-Rebuild

Самомодифицирующаяся инфраструктура и конец push-pull-rebuild

Swyx [00:48:18]: One thing I want to mention on the OpenCloud idea is self-modification. I don’t know how Railway would support it, but I have my OpenClaw, and I just tell it it has the Railway CLI and can do whatever. In theory, whatever capabilities or new infra it needs, it can call the Railway CLI, provision it, and add it to itself. The agent can modify its own infra.

Swyx [00:48:18]: Хочу упомянуть про идею OpenCloud — самомодификацию. Не знаю, как Railway будет это поддерживать, но у меня есть мой OpenClaw, и я просто говорю ему, что у него есть Railway CLI, и он может делать что угодно. В теории, какие бы возможности или новая инфра ему ни понадобились, он может вызвать Railway CLI, поднять и добавить к себе. Агент может модифицировать собственную инфру.

Jake [00:48:45]: It’s nuts. I have a loop set up where you put the Railway CLI on top of something that runs on Railway. You’re authenticated as whatever the current box is, and you can make any changes to it. Then you call Railway deploy, and it deploys itself.

Jake [00:48:45]: Это безумно. У меня настроен цикл, где ты ставишь Railway CLI поверх чего-то, работающего на Railway. Ты аутентифицирован как текущий box и можешь вносить в него любые изменения. Потом вызываешь railway deploy, и он деплоит сам себя.

Jake [00:49:04]: It’s like: “I need to spin up this instance of this environment. I already exist in this environment. Excellent, I have access to a Postgres instance now.” That’s where we want to go with agentic, self-replicating infrastructure. That’s your loop: iterate in production. You continue making changes. If it works, merge it upstream. If it doesn’t, throw it away.

Jake [00:49:04]: Это как: «Мне надо поднять этот инстанс этого окружения. Я уже существую в этом окружении. Прекрасно, у меня теперь есть доступ к инстансу Postgres». Туда мы и хотим идти с агентской самореплицирующейся инфраструктурой. Это и есть твой цикл: итерируй в продакшне. Продолжаешь делать изменения. Если работает, мержь upstream. Если нет — выбрасывай.

Jake [00:49:37]: How do you make throwaway copies trivial to spin up and super cheap? The era of “I have an AWS instance with four vCPU and 16 gigs of RAM” is going to get destroyed. If you do that for agents, you need a thousand of those machines. It’s prohibitively expensive compared with what we’ve spent a ton of time figuring out: the atomic unit of deploy, whether you call it isolates, sandboxes, or something else. Only pay for what you use, spin up instantaneously, and close the loop as quickly as possible.

Jake [00:49:37]: Как сделать тривиальным и супердешёвым создание одноразовых копий? Эра «у меня AWS-инстанс с 4 vCPU и 16 гигами RAM» будет уничтожена. Если ты так делаешь для агентов, тебе нужна тысяча таких машин. Это запретительно дорого по сравнению с тем, над чем мы потратили кучу времени: атомарной единицей деплоя, называй её isolates, sandboxes или как-то ещё. Платишь только за то, что используешь, поднимаешь мгновенно и замыкаешь цикл максимально быстро.

Jake [00:50:15]: If the system can self-replicate safely and say, “This is my environment, I’m making these changes,” it can come back with, “Does this look good? This is a new state of infrastructure given this prompt. I think I’ve solved it.” Then you go back and say, “Actually, it looks different.” It does the loop again. Then you say, “Cool. Apply.”

Jake [00:50:15]: Если система может безопасно реплицироваться и сказать: «Это моё окружение, я делаю эти изменения», она может вернуться с «Норм выглядит? Это новое состояние инфраструктуры с учётом этого промпта. Думаю, я её решил». Потом ты говоришь: «На самом деле выглядит иначе». Цикл снова. Потом ты говоришь: «Круто. Применяй».

Swyx [00:50:38]: That’s retroactively obvious, which is the most useful kind. Any other comments on agent deployment on Railway?

Swyx [00:50:38]: Это ретроспективно очевидно, что является самым полезным видом очевидности. Ещё комментарии про деплой агентов на Railway?

Jake [00:50:51]: It’s getting better every day. I’m on X or Twitter. You can always yell at me about the parts not working as well as they should, because plenty of things should work way better.

Jake [00:50:51]: С каждым днём становится лучше. Я в X или Twitter. Можете всегда орать на меня про те части, которые работают не так хорошо, как должны, — много чего должно работать намного лучше.

The New Serverless: Stateful, Long-Running, Pay-for-What-You-Use Linux

Новый serverless: stateful, долгоиграющий, pay-for-what-you-use Linux

Swyx [00:51:04]: At this stage, when people want massively or embarrassingly parallel compute, they usually talk serverless. I feel like there’s a new serverless compared to the previous five years of serverless. You’re in that new bucket. Do you have comparisons or philosophical differences you want to call out?

Swyx [00:51:04]: На этом этапе, когда людям нужен массивный или embarrassingly parallel compute, они обычно говорят про serverless. Чувствую, есть новый serverless по сравнению с предыдущими пятью годами serverless. Вы в этом новом ведре. Есть ли сравнения или философские отличия, которые ты хочешь обозначить?

Jake [00:51:31]: It’s somewhere in between. It’s the ability to run stateful, long-running workflows or executions.

Jake [00:51:31]: Это где-то посередине. Возможность запускать stateful, долгоживущие workflow или executions.

Swyx [00:51:42]: Vercel has Fluid Compute, Cloudflare has some container thing, Google has App Runner and others.

Swyx [00:51:42]: У Vercel есть Fluid Compute, у Cloudflare какая-то контейнерная штука, у Google App Runner и другие.

Jake [00:51:55]: That’s where everything is roughly going, and it’s why we’ve been working on this for six years. We believe users need access to a computer: a box that speaks Linux. They need to deploy what they want. Other systems change the surface area of what you can build. For us, users need a computer and need to deploy anything they truly want. That’s why we’ve focused on the primitives: network, compute, storage. If we give you those and expose them so you can run things indefinitely, that’s where we believe it’s going.

Jake [00:51:55]: Туда примерно всё и идёт, и поэтому мы работаем над этим шесть лет. Мы считаем, что пользователям нужен доступ к компьютеру: коробке, говорящей на Linux. Им нужно деплоить, что они хотят. Другие системы меняют поверхность того, что можно построить. Для нас пользователям нужен компьютер и возможность задеплоить что угодно. Поэтому мы фокусируемся на примитивах: сеть, compute, хранилище. Если мы дадим эти и экспонируем так, чтобы ты мог запускать вещи бесконечно, — туда, мы считаем, всё и движется.

Jake [00:52:43]: Twitter has no nuance, so everyone says “servers” or “serverless.” It’s always somewhere in the middle: I want to run it for a long time, but I don’t want to provision the resource statically or pay for things I’m not using. That’s been our thesis from day one: pay only for what you use, run it indefinitely, and it is full Linux.

Jake [00:52:43]: У Twitter нет полутонов, поэтому все говорят «серверы» или «serverless». Это всегда где-то посередине: я хочу запускать долго, но не хочу резервировать ресурс статически или платить за то, что не использую. Это был наш тезис с первого дня: платить только за то, что используешь, запускать бесконечно, и это полноценный Linux.

Swyx [00:53:12]: That’s why I like the naming of Fluid. It’s fluid. Flexible.

Swyx [00:53:12]: Поэтому мне нравится название Fluid. Текучий. Гибкий.

Heroku, Focus, and Carrying the Torch Without Becoming the Past

Heroku, фокус и нести факел, не становясь прошлым

Swyx [00:53:18]: Another milestone is the Heroku official deprecation. You’re one of the presumptive new Herokus. “New Heroku” has been a category for as long as I’ve been in developer tooling. It’s finally happening. What was that like? Any behind-the-scenes of, “This is the moment”?

Swyx [00:53:18]: Ещё одна веха — официальный deprecation Heroku. Вы один из предполагаемых новых Heroku. «Новый Heroku» — это категория, сколько я в developer tooling. Это наконец произошло. Каково это было? Какие-то закулисные «вот этот момент»?

Jake [00:53:42]: You have people where you’re like, “You were running stuff on here? You, as this company?” It’s crazy that names you would know are running on it and now coming to us saying, “We want to move a lot of this off.”

Jake [00:53:42]: Есть люди, про которых думаешь: «Ты что, запускаешь это здесь? Ты, как компания?» Безумие, что названия, которые ты бы знал, запускаются на этом, и теперь приходят к нам со словами: «Мы хотим много чего отсюда перевезти».

Swyx [00:54:00]: Any behind-the-scenes on why Salesforce let Heroku stagnate?

Swyx [00:54:00]: Какие-то закулисные мысли о том, почему Salesforce дала Heroku загнить?

Jake [00:54:05]: I can only guess. It’s hard when it’s not your business. Salesforce’s business is to build a great CRM. That’s their focus. Then you acquire a compute business as an offshoot. A lot of early Meta people talk about focus. Boz has a write-up about how in the early days of Meta they had no money, so they were forced to focus. Then they turned on the money tree and had no reason not to split their focus.

Jake [00:54:05]: Могу только гадать. Сложно, когда это не твой бизнес. Бизнес Salesforce — построить отличный CRM. Это их фокус. А потом ты приобретаешь compute-бизнес как ответвление. Многие ранние сотрудники Meta говорят о фокусе. У Boz есть пост про то, как в ранние дни Meta у них не было денег, поэтому им приходилось фокусироваться. Потом включили денежное дерево, и не стало причины не дробить фокус.

Jake [00:54:52]: But that dilutes your product. You get offshoots where you ask, “Is this the focus of the business?” If it’s not core, it languishes. A lot of companies get in trouble when they split focus because they’re fighting a multi-front war, not just externally but internally for alignment. Where are we going? What are we doing? What is our purpose?

Jake [00:54:52]: Но это разбавляет продукт. Появляются ответвления, про которые спрашиваешь: «Это фокус бизнеса?» Если не основной — затухает. Многие компании попадают в беду, когда раздваивают фокус, потому что ведут многофронтовую войну, не только внешне, но и внутренне за выравнивание. Куда мы идём? Что мы делаем? Какова наша цель?

Jake [00:55:24]: If you’re Salesforce-built and mission-driven, you want to work on Salesforce. Heroku is off to the side. It’s not core to the business. Getting resources, budget, focus, and alignment internally becomes hard. It was a matter of time.

Jake [00:55:24]: Если ты Salesforce-built и mission-driven, ты хочешь работать над Salesforce. Heroku — сбоку. Не основной бизнес. Получить ресурсы, бюджет, фокус и внутреннее выравнивание становится сложно. Это был вопрос времени.

Swyx [00:56:06]: Kudos for them to call it out instead of leaving it unknown.

Swyx [00:56:06]: Респект за то, что заявили, а не оставили неизвестным.

Jake [00:56:12]: Their release was a little odd. They called it out, but they didn’t say they were shutting it down. Behind the scenes, I think they issued messages to people saying they should close accounts and that they were going to deprecate and remove things over time.

Jake [00:56:12]: Их анонс был странноват. Они заявили, но не сказали, что закрывают. Закулисно, кажется, они выпустили сообщения людям, что те должны закрывать аккаунты и что они будут постепенно депрекейтить и убирать вещи.

Jake [00:56:30]: It’s crazy because some of my first deployment experiences were on Heroku. You start with dragging things into an FTP server, then you try to get a deploy working, and then it’s Heroku. It was the on-ramp for us. But the wheel turns. New things emerge. We’re happy to carry the torch for a lot of that. But we don’t want to be the new Heroku. We want to be the way people build and deploy software, and ultimately the way people monetize software over time.

Jake [00:56:30]: Безумно, потому что мой первый опыт деплоя был на Heroku. Начинаешь с перетаскивания вещей в FTP-сервер, потом пытаешься завести деплой, и вот Heroku. Это был наш on-ramp. Но колесо крутится. Появляются новые штуки. Мы рады нести факел во многом из этого. Но мы не хотим быть новым Heroku. Мы хотим быть способом, которым люди строят и деплоят софт, и в конечном счёте — способом, которым люди монетизируют софт со временем.

Swyx [00:57:19]: It’s still a big crown to be the new Heroku. There are 50 companies that fought for that.

Swyx [00:57:19]: Это всё ещё большая корона — быть новым Heroku. 50 компаний боролись за неё.

Jake [00:57:23]: Everybody is holding some portion of it. We’re happy to support people and companies. The platform works differently. The game loop is similar, but we’ve been dogmatic about where these things are going: primitives, agents, fan-out. Some things fit; some workflows need to change. We have an approximation of Heroku pipelines with the environment system. It’s exciting. We’ve got a ton of people we can support, and it’s growing a lot.

Jake [00:57:23]: Каждый держит какую-то часть. Мы рады поддерживать людей и компании. Платформа работает иначе. Игровой цикл похож, но мы догматичны в том, куда эти штуки идут: примитивы, агенты, fan-out. Что-то подходит, какие-то workflow должны меняться. У нас есть аппроксимация Heroku pipelines с environment-системой. Это волнующе. У нас уйма людей, которых мы можем поддержать, и это сильно растёт.

Temporal, Workflow Engines, and State Machines

Temporal, workflow-движки и конечные автоматы

Swyx [00:58:12]: I have one more technical question about Temporal. I’ve sold my shares. You’re a power user and one of our earliest customers. I met you through Temporal. You built on Temporal. You have complaints. This may be the most neutral and informed conversation anyone will hear about Temporal without someone working at the company.

Swyx [00:58:12]: У меня ещё один технический вопрос про Temporal. Я продал свои акции. Ты power user и один из наших самых ранних клиентов. Я познакомился с тобой через Temporal. Ты строил на Temporal. У тебя есть жалобы. Это может быть самый нейтральный и информированный разговор о Temporal, который кто-либо услышит без участия сотрудника компании.

Jake [00:58:39]: That’s fair. I’ve used Temporal for almost 10 years because of Cadence at Uber.

Jake [00:58:39]: Справедливо. Я использую Temporal почти 10 лет — через Cadence в Uber.

Swyx [00:58:52]: Give people a sense of what Cadence was at Uber.

Swyx [00:58:52]: Дай людям представление, чем был Cadence в Uber.

Jake [00:58:57]: Cadence was the precursor to Temporal. It powers trip actions, rides, when you rent a Jump bike or scooter or car. You’re running workflows for a period of time and saying, “This ride will run indefinitely until it finishes.” You attach information: you paused in this zone, so add this charge to the bill. When you end the trip, the workflow is done. That experience was powered by Cadence at the time.

Jake [00:58:57]: Cadence был предшественником Temporal. Он питал trip actions, поездки — когда ты арендуешь Jump-байк, самокат или машину. Ты запускаешь workflow на какой-то период и говоришь: «Эта поездка будет идти, пока не закончится». Прикрепляешь информацию: ты остановился в этой зоне — добавь это начисление в счёт. Когда заканчиваешь поездку, workflow завершён. Этот опыт тогда питался Cadence.

Swyx [00:59:34]: I used to say it’s like programming the entire user journey top-down as one function.

Swyx [00:59:34]: Я раньше говорил, что это как программировать весь user journey сверху вниз одной функцией.

Jake [00:59:39]: It’s a powerful idea and important. It’s also important for the next phase of the agentic journey. You want an agent to do a specific task, be complete or incomplete on that task, and move on to the next thing. You need a way to manage workflows dynamically.

Jake [00:59:39]: Это мощная идея и важная. Она также важна для следующей фазы агентского пути. Хочется, чтобы агент сделал конкретную задачу, был complete или incomplete по этой задаче и перешёл к следующему. Нужен способ динамически управлять workflow.

Jake [00:59:59]: Temporal was always great in theory, and great when you got it working the way you wanted in production. But it required you to model the entire journey in your head. If you didn’t, you could cause issues where replaying the state of the workflow causes non-determinism.

Jake [00:59:59]: Temporal всегда был хорош в теории и хорош, когда заставлял его работать так, как тебе надо, в продакшне. Но он требовал держать весь путь в голове. Если не держал, можно было создать проблемы, где реплей состояния workflow вызывает недетерминизм.

Swyx [01:00:25]: Because it works on deterministic workflow history.

Swyx [01:00:25]: Потому что он работает на детерминированной истории workflow.

Jake [01:00:28]: Exactly. I describe it as a jet engine. If you know how to operate it and run it, it’s great. But you can’t hand it to people trying to build complicated things if they don’t have the whole state in their head.

Jake [01:00:28]: Точно. Я описываю это как реактивный двигатель. Если ты знаешь, как его эксплуатировать и запускать, — отлично. Но нельзя выдавать его людям, пытающимся строить сложные вещи, если у них нет всего состояния в голове.

Jake [01:00:48]: We run our whole deployment pipeline on top of it. That’s a reasonably complicated workflow: pre-commit hooks, signaling, queuing, and all the rest. We ran into the same thing at Uber. As you express a large workflow, it gets more complicated, with more states in the state machine that you have to map back to the workflow.

Jake [01:00:48]: Мы крутим весь наш deployment pipeline поверх него. Это разумно сложный workflow: pre-commit-хуки, signaling, queueing и прочее. Мы наткнулись на то же самое в Uber. По мере того, как выражаешь большой workflow, он усложняется, в state machine больше состояний, которые надо отображать обратно в workflow.

Swyx [01:01:15]: It’s a lot of ifs.

Swyx [01:01:15]: Это куча if’ов.

Jake [01:01:16]: Exactly. At Uber, we built a system for doing the state machine and testing it. We’ve started to build some of those things here because it’s grown heavily. It’s not quite love-hate. When it works well, it works super well. But if someone who doesn’t have full context puts something into the system that invalidates state or causes non-determinism, or spins off a ton of activities, you have to keep track of underlying SRE knobs like activity slots. Those should scale with memory, vCPU, and so on. It becomes a bear to scale.

Jake [01:01:16]: Точно. В Uber мы построили систему для работы со state machine и её тестирования. Мы начали строить такие штуки тут, потому что это сильно выросло. Это не совсем love-hate. Когда работает хорошо, работает супер хорошо. Но если кто-то без полного контекста добавляет что-то в систему, что инвалидирует состояние или вызывает недетерминизм, или порождает кучу activities, приходится следить за подкапотными SRE-ручками вроде слотов activity. Они должны масштабироваться с памятью, vCPU и так далее. Становится тяжело масштабировать.

Swyx [01:02:10]: You need a capable sysadmin running things behind the scenes. If you moved off, what would you do?

Swyx [01:02:10]: Нужен способный сисадмин, ведущий дела за кулисами. Если бы ты съехал — что бы сделал?

Jake [01:02:19]: We’d build our own workflow engine. We have a few internally that we’ve worked on.

Jake [01:02:19]: Построили бы свой workflow-движок. У нас есть несколько внутри, над которыми мы работали.

Swyx [01:02:27]: This is one of those classes of things you typically wouldn’t vibe code, but I’m wondering if you can.

Swyx [01:02:27]: Это один из тех классов вещей, которые обычно не стал бы вайб-кодить, но интересно, можно ли.

Jake [01:02:33]: I still don’t think you should vibe code it. You still want to run decent tests to make sure it works.

Jake [01:02:33]: Я всё ещё не думаю, что это надо вайб-кодить. Всё равно нужны нормальные тесты, чтобы убедиться, что работает.

Swyx [01:02:39]: Timo didn’t invent that from scratch either. There are libraries you can run. On top of that, it’s just a state machine that you have to map out. Ultimately, you define the instructions you want and run them through a state machine.

Swyx [01:02:39]: Timo тоже не изобретал это с нуля. Есть библиотеки, которые можно запустить. На самом деле это state machine, которую надо размапить. В конечном счёте, ты определяешь инструкции и пропускаешь их через state machine.

Jake [01:03:00]: It’s very doable. Workflow stuff is interesting. Restate is doing neat stuff here.

Jake [01:03:00]: Очень делаемо. Workflow-штуки интересные. Restate делает классные вещи здесь.

Swyx [01:03:10]: You’re tied into JavaScript. Are you a JavaScript maxi?

Swyx [01:03:10]: Ты завязан на JavaScript. Ты JavaScript-макси?

Jake [01:03:13]: Internally, we have TypeScript, Rust, and Go. We don’t add more languages. Actually, we have a little C because we write BPF code and hooks. But those are the languages.

Jake [01:03:13]: Внутри у нас TypeScript, Rust и Go. Языки не добавляем. На самом деле у нас немного C, потому что мы пишем BPF-код и хуки. Но это языки.

Swyx [01:03:28]: Is this for sidecars?

Swyx [01:03:28]: Это для sidecar’ов?

Jake [01:03:32]: No. It’s for the networking stack, volumes, and things like that. We use TypeScript a lot because it powers the dashboard, but we’re moving a lot of workflow stuff off the dashboard stack and into the infrastructure stack.

Jake [01:03:32]: Нет. Это для сетевого стека, томов и подобного. Мы много используем TypeScript, потому что он питает дашборд, но переносим много workflow-вещей из dashboard-стека в инфраструктурный.

Railpack, Nixpacks, and Content-Addressable Filesystems

Railpack, Nixpacks и content-addressable файловые системы

Swyx [01:04:00]: Cool. Any other technical infrastructure stuff? Railpacks?

Swyx [01:04:00]: Круто. Ещё какие-то технические инфраструктурные штуки? Railpacks?

Jake [01:04:07]: We built an engine for determining dependencies based on source code. It’s called Railpack. We built the first version, Nixpacks, on top of Nix, and then we moved.

Jake [01:04:07]: Мы построили движок для определения зависимостей по исходному коду. Называется Railpack. Сначала построили первую версию, Nixpacks, поверх Nix, потом перешли.

Swyx [01:04:17]: People have been trying to get me to adopt Nix and NixOS for four years. Is it ever going to be a thing?

Swyx [01:04:17]: Меня уже четыре года уговаривают адоптить Nix и NixOS. Это вообще когда-нибудь произойдёт?

Jake [01:04:23]: I don’t know. We’re excited about it, but it has pain points. Think of it as a stack of versioned binaries at specific slices in time. If you want version X and version Y, you bloat the package space, which blows up image size and makes real-world workloads difficult.

Jake [01:04:23]: Не знаю. Мы рады за это, но у этого есть болевые точки. Думай о нём как о стопке версионированных бинарей в конкретных временных срезах. Если хочешь версию X и версию Y, ты раздуваешь пакетное пространство, что взрывает размер образа и делает реальные нагрузки сложными.

Swyx [01:04:53]: But you content-address it and cache it. In theory, there are optimizations.

Swyx [01:04:53]: Но ты content-address это и кешируешь. В теории есть оптимизации.

Jake [01:05:00]: In theory, yes. But with a large enough user base and disparate enough machines, you run into a problem Meta described in the XFAAS paper, their internal serverless system. It becomes difficult at scale unless you break out specific runtimes.

Jake [01:05:00]: В теории — да. Но при достаточно большой пользовательской базе и достаточно разных машинах ты сталкиваешься с проблемой, которую Meta описала в статье XFAAS — их внутренней serverless-системе. Это становится сложно на масштабе, если не выделять конкретные runtime.

Jake [01:05:24]: We didn’t want to do that because we wanted to truly allow you to deploy anything. That was our initial thing with Nix. But we’ve moved toward interesting work around content-addressable file systems that can lazy-load anything from any point and page it into memory.

Jake [01:05:24]: Мы не хотели так делать, потому что хотели реально позволять деплоить что угодно. Это была наша первоначальная задумка с Nix. Но мы пошли в сторону интересной работы вокруг content-addressable файловых систем, которые могут lazy-load что угодно из любой точки и подгружать в память.

Swyx [01:05:48]: Amazing.

Swyx [01:05:48]: Шикарно.

Jake [01:05:49]: The future is very bright. It’s crazy, and it’s going to be nuts.

Jake [01:05:49]: Будущее очень светлое. Это безумие, и будет ещё безумнее.

Coding Agent Spend, Roadmaps, and Token ROI

Расходы coding-агентов, дорожные карты и ROI токенов

Swyx [01:05:54]: Founder journey stuff?

Swyx [01:05:54]: Founder-journey штуки?

Alessio [01:05:56]: Your cloud usage: you tweeted you’re going to spend $300K this month?

Alessio [01:05:56]: Твоё облачное использование: ты твитнул, что собираешься потратить $300K в этот месяц?

Jake [01:06:01]: I think we got to $200K.

Jake [01:06:01]: Думаю, дошли до $200K.

Alessio [01:06:02]: Coding agents?

Alessio [01:06:02]: Coding-агенты?

Jake [01:06:03]: Yeah.

Jake [01:06:03]: Да.

Swyx [01:06:04]: Across the company?

Swyx [01:06:04]: По всей компании?

Alessio [01:06:05]: You only have 35 people, so I’m sure they’re not all spending $10K a month. What’s the distribution?

Alessio [01:06:05]: У вас всего 35 человек, так что уверен, не все тратят $10K в месяц. Какое распределение?

Jake [01:06:10]: I think I’m at about $25K. We have power users all the way down. We came back from winter break, and I basically said, “If you’re writing code by hand, you’re doing this wrong.” The tools are good enough now that you can move extremely quickly. There are issues and pain points, but you should be reviewing the code you are writing instead of writing it by hand.

Jake [01:06:10]: Думаю, у меня около $25K. У нас power users по всему спектру. Мы вернулись с зимних каникул, и я в принципе сказал: «Если ты пишешь код руками — ты делаешь это неправильно». Инструменты сейчас достаточно хороши, чтобы двигаться очень быстро. Есть проблемы и болевые точки, но ты должен ревьюить тот код, который пишешь, вместо того чтобы писать его руками.

Jake [01:06:40]: Architectural patterns matter more now than ever, but you shouldn’t spend your time generating code you would write. If you know how to write it, ask the agent to write it and reconcile it until it looks like you would have written it yourself.

Jake [01:06:40]: Архитектурные паттерны сейчас важны как никогда, но ты не должен тратить время на генерацию кода, который написал бы сам. Если знаешь, как написать, проси агента написать и согласовывай, пока не будет выглядеть как у тебя.

Jake [01:06:58]: People misconstrue my propensity to push people toward agents as connected to our growth and some reliability bumps. They’re not necessarily related. The tools are good enough to move extremely quickly and build things way larger than you could before.

Jake [01:06:58]: Люди ошибочно связывают мою склонность подталкивать людей к агентам с нашим ростом и какими-то проблемами с надёжностью. Они не обязательно связаны. Инструменты достаточно хороши, чтобы двигаться очень быстро и строить вещи гораздо больше, чем раньше.

Jake [01:07:19]: To the earlier point about cooling data centers in space: I don’t know. But with software, you can ask, “How would I build block storage from scratch? How would I do these things?” I have ideas because I have history and have read papers. Let me work them out and build massive test benches with thousands of tests, because those are now free to author. If you’re not using AI systems to speed-run your roadmap and reconcile your existing system onto the future, you’re missing a large point of what’s happening.

Jake [01:07:19]: К более раннему пункту про охлаждение дата-центров в космосе: я не знаю. Но с софтом можно спросить: «Как бы я построил блочное хранилище с нуля? Как бы я делал эти вещи?» У меня есть идеи, потому что у меня есть история и я читал статьи. Дай я их продумаю и построю массивные тестовые стенды с тысячами тестов — теперь они бесплатно пишутся. Если ты не используешь AI-системы, чтобы спринтом проходить roadmap и согласовывать существующую систему с будущим, ты упускаешь большую часть происходящего.

Alessio [01:08:12]: What’s the path to spending $3 million a month? Is it bound by ideas and things customers can absorb?

Alessio [01:08:12]: Какой путь к $3 миллионам в месяц? Это ограничено идеями и тем, сколько клиенты могут поглотить?

Jake [01:08:19]: For most companies, it’s bound by deployment at this point. That’s why we’ve seen a massive boom in users and companies, from Fortune 50s down, asking how to get developers to move faster. You’ll probably hit your CFO before any technical limits because they’ll look at the eye-watering amount of money spent on tokens. Inference costs have to come down, but we’re inference constrained now. There will be price discovery around what makes sense for an org to adopt.

Jake [01:08:19]: Для большинства компаний это сейчас ограничено деплоем. Поэтому мы видим массовый бум пользователей и компаний — от Fortune 50 и ниже, — которые спрашивают, как заставить разработчиков двигаться быстрее. Ты, наверное, упрёшься в CFO раньше, чем в любой технический предел, потому что они посмотрят на астрономические суммы, потраченные на токены. Стоимость inference должна упасть, но сейчас мы inference constrained. Будет открытие цены вокруг того, что имеет смысл для организации.

Jake [01:09:06]: I think you’ll end up with the F1 driver concept. If someone is really adept at these things, it makes sense to put them in a $3 million car. If they’re not, it probably doesn’t make sense. You’ll take a few people and say, “You can drive the F1 car. We need to go in this direction. Figure out if it works and prototype it.”

Jake [01:09:06]: Думаю, придём к концепции F1-пилота. Если кто-то реально хорош в этих штуках, имеет смысл посадить его в машину за $3 миллиона. Если нет — наверное, не имеет. Возьмёшь нескольких людей и скажешь: «Вы можете водить F1-машину. Нам надо в этом направлении. Выясните, работает ли, и спрототипируйте».

Jake [01:09:33]: We’ve done some of that and vastly accelerated our roadmap. We thought we’d ship something in a few years; now we can probably ship it in a few months because we validated it and don’t have to build it incrementally. We can skip steps and move toward our vision.

Jake [01:09:33]: Мы это частично сделали и сильно ускорили roadmap. Думали, что-то поставим через несколько лет; теперь, наверное, поставим за несколько месяцев, потому что мы это валидировали и не приходится строить инкрементально. Можем перескакивать шаги и двигаться к видению.

Alessio [01:09:58]: A lot of people are realizing the roadmap doesn’t always have a business impact, so they say tokens are too expensive. But if your roadmap were built to make more money by the time you built it, you’d have token pricing for it, the same way you do with sales. You’d spend a billion dollars on sales if you knew you would get $2 billion of revenue.

Alessio [01:09:58]: Многие осознают, что roadmap не всегда имеет бизнес-импакт, поэтому говорят, что токены слишком дорогие. Но если бы roadmap была построена так, чтобы зарабатывать больше денег к моменту построения, у тебя были бы токены под её цену, как у тебя с продажами. Ты бы потратил миллиард долларов на продажи, если бы знал, что получишь $2 миллиарда выручки.

Jake [01:10:19]: Exactly. A naive way to measure this is the percentage of tokens that end up in production. If you can measure impact because those tokens end up in production, that’s awesome. But the burden of proof will rise. Internally, we have a growing number of pull requests that haven’t merged. The question becomes: how do you get this into production? It’s about how quickly you can build and deploy software, which is exciting because that’s our whole thing.

Jake [01:10:19]: Именно. Наивный способ измерить это — процент токенов, попавших в продакшн. Если можешь измерить импакт, потому что эти токены попали в продакшн, — круто. Но планка доказательства будет расти. Внутри у нас растущее количество PR, которые не смержились. Вопрос становится: как затащить это в продакшн? Это о том, как быстро ты можешь строить и деплоить софт, что волнующе, потому что это и есть наша основная штука.

The SDLC Shift: Prompt Requests, Feature Flags, and Safe Rollouts

Сдвиг SDLC: prompt request, feature flags и безопасные роллауты

Swyx [01:10:56]: The SDLC is changing. One thesis is that the pull request is dying. It’s going to be the prompt request. Beyond that, code review is also kind of dying if you have all the other systems in place. What else is changing about the SDLC?

Swyx [01:10:56]: SDLC меняется. Один тезис — pull request умирает. Это будет prompt request. Кроме того, code review тоже отчасти умирает, если на месте остальные системы. Что ещё меняется в SDLC?

Jake [01:11:19]: The AISRE and the tools to make it happen. AISRE is pie-in-the-sky aspirational. What does it take to get an AISRE? What tools do you need to build?

Jake [01:11:19]: AISRE и инструменты, чтобы это сделать. AISRE — это аспирационная мечта в облаках. Что нужно, чтобы получить AISRE? Какие инструменты надо построить?

Swyx [01:11:32]: You should expose your tooling to customers at some point. The Central Station command center.

Swyx [01:11:32]: В какой-то момент стоит экспонировать свой тулинг клиентам. Командный центр Central Station.

Jake [01:11:39]: We have it for template maintainers. Template maintainers can deploy and maintain templates, and they get feedback. We’re going to expose those things incrementally.

Jake [01:11:39]: У нас есть для майнтейнеров шаблонов. Майнтейнеры шаблонов могут деплоить и поддерживать шаблоны и получают фидбэк. Будем экспонировать эти штуки инкрементально.

Swyx [01:11:51]: Clustering around incidents. Everyone has a version of that, but I don’t think anyone has solved it.

Swyx [01:11:51]: Кластеризация вокруг инцидентов. У всех есть какая-то версия этого, но не думаю, что кто-то это решил.

Jake [01:11:56]: I won’t say we’ve solved it internally, but it’s gotten so good that we can see incidents forming pretty quickly. At some point, those will be things either someone else builds or we build. We’ve always built things purpose-built for us. If it makes sense to make it useful for users, monetize it, or turn that loop into a profit center instead of a cost center, we want to do that.

Jake [01:11:56]: Не скажу, что мы решили это внутри, но это стало настолько хорошим, что мы видим инциденты формирующимися довольно быстро. В какой-то момент это будут либо штуки, которые построит кто-то ещё, либо мы. Мы всегда строили вещи, заточенные под нас. Если имеет смысл сделать полезным для пользователей, монетизировать или превратить этот цикл из центра затрат в центр прибыли — мы хотим это делать.

Jake [01:12:28]: Pull request is definitely dying.

Jake [01:12:28]: Pull request определённо умирает.

Swyx [01:12:29]: Do you do first-party feature flagging and incremental rollout stuff?

Swyx [01:12:29]: Делаете ли вы first-party feature flagging и инкрементальные роллауты?

Jake [01:12:34]: We have a feature-flagging engine we built internally and will eventually roll out.

Jake [01:12:34]: У нас есть движок feature flagging, который мы построили внутри и в итоге выкатим.

Swyx [01:12:38]: I don’t see it as a user. How come you didn’t give us what you have?

Swyx [01:12:38]: Я не вижу его как пользователь. Как так, что вы не дали нам то, что у вас есть?

Jake [01:12:43]: We have to beta test it. We care a lot about the quality of the things. There’s plenty we’ve used internally that doesn’t make it all the way through the journey because it fails. It works for one service but not multiple services. We’d have to build it for multiple services and know that if we released it, we’d rebuild it again and again. Some things are worth that, but many inform the roadmap.

Jake [01:12:43]: Нам надо его бета-тестировать. Мы сильно заботимся о качестве вещей. Мы много чего использовали внутри, что не доходит до конца, потому что не выдерживает. Работает для одного сервиса, но не для нескольких. Нам пришлось бы строить для нескольких сервисов и знать, что если выпустим — будем перестраивать снова и снова. Что-то стоит того, многое же информирует roadmap.

Jake [01:13:18]: We don’t want to dilute the experience by saying, “This works, but only for this service,” unless it’s a core initiative. Over the next few months, we’ll roll out things that work for a single service, then multiple services, then multiple services across the environment. You have to be deliberate. Otherwise you create broken disparate experiences and support load because people ask how to use the feature.

Jake [01:13:18]: Мы не хотим разбавлять опыт, говоря: «Это работает, но только для этого сервиса», — если только это не основная инициатива. В ближайшие месяцы будем выкатывать вещи, которые работают для одного сервиса, потом нескольких сервисов, потом нескольких сервисов поверх окружения. Надо быть осмысленным. Иначе создаёшь сломанные разрозненные опыты и нагрузку на саппорт, потому что люди спрашивают, как пользоваться фичей.

Jake [01:13:52]: It’s the earlier expansion and compaction pattern. You expand the company to get features, then compact and smooth them out so the experience is stellar. You told me in the hallway, “It’s gotten so much better.” Internally we’re saying, “This part really sucks. We need to make it significantly better.”

Jake [01:13:52]: Это тот же паттерн расширения и сжатия. Расширяешь компанию, чтобы получить фичи, потом сжимаешь и сглаживаешь, чтобы опыт был великолепный. Ты сказал мне в коридоре: «Стало намного лучше». Внутри говорим: «Эта часть реально отстой. Нужно сделать значительно лучше».

Swyx [01:14:11]: I can attest to that over the last three years watching you build Railway. For listeners, feature flagging is a huge part of Uber culture. So much so that they have too many feature flags and another thing to remove feature flags. Facebook has Gatekeeper. Agents are going to need this. It’s fundamental to incremental rollouts. OpenAI acquired Statsig. GPT-5 is routing and flagging through different models.

Swyx [01:14:11]: Могу подтвердить за последние три года, наблюдая, как ты строишь Railway. Для слушателей: feature flagging — большая часть культуры Uber. Настолько, что у них слишком много feature flags и ещё одна штука для удаления feature flags. У Facebook есть Gatekeeper. Агентам это понадобится. Это фундаментально для инкрементальных роллаутов. OpenAI купила Statsig. GPT-5 маршрутизирует и флагует через разные модели.

Jake [01:14:56]: It’s super important. If the software development lifecycle is going to change because we’re doing things 1,000 times faster and 1,000 times more concurrently, what becomes important at scale?

Jake [01:14:56]: Это супер важно. Если software development lifecycle изменится, потому что мы делаем вещи в 1000 раз быстрее и в 1000 раз параллельнее, что становится важным на масштабе?

Jake [01:15:16]: Before I started Railway, I built a feature-flagging product and tried to sell it. It was an easier version of LaunchDarkly. I ran into a problem: anyone small enough to adopt your technology doesn’t care about feature flags, and anyone large enough to need feature flags needs so much scale that you have to build out all the infrastructure. I scrapped it.

Jake [01:15:16]: До того, как я основал Railway, я построил feature-flagging-продукт и пытался его продать. Это была более простая версия LaunchDarkly. Я столкнулся с проблемой: любой достаточно маленький, чтобы адоптить твою технологию, не парится про feature flags, а любому достаточно большому, чтобы feature flags понадобились, нужен такой масштаб, что приходится строить всю инфраструктуру. Я его прикрыл.

Jake [01:15:42]: But what is old is new again. Companies are trying to move quickly, but you can’t YOLO a vibe-coded thing straight into production. You need to say, “Here’s my blast radius, my impact, and I want to shadow it for these users.” Feature flags. You’re going to need the tools larger companies built to maintain their structures. Everything gets compressed by 1,000x so everybody can build those structures quickly.

Jake [01:15:42]: Но что было старым — новое снова. Компании пытаются двигаться быстро, но нельзя выкатить вайб-коженую штуку прямо в продакшн. Надо сказать: «Вот мой blast radius, мой импакт, и я хочу затенять для этих пользователей». Feature flags. Понадобятся инструменты, которые большие компании строили для поддержания своих структур. Всё сжимается в 1000x, чтобы все могли быстро строить эти структуры.

Jake [01:16:07]: That’s exactly where we are: compressing the software development lifecycle, then expanding it and adding more new things.

Jake [01:16:07]: Это ровно туда, куда мы движемся: сжимаем software development lifecycle, потом расширяем и добавляем больше новых штук.

Cattle, Pets, and Clonable Infrastructure

Cattle, pets и клонируемая инфраструктура

Swyx [01:16:15]: Another term that comes to mind for newer developers is “cattle, not pets.” People treat production like a pet. It has a name. You baby it and keep it alive. With cattle, you can mass farm, roll out, portion parts out, and kill them.

Swyx [01:16:15]: Другой термин, который приходит на ум для новых разработчиков, — «cattle, not pets». Люди относятся к продакшну как к питомцу. У него есть имя. Ты его балуешь и поддерживаешь жизнь. С cattle можно массово фармить, выкатывать, разделять и убивать.

Jake [01:16:37]: I think that might change. You can move toward having pets as long as you have a cloning machine for your pets.

Jake [01:16:37]: Думаю, это может измениться. Можно двигаться в сторону pets, если у тебя есть машина для клонирования pets.

Swyx [01:16:52]: Yeah.

Swyx [01:16:52]: Да.

Jake [01:16:52]: If you can snapshot every single thing at every frame, it doesn’t matter if something gets obliterated because you have a snapshot of it. The things we’ve built right now are designed to block changes from the hermetically sealed DevOps line. You have to write a Dockerfile because you need a specific cut of the file system.

Jake [01:16:52]: Если можешь снапшотить каждую вещь на каждом кадре, не важно, что что-то снесли, потому что у тебя есть снапшот. Те штуки, которые мы построили сейчас, спроектированы для блокировки изменений на герметично запечатанной DevOps-линии. Тебе приходится писать Dockerfile, потому что нужен конкретный срез файловой системы.

Jake [01:17:14]: What if you had the whole file system? What if you snapshot it and lazily load the entire file system? Then you get around this problem entirely. You don’t need the ceremony of Dockerfiles, Ansible scripts, or other things. You can iterate, snapshot, ask if it’s the right loop or state, and then merge it into production. Merge the file system.

Jake [01:17:14]: Что если у тебя есть вся файловая система? Что если ты снапшотишь её и ленниво подгружаешь всю файловую систему? Тогда обходишь эту проблему полностью. Не нужна церемония с Dockerfile, скриптами Ansible или другими вещами. Можешь итерировать, снапшотить, спрашивать, правильный ли это цикл или состояние, и мержить в продакшн. Мержить файловую систему.

Swyx [01:17:45]: Why not?

Swyx [01:17:45]: А почему нет?

Jake [01:17:46]: It’s going to be fun.

Jake [01:17:46]: Будет весело.

Swyx [01:17:47]: This is a whole other can of worms, but if you cataloged the stateful things in a VM and developed dedicated solutions for each, you can cut the problem down a lot. It’s surprising people weren’t trying until now.

Swyx [01:17:47]: Это совсем другая банка червей, но если ты каталогизируешь stateful-вещи в VM и разработаешь специальные решения для каждой, проблему можно сильно урезать. Удивительно, что люди не пробовали до сих пор.

Jake [01:18:04]: It has always been surprising to me because these are the things we would work on. It’s obvious.

Jake [01:18:04]: Меня всегда удивляло, потому что это именно те штуки, над которыми мы бы работали. Это очевидно.

Swyx [01:18:11]: At first principles, you need them. Everyone needs them in theory. Then the big clouds don’t do them, so you assume it’s impossible.

Swyx [01:18:11]: От первых принципов — они нужны. Всем они нужны в теории. Но крупные облака этого не делают, и ты предполагаешь, что это невозможно.

Jake [01:18:18]: Exactly. You think, “Meta has all the people writing eBPF code, and they’re doing something with them.” But you need that kind of work to solve these problems. Whatever is required, however deep we have to go, we’ll go all the way down to the kernel’s TCP/IP stack if needed. If we need to modify something to make it work for the mental model of the universe moving forward, we’ll do it and keep going down.

Jake [01:18:18]: Точно. Думаешь: «У Meta все эти люди, пишущие eBPF-код, и они с ними что-то делают». Но нужна именно такая работа для решения этих проблем. Что нужно — насколько глубоко нам надо идти — мы пойдём вниз вплоть до TCP/IP-стека ядра, если потребуется. Если надо что-то модифицировать, чтобы заработала ментальная модель вселенной впереди, — мы это сделаем и продолжим вниз.

Swyx [01:18:52]: That sounds fun.

Swyx [01:18:52]: Звучит весело.

Jake [01:18:53]: It’s so much fun. I have to peel myself away from fun, interesting problems to make sure we can scale the company in a way that works. There are so many fun problems: getting information from customers to support to the person who built the thing internally, safe iteration, context from the dashboard to users, drilling down to the infrastructure layer, and managing orchestration as a real-time operating system versus a feedback control system. It’s just so fun.

Jake [01:18:53]: Это так весело. Приходится отрывать себя от классных интересных проблем, чтобы убедиться, что мы можем масштабировать компанию работающим способом. Так много весёлых проблем: переносить информацию от клиентов к саппорту к человеку, который построил это внутри, безопасная итерация, контекст от дашборда до пользователей, спуск к инфраструктурному слою, управление оркестрацией как realtime-операционной системой против системы обратной связи. Это просто очень весело.

Solo Founder Lessons: Obsession, Writing, and Focus

Уроки соло-основателя: одержимость, письмо и фокус

Swyx [01:19:29]: Speaking of the founder side, you’re famously outside the YC/SF consensus. You go to YC, get a co-founder, and do all these things. You did none of that.

Swyx [01:19:29]: Кстати о стороне основателя — ты знаменито вне YC/SF-консенсуса. Идёшь в YC, находишь сооснователя, делаешь всё это. Ты не сделал ничего из этого.

Jake [01:19:40]: None.

Jake [01:19:40]: Ничего.

Swyx [01:19:45]: In the elevator you said a co-founder makes sense if one person is the tech person and the other is the biz dev person. But you have to contain those multitudes yourself. How do you do it?

Swyx [01:19:45]: В лифте ты сказал, что сооснователь имеет смысл, если один — технарь, а другой — биздев. Но тебе самому приходится содержать в себе эти множества. Как ты это делаешь?

Jake [01:19:58]: I try to get eight hours of sleep.

Jake [01:19:58]: Я стараюсь спать восемь часов.

Swyx [01:20:11]: Is there a balance: 50/50, 30/30/30? What’s the mental model as a solo founder?

Swyx [01:20:11]: Есть ли баланс: 50/50, 30/30/30? Какова ментальная модель соло-основателя?

Jake [01:20:17]: There’s no balance. You have to think about all these things and be obsessed with them. Be obsessed with how people think about your product from a go-to-market perspective, and be obsessed with the kernel-level change that makes a user’s SSH connection never drop. I want a universe where you can snapshot everything and it feels like iterating on a VM.

Jake [01:20:17]: Никакого баланса. Надо думать обо всех этих вещах и быть ими одержимым. Быть одержимым тем, как люди думают о твоём продукте с точки зрения go-to-market, и одержимым kernel-level изменением, которое делает так, что SSH-соединение пользователя никогда не падает. Я хочу вселенную, где можно снапшотить всё, и это ощущается как итерация на VM.

Jake [01:20:47]: You have to be obsessed at every layer of the stack. That’s what makes it easier for me. Some people are obsessed with different portions of the company journey, and if you can segment those lines well and be clear about ownership, you’ll have a good time.

Jake [01:20:47]: Надо быть одержимым на каждом слое стека. Это и упрощает дело для меня. Некоторые люди одержимы разными частями пути компании, и если можешь хорошо разделить эти линии и быть ясным насчёт владения — будешь в порядке.

Jake [01:21:12]: I said two is the worst number of co-founders because you have no tiebreak. You disagree, and how do you resolve it?

Jake [01:21:12]: Я говорил, что два — худшее число сооснователей, потому что нет tiebreak. Не согласны — как разрешить?

Swyx [01:21:38]: Usually someone is CEO, so they have the tiebreaker.

Swyx [01:21:38]: Обычно кто-то CEO, так что у него tiebreaker.

Jake [01:21:43]: Totally. It’s hard every way you cut it. It’s hard if you get help, and it’s hard if you do it yourself. Running things is hard, but it’s so rewarding and fun.

Jake [01:21:43]: Полностью. Сложно как ни крути. Сложно, если получаешь помощь, и сложно, если делаешь сам. Управлять — сложно, но это так вознаграждающе и весело.

Swyx [01:21:56]: What have you found useful? A coach? Any advice that has been helpful?

Swyx [01:21:56]: Что ты находил полезным? Коуч? Какие-то полезные советы?

Jake [01:22:01]: I like to write a lot. I get in trouble a lot for my Twitter. I once said if you’re working weekends, you’re messing up your planning. I’ve gone back and forth on that because right now we’re at an extenuating time where it makes sense to work more. The goals are clear in my mind. If you have the vision and know where you’re going, work harder to distill that vision and do those things.

Jake [01:22:01]: Я люблю много писать. Часто попадаю в неприятности из-за Twitter. Я однажды сказал, что если работаешь по выходным — у тебя проблемы с планированием. Я туда-сюда по этому, потому что сейчас экстраординарное время, когда имеет смысл работать больше. Цели чётко в голове. Если у тебя есть видение и знаешь, куда идёшь — работай усерднее, чтобы дистиллировать видение и делать эти вещи.

Jake [01:22:33]: If you’re not certain and need clarity, disconnect and take your weekends seriously. Write about where you are, what you want to do, where you want to go, and what problems you’re solving.

Jake [01:22:33]: Если ты не уверен и нужна ясность — отключайся и относись к выходным серьёзно. Пиши о том, где ты, что хочешь делать, куда хочешь идти и какие проблемы решаешь.

Jake [01:22:56]: Writing is important. I don’t love the word meditation, but whatever gets you into mental clarity is important when you’re trying to say, “We’re here and need to be here,” or “We’re here and I think we need to be in this general space for this to work.”

Jake [01:22:56]: Письмо важно. Не люблю слово медитация, но что бы ни приводило тебя к ментальной ясности — это важно, когда пытаешься сказать: «Мы здесь, и нам надо быть здесь», или «Мы здесь, и я думаю, нам надо быть в этом пространстве, чтобы это сработало».

Jake [01:23:22]: Disconnect, hang out with people you love, and work hard when you’re working. I try to work sunup to sundown, Monday to Friday, all out. I disconnect on Saturday and come back Sunday afternoon to write, plan the week, and do everything else. It works well for me.

Jake [01:23:22]: Отключайся, общайся с теми, кого любишь, и работай тяжело, когда работаешь. Я стараюсь работать от рассвета до заката, с понедельника по пятницу, на все деньги. Отключаюсь в субботу и возвращаюсь в воскресенье днём, чтобы писать, планировать неделю и делать всё остальное. У меня это работает.

Jake [01:23:43]: Another hot take: most advice should be digested and thrown out the window. If it’s helpful, it’ll come back. You’ll learn it through experience. We have made failure very expensive as a society, and it makes it difficult for people to walk off the paths.

Jake [01:23:43]: Ещё горячее мнение: большинство советов надо переварить и выбросить в окно. Если будет полезно — вернётся. Узнаешь это через опыт. Мы сделали неудачу очень дорогой как общество, и из-за этого людям сложно сходить с протоптанных дорог.

GPUs, Focus, and the Dominant Role of Agents

GPU, фокус и доминирующая роль агентов

Swyx [01:24:03]: Anything you haven’t tweeted and gotten in trouble with that you want to preview to the world?

Swyx [01:24:03]: Что-то, чего ты ещё не твитнул и за что не попадал, что хочешь предварить миру?

Jake [01:24:12]: The agent stuff is crazy. It’s going to be the dominant way people do pretty much everything, provided we can get the inference required for that to happen. Over the next 10 years, you’ll see a fundamental shift in how people think about authoring the logic in their head.

Jake [01:24:12]: Агентские штуки безумные. Это будет доминирующий способ, которым люди делают практически всё, при условии, что мы сможем получить нужный inference, чтобы это произошло. В ближайшие 10 лет увидишь фундаментальный сдвиг в том, как люди думают об авторстве логики в голове.

Swyx [01:24:36]: One way of phrasing it is: if Allbirds can become a GPU provider, so can Railway.

Swyx [01:24:36]: Один способ это сформулировать: если Allbirds может стать GPU-провайдером, то и Railway может.

Jake [01:24:44]: I think there’s a lot of “everyone becomes a GPU provider” that is actually not becoming a GPU provider. You’re defined more by the things you don’t do than the things you do, because it’s easy to say yes to a lot of things.

Jake [01:24:44]: Думаю, есть много «все становятся GPU-провайдерами», что на самом деле не становление GPU-провайдером. Тебя больше определяет то, чего ты не делаешь, чем то, что ты делаешь, потому что легко сказать «да» куче всего.

Jake [01:24:56]: Anthropic is amazing and moving into different zones. They’re moving into Figma-like things.

Jake [01:24:56]: Anthropic потрясающие и заходят в разные зоны. Заходят в Figma-подобные штуки.

Swyx [01:25:09]: As we’re recording, Mike Krieger was on Figma’s board, they removed him Monday, and then they launched this today.

Swyx [01:25:09]: Прямо как мы записываем — Mike Krieger был в совете Figma, его убрали в понедельник, и сегодня они запустили это.

Jake [01:25:18]: Things move fast right now. But agents are going to be the way people operate.

Jake [01:25:18]: Вещи сейчас движутся быстро. Но агенты будут способом, которым люди работают.

Swyx [01:25:25]: So your answer is focus: no GPUs for now, but never say never.

Swyx [01:25:25]: Так твой ответ — фокус: пока без GPU, но никогда не говори никогда.

Jake [01:25:27]: Focus. We will not do GPUs now, but we 100% will do GPUs at some point in the future. That’s not me leaking our roadmap because we don’t have plans to do GPUs. It’s just a function of needing FLOPS at some point. If you’re fully vertically integrated and want to make it trivial for people to iterate, build, and deploy, you need access to this core piece of fundamental logic.

Jake [01:25:27]: Фокус. Мы сейчас не будем делать GPU, но 100% будем делать GPU в какой-то момент в будущем. Это не я сливаю наш roadmap — у нас нет планов делать GPU. Это просто функция нужды во FLOPS в какой-то момент. Если ты полностью вертикально интегрирован и хочешь сделать тривиальным итерации, построение и деплой, тебе нужен доступ к этой core части фундаментальной логики.

A New Cloud From First Principles

Новое облако от первых принципов

Swyx [01:25:57]: Presumably your own data center traffic is a minority of your workload right now, but is there a point where it’s a majority or you turn off public clouds?

Swyx [01:25:57]: Видимо, трафик ваших собственных дата-центров сейчас — меньшая часть нагрузки, но есть ли точка, когда это большинство или вы отключите публичные облака?

Jake [01:26:10]: At some point, we got to 100% data center: our own data centers. Right now, the vast majority of what exists on our platform is on our bare-metal data centers.

Jake [01:26:10]: В какой-то момент мы дошли до 100% дата-центров: наших собственных. Сейчас подавляющее большинство того, что существует на платформе, на наших bare-metal дата-центрах.

Swyx [01:26:21]: So you’re already there.

Swyx [01:26:21]: То есть вы уже там.

Jake [01:26:23]: Yeah. The transition was completed at some point, and then we grew so fast that we had to scale back on that. It got to 100% on the Datadog dashboard and then divoted back into the 90s because we were adding capacity.

Jake [01:26:23]: Да. Переход был завершён в какой-то момент, потом мы выросли так быстро, что пришлось откатиться. Дошло до 100% на дашборде Datadog, потом опустилось обратно в 90-е, потому что мы добавляли ёмкость.

Swyx [01:26:45]: You’re literally building a new independent cloud, and people assume that could never happen post-AWS.

Swyx [01:26:45]: Вы буквально строите новое независимое облако, и люди считают, что такое уже невозможно после AWS.

Jake [01:26:53]: It’s hard. We’re going to figure out a bunch of things to make sure the platform is deeply reliable. But you have to break ground on new things when you decide to build a cloud from scratch but not copy the hyperscalers.

Jake [01:26:53]: Сложно. Будем разбираться с кучей штук, чтобы убедиться, что платформа глубоко надёжна. Но надо вспахивать новую почву, когда решаешь строить облако с нуля, не копируя гиперскейлеров.

Jake [01:27:10]: We’ve been deliberate about inventing our own infrastructure from scratch based on reading a ton of papers, while promising ourselves we wouldn’t copy someone else’s homework. If we copy someone else, we lose. You become them over time. You need a core thesis for why this business needs to exist now.

Jake [01:27:10]: Мы были осмыслены в том, чтобы изобретать свою инфраструктуру с нуля на основе чтения кучи статей, обещая себе не копировать чужую домашку. Если копируем кого-то — проигрываем. Со временем становишься им. Нужен core-тезис, почему этот бизнес должен существовать сейчас.

Jake [01:27:33]: For us, the activation energy required to deploy something in production on hyperscalers is far too high. We believe it should be instantaneous. There should be no friction between your thought and the reality that comes out and that you can share with friends. That’s what we’re building toward at every layer of the stack. If we have to go down to energy, we’ll go down to energy.

Jake [01:27:33]: Для нас энергия активации, нужная для развёртывания чего-то в продакшне на гиперскейлерах, слишком высока. Мы считаем, что должно быть мгновенно. Не должно быть трения между твоей мыслью и реальностью, которая получается и которой можно поделиться с друзьями. Это то, к чему мы строим на каждом слое стека. Если надо спуститься до энергии — спустимся до энергии.

Jake [01:27:58]: It matters for giving people access to this tooling. It’s gated not just for citizen developers who are now vibe coding. You have multiple layers: citizen developer, front-end developer, back-end developer, DevOps person, and more. Those layers need to disappear so people can just ship.

Jake [01:27:58]: Это имеет значение для того, чтобы дать людям доступ к этому тулингу. Это закрыто не только для citizen developers, которые сейчас вайб-кодят. У тебя несколько слоёв: citizen developer, фронтенд-разработчик, бэкенд-разработчик, DevOps-человек и так далее. Эти слои должны исчезнуть, чтобы люди могли просто шипить.

Swyx [01:28:20]: Amazing. That’s the future of cloud.

Swyx [01:28:20]: Шикарно. Это будущее облака.

Jake [01:28:22]: Awesome. Thanks for coming on. Thank you for having me. It’s been wonderful.

Jake [01:28:22]: Круто. Спасибо, что пришёл. Спасибо, что позвали. Было замечательно.

Discussion about this episode

Обсуждение этого эпизода