Physical AI that Moves the World — Qasar Younis & Peter Ludwig, Applied Intuition

Физический AI, который движет миром — Касар Юнис и Питер Людвиг, Applied Intuition

Пройдя путь от инструментов автономии эпохи YC к компании физического AI стоимостью $15B, Касар Юнис и Питер Людвиг прожили последнее десятилетие в полном цикле автономии: от симуляции и инфраструктуры данных для робо-такси-компаний к операционным системам для safety-critical машин и развёртыванию AI на легковых и грузовых авто, в горной технике, строительной технике, сельском хозяйстве, оборонных системах и беспилотных грузовиках L4, которые сегодня уже ездят по Японии. Они присоединяются к нам, чтобы объяснить, почему «физический AI» — это не просто LLM на колёсах, почему реальное узкое место — уже не интеллект моделей, а развёртывание на ограниченном железе, и почему будущее автономии может выглядеть не как разовые демо, а как Android для каждой движущейся машины. Building Applied Intuition.

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

Миссия Applied Intuition: создание физического AI для более безопасного и процветающего мира — для машин, грузовиков, строительной и горной техники, сельского хозяйства, обороны и других движущихся системПочему физический AI отличается от экранного AI: обученные системы могут ошибаться в чате или коде, но safety-critical машины вроде беспилотных грузовиков, автономных авто и роботов требуют гораздо большей надёжностиЭволюция от инструментов автономии к широкой платформе физического AI: начало с симуляции и инфраструктуры данных для робо-такси, затем расширение до 30+ продуктов в симуляции, операционных системах, автономии и AI-моделяхПочему компании про инструменты снова вошли в моду: Касар о том, почему dev tooling выглядел немодным в 2016 году, почему Applied Intuition всё равно сделали на него ставку, и как AI-бум вернул workflow и инструменты в центр вниманияТри ключевых блока технологий Applied Intuition: симуляция и RL-инфраструктура, настоящие операционные системы для машин, и фундаментальные AI-модели для автономии и понимания мираПочему машинам нужна настоящая AI-операционка: real-time управление, стриминг с сенсоров, латентность, управление памятью, fail-safe, надёжные обновления, и почему «забриковать машину» гораздо хуже, чем забриковать iPadФизические машины как «телефоны до Android и iOS»: Питер объясняет, почему сегодняшний софт-стек авто и техники фрагментирован между множеством ОС, и почему Applied Intuition хочет консолидировать слой платформыCoding-агенты внутри Applied Intuition: Cursor, Claude Code, внутренние leaderboards по внедрению, и как AI-инструменты меняют инженерные workflow даже в embedded-системах и safety-critical софтеВерификация и валидация физического AI: почему evals усложняются по мере улучшения моделей, как end-to-end автономия меняет требования к симуляции, и почему нейронная симуляция должна быть быстрой и дешёвой, чтобы RL был практиченОт детерминированных тестов к статистической безопасности: почему валидация автономии смещается от бинарного pass/fail к «скольким девяткам» надёжности и среднему времени между отказамиCruise, Waymo и общественное доверие: Касар и Питер о том, почему сбои автономии — не только технические вопросы, как компании взаимодействуют с регуляторами, и почему Waymo задаёт высокую планку для индустрииСимуляция против реальности: почему ни один симулятор не отражает реальный мир идеально, как работает sim-to-real валидация, и почему реальное тестирование никогда не исчезнетМировые модели для физического AI: аквапланирование, строительная техника, визуальные подсказки, обучение причинно-следственным связям, где мировые модели помогают, а где их недостаточноOnboard vs. offboard AI: почему дата-центровые модели могут быть огромными и медленными, но onboard-моделям в машине нужна латентность в миллисекунды, низкое энергопотребление, малый размер и эффективность уровня дистилляцииПочему физический AI ограничен не только интеллектом моделей: сложная часть — развернуть модели на реальном железе при ограничениях безопасности, латентности, энергии, стоимости и надёжностиLegacy-автономия против intelligent-автономии: RTK GPS в горной добыче и сельском хозяйстве, почему hand-coded path-following работал десятилетиями, и почему современные системы требуют восприятия и динамического интеллектаПланирование для физических систем: как «plan mode» применяется к робо-такси, горной добыче, обороне и многошаговым физическим задачам, где действия меняют состояние мираПочему robotics-демо — это не production: хрупкий последний 1%, надёжность гуманоидов, prize policy в духе DARPA Grand Challenge, и разрыв в advanced engineering между исследованиями и развёртываниемУроки Applied Intuition, оплаченные кровью: спустя почти десятилетие Питер говорит, что они могут посмотреть на demo робота и предсказать следующие 20 проблем, с которыми столкнётся компанияСовет Касара фаундерам: ограничивайте коммерческую задачу, не копируйте стратегии зрелых компаний слишком рано, и помните, что compounding-технологии работают только если вы доживёте до того, чтобы увидеть это compoundПочему советы YC 2014 года могут не работать в 2026-м: рынки капитала, динамика AI-компаний и разница между построением в stealth с глубокой сетью контактов и построением как новый фаундер сегодняКого нанимает Applied: операционные системы, автономия, dev tooling, производительность моделей, evals, safety-critical системы, граница hardware/software и инженеры с глубоким любопытством к тому, как устроены вещи

Applied Intuition:

YouTube: https://www.youtube.com/@AppliedIntuitionIncX: https://x.com/AppliedIntLinkedIn: https://www.linkedin.com/company/applied-intuition-inc

Касар Юнис:

X: https://x.com/qasarLinkedIn: https://www.linkedin.com/in/qasar/

Питер Людвиг:

LinkedIn: https://www.linkedin.com/in/peterwludwig/

Тайм-коды

00:00:00 Введение: Applied Intuition, физический AI и 10 лет разработки

00:01:37 Физический AI против экранного AI: почему safety-critical меняет всё

00:02:51 История возникновения: инструменты, YC и сравнение со Scale AI

00:05:41 Три блока: симуляция, операционные системы и модели автономии

00:11:10 Железо, сенсоры и вопрос про LiDAR

00:14:26 Слой операционной системы: почему машины похожи на телефоны до Android

00:19:13 Клиенты, лицензирование и стек «лучше вместе»

00:21:19 Внедрение AI-кодинга: Cursor, Claude Code и бимодальный инженер

00:26:41 Verifiable rewards, evals и нейронная симуляция

00:31:04 Статистическая валидация, регуляторы и урок Cruise

00:40:25 Мировые модели, аквапланирование и обучение причинно-следственным связям

00:43:34 Onboard против offboard: латентность, embedded ML и дистилляция

00:50:57 Plan mode для физических систем и универсальность next-token prediction

00:53:04 Продакшен: 20 проблем, на которые наткнётся любое robotics-демо

00:58:00 Советы фаундерам: ограничения, compounding-технологии и подражание зрелым компаниям

01:05:41 Философия найма: граница hardware/software и инженерный mindset

01:08:50 Институт General Motors, образование и mindset любопытства

Транскрипт

Введение: Applied Intuition, физический AI и 10 лет разработки

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

Swyx [00:00:10]: И сегодня у нас большая честь — с нами фаундеры Applied Intuition, Касар и Питер. Добро пожаловать.

Касар [00:00:17]: Ребята, вы реально умеете переключаться в подкаст-режим. Настоящие профи.

Касар [00:00:23]: Только что шутили перед началом, а потом — раз, и моментально переключились.

Алессио [00:00:29]: О да, рады вас видеть. Может, представитесь, чтобы слушатели знали, чей голос звучит в микрофоне?

Питер [00:00:33]: Конечно. Я Питер Людвиг, сооснователь и CTO Applied Intuition.

Касар [00:00:38]: А меня зовут Касар Юнис. Я CEO и сооснователь вместе с Питером.

Алессио [00:00:42]: Отлично. Можете дать общий обзор того, что такое Applied Intuition? Я читал материалы из Конгресса — Питер, когда ты там выступал — 18 из 20 крупнейших мировых автопроизводителей вне Китая, у вас клиенты в сельском хозяйстве, обороне, строительстве. Думаю, большинство слышали про Applied Intuition ещё со времён YC, потом вы долго были в stealth-режиме. Расскажите, что компания представляет сегодня, а потом нырнём в детали.

Питер [00:01:10]: Да. Миссия Applied Intuition — строить физический AI для более безопасного и процветающего мира. Мы работаем над физическим AI для самых разных движущихся систем: от легковых автомобилей и грузовиков до строительной и горной техники, до оборонных технологий. Мы настоящая технологическая компания: мы создаём и продаём технологии — компаниям, которые производят машины. Мы продаём правительству, в общем — всем, кто хочет купить технологию, чтобы сделать машины умными.

Физический AI против экранного AI: почему safety-critical меняет всё

Касар [00:01:38]: Да. Думаю, в более широком AI-ландшафте основной фокус последних трёх лет вполне справедливо был на больших языковых моделях — то есть на всём, что помещается в экран. Будь то продукты для автодополнения кода или что-то в этом духе. А мы отличаемся тем, что разворачиваем интеллект в массе вещей, у которых нет экранов. Это физические машины. Иногда в кабине, например в машине или грузовике, есть экраны, но основная ценность, которую мы создаём, — это размещение интеллекта в safety-critical средах. Эти два слова крайне важны: обученные системы могут ошибаться, если их попросишь, скажем, «расскажи мне про этих ведущих подкаста,»

Касар [00:02:28]: «с которыми я сейчас иду встречаться». Но мы не можем себе такого позволить, например, у нас прямо сейчас в Японии ездят беспилотные грузовики. Мы не можем допускать ошибок. Это L4-грузовики. Да.

Алессио [00:02:40]: Да. А такая миссия была изначально? Помню, поначалу вас сравнивали со Scale AI — что-то про инфраструктуру данных. Как эволюционировала компания?

История возникновения: инструменты, YC и сравнение со Scale AI

Питер [00:02:51]: С самого начала мы всегда хотели быть технологической компанией, которая в целом двигает вперёд индустриальный сектор. Стартовали мы в области автономии. Нашими самыми первыми клиентами были компании, делающие робо-такси. Мы начинали с большой работы по симуляции и инфраструктуре данных. А с годами портфолио расширялось — сейчас у нас более 30 продуктов, и это уже довольно широкая технологическая игра в ландшафте физического AI.

Касар [00:03:19]: Да, сравнение со Scale возникает потому, что мы все из YC-вселенной. Но это была очень другая компания. Scale — это, по сути, сервисная компания, фундаментально — компания по разметке данных. Мы стартовали и до сих пор много делаем в инструментах. Сейчас dev tooling снова в моде благодаря AI-буму. Но честно — десять лет назад это было немодно. Делать tooling-компанию в 2016–2017 годах было «не то». Не помню, может, вы помните, но позиция VC в целом была: tooling — это просто workflow, а workflow, в конечном счёте, не очень интересны. Мы прошли с этим полный круг. Но когда мы запускали компанию, это было где-то на периферии того, чем компания хотела быть. С самых первых дней мы хотели разворачивать софт на физических машинах — на машинах, грузовиках и тому подобном. И, очевидно, мы не знали, что случится трансформерный бум. Не знали, что системы автономии станут end-to-end. Этих вещей мы не знали. И почему это важно: когда системы автономии становятся end-to-end, эти модели можно обобщить на много форм-факторов. Поэтому 9–10 лет назад tooling был — и остаётся — отличным способом построить технологию и продавать её конечным клиентам, многие из которых хотят строить это сами. Поэтому мы предлагаем спектр решений: от использования одной части набора инструментов разработки до покупки всего стека целиком. Способ думать о компании — по крайней мере, как мы о ней думаем, — как Питер сказал, технологический поставщик. Это вроде того, что делает NVIDIA или AMD, только мы не делаем чипы.

Касар [00:05:06]: Мы не делаем кремний. Но мы фундаментально технологический поставщик. И, кстати, мы шутили, когда запускались, что мы — не те ребята, которые построят Instagram. Это просто… это не мы, на самом базовом уровне.

Алессио [00:05:20]: У вас есть мысли.

Касар [00:05:21]: Да.

Касар [00:05:22]: Ну, мы работали над Maps и прочим, Google Maps. Потребительские продукты крайне сложны по куче причин. Это просто… думаю, не цепляет. Мы скорее ребята из Мичигана, ближе к традиционной инженерной школе, к этой линии. Мы шутили…

Три блока: симуляция, операционные системы и модели автономии

Питер [00:05:41]: Должен сказать, что десять лет назад было очевидно: с софтом и AI в машинах возможно гораздо больше,

Питер [00:05:47]: и именно с этого пространства мы стартовали десять лет назад.

Питер [00:05:51]: А точный путь, который мы прошли за эти годы, — думаю, мы были стратегичны и корректировались, чтобы строить именно то, что ценно для рынка. Технологии так сильно изменились. Наш собственный технологический стек полностью менялся, я бы сказал, примерно каждые два года. Так что мы сделали уже примерно четыре полные эволюции стека. И эта частота, мне кажется, сохранится.

Питер [00:06:13]: Поэтому даже сама инженерная работа у нас выстроена с горизонтом примерно в два года: мы готовимся к тому, что хотим инвестировать соответствующий объём, но при этом быть очень динамичными по мере того, как публикуются исследования и наша исследовательская команда находит новые продвижения.

Касар [00:06:27]: Да. Что было неизменным — это тип людей, которых мы нанимаем. Это инженеры, которые попадают в очень традиционный кластер вроде Google,

Касар [00:06:38]: но при этом сильно отличаются от других компаний. Мы нанимаем людей, которые реально понимают пересечение железа и софта, разбираются в low-level системах. Очевидно, традиционных ML-исследователей и тех, кто реально выводил ML-системы в production. Это было довольно постоянно. Если посмотреть на структуру нашего инженерного состава — 83% компании это инженеры, такой огромный список.

Касар [00:07:05]: Куча инженеров.

Алессио [00:07:06]: Кстати, тысяча инженеров,

Касар [00:07:07]: Да. Тысяча инженеров.

Алессио [00:07:08]: написано на сайте, надеюсь, информация актуальная.

Касар [00:07:11]: Актуальная, да. Да.

Алессио [00:07:12]: Окей. И сорок с лишним фаундеров.

Касар [00:07:15]: Да. Тут больше удача, чем стратегия. Но мы наняли много бывших фаундеров. Для них наша компания — отличное место, и для YC-выпускников, и для не-YC, поскольку я, очевидно, знаю многих YC-ребят. Это как мы нанимаем много людей из Google.

Касар [00:07:33]: Чтобы они могли реализовывать и технические, и нетехнические навыки, потому что мы на стороне applied. У нас есть исследовательская команда, которая занимается фундаментальными исследованиями, мы публикуемся, и у нас отличная traction там. Но фундаментально бизнес хочет брать этот интеллект и развёртывать его в production, и есть определённый тип людей, которых это больше интересует.

Алессио [00:07:54]: Да. Питер, ты упомянул техстек, дам тебе развить тему. Мне интересно, где Applied Intuition начинается и заканчивается? Чего вы не делаете? И что общего у того, что вы делаете для всех вертикалей?

Питер [00:08:10]: У нас есть несколько блоков работы. Мы этим занимаемся уже почти десять лет, так что технологии у нас довольно широкие. Стартовали мы…

Касар [00:08:17]: Да, с тысячей инженеров можно работать над многими вещами.

Питер [00:08:19]: Лотов всего, да, особенно с AI-инструментами в помощь.

Питер [00:08:22]: Стартовали мы в симуляции и инструментарии/инфраструктуре для симуляции. В общем, если вы строите очень сложную программную систему, в которой задействованы движущиеся машины, её нужно тестировать. И лучший способ — комбинация виртуальной разработки, симуляции и реального тестирования.

Питер [00:08:39]: Затем идёт очень тщательный процесс корреляции между результатами симуляции и реального мира — нужно убедиться, что симулятор действительно точен. Симуляция — очень глубокая тема.

Питер [00:08:49]: У нас целый набор продуктов в этой области, мы могли бы говорить об этом часами. Но это одна часть того, что мы делаем как компания. Reinforcement learning как подраздел — тоже сверхкритичен. Думаю, многие лучшие продвижения в AI-системах сейчас так или иначе связаны с RL, и сейчас, когда у нас много compute, можно делать массу интересного. Второй блок нашей работы — операционные системы. Настоящие операционные системы. Имеется в виду планировщики, управление памятью, middleware, передача сообщений, высоконадёжный networking и data links. По сути, если хотите развернуть AI на машинах, нужна реально хорошая операционная система. И когда мы стали глубже копать в это пространство, на рынке не было ничего, что нас бы устроило.

Питер [00:09:39]: Решения существовали — мы использовали то, что доступно на рынке, — и как инженерная организация мы постепенно поняли: это не очень. Мы думаем, что сделаем лучше — давайте построим что-то своё. Это и был момент вдохновения, с которого начался наш бизнес по операционным системам — сейчас это очень реальный бизнес для нас. Чтобы писать и запускать отличный AI, нужна отличная ОС, и так мы туда пришли. А третий блок, над которым мы работаем, — это настоящая фундаментальная AI-технология. Модели — мы много занимаемся фундаментальными исследованиями, как уже говорилось, но также мировыми моделями и реальными моделями автономии, которые работают на этих физических машинах. Это касается машин, грузовиков, горной, строительной, сельскохозяйственной техники и обороны — то есть земля, воздух и море.

Касар [00:10:31]: И ещё меньший подсектор этого третьего блока — взаимодействие людей с этими машинами.

Касар [00:10:38]: Это мультимодальный опыт. Исторически, если вы управляете самосвалом или любой такой машиной, там есть кнопки, которые надо нажимать, — физические тактильные кнопки или, например, тачскрин. Это фундаментально меняется на то, что вы просто разговариваете с машиной и работаете в команде с машиной.

Алессио [00:10:58]: Голосом?

Касар [00:10:59]: Да, голосом, абсолютно.

Алессио [00:11:00]: О.

Касар [00:11:00]: И ещё машина просто понимает, кто в кабине и в каком он состоянии. С точки зрения систем безопасности самая простая версия этого — водитель устал. Те самые алерты, когда вы едете в машине, и она говорит:

Железо, сенсоры и вопрос про LiDAR

Касар [00:11:15]: «может, сделай перерыв на кофе», — теперь умножьте это на пару порядков. Но концепция команды человека и машины важна. Если думать про запуск агентов или, скажем, разные инстансы Claude, делающие для вас работу в фоне, можно почти скопировать эту аналогию и перенести её на ферму, где фермер управляет рядом машин. Взаимодействие с машиной происходит, когда есть важное решение, disengagement или что-то подобное, но в целом агент на физической машине работает и принимает решения от имени фермера, пока не появится что-то критическое. Над этим мы тоже работаем. Это не чистая автономия, это немного смесь, но входит в автономию. В автомобильном смысле это обычно классифицируется по уровням SAE как система L2++

Касар [00:12:05]: с человеком в петле. Просто перенесите эту идею на другие вертикали.

Алессио [00:12:09]: Да. Вы вообще не упомянули hardware — например, сенсоры. Очевидно, вы говорили, что не делаете чипы. Я думаю, даже в автономном вождении есть большая дискуссия — камеры против LiDAR. Какие в вашей сфере дизайн-решения вы приняли, и продиктованы ли они возможностью OEM ставить вещи на технику? И насколько вы влияете на их совместный дизайн?

Питер [00:12:32]: Да, мы сенсоры не делаем. Мы не производитель. Очевидно, мы используем много сенсоров в наших продуктах автономии. По тому, что реально ставится на машины, у нас есть преимущественный набор сенсоров, которые мы, скажем так, полностью поддерживаем, и наши клиенты могут выбирать из этого набора. Если у них сильное мнение в пользу чего-то другого, мы добавим это на платформу тоже. А вопрос про LiDAR — это уже классическая,

Питер [00:12:59]: вечная тема в автономии. Состояние индустрии сейчас такое: LiDAR — однозначно полезный сенсор, особенно для сбора данных и фазы R&D в разработке автономии. Если посмотреть, например, на R&D-машину Tesla — там вообще-то есть LiDAR.

Питер [00:13:17]: До сих пор. В Bay Area такие можно видеть — Model Y или Cybercab с LiDAR на крыше просто ездят. Это полезно, потому что даёт информацию о глубине на пиксель. Если пара LiDAR с камерой смотрит в одном направлении, то для каждого пикселя камеры можно понять, насколько он далеко. Это можно использовать как часть обучения модели — информация о глубине становится выученным состоянием данных с камеры. И уже в продакшен-системе LiDAR можно убрать

Питер [00:13:52]: и получать глубину только с камеры. Разница между сильно засенсоренной R&D-машиной и удешевлённой продакшен-машиной — мы используем этот приём по всему портфелю продуктов. Конечная цель, конечно, — суперэффективная стоимость и сверхнадёжность.

Питер [00:14:08]: А в некоторых кейсах есть более специфические вещи. В обороне, например, многое делается ночью, поэтому важны сенсоры типа инфракрасных — больше, чем… И вы не хотите излучать энергию, поэтому LiDAR или радар использовать не будете.

Питер [00:14:23]: Но видеть ночью всё равно надо. Мы работаем по всему спектру.

Слой операционной системы: почему машины похожи на телефоны до Android

Алессио [00:14:27]: Круто. Это про hardware. А про OS — как это выглядит? Что уникального? Я езжу на Tesla. Когда я сажусь в другие машины с экраном — это всегда отстой.

Алессио [00:14:38]: Как будто стоит дешёвый Android-планшет, лагающий и так далее. Как будет выглядеть ОС в автономном будущем?

Питер [00:14:46]: Когда большинство людей слышит «операционная система автомобиля», они представляют именно то, что ты описал — HMI, human machine interface. Это, конечно, важный слой, но на самом деле — лишь один тонкий слой сверху. Когда мы говорим про операционные системы для AI в машинах, есть много слоёв, идущих вглубь CPU-критичной области и embedded-систем, — это real-time управление…

Питер [00:15:13]: например, электромоторов или двигателя и актуаторов. Разные redundancies для разных частей — скажем, актуатор рулевого управления. Все эти вещи требуют ядровой поддержки в ОС. Для автономии есть real-time данные с сенсоров, которые туда стримятся, и латентности тут очень важны. Представьте, что вы пытаетесь запустить Microsoft Windows

Питер [00:15:35]: и стримить туда данные с сенсоров или управлять машиной. Латентности будут абсурдными. Так делать нельзя. То, что в нас особенного, — это системное мышление: нас волнуют характеристики производительности всей системы, и поскольку мы делаем большую часть этого софта или весь его целиком, мы можем точно настраивать и контролировать все эти вещи. Можно тонко настраивать латентности под каждый аспект системы. Аккуратно настраивать управление памятью. У нас есть правильные fail-safe и fallback. Потому что надо учитывать: а что если будет критический сбой? Что если cosmic ray перевернёт

Питер [00:16:14]: бит в процессоре и вызовет какой-то сбой? У всего должен быть fail-safe, и ядро ОС — часть этого. И последнее, что менее зрелищно, но очень большая тема, — надёжность обновлений.

Питер [00:16:30]: У меня Tesla, и обновления приходят довольно часто.

Питер [00:16:36]: Раз в месяц. Большинство компаний, делающих машины,

Питер [00:16:40]: по сути не делают обновления вообще. Даже если делают, то обычно обновляют только один модуль. Возможно, модуль HMI. Но они не могут обновить, скажем, CPU-критичные части системы.

Питер [00:16:51]: Для этого надо ехать к дилеру. Наша ОС позволяет реально надёжно обновлять любые системы в машине, и это куда легче сказать, чем сделать. В техстеке для этого куча сложных вещей, чтобы случайно не забриковать машину.

Питер [00:17:08]: Представьте свою…

Алессио [00:17:10]: Это было бы плохо.

Алессио [00:17:11]: Плохо.

Питер [00:17:11]: Забриковать машину очень дорого

Питер [00:17:13]: и, честно, наверное, одна из самых импактных вещей, которые мы сделали для индустрии, — что мы позволяем индустрии вообще делать software-обновления.

Алессио [00:17:22]: Уточню — а кто заказчик? Я полагаю, у многих производителей железа своя прошивка, и некоторые из них с радостью попросят вас её написать, потому что вы эксперты. У других — своя. Кто за это платит? Кто вас приглашает в дом — конечный пользователь или производитель?

Питер [00:17:41]: Да. Сначала аналогия про фрагментацию софта. Физические машины сегодня больше похожи на рынок телефонов до появления Android и iOS. Я, кстати, много лет назад работал в Google над Android, и часть причины, по которой Ларри в Google решил заняться Android, — желание запускать продукты Google на куче телефонов. Они скупили кучу телефонов с рынка и обнаружили, что там 50 разных операционных систем. И сделать так, чтобы их приложение одинаково хорошо работало на всех 50 устройствах, было практически невозможно

Питер [00:18:17]: для Google. Решение: а что если создать реально классную ОС и сделать её привлекательной для всех этих производителей телефонов? Это и был генезис того, чем стал Android и зачем он существовал. Это был способ для Google поставить свои продукты на очень разнообразные устройства. Состояние физической индустрии сейчас немного похоже на это. Да, у этих компаний есть firmware, но у них столько разных ОС, всё так фрагментировано, что для запуска современного AI-приложения на этих машинах сначала надо консолидировать ОС. Поэтому мы это и сделали. Если конкретно про клиентов — обычно это компании, которые делают эти машины.

Питер [00:19:06]: И мы продаём нашу технологию им — чтобы реально упростить архитектуру и позволить AI-приложениям на них работать.

Клиенты, лицензирование и стек «лучше вместе»

Swyx [00:19:13]: Насколько это переиспользуется? У вас одна ОС, которая просто конфигурируется под всё, или нужна более глубокая кастомизация?

Питер [00:19:22]: Да, сильно переиспользуется. Фундаментальная технология весьма универсальна. О чём нам всё же приходится думать — это поддержка чипсетов. Если вы пишете, скажем, LLM, и стартуете с предположением: «окей, я возьму CUDA, запущу это на NVIDIA-чипе», то про железо думать особо не нужно. Вы просто в экосистеме CUDA/NVIDIA и в ней работаете. Но железо, особенно в safety-critical системах, гораздо более разнообразное. Тут нет одного-двух игроков. Есть куча разных чипсетов, которые надо поддерживать. Наша ОС работает не только на эквиваленте x86. Ей нужно работать на ряде разных архитектур от чипов разных компаний. Но опять же, мы работаем над этим уже долго, и поддержка всех этих чипсетов у нас есть. И тогда, когда вы запускаете AI-приложения, мы можем это делать надёжно у целого ряда поставщиков.

Касар [00:20:19]: Тут много вдохновения от Android. У Android огромный набор тестирования, это надёжная ОС, которая работает на тысячах устройств. Мы думаем, что можем сделать то же самое во всех этих физических движущихся машинах, с тем отличием, что мы реально в safety-critical зоне. Android — нет.

Алессио [00:20:40]: Если на Android мне не обязательно использовать Gmail, я могу использовать Superhuman. А у вашей техники как? Можно ли привнести чью-то ещё автоматизацию или это all-in-one?

Касар [00:20:50]: Только нас. Нет. Да. Если, ну, да. Да, всё абсолютно открыто. Да.

Питер [00:20:56]: Да. Наша философия — мы технологическая компания, и лицензируем технологию клиентам так, как они хотят. Если клиент хочет лицензировать наш autonomy-стек и нашу ОС — отлично, мы лицензируем оба. Если хочет лицензировать только ОС и использовать другой autonomy-стек — тоже окей, и у нас есть отличная документация и…

Swyx [00:21:17]: Или если они хотят использовать dev tooling.

Питер [00:21:18]: Да, именно.

Внедрение AI-кодинга: Cursor, Claude Code и бимодальный инженер

Swyx [00:21:19]: Это как «лучше вместе», если они работают вместе. Полагаю, всё на C++ с разными compile target'ами?

Питер [00:21:27]: Мы много используем C++.

Питер [00:21:28]: Rust — это вроде нового модного парня в квартале

Питер [00:21:32]: для кучи вещей. Но да, чем ниже спускаешься, особенно при real-time ограничениях, тем чаще упираешься в C++, а в какой-то момент — и в ассемблер, когда это нужно.

Swyx [00:21:44]: Ого.

Алессио [00:21:46]: Мне интересен внутренний пикап coding-агентов, раз вы упомянули более эзотерические языки. Какое внутреннее усвоение? Чему вы научились?

Питер [00:21:55]: Да. Мы используем всё. Cursor долгое время был самым горячим инструментом в компании. Сейчас Claude Code, кажется, перехватил инициативу. У нас есть внутренний leaderboard, который мы используем, чтобы поощрять внедрение

Питер [00:22:09]: внутри компании. И да, это феноменально полезно. Мы, честно, черпаем вдохновение в этих инструментах и в том, как переносим этот mindset в физический мир. Если так легко собрать приложение, которое живёт только на экране, можно ли применить эти идеи к тому, чтобы физическая машина что-то делала — насколько просто мы можем сделать это, используя наше же tooling и платформу?

Алессио [00:22:40]: Вы меняете архитектуру ОС, как выставляете сервисы, чтобы они были более AI-friendly?

Питер [00:22:48]: Да, абсолютно. В ранние дни нашей работы над tooling-инфраструктурой это было про инженеров, которые были экспертами в определённых темах, но вещи, с которыми они имеют дело, нередко более математические или абстрактные, и GUI-инструменты тут реально полезны. Например, у нас есть продукт Sensor Studio, который помогает спроектировать набор сенсоров для автономного транспорта — будь то машина, дрон, горная техника или робот. Вы расставляете сенсоры в разных местах. Есть библиотека. Можно понимать trade-off'ы при проектировании. Это был очень GUI-интенсивный инструмент, ближе к CAD по духу,

Swyx [00:23:37]: Угу.

Питер [00:23:37]: если вы видели CAD-инструменты. Сейчас же мы выставляем все нижележащие API, и с помощью AI-агентов вы можете сконфигурировать набор сенсоров просто текстом и, скорее всего, получить лучший результат, чем через GUI. Эту идею мы сейчас разносим по всему портфелю продуктов.

Swyx [00:23:57]: Ещё думал — внедрение AI меняет ли ваш найм хоть немного, или как вы по-другому управляете инженерами?

Питер [00:24:08]: Да. Абсолютно меняет. Думаю, как и любая компания в Долине сейчас, мы эволюционируем практики найма,

Питер [00:24:16]: потому что навыки, нужные для эффективности, меняются так быстро. Раньше отбирали в основном по способности рутинно имплементить, а сейчас это уже AI-engineer skill set. Да, как реализовывать, но фактически — просто молотить код больше не основная работа. Реально важно знать, какие вопросы задавать, как связывать разные AI-инструменты. И собеседования, которые мы сейчас проводим, я бы сказал, гораздо сложнее, чем когда-либо.

Питер [00:24:46]: Но мы и разрешаем выборочное использование AI-инструментов для решения задач. И тут начинаешь видеть более бимодальное распределение инженеров. Видишь — есть подгруппа людей, они реально въезжают. Они all-in и явно вложили нужные часы в изучение этих инструментов и того, как быть эффективным.

Питер [00:25:09]: А есть группа людей, которые этого не делали, и разрыв в производительности — просто огромный. Поэтому мы стараемся отбирать тех, кто реально в это вложен.

Касар [00:25:20]: Я писал свою статью про AI Engineer три года назад, и тогда я говорил: «На самом деле, не каждый должен быть AI engineer». Есть экстремистская позиция: «каждый разработчик — AI engineer». А моим примером тех, кому AI внедрять не стоит, были embedded-системы, операционные системы и работа с базами данных. Они внедряют AI?

Питер [00:25:41]: Думаю, это классический урок: полгода назад я бы сказал то же самое, но это становится суперполезным для каждой области.

Касар [00:25:53]: Уверен.

Питер [00:25:54]: Точно.

Питер [00:25:56]: Думаю, полгода назад или год назад, если бы вы попробовали последнюю модель Claude для написания шейдеров (GPU-шейдеров), результаты были бы, скорее всего, разочаровывающими. А если использовать последнюю модель сейчас — вы немного офигеете: «вау, это работает, это классно». В embedded-сфере мы видим то же самое. Без вопросов, особенно в safety-critical системах, валидация человеком —

Питер [00:26:25]: на 100% ключевая. Вы не доверите свою жизнь софту, написанному AI без тщательной проверки человеком. И сейчас реальный вызов — это адекватный уровень human-валидации для safety-critical систем.

Verifiable rewards, evals и нейронная симуляция

Алессио [00:26:41]: Как вы думаете про verifiable reward и reinforcement learning? Это сейчас одна из самых горячих тем. Что вы делаете внутри, чтобы это построить? Что даёт спать спокойно? Если кто-то просто vibe-кодит что-то новое,

Алессио [00:26:57]: и у вас должен быть достаточно хороший проверочный контур. Потому что обратное тоже верно: если очень легко писать что угодно,

Алессио [00:27:04]: это сильно нагружает verifiable

Алессио [00:27:07]: сторону. Как это устроено?

Питер [00:27:10]: Да. Verifiability — это часть более широкого блока evaluations. Как оценивать результаты, которые вы получаете? Это, наверное, сейчас самая сложная проблема, потому что чем лучше становятся модели, тем сложнее найти неисправности в системе.

Питер [00:27:29]: Задача делать правильные evals тоже становится всё сложнее по мере роста моделей. Но не менее важна, чем когда-либо: всегда будут edge-кейсы, которые не покрыты. Это большая зона инвестиций для нас. По теме RL — ключевое: с последним поколением технологий приходят новые требования. Например, end-to-end — большая тема сейчас в автономии и физическом AI. Вы можете обучить модели, которые эффективно берут данные с сенсоров на вход и выдают control signals на выходе, получая отличные результаты. Но способ обучения и улучшения этих моделей радикально отличается от предыдущих поколений. Чтобы делать RL над end-to-end-моделью, нужно симулировать все сенсорные данные. И это становится тем, что мы называем нейронной симуляцией —

Питер [00:28:26]: думайте об этом как о гибриде Gaussian splatting и diffusion-методов, где производительность — это всё. Если не можете симулировать достаточно быстро и дёшево, результаты в итоге не оправдают себя. Это упирается во многое из нашей работы по embedded-системам, тоже performance-критичной. И эта оптимизация и критичность производительности переносятся на тренировку моделей, потому что единственный способ сделать её доступной — она должна быть очень быстрой.

Касар [00:28:58]: Стоит уделить пару минут нашим эволюционирующим взглядам на verification и validation —

Касар [00:29:05]: внутри традиционных симуляторов, скажем, vehicle dynamics, где вы берёте учебники, формулы и переносите их в софт,

Касар [00:29:13]: и до вселенной neural sim и world models. Думаю, это интересная тема.

Питер [00:29:20]: Да. В более традиционной разработке у вас часто были более чёрно-белые ответы на вопросы.

Питер [00:29:28]: В Европе, например, есть регуляторная система Euro NCAP — European New Car Assessment Program. Машины должны проходить набор тестов, включая системы безопасности. Например, automatic emergency braking — экстренное торможение при ребёнке, выбегающем перед машиной

Питер [00:29:51]: или закрытом ребёнке, который выбегает на дорогу и вы его сбиваете. Получались такие бинарные ответы: прошёл или не прошёл тестируемый автомобиль конкретный тест. Есть очень известный набор тест-кейсов,

Питер [00:30:05]: которые автомобиль должен пройти. Так индустрия работала примерно до 10 лет назад. А с этими моделями всё стало статистикой. У вас больше нет чёрно-белого ответа — а сколько порядков, сколько девяток надёжности я могу достичь и как это доказать? И большой unlock для физического AI как индустрии — модели становятся гораздо надёжнее. Вещи реально работают значительно лучше. Количество девяток теперь достаточно хорошее, чтобы реально стало экономически осмысленно разворачивать эти системы. Большой сдвиг в verification & validation — раньше это были жёсткие требования, и вы либо им соответствуете, либо нет. Теперь это скорее статистическая верификация и валидация, где всё про сколько девяток надёжности и mean time between failures.

Статистическая валидация, регуляторы и урок Cruise

Swyx [00:31:04]: А целевая аудитория — это регуляторы или клиенты тоже? Полагаю, клиенты bought-in, и в основном надо удовлетворить регуляторов.

Питер [00:31:15]: Мы работаем с правительством США, с европейскими правительствами и с правительством Японии. Правительство — это никаким образом не AI-лаборатория.

Питер [00:31:25]: Поэтому Swyx [00:31:26]: Им просто важен результат.

Питер [00:31:27]: Им важен результат.

Питер [00:31:28]: Поэтому мы занимаемся образованием в этом отношении — рассказываем: «вот так, мы считаем, должна делаться валидация, и вот разумный подход», как думать о том, когда беспилотная система действительно достаточно безопасна для дорог. Но не сказал бы, что правительство этого требует. Мы скорее обучаем правительство. Честно говоря, это нужно больше для нашего собственного комфорта: мы хотим строить очень безопасные системы, и наши клиенты, конечно, тоже о этом глубоко заботятся. Но в этом контексте мы обычно ещё и обучаем клиентов.

Касар [00:32:01]: Да. Наш первый core value — про безопасность. Нельзя достаточно подчеркнуть, что нам самим важно верифицировать и валидировать, что разворачиваемые нами системы безопасны, — это, наверное, не менее важно, чем мнение регулятора или клиента,

Swyx [00:32:19]: Конечно. Окей. Да.

Swyx [00:32:20]: Надо устроить самих себя.

Питер [00:32:22]: Как правило, по миру в целом регулирование — это почти lowest common denominator. Вам нужно реально превзойти то, что ждут регуляторы, чтобы сделать хорошие продукты.

Swyx [00:32:33]: Да. Одно, о чём я часто говорю и пытаюсь сделать релевантным для аудитории, — это Cruise: у них случилась авария, которая, по сути, закончила компанию. Думаю, люди переоценивают единичные инциденты, потому что инциденты будут происходить так или иначе — это статистика, но я не уверен, что регуляторы это понимают. Нельзя экстраполировать с одного инцидента, но мы это делаем, потому что больше ничего нет. И размеры выборок у вас обязательно будут меньше, чем у обычного

Swyx [00:33:00]: вождения людьми.

Касар [00:33:01]: Да. Думаю, пример с Cruise — это не технологический провал. Реально усугубляющая проблема была в том, как компания говорила с регуляторами, какое у неё было поведение, — это стало главной проблемой. Если посмотреть,

Питер [00:33:19]: Это технологический провал был. Но его сильно усугубил…

Swyx [00:33:23]: Перепарковали машину поверх женщины.

Касар [00:33:25]: Да. Скажу иначе. Есть версия мира, где Cruise всё ещё существует.

Swyx [00:33:29]: Точно. Да.

Касар [00:33:30]: Точно.

Swyx [00:33:30]: Это была последняя капля

Касар [00:33:31]: Это

Swyx [00:33:31]: в длинной цепочке

Swyx [00:33:33]: проблем.

Касар [00:33:33]: Так что считаете ли, что у ATG (Uber ATG) была эта жуткая авария, или, скажем, реальная гибель человека — там был бездомный, переходивший улицу? Так что не могу преувеличить — статистическая валидация это одно, но это не единственная часть. Принятие потребителями, mainstream-усвоение этих технологий тоже будет частью этой беседы. Думаю, такие компании, как Waymo, делают много позитивного для индустрии — задают высокую планку и показывают, как ответственно подходить к этому. У Waymo тоже были инциденты. Просто они не были такими значимыми, как у Cruise. И вы продолжите это видеть. Долгосрочный вопрос будет про… С людьми статистически дела хуже на дороге.

Касар [00:34:29]: Дебатов нет. И в какой момент… Но мы эмоциональные животные.

Swyx [00:34:34]: Да. Моя мысль в том, что нам как обществу надо дойти до точки, где мы принимаем ужасные аварии, которые с человеком никогда не произошли бы, потому что статистически система безопаснее в целом. Так же, как самолёты — самый безопасный вид транспорта.

Касар [00:34:50]: Да. Ехать в аэропорт опаснее, чем лететь.

Касар [00:34:53]: Так что если когда-нибудь

Касар [00:34:54]: будете нервничать перед посадкой, думайте: «мне просто надо добраться до аэропорта».

Swyx [00:34:58]: Да, мы летим.

Касар [00:34:59]: Если я доберусь до аэропорта,

Касар [00:35:00]: всё ок.

Swyx [00:35:00]: Но самолёты также концентрируют tail risk. Если самолёты

Касар [00:35:03]: Да. И

Питер [00:35:04]: Не думаю, что нам реально стоит волноваться, что эти системы когда-либо приведут к авариям хуже, чем те, что вызывают люди. Люди делают ужасные вещи.

Питер [00:35:14]: Люди постоянно засыпают за рулём.

Swyx [00:35:16]: Я тоже.

Swyx [00:35:17]: Я был сонным водителем.

Питер [00:35:19]: Пьяные водители — это крайность.

Питер [00:35:20]: А у AI-систем есть redundancies, fallback'и. Многое должно пойти не так, чтобы случилось что-то катастрофическое, потому что fallback'ов много.

Алессио [00:35:36]: Ваша симуляция огромна, потому что юзкейсов много. Что-то работало в симуляции, а потом в реальности — «чёрт, это вообще не работает,»

Алессио [00:35:45]: вообще не работало?»

Питер [00:35:47]: Да.

Алессио [00:35:47]: Это

Питер [00:35:47]: Это, наверное, некоторое заблуждение про симуляцию. Дам чуть более технический ответ. Изначально — никакая симуляция не отражает реальный мир. Всегда есть процесс sim-to-real matching,

Питер [00:36:02]: где вам нужен feedback из реального мира, который попадает в параметры симулятора. И вы делаете это — этот flow валидации — несколько раз, пока не получите уверенность: «думаю, симулятор теперь точно отражает,»

Питер [00:36:19]: что произойдёт в реальном мире. Если же вы прошли всю валидацию и думали, что точно, а потом оказалось иначе — это куда более коварные случаи, и они абсолютно случаются. Но процесс валидации очень важен. Никогда нельзя пропускать процесс валидации симулятора — где вы убеждаетесь, что sim-to-real gap достаточно мал, чтобы доверять результатам симуляции. И в этом полно прикольных вещей. Дам один забавный пример из недавнего — в гуманоидных роботах перегрев актуаторов — реальная проблема. Демки потрясающие. Я

Питер [00:37:01]: Самые потрясающие

Алессио [00:37:02]: На 10 минут.

Питер [00:37:03]: Самые потрясающие, которые я могу собрать. Обожаю смотреть, как роботы делают акробатику, как и все. Но эти системы реально перегреваются. И один из способов использовать симуляцию — сделать температуру актуаторов одним из параметров, представленных

Питер [00:37:18]: в симуляции. И если вы делаете RL над какой-то задачей, робот может корректировать движения в симуляции, учитывая, что, двигаясь, он начинает перегревать этот мотор. А если бы вы не имели параметра тепла мотора в симуляции изначально, RL-политика его проигнорировала бы. И запустив это на роботе, он бы перегрелся и сломался.

Алессио [00:37:43]: Вопрос: как учитывать все эти параметры и одновременно понимать среду развёртывания? Температура — хороший пример. Ну,

Алессио [00:37:53]: «зачем вы сделали моего робота хуже, когда он работает в морозильнике?»

Алессио [00:37:57]: Это и не должно его беспокоить. Как вы такие симуляции проектируете?

Питер [00:38:02]: Это, честно, то, что делает симуляцию настолько сложной. Симуляция фундаментально про оптимизацию разработки системы — как мне строить эту систему быстрее, лучше и дешевле, и какие у меня есть рычаги для этого? Поскольку симуляция — просто софт, её можно менять гораздо легче, чем железо. И что особенно круто в world models как части симуляции, — симуляция теперь масштабируется не только добавлением математики,

Питер [00:38:36]: но и дополнительными реальными данными, и это открывает целое новое поле в робототехнике.

Касар [00:38:46]: Есть граница, после которой реальное тестирование лучше. В sim-to-real gap можно воспроизвести реальность с непомерно высокой стоимостью — ничто не бесплатно. Поэтому вы ищете ту линию, где получаете отличный perfomance, отличный feedback — на тренировке или на eval — но это куда дешевле, чем реальный мир. В какой-то момент это просто перестаёт иметь смысл. С самых ранних дней в автономии у нас была установка: реальное тестирование всё равно будет. Нет такой магической страны, где его не будет. Возможно, более нюансная версия в традиционной разработке софта — большая часть тестирования авто-софта, 95%, может быть как обычный CI/CD в web-разработке. Но если у вас грузовик, ну, 4% можно делать на стенде, где есть электрика и электроника грузовика, но нет шин и нет… А есть 1% — это сам автомобиль. Похожая аналогия и в использовании симуляции для интеллектуальных систем. В симуляторе можно делать много, используя world models, но в конечном счёте это physical AI. Вы развёртываете его на физических машинах, и

Касар [00:40:17]: пример с морозильником всплывает.

Алессио [00:40:20]: Тема world models — самое сложное для меня, чтобы

Алессио [00:40:22]: уложить в голове. У нас был Faith Eliyon в подкасте.

Мировые модели, аквапланирование и обучение причинно-следственным связям

Касар [00:40:25]: Мы делаем небольшую серию с другой Intuition-компанией — General Intuition тоже.

Касар [00:40:31]: Да. И ещё много материала про NeRFs.

Алессио [00:40:34]: Да. Это как разговор о гелиоцентризме. Если world-модели скармливать только визуальные данные, модель может выучить, что Солнце вращается вокруг Земли. Это имеет смысл, верно? И тут — ну, на самом деле нет. И ещё — про аквапланирование: может ли world-модель понимать аквапланирование и сколько именно воды его вызывает? Это для меня загадка. И ещё интересно — когда вы делаете и машины на хайвее в Японии, и экскаватор на шахте в…

Касар [00:41:13]: Аризоне

Алессио [00:41:13]: Аризоне, где бы вы их ни разворачивали.

Алессио [00:41:15]: Насколько вы опираетесь на world models, чтобы они генерировали симуляции, и потом закрываете разрыв, по сравнению с тем, чтобы давать world models как инструмент инженерам для курирования симуляций?

Питер [00:41:28]: Да. С чисто инженерной позиции: если вы надеетесь делать реальные деплои и опираетесь только на world model подход — вы, скорее всего, не дойдёте до чего-то работающего раньше, чем обанкротитесь. Поэтому есть очень практичный mindset: world models потрясающие и полезны для множества кейсов, но есть и много другого, что нужно сделать, чтобы что-то развернуть и заставить работать. Самое фундаментальное — world models про понимание мира и про то, что произойдёт. Это причинно-следственная связь.

Питер [00:42:01]: Если у вас строительный инструмент, и он будет работать с землёй — двигать землю — world model должна понимать эту cause-effect связь. «Окей, когда я беру материал отсюда и кладу туда, теперь здесь его нет, а там есть» — эта причинно-следственная связь. Данные — большая проблема. Пример с аквапланированием —

Питер [00:42:26]: реально классный, потому что он часто неочевидный. Идёт дождь, у этой дороги адекватная кривизна, вода с неё стекает, и машины едут быстрее, а потом подъезжаешь к плоскому участку, вода скапливается, и вдруг машины едут медленнее — потому что когда они ехали быстрее, они начинали терять управление. В сцене много визуальных нюансных подсказок, и я думаю, что world model вполне может научиться, что в таких условиях нужно ехать медленнее — это и есть

Питер [00:43:14]: красота этих моделей: они выучивают неочевидные вещи.

Swyx [00:43:14]: Ей не нужно знать про аквапланирование, чтобы понимать, что надо ехать медленнее.

Питер [00:43:17]: Да.

Onboard против offboard: латентность, embedded ML и дистилляция

Swyx [00:43:17]: Да, я хочу спросить про развёртывание моделей. Полагаю, вы используете world models для тренировочных данных и симуляции, но что насчёт развёртывания в production? Полагаю, у вас есть GPU на устройстве. Я говорю «на устройстве».

Swyx [00:43:36]: Какое правильное слово?

Питер [00:43:40]: «На машине».

Swyx [00:43:41]: На машине.

Питер [00:43:41]: Или embedded, да.

Swyx [00:43:42]: Да. Каков мир embedded? Для тех, кто к нему не привык, всё это инопланетно.

Питер [00:43:49]: Да. У нас это называется onboard и offboard.

Питер [00:43:52]: Onboard-софт и offboard-софт.

Питер [00:43:54]: Класс offboard-софта — в нём не надо беспокоиться о времени, и можно гонять реально большие модели. Можно сказать: «эта модель — мне без разницы, выдаст она результат через секунду или через 10 секунд, потому что у нас есть время». Модели могут быть огромные, работать в дата-центре или на гигантском GPU, можно распределять compute и так далее. Но onboard ничего из этого нет. У вас есть конкретное число миллисекунд, в которые нужен ответ. И гораздо больше энергии уходит на дистилляцию и реальную эффективность — буквально каждая доля миллисекунды на счету. Не может быть ситуации, когда модель занимает слишком много времени, потому что тогда машина не сможет функционировать.

Питер [00:44:42]: Можно использовать многие из тех же техник, и модели можно считать производными от больших офлайн-моделей. Вы стремитесь получить модель, которая всё ещё работает очень хорошо, но достаточно мала, чтобы её можно было запустить на embedded-системе с заботой о латентности и энергопотреблении.

Касар [00:45:03]: Да. И более широкая мысль, возможно, неочевидная, но важная: в мире физического AI мы сейчас не ограничены интеллектом моделей. Ограничивает именно то, о чём говорит Питер, — развёртывание моделей в…

Swyx [00:45:19]: …на железе, которое вам дают.

Касар [00:45:21]: Да. На железе, которое дают.

Касар [00:45:22]: И есть реальность safety-critical систем. Это и становится вашим limiting factor,

Касар [00:45:29]: тогда как, скажем, для foundation model компании limiting factor —

Касар [00:45:34]: капитал или исследователи.

Касар [00:45:38]: Мы в этом смысле имеем дело с очень интересными ограничениями, и они forcing creativity.

Swyx [00:45:47]: Полагаю, никто в 2018-м не давал вам железо для трансформеров, а сейчас дают. Как шла эволюция? Откройте чуть-чуть занавес.

Питер [00:45:59]: Да. Трансформеры — изначально статья опубликована в 2017.

Swyx [00:46:02]: 2017.

Swyx [00:46:02]: Не так давно.

Питер [00:46:04]: А я

Swyx [00:46:05]: Просто хочу сказать — embedded ML обычно гораздо меньше параметров, меньше compute, а сейчас на порядки больше.

Питер [00:46:14]: Да, абсолютно. Что я хотел сказать — в оригинальной статье 2017-го, кажется в последнем параграфе, авторы пишут: «кстати, эта техника может быть полезна также для изображений и видео».

Питер [00:46:30]: Эти последние сюжеты.

Питер [00:46:31]: И понадобилось несколько лет, чтобы эффект реально проявился. Но сейчас трансформеры повсюду.

Swyx [00:46:39]: Да. Vision transformers.

Питер [00:46:40]: А compute всё продолжает улучшаться. И есть фундаментальный trade-off: мощность, стоимость и производительность. Получить правильный микс в embedded-корпусе, который ещё должен выдерживать тряску и прогрев в любых

Питер [00:47:00]: условиях работы. Но всё будет только лучше, поэтому мы планируем стратегию с пониманием темпа улучшений этих систем.

Swyx [00:47:11]: Да. Google только что выпустил модель Gemma 2B

Swyx [00:47:15]: эффективная 2B-модель. Это полезно вам или слишком большое?

Питер [00:47:18]: Эту модель можно запустить на embedded-системе, определённо.

Питер [00:47:21]: В этом смысле она полезна. Большой вопрос — для чего вы её используете в embedded-системе. Её нужно довольно сильно кастомизировать, чтобы она была полезна для конкретного. Но да, модель на 2 миллиарда параметров можно запустить.

Swyx [00:47:35]: Интересно — какой процент это кастомная ML-модель только под одну задачу, а какой — generalist LLM,

Swyx [00:47:41]: которая, наверное, не так полезна в вашем контексте.

Питер [00:47:46]: Можно представить разные кейсы.

Питер [00:47:48]: Так что

Swyx [00:47:49]: Голос, да.

Питер [00:47:49]: Да, голос. Однозначно.

Питер [00:47:51]: Для реальных элементов автономии — это на 100% in-house. Мы делаем всё: данные, симуляцию, модель — всё. Когда речь идёт о более общих кейсах — голос или voice assistant, — вот тут более универсальные модели вроде Gemma могут быть очень полезны.

Swyx [00:48:09]: Да. И есть, очевидно, ещё trade-off: какой процент должен исполняться на машине, а какой — звонком домой.

Питер [00:48:16]: Да. Всё про латентность.

Swyx [00:48:17]: Латентность.

Питер [00:48:17]: Всё про латентность.

Swyx [00:48:18]: Да. Думаю, в куче контекстов, особенно в США, можно просто иметь связь с сетью.

Касар [00:48:26]: Да. Хотя большая часть нашей вселенной — всё должно быть достаточно embedded и локально, просто в силу природы. Даже в США есть много мест с

Swyx [00:48:39]: Лоскутным

Касар [00:48:40]: покрытием. И если посмотреть на старый мир автономии в горнодобыче — задолго до трансформеров и нейронных сетей CNN-эпохи — это были hand-coded системы. «Эта машина едет туда вот с этим…»

Питер [00:49:03]: Это был наш GPS, очень точный GPS.

Касар [00:49:05]: Да. И это работало 20 лет — зачем нам трансформеры или современные end-to-end системы? В основном потому, что можно было только пройти заранее заданный путь туда-обратно. Это давало большую ценность, но не такую, как когда машина реально интеллектуальна — она видит, воспринимает, действует в динамическом мире.

Алессио [00:49:28]: Я загуглил RTK — real-time kinematic, точность 1–2 см.

Касар [00:49:32]: Да. Фантастика. И фантастика — в далёких краях, где не будет сотового покрытия.

Питер [00:49:39]: Да. RTK широко применяется в legacy-системах горнодобычи и сельского хозяйства. Например, комбайн, который может ехать вдоль поля с точностью 1–2 см — он использует RTK.

Касар [00:49:53]: Да.

Питер [00:49:53]: Но это дорого.

Касар [00:49:54]: Да. И это автономия, но не интеллект в том смысле, в каком…

Касар [00:49:58]: в 2026-м мы говорим об интеллекте.

Алессио [00:50:00]: В одном из ваших постов вы упоминаете исследования по large scale трансформерам, аналогичным современному generative AI. В чём, помимо «ты абсолютно прав, мне стоит вести машину, поэтому давай это уберём», ключевые отличия?

Питер [00:50:14]: У нас внутри диверсифицированная стратегия ставок, и причина — мы работаем в нескольких индустриях, нескольких географиях, и у каждого подхода — свои очевидные риски.

Питер [00:50:27]: Поэтому мы не кладём все яйца в одну корзину для какого-то одного подхода, который может не сработать.

Питер [00:50:36]: И на практике у этого есть плюсы и минусы. Исследовательская команда затем работает над сценариями, где подход хуже других, чтобы в конечном счёте прийти к реально отличному решению для всех этих вещей.

Plan mode для физических систем и универсальность next-token prediction

Алессио [00:50:57]: Есть ли plan mode для физической автономии — отдельный шаг планирования, потом действия?

Питер [00:51:03]: Короткий ответ — да. Так же, как вы можете использовать Claude Code, чтобы спланировать сложную задачу по кодированию, и получить почти спецификацию, аналогичные подходы применимы к физическим системам. Представьте, что вы пытаетесь выполнить какую-то задачу. Проще всего думать про robotaxi, но,

Питер [00:51:23]: думаю, всё становится интереснее, скажем, в оборонном контексте или горнодобыче. Там вам реально нужно продумывать много шагов вперёд.

Питер [00:51:32]: Это не одно действие — чтобы достичь цели, нужно сто шагов, и концепция plan mode очень применима в этих

Алессио [00:51:40]: Да. Я хотел сказать — вождение похоже на отличный кейс next-token prediction, потому что ты идёшь по маршруту, и неважно, что было до. Всегда можно развернуться.

Касар [00:51:49]: Это всё планирование. Да.

Алессио [00:51:50]: Да. А горнодобыча — «о, я взял ковш отсюда». Теперь мы не можем

Алессио [00:51:57]: я не могу туда вернуться. Есть огромная разница? Есть ли у вас таксономия этих разных типов? Есть вождение,

Алессио [00:52:07]: экскавация, полёт. Как вы…

Питер [00:52:11]: Интересное наблюдение: да, думаю, в принципе всё в мире можно свести к задаче next-token prediction.

Питер [00:52:18]: Любой workflow, любая последовательность шагов или траекторий — как ни назови — сводится к этому. В кейсе горнодобычи, представьте: «взял ковш — это был набор токенов, теперь модель понимает, что state space другой», и следующая токен-prediction будет модифицирована этим. Удивительная вещь в этих техниках — насколько они универсально применимы. Это правда невероятно.

Алессио [00:52:53]: Что ещё недооценено в том, что вы строите на физической стороне? Мы говорили перед эпизодом, что много humanoid-компаний делают отличные демо, но я не могу это купить — значит, всё не там. У вас же машины в production на реальных дорогах, у вас много клиентов. Что люди недооценивают? Демки Waymo семь лет назад были классные, и понадобилось семь лет, чтобы их вывести на улицы. Расскажете про последний 1%, который технически было особенно сложно сделать?

Продакшен: 20 проблем, на которые наткнётся любое robotics-демо

Питер [00:53:27]: Да. Продакшенизация чего угодно — большой вызов. Я бы поделил ответ на research и production. На стороне production — куча проблем, которые проявляются, когда вы выходите в реальный мир. Классическая проблема в гуманоидах сейчас — эти системы довольно хрупкие.

Питер [00:53:48]: Я не про какую-то одну компанию, а про индустрию — системы хрупкие. Интересно, на днях видел, что Китай проводит марафон с гуманоидами.

Касар [00:54:00]: Что?

Питер [00:54:00]: Да. Это в государстве — не конкретно Китай — концепция «prize policy». Есть разные способы влиять на индустрию: можно регулировать, делать мандаты или просто проводить такие соревнования. US-версия — DARPA Grand Challenge. Это

Алессио [00:54:20]: Сработало.

Питер [00:54:21]: Реально сработало. Это

Алессио [00:54:22]: Реально сработало.

Питер [00:54:22]: всю индустрию перенесло. Думаю, Китай буквально проводит этот марафон, потому что знает, что надёжность гуманоидов — проблема. Что может быть круче, чем соревнование, где гуманоиды должны пробежать 26 миль?

Алессио [00:54:37]: Мы уже дошли? Роботы могут пробежать марафон?

Питер [00:54:40]: Думаю, это вот-вот случится.

Питер [00:54:42]: Это

Алессио [00:54:43]: Так мы там.

Касар [00:54:43]: Кстати, в автопроме есть аналог — 24 Hours of Le Mans.

Касар [00:54:48]: Porsche выигрывает Le Mans

Алессио [00:54:51]: Новый продукт

Касар [00:54:51]: и буквально ставит эти продукты в production. Я бы разбил так — research, production и между ними advanced engineering. Большая часть индустрии переходит в advanced engineering: это не фундаментальные исследования с новыми техниками. Реально это advanced engineering для production. Какие подкомпоненты ограничат выход в production? Когда вы уже в production — другая группа проблем: развёртывание, обслуживание существующих машин. В нашей сфере мы в основном в advanced engineering в автомобильной терминологии.

Питер [00:55:29]: Честно, каждый шаг сложный.

Алессио [00:55:33]: Пол, вы стоите $15B, так что не отвечайте.

Касар [00:55:36]: Кровь на каждом шагу.

Касар [00:55:38]: Да. И

Питер [00:55:39]: Это весело. Не знаю. Мне реально нравится. Прикольно, что мы этим занимаемся уже почти 10 лет, видели столько плохих времён. Сейчас можем посмотреть на любую компанию в этом пространстве, увидеть демо — и я могу выписать список из следующих 20 проблем, на которые они наткнутся.

Питер [00:55:59]: И могу угадать, что они попытаются решить в каждой из них, и какая попытка реально сработает.

Касар [00:56:04]: Да. Не потому что мы гении.

Питер [00:56:07]: Мы это уже видели.

Касар [00:56:07]: Да. Достаточно насмотрелись. Пережили этого достаточно. Наши собственные ментальные модели мира как лидеров компании — мы перепробовали столько вещей, и многих… Мы говорим тут о победах.

Касар [00:56:21]: Тут

Питер [00:56:21]: Поражений тоже хватает.

Касар [00:56:21]: Хватает поражений, когда столько людей делают столько разных вещей, это въедается в

Касар [00:56:29]: ментальную модель мира.

Питер [00:56:30]: Да. В целом мы экзайтед по робототехнике, и

Питер [00:56:34]: тут

Касар [00:56:36]: Огромная возможность.

Питер [00:56:37]: Огромная возможность. То, что сейчас происходит в индустрии: ни одна из этих концепций не новая. Новое — что всё это реально начало работать.

Питер [00:56:46]: Люди хотели использовать нейросети в робототехнике давно, но теперь у нас есть датасеты, у нас есть симуляционные технологии, где вещи реально начинают работать. И мы хотим быть частью этого, мы

Питер [00:56:58]: будем частью этого без сомнений.

Алессио [00:57:00]: Есть ли requests for startups или, наоборот, советы не делать определённые стартапы? Много scale-up robotics-компаний. Что вы думаете?

Касар [00:57:10]: Куча applied intuitions для других вещей.

Касар [00:57:14]: Думаю, ты достигаешь какого-то значка в YC,

Питер [00:57:21]: X для Y

Касар [00:57:21]: или буквально похожие названия. Главный совет в этой коммерциализации технологий: часто это ограничение… Мы говорили про hardware-ограничения; есть и коммерческие ограничения — мы делаем только то, что укладывается в эту коробку. Это, думаю, очень хорошо для фаундеров. Но об этом часто не говорят, потому что у вас полно доступа к капиталу, а технические проблемы такие сложные, что вы как будто говорите: «у меня уже есть ограничение — решить эту техническую проблему». А venture community в массе своей не очень техническое. Им если вы говорите «если мы это решим, будет куча денег» — этого, типа, достаточно. Но вы как фаундер — я не даю советы, как питчить VC. Это сработает с VC. Вам всё равно нужно строить устойчивый бизнес. И мы реально про это — про вопрос «что неочевидно в нашей компании». Это truly compounding technology. Большая часть нашей работы compound'ится. Мы её не выбрасываем. Она улучшается. Работа по ОС улучшается. Dev tooling улучшается. Модели улучшаются. И мы реально получим огромный — это видно на примере Waymo. Waymo — очень интересная компания долгое время, но не стоящая $126 млрд. И вот, человеческий мозг просто эмоционально не понимает compound-эффектов. То же будет в нашей вселенной. Если вы фаундер, вы в начале этой долгой прогулки. Если вы добавите небольшое ограничение по коммерции, увеличите вероятность дойти до другого конца этой прогулки, потому что если вы дойдёте — получите большой возврат от compounding technology. Просто многие не доходят. Так что подумайте чуть-чуть об уравнении: как вы используете деньги и где используете ограниченные ресурсы и инженеров. Иногда фаундеры ошибочно берут стратегии очень зрелых компаний и применяют их к своим юным. Они говорят: «Стив Джобс сказал быть полностью вертикальным». Ну да, в 2007-м Apple очень отличался от Apple 1978-го и 1982-го. Те компании были другие — буквально брали электронику у других производителей и складывали в корпус. Будьте чуть более нюансными в коммерческом подходе, как он информирует ваш технический подход.

Советы фаундерам: ограничения, compounding-технологии и подражание зрелым компаниям

Алессио [01:00:03]: Чувствуете по-другому сегодня? Вы только что появились в X.

Алессио [01:00:06]: Вы строили компанию

Алессио [01:00:08]: в stealth, и сейчас «надо, наверное, рассказать, что делаю». Многие фаундеры идут схожим путём — хотят поднять много денег, чтобы сигнализировать силу, и не тратят их.

Касар [01:00:20]: И на найм. И на найм, да.

Алессио [01:00:21]: Это вы любите. Вы всё ещё думаете, что возможен очень узкий подход — «мы строим compounding-вещь без grand vision сразу»?

Касар [01:00:32]: Очень сложно отвечать на очень общие вопросы.

Алессио [01:00:35]: Ну

Касар [01:00:35]: Может, переформулирую: возможно ли построить продукт с маленьким problem space, надеясь, что problem space вырастет? Так, наверное, тот же вопрос, но отвечабельнее. Думаю, всегда да. Это старый YC: идти глубоко, а не широко и мелко.

Касар [01:01:00]: Широко и мелко — к сожалению, в hard-tech-компаниях слишком много проблем, и вы будете делать всё посредственно, и продукт получится посредственным. Так что я в лагере «находите маленький problem space». Другой вопрос — стоит ли строить в stealth и анонимно? Да, если вы YC COO,

Касар [01:01:28]: вы можете быть

Swyx [01:01:29]: О, Travis Kalanick.

Касар [01:01:29]: И мы, да, мы вместе работали в Google. Большая история, и не… Иначе говоря, у нас большие сети контактов. Первые 400 человек большинство были Googler'ами. Большинство пришло из этой гигантской компании, где мы работали. У других фаундеров такого нет. Им приходится делать другие вещи. Не берите мою версию мира или версию Jensen'а. Они в другом времени и пространстве.

Касар [01:02:02]: И, главное, их компании в другой фазе.

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

Касар [01:02:11]: Единственное реальное решение — first principle thinking: «исходя из моих навыков, навыков ко-фаундеров и ранних членов команды, и того, что я слышу от клиентов, какой product space мне стоит строить?»

Касар [01:02:26]: Понятно?

Swyx [01:02:27]: Да.

Алессио [01:02:27]: Да. Sam Altman сказал, что жалеет о многих советах, которые давал в YC.

Алессио [01:02:33]: Мне всегда интересно спросить фаундеров вроде вас, которые давно…

Касар [01:02:36]: Так я

Алессио [01:02:36]: Давным-давно

Касар [01:02:37]: Все, кто выходит из YC, делают наоборот.

Касар [01:02:41]: Sam был президентом, я был COO.

Касар [01:02:43]: У нас был CEO, мы работали вместе — сказать, что очень близко, — это ничего не сказать.

Касар [01:02:48]: Фирма была маленькой.

Алессио [01:02:50]: Угу.

Касар [01:02:50]: YC не был таким большим, как OpenAI. Я директионально соглашусь, но это больше функция рынка.

Касар [01:03:02]: изменился.

Касар [01:03:03]: Это другой мир. AI-индустрия, AI-компании, и как они относятся к другим YC-компаниям и рынку — фундаментально иные. Объёмы денег, число инвесторов, количество seed-фондов. Один из наших ранних инвесторов — Floodgate. Они делали анализ в конце 2000-х: «было односложное число фондов вроде Floodgate, которые выписывали первые чеки на сумму меньше $1M, и не были акселератором или incubator». Anne, одна из сооснователей вместе с Майком, говорила, что недавно — года 3–4 назад — пытались сделать тот же анализ и потеряли счёт

Касар [01:03:46]: на 350 фондах или около того. Мы в другой среде, и YC-совет 2014-го

Касар [01:03:55]: просто не сработает в 2026-м. Но Sam лучше меня умеет это формулировать.

Касар [01:04:00]: Он говорит короче, интереснее. Я могу только дать… Если спросите меня «какой смысл машины», я открою owner's manual и скажу:

Касар [01:04:13]: «Номер один: вот руль», вместо «она может изменить твою жизнь и будет рядом».

Алессио [01:04:21]: Да, она даёт автономию и свободу.

Касар [01:04:22]: Да, точно. Да.

Swyx [01:04:24]: И для Питера: есть ли какая-то конкретная техническая или исследовательская проблема, которую вы бы выделили как очень важную для вас, если бы её решили? Нерешённая, и если кто-то над этим работает — пусть свяжется.

Питер [01:04:40]: Да. В целом — делать модели очень эффективными. Поскольку мы должны работать на реальных машинах, физический AI — это буквально брать очень большой AI и делать его очень маленьким и очень эффективным. Мы постоянно на этой границе ограничений: «есть отличная модель, но нам нужно сделать её быстрее и меньше». В целом как поле. И ещё — те, кто реально страстен по поводу оценки этой технологии. Model evals — это огромная сложная тема, особенно в safety-critical системах. У нас отличная инженерная команда и исследователи, работающие над этим, но это большая зона инвестиций. Так что — те, кто страстен по поводу производительности (и в плане способностей, и в плане буквально латентности) и оценки моделей.

Философия найма: граница hardware/software и инженерный mindset

Алессио [01:05:41]: Круто. Конкретные инженерные роли, которые вы нанимаете? И главное — кто успешен в вашей компании как инженер? Это всегда самое важное.

Касар [01:05:50]: Да. fly.co/careers, там буквально сотни ролей. Смотрим всё, о чём говорили: от dev tooling и физического AI до операционных систем, автономии и AI в физических машинах. Типы инженеров — отличный вопрос, интереснее, чем

Касар [01:06:09]: роли, потому что мы большая компания, мы

Алессио [01:06:11]: Нанимаем всё.

Касар [01:06:12]: Всё, да. Мы нанимаем всё.

Касар [01:06:14]: Мы компания из Sunnyvale, и из нашего разговора и бэкграундов можно немного предсказать, что это значит. Мы обычно нанимаем достаточно серьёзных людей, которые понимают low-level системы — не на поверхностном уровне, инженеры-инженеры почти. Нанимаем и людей с разнообразными скиллами. Нанимаем массу специалистов тоже, чтобы было понятно, но они видели production, и это очень информирует подход к созданию технологии.

Питер [01:06:53]: Да. Люди, которые реально ценят границу hardware/software.

Касар [01:06:56]: Да, точно.

Питер [01:06:56]: В эпоху vibe coding есть группа инженеров, которые вообще не думают о железе.

Питер [01:07:05]: У нас такой роскоши нет. Поэтому ищем людей, которые более страстно идут чуть глубже.

Касар [01:07:09]: Если контрастировать нас с AI-лабом — самый большой контраст в том, что мы имеем дело с реальностью. Что ещё? Все классические вещи. Хочется людей, которые работают усердно, любят технологию и

Касар [01:07:30]: Если вы досидели до этой части подкаста,

Касар [01:07:33]: то вы, наверное, квалифицированы или интересуетесь этим.

Swyx [01:07:37]: Да. И Питер сказал, что ему тоже нравится подкаст, что

Swyx [01:07:42]: реально круто.

Касар [01:07:43]: Я фанат. Да.

Swyx [01:07:44]: Да. Конкретно про границу hardware/software — я часто думаю об образовании, в США в частности и в целом. Есть отступление от классического CS или EE-образования.

Касар [01:07:59]: Computer engineering или Да.

Swyx [01:08:01]: И — есть ли точка, где надо просто делать самим? Сейчас вы в этом мировые эксперты, и не должны ждать, пока какая-то система образования вам их выдаст.

Питер [01:08:11]: В смысле образования и upskill?

Swyx [01:08:14]: Да. Брать молодых

Касар [01:08:16]: General Motors это уже сделал.

Swyx [01:08:17]: Умных детей.

Питер [01:08:19]: GMI.

Касар [01:08:19]: Буквально.

Swyx [01:08:19]: Есть Harvard University?

Касар [01:08:21]: Да, я там учился на бакалавриате. Учился в General Motors Institute.

Swyx [01:08:25]: Это, кажется, не всплывало. Я видел HBS.

Swyx [01:08:27]: Я не…

Касар [01:08:27]: Все видят HBS.

Касар [01:08:31]: Бренд Harvard сильный.

Swyx [01:08:34]: А что такое General Motors Institute?

Касар [01:08:36]: Он был основан 100 лет назад ровно для того, чтобы ответить на твой вопрос —

Касар [01:08:40]: «недостаточно инженеров в Мичигане». Ранние дни современной корпорации,

Касар [01:08:45]: General Motors. Есть отличная книга — My Years with General Motors Альфреда П. Слоуна — крайне рекомендую, по сути, про то, что становится современной корпорацией. И часть этого: «у нас не хватает инженеров». Поэтому открыли школу. Даже Google всего лет 10 назад думал о запуске университета. Так что да — мы определённо upskill-им людей. Объём обучения у нас на самом деле удивляет. Да. Но это роскошь, когда вы нашего размера.

Институт General Motors, образование и mindset любопытства

Касар [01:09:20]: Когда у тебя 25 инженеров,

Swyx [01:09:22]: Нет.

Касар [01:09:22]: тебе нужно просто выжить. Опять же, берите советы, которые актуальны вашей компании, а не сразу пытайтесь брать старшеклассников

Касар [01:09:29]: и делать из них инженеров.

Swyx [01:09:30]: Но я доходил до класса, который ты вёл, потому что, кажется, можно многому научить.

Питер [01:09:36]: Да. Честно, один из самых удивительных кейсов больших моделей сейчас — образование.

Питер [01:09:42]: У нас есть инженер с бэкграундом в aerospace engineering, очень хороший инженер, и за относительно короткое время он уверенно делает front-end, уверенно делает back-end — с помощью этих моделей.

Питер [01:09:57]: Можно не только имплементить с ними, можно и учиться. Задаёшь вопросы и не стесняешься, потому что модель

Питер [01:10:04]: не будет тебя стыдить.

Касар [01:10:07]: Да. Думаю, нужнее, чем инженерная степень… хотя инженерные степени очень важны — я не знаю, как срезать путь через fluid dynamics или heat transfer.

Питер [01:10:17]: Фундаменталка.

Касар [01:10:17]: Фундаменталка, по крайней мере на mechanical-стороне. Нужен инженерный mindset, и не у всех он есть. Кого-то эмоционально тянет к искусствам или чему-то ещё, и это окей, никакого осуждения. Но инженерный mindset, может, в более практичном виде — это желание понять более низкий уровень, ещё более низкий уровень: как двигаются фотоны?

Питер [01:10:42]: И экстремальное любопытство.

Касар [01:10:44]: Экстремальное любопытство. Что такое свет? Что такое радиоволна? Реально фундаментальные вопросы.

Питер [01:10:49]: И если вы достаточно увлеклись софтом, в конце концов придёте к железу.

Питер [01:10:55]: И

Swyx [01:10:56]: Это цитата Алана Кея. Да.

Касар [01:10:57]: Да, точно.

Swyx [01:10:58]: Так что, пытаюсь делать аналогии — вы вроде смеси New General Motors и Tesla autonomy division для всех остальных.

Касар [01:11:07]: Мы делаем работу во всех этих других полях. Если поговорите с нашими trucking-клиентами, они даже не воспримут так, мол: «вы делали что-то автомобильное, но вы реально помогаете нам». Так что

Swyx [01:11:18]: Автомобильное — это не trucking?

Касар [01:11:19]: Нет. Это

Swyx [01:11:20]: Это, типа, целая

Касар [01:11:21]: Это отдельно. Разные проблемы. Масса… И у вас есть общие категории on-road и off-road — это, наверное, то, о чём ты думаешь. Внутри on-road есть подклассы

Swyx [01:11:33]: О, окей.

Касар [01:11:33]: машин. Особенно — посмотрите на delivery robot без человека внутри. Это совсем другое, потому что вас не волнует ощущение, которое у вас

Касар [01:11:45]: возникает в self-driving системе. Это можно не учитывать. Можно

Swyx [01:11:48]: Просто тормозить.

Касар [01:11:48]: Можно тормозить жёстко.

Касар [01:11:50]: И не волноваться о рывках и всех этих метриках, они становятся…

Питер [01:11:53]: Если думать честно, любая система, для управления которой человеку нужно специальное обучение, рассматривается чуть иначе. Например, лицензия на грузовик отличается от лицензии на машину,

Питер [01:12:04]: которая отличается от лицензии пилота. Отличается от… ну, поняли идею.

Swyx [01:12:08]: Круто, ребята. Спасибо, что нашли время.

Касар [01:12:10]: Да, спасибо, что позвали.

Питер [01:12:11]: Спасибо, что позвали.

Питер [01:12:11]: Спасибо. [аутро-музыка]

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